Wednesday Feb 10, 2016

Java EE in Practice for Secure Online Voting at Scytl

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through our adoption stories blog, this humble blog as well as JavaOne. Indeed JavaOne 2016 was particularly good in this regard. We had a number of solid adoption stories submitted that we could select from. We will highlight all of those stories here in the coming months. A particularly nice adoption story presented at JavaOne 2016 was from Scytl. The session was presented by Alex Soto.

Scytl is a very innovative and important company that enables secure online voting across the world. Alex was the architect of a service-only back end system at Scytl written using vanilla Java EE and TomEE. Alex talked about the reasons they chose Java EE (over Spring in this case) such as ease-of-use, productivity, simplicity, standardization, lack of third-party dependencies, simple deployment, fast startup and performance. He also discussed their use of some pretty cool TomEE features, Arquillian, Docker and Apache Mesos. For those unaware, Alex is a Java EE advocate, blogger, author, JCP expert and open source commiter. You can view Alex's well-rated session below (click here if you are having trouble seeing the embedded video).

If you have a similarly great Java EE adoption story to share with the community (particularly migration stories from other technologies), please do feel encouraged to reach out. In the spirit of Java EE centric vendor neutrality, what Java EE implementation or tool set you choose does not matter at all and neither does which part of the globe you are in.

Tuesday Feb 09, 2016

Cargo Tracker Java EE 7 Blue Prints Now Running on WebLogic

For those unaware the Cargo Tracker project exists to serve as a blue print for developing decently designed Java EE 7 applications, principally utilizing Domain-Driven Design (DDD). The project has long run on GlassFish 4 and Java SE 7. The project was recently enhanced to run the same code base also on WebLogic 12.2.1 and Java SE 8. The instructions for running the project on WebLogic are available here. Feel free to give it a spin to get a feel for both Java EE 7 and WebLogic 12.2.1.

The fact that a fairly non-trivial project like Cargo Tracker can run on both GlassFish and WebLogic with no code changes and some very minimal configuration differences handled via Maven profiles speaks to how much Java EE portability is a reality with Java EE 7. Some initial work has also been done to run the project on WildFly - hopefully we will be able to highlight that work here soon as well.

Monday Feb 08, 2016

Revamping the Security API in Java EE 8

JAAS, JASPIC, JACC. If those acronyms do not sound familiar, you are in good company. I have been developing with Java EE for almost two decades and I was not terribly familiar with them until I seriously started thinking about revamping Java EE security in the early Java EE 7 time frame. Those are the three main Java EE related standard APIs that have remained largely unchanged since the J2EE era. That is until the Java EE Security API aimed for Java EE 8.

The reason I mostly didn't need to know about these APIs is because of the way Java EE security has evolved over the years. As of Java EE 7 the way applications work is that you do some minimal web.xml configuration declaring what type of authentication you want (basic, form, digest, etc), what application server "realm" (logical link name to application server security configuration) and what roles (security groups) have access to secure parts of the application. Most of the real work is typically actually done in application server admin GUI wizards like configuring what identity store you want to use (database, LDAP, etc) and how underlying groups map to roles (for most of my applications the application roles and identity store groups are exactly the same). There are certainly some benefits to this approach that most other technologies do not have. Most of the heavy lifting for security is just a few mouse clicks as opposed to writing and maintaining code. You can hand off the work of securing the application to an admin where this work often best belongs. Application servers have sophisticated security admin tooling that seems to have everything under the Sun including things like federated security through SAML.

This is not the approach more feature poor runtimes that lack admin GUIs take and the approach also has some downsides. The most significant downside is that beyond learning Java EE APIs as a developer you also need to know about each application server's security administration features. This also means that these features are slightly different from one application server to another, limiting application portability. In a PaaS environment it is a lot easier if all security configuration is done inside the application itself, making the application more self-contained. The last problem is related to the age and focus of the current APIs used in Java EE - JAAS, JASPIC, JACC. These APIs have not gone through a significant revision in a while and their focus is on vendor plug-in writers, not application developers. This becomes a problem when developers need to do things that the application server does not have built-in support for such as using a custom data store (say using a security database with a poorly designed legacy schema) or using a custom authentication mechanism (say your own homegrown HTTP headers for federated security). There are third party frameworks in the Java EE ecosystem such as Shiro and PicketLink that attempt to solve these issues - in particular making application security embedded. These frameworks are of course non-standard and increase the need to add more runtime dependencies in the application.

The new Java EE Security API slated for Java EE 8 aims to solve these problems by simplifying and modernizing security in the platform. The Security API will make it possible to embed security in most common cases in the application in the simplest way possible. It will allow for easy extensibility by providing a much simpler, modernized, developer-focused alternative to JASPIC, JAAS and JACC. In the process it will introduce simple standard terms and interfaces for Java EE security. It will also add some cool new authorization mechanisms in addition to the basic role based security that Java EE offers today.

Specification lead Alex Kosowski described all of this well during his JavaOne 2015 talk embedded below (click here if you can't see the embedded video).

The Java EE Security API is one of the most important and perhaps most awaited parts of Java EE 8. It is not very surprising that it is one of the Java EE 8 JSRs that has seen the most active participation from the community - Alex refers to some of this participation in his talk. You should feel encouraged to participate yourself perhaps starting by viewing the video above.

Friday Feb 05, 2016

Some Interesting Real World CDI Usage Statistics

The good folks over at Genuitec developing MyEclipse recently asked the Twittersphere about real world CDI usage. They ran a week-long Twitter survey asking the simple question - "Do you use CDI in your Java EE applications?". The results of the survey were pretty interesting and certainly worth sharing. As the graph below shows 60% responded they use CDI. 21% responded that they did not. 19% did not know what CDI was.

Here is a link to the actual survey on the MyEclipse twitter account. For those unaware the MyEclipse team is working hard to bridge the CDI and Java EE support gaps in Eclipse - hence the question.

It is definitely very good that a clear majority said they were using CDI. CDI is key to writing effective Java EE applications. This data point goes a long way to removing the severe CDI skepticism in certain corners of the Java EE ecosystem. The 19% that responded that they did not know what CDI was pose both a challenge and an opportunity. If you are a Java EE or CDI fan it should tell you that there are colleagues that you should educate on CDI. I am often still taken aback when a developer does not know what CDI is or still refers to Java EE as "J2EE" (the term J2EE has been long retired with the likes of "J2SE" and COM/DCOM). A large number of these same developers are very pleasantly surprised to learn how much modern Java EE can help make their day-to-day work easier.

No survey is perfect of course. The sample data size for the survey is small but respectable at around 300. Around 500-1000 data points is probably more representative of the Java ecosystem. Since it is a Twitter survey it is probably highly susceptible to selection bias. That being said the results are definitely good enough to think about seriously.

Wednesday Feb 03, 2016

Migrating from Java EE 5 to Java EE 7 at Segurnet Portugal

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through our adoption stories blog, this humble blog as well as JavaOne. Indeed JavaOne 2015 was particularly good in this regard. We had a number of solid adoption stories submitted that we could select from. We will highlight all of those stories here in the coming months. A particularly nice adoption story presented at JavaOne 2016 was from Segurnet Portugal on migrating from Java EE 5 to Java EE 7.

Segurnet is a data sharing platform for key insurers in Portugal. It used by 65 companies, about 30,000 users with close to 1.5 million page views and over 3 million server requests. Roberto Cortez detailed how the platform was recently migrated from legacy Java EE 5 to Java EE 7 - showing specific code examples. As the end result of the migration Roberto noted latest technology adoption, improved standardization, simplicity, a net reduction in code, an increase in productivity, faster deployment times and better performance. Roberto's experience is typical for anyone considering such a migration. You can view the session below (click here if you are having trouble seeing the embedded video).

The slide deck for the talk is available on SlideShare. For those unaware, Roberto is a passionate Java EE advocate, frequent speaker, blogger and JUG leader. He now works on the TomEE Java EE application server.

If you have a similarly great Java EE adoption story to share with the community (particularly migration stories from other technologies), please do feel encouraged to reach out. In the spirit of Java EE centric vendor neutrality, what Java EE implementation or tool set you choose does not matter at all and neither does which part of the globe you are in.

Monday Feb 01, 2016

HTTP/2 and Servlet 4 in Java EE 8

HTTP is very easily the most important standard in server-side Java. The much awaited HTTP/2 standard is now complete, was fifteen years in the making and promises to radically speed up the entire web through a series of fundamental protocol optimizations. Slated to be a part of Java EE 8, Servlet 4 is the primary vehicle for making HTTP/2 available to the server-side Java ecosystem. In a key JavaOne 2016 session Servlet 4 specification leads Ed Burns and Shing wai Chan discussed Servlet 4 in detail. You can view the video below on the JavaOne 2016 YouTube playlist (click here if you can't see the embedded video). The slide deck for the talk is available here.

In the session they took a detailed look at the changes in HTTP/2 and discussed how these changes will be adopted by the Servlet 4 specification as well as technologies like JSF.

Friday Jan 29, 2016

EJB3 @Lock Annotation for CDI Beans

The EJB 3 @Lock annotation is pretty unique, interesting and useful. It provides an elegant declarative way of controlling concurrency for beans that can be shared across multiple threads such as singletons. As of Java EE 7 the annotation is only available to EJB 3 @Singleton session beans. There is a lot of value to making this bean available to all CDI beans in general. Very recently Stephan Knitelius did exactly that through a pretty simple CDI interceptor. You can read his nice write-up here.

In the longer term this work probably belongs somewhere in the standard such as in an update of the Java EE Concurrency specification or a modular CDI 2 specification. Another good place for Stephen's work is the DeltaSpike project. There are many other cool EJB 3 features that could be similarly made available to CDI beans generally such as @Startup, @Asynchronous and @MaxConcurrency. Some of these issues have long been discussed in the EJB specification JIRA entries.

Wednesday Jan 27, 2016

Java EE @ Oredev

Oredev 2015 was held on 3-6 November in Malmo Sweden. This was my third time at the largest IT conference in the Scania region. The conference is rooted in .NET and development process/methodology but has been trying hard to beef up it's Java content. This year it attracted a decent section of the Java crowd including my fellow Oracle colleagues Bruno Borges and Stephen Chin. Topics covered included .NET, Java SE, Java EE, mobile, methodology, agile, HTML5, JavaScript and NoSQL.

I did talks on Java EE 8 and aligning Java EE with the reactive movement. More details, including slide decks and session videos, posted on my personal blog.

Monday Jan 25, 2016

Migrating from Tomcat to Java EE and TomEE at Dassault Systemes

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through our adoption stories blog, this humble blog as well as JavaOne. Indeed JavaOne 2016 was particularly good in this regard. We had a number of solid adoption stories submitted that we could select from. We will highlight all of those stories here in the coming months. A particularly nice adoption story presented at JavaOne 2016 was from Dassault Systemes.

Although the average developer and consumer is probably not aware of Dassault Systemes, it is a company that powers many of the world's most critical industrial processes. It is one of the global leaders in 3D modelling (think CAD/CAM), product life-cycle management systems. Just some companies that rely on Dassault Systemes include the likes of Boeing, Toyota, BMW, Mercedes, Honda, Samsung, Coca Cola, Nokia, Nikon, Panasonic, LG, Procter & Gamble, GE, Johnson & Johnson and Exxon. French based Dassault Systemes is recognized to be one of the most innovative companies in the world. The company offers it's products both on-premise and as SaaS on their own cloud.

The company chose to standardize their very diverse set of products geared towards various industry verticals on Java EE and TomEE. They cited reasons like ensuring consistency throughout a large number of systems, avoiding third-party jar/configuration/class-path hell, providing a fully supported uniform stack, portability and modernizing technology in a managed, sustainable fashion. Their migration experience was quite varied and represents the gamut of what others can expect in adopting Java EE. They migrated a large number of Tomcat based applications using various third-party libraries to Java EE. They also migrated over legacy C/C++ applications as well as legacy J2EE applications. They even ported from one Java EE application server to another to get to a common base with TomEE. TomEE was cited as a particularly easy way to migrating from Tomcat to Java EE. They are looking forward to TomEE moving ahead with Java EE 7 support. The session explains their entire migration story in a concise, clear fashion. You can view the session below (click here if you are having trouble seeing the embedded video).

If you have a similarly great Java EE adoption story to share with the community (particularly migration stories from other technologies), please do feel encouraged to reach out. In the spirit of Java EE centric vendor neutrality, what Java EE implementation or tool set you choose does not matter at all and neither does which part of the globe you are in.

Thursday Jan 21, 2016

AngularBeans: Java EE 7/CDI Integration with AngularJS

In the highly volatile world of JavaScript frameworks, AngularJS has managed to maintain a lead at least for now. The good news for Java EE developers is that Java EE generally and Java EE 7 in particular works extremely well as a back-end for frameworks like AngularJS. To see why this is you need not look much farther than my talk on the topic and the corresponding example code (the code is deliberately self-contained with setup instructions so that you can explore it in detail on your own).

One of the drawbacks of the JavaScript rich client approach is that it often involves some boilerplate code that does not exist in server-side web frameworks due to the remote communication layer involved. To borrow concepts from the old J2EE design patterns, this boilerplate involves the creation and maintenance of DTOs (Data Transfer Objects) and remote proxies, not to mention the plumbing code necessary for the remote communication.  If you look carefully at my code example the boilerplate is not that hard to spot.

One way of avoiding this boilerplate is a tight binding layer with the underlying back-end technology that automatically generates the DTO, remote proxy and remote plumbing parts. In the process the binding layer can bring a lot of interesting back-end features forward to the client as well.

Fortunately for the Java EE ecosystem, my Tunisian friend Bessem Hmidi has formulated just such a solution focusing on CDI as the back-end component model. He has aptly named his project AngularBeans and the project is now on GitHub for everyone to use. I am very happy that we were able to host Bessem at JavaOne 2015 to talk about the project. In his session he explained the basic motivation for AngularBeans, discussed the features he has implemented so far and did quite a bit of live coding in the process! You can view the session below (click here if you can't see the embedded video).

The session really speaks volumes as to the power of the solution and why it is a very valuable part of the CDI/Java EE ecosystem. The project is at a very early stage, so this is a great time to get involved, evaluate the project and perhaps even contribute.

Thursday Jan 14, 2016

Java EE @ Java Day Mexico

Java2Days 2015 was held on November 2-4 in Sofia, Bulgaria. It is far and away the largest Java conference in the Balkans region and now perhaps one of the most important conferences in Europe as a whole. This was another great year for this rapidly growing, vibrant event. It attracted a host of international and local speakers including Patrick Curran, Geertjan Wielenga, Ivan St. Ivanov, Vladimir Pavlov and Andrew Lombardi. Topics included Java SE, Java EE, HTML5/JavaScript, mobile, and the cloud.

I did talks on real world microservices with Java EE and aligning Java EE with the reactive movement. I also ran a lab on JMS 2. More details, including slide decks, session video and code, posted on my personal blog.

Wednesday Jan 13, 2016

Hypermedia/HATEOAS Support in JAX-RS 2/Java EE 7

The concepts of Hypermedia and HATEOAS (shorthand for the mouthful of "Hypermedia as the Engine of Application State") have made the rounds in the REST ecosystem for a little while now. If you Google around a bit you'll find no shortage of arcane academic-sounding text describing it's supposed universal virtues. For the rest of us a simple explanation is that it is an attempt to utilize web page style links in REST based web services. Using the hypermedia concept, you can send the client links for what they may be able to do further after receiving a REST response. A simple example is including links for canceling or getting details for an order in addition to a confirmed order object probably retrieved via a GET request. Although less common, links can also be embedded as data within the response. An example would be embedding a link to retrieve the delivery address in the order data body instead of embedding the actual address body or an address ID. Finding a reasonably down-to-earth, unpretentious explanation of Hypermedia was shockingly difficult. The best I could find is the humble documentation for the PayPal Payment REST API that makes real world use of Hypermedia.

In practical terms Hypermedia helps make clients more flexible by avoiding hard-coding REST URLs. It can also help in self-documenting REST APIs. If you look around on the web it is an open question whether these purported benefits are actually worth the additional implementation complexity. Hypermedia may be best applied in a situation when you are developing a public API where you do not know much about potential users of the API. The PayPal Payment REST API is a good example of such a case.

The good news is that if you have a good use case for Hypermedia Java EE 7 adds support for it via JAX-RS 2. Sam Sepassi recently did an excellent write-up detailing the newly added API. It is far and away the best write-up that exists on the topic. He includes a brief explanation of Hypermedia including example code using JAX-RS 2. He also included some details on experimental work that is being done in the Jersey JAX-RS RI to include support for declarative Hypermedia (the Hypermedia APIs added in JAX-RS 2 are basically programmatic).

Enjoy and feel free to share with anyone that you might think would find this useful.

Monday Jan 11, 2016

Java EE in Practice at Lufthansa Industry Solutions

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. We have been doing just that for a long time through our adoption stories blog, this humble blog as well as JavaOne. Indeed JavaOne 2016 was particularly good in this regard. We had a number of solid adoption stories submitted that we could select from. We will highlight all of those stories here in the coming months. A nice JavaOne 2016 session to start with is the one from Lufthansa industry solutions.

Lufthansa industry solutions develops systems both internally at Lufthansa as well as for external customers. They chose to standardize on Java EE to ensure consistency throughout a large number of systems. The session explains what the organization does, it's architectural approach and why they chose Java EE. The session also dives into some interesting details on two different Java EE applications (one still using Java EE 6 and one already on Java EE 7) that Lufthansa industry solutions developed for clients. The session touches upon how Java EE applications can take advantage of most of the practical benefits of microservices without the added complexity. The applications use a mix of WildFly and JBoss EAP along with other JBoss ecosystem projects like Hibernate Envers, Hibernate Search, Drools. The applications also used ICEfaces and PrimeFaces (the older Java EE 6 application used ICEfaces while the newer Java EE 7 application uses PrimeFaces). You can view the session below (click here if you are having trouble seeing the embedded video).

If you have a similarly great Java EE adoption story to share with the community (particularly migration stories from other technologies), please do feel encouraged to reach out. In the spirit of Java EE centric vendor neutrality, what Java EE implementation or tool set you choose does not matter at all and neither does which part of the globe you are in.

Friday Jan 08, 2016

Meet SnoopEE, a Discovery Service for Java EE

SnoopEE is a very interesting grass roots open source Java EE ecosystem project. Akin to NetFlixOSS Eureka it enables microservices discovery, lookup and registration. SnoopEE is developed by Java EE advocate, JCP expert, speaker and blogger Ivar Grimstad. Ivar presented on SnoopEE at JavaOne 2016. One very nice aspect of Ivar's talk is that it actually discusses the basic motivation for service discovery and SnoopEE instead of simply covering the features of the project. You can see his well done session below (click here if you can't see the embedded video).

The slide deck for his talk can be found here. The project itself is on GitHub. SnoopEE is still pretty nascent and under active development. You should consider giving it a try, using it and contributing back to it.

Tuesday Jan 05, 2016

Java EE @ Java Day Mexico

Java Day Mexico 2015 was held on August 29 in historic Guadalajara. I was truly honored to be invited to speak here and this is a very fitting first trip report of the year. Java Day Mexico is the largest Java developer conference in Mexico and it is led primarily by Mexican JUGs. This was another highly successful year for the growing conference. Speakers included Venkat Subramaniam, Pratik Patel, Bruno Borges and Heather VanCura. Topics included Java SE, Java EE, HTML5, JavaScript, architecture, JVM languages, mobile and the cloud.

I had five talks total, essentially back-to-back. I did talks on Java EE 7, Java EE 8, real world microservices with Java EE, aligning Java EE with JavaScript/HTML5 rich clients and open standards. More details, including slide decks and code, posted on my personal blog.