Beyond web logs

With Java EE 6 just around the corner, many developers are beginning to wonder just what the new enterprise Java will offer them as a compelling reason to upgrade. Even more important is the question of what new tools will make Java EE 6 applications easier to write and manage. With much of the Java EE 6 update including fixes, updates and reworking of old standards, however, it would seem that much of Java EE 6 will not see new tooling for quite some time.
The Eclipse Foundation, for example, is not planning to push any new tooling for Java EE 6 into its summer Galileo release train. That might be just as well, as the only new specifications in the Java EE 6 stack are JAX-RS and Web Beans. Both of these specifications are basically new takes on old ideas: JAX-RS offering support for RESTful Web services, and Web Beans being a Web-focused version of Java beans.
But that's not to say that there aren't new ideas in Java tooling. Mike Rozlog, senior director of products for developer tools at Embarcadero Systems, said that his team is already researching methods of supporting JAX-RS.
“From a development standpoint, is there a big difference between JAX-WS and JAX-RS?” he asked. “One of the areas that we've been looking at is what would it take to be able to migrate from one to another. I have a service, now I want to make it a RESTful service. It's something we've been researching.”
That's the sort of tooling that Rozlog expects Java EE 6 to foster, though his team at Embarcadero has yet to begin work on such a tool within the Eclipse-based JBuilder.
Java six ways from Sunday
Java EE 6 isn't all REST and Web Beans, however. There are meaningful changes to the underlying structure of the Java EE stack. Chief among them is the introduction of profiles, slimmer, trimmer stacks of Java EE software that aim to address the common accusation that Java EE has become bloated and overburdened.
Roberto Chinnici, senior engineer at Sun Microsystems, said that profiles will start out small, but they will be joined over time by additional versions. “We are now enabling profiles: bundles of technology taken from the ones the full platform contains," he said.
"The idea is that the profile gives a better way to drive the needs of a particular class of developers. The first profile is a Web profile, and it is targeted at Web application developers. It goes from presentation technology like JSF to the core Web API, which is a servlet API. [It] also [has] business logic APIs, like EJB lite and a persistence API.”
Profiles came in response to years of criticism over how bloated the Java EE environment has become, Chinnici said. “We've been hearing that feedback for many years. We were faced with a real dilemma in that we knew that we needed to keep evolving the technology and keep it fresh, so we have to add new APIs once in a while.
"At the same time, there were a lot of APIs in Java EE that people don't use on a daily basis. Definitely profiles were meant to give us the opportunity to focus on the most used, more powerful features in EE, and [to] be able to shed some of the APIs [that] are outdated right now.”
When asked about how profiles would effect tooling, Chinnici said that the IDE vendors have not yet answered this question. “At this point, no products yet have implemented it.
"There are a couple ways you could do it. On one hand, it's possible to have entirely new products [that] are Web profile-based, but maybe come from vendors who don't have an application server. You also have the case of a vendor that has a full application server product, and then they could give you the option at install time to install a smaller footprint Web profile. A lot of technology in the full platform can be added on to the Web profile platform. A vendor could give you a checklist of what you want to install. You get a lot more freedom in the way your users install the product.”
Beans everywhere
Another area where Chinnici expects developers to appreciate Java EE 6 is around the use of the various types of beans. “I think the feedback we got on EJB 3 [Enterprise JavaBeans], when people actually got their hands on it and wrote programs with it, was very positive," he said.
"I think there were areas where EJB 3 didn't do 100% of the work, and 3.1 is adding that. Some people have a single EJB component, which is unique across an entire server. It can be done to manage some data you want to share, or to put initialization code for the whole application, or to have a centralized point to communicate with. It's a common design pattern people use in the Java language. There was no way to express that in EJB 3. Now it's been added in EJB 3.1."
Another important change to EJB 3.1 is the ability to perform an “asynchronous invocation of business methods on an EJB," said Chinnici.
"People were using workarounds until EJB 3. That required a certain amount of code. In EJB 3.1, we added the concept of asynchronous method invocation. You can now do it without a lot of support classes."
But the beans don't stop evolving there, he said. “I think that an area where there has been a lot of work is the whole dependency injection and context area.
"There is the Web Beans JSR, which is doing exactly that: adding context management and dependency injection. There are coordination issues. That's something where we're spending a lot of time on right now. It's fairly complicated. There's a long history of doing dependency injection in the platform. Adding another layer has to be done very carefully. OSGi does it but at a fairly low level with different goals in mind. They have dependency injection more in the sense of the service framework, where it was originally meant for embedded systems.
“The other thing we are doing in the servlets package is to add a plugability API. Effectively, you can now drop a library JAR file in your application and have that library automatically register a set of endpoints with the container, so you can physically use a Web framework without having to do any manual configuration, because the framework will just register itself. You can use this with scripting languages. Your scripting engine can be packaged as a JAR, and using rails becomes as easy as dropping this JAR in your application. This lowers the barrier of entry to scripting languages in your application.”
Persistence everywhere
Terracotta is using the move to Java EE 6 to bring persistence down to a manageable level. Ari Zilka, CTO of Terracotta, said that the updates to JPA in Java EE 6 will help to simplify the process of persisting information, whether it's on disk or in memory. He said that there are three basic ways applications use databases: read-only, lazy read-write and conversational read-write.
“Basically, persistence in EE 6 is going to allow you to make it easier to say, 'I use one interface for all three types of data, but I get to decide in configuration that the read-write is in an Oracle database, read-only is in MySQL, and in-memory is in a clustered grid solution,' ” said Zilka.
He added that the Java Persistence API has become more important as it has matured, and that the modifications in Java EE 6 will be welcomed by many developers.
“I see a lot of vendors moving to JPA-style persistence for in-memory persistence and in-memory data grids. They're using Eclipse-link TopLink, or OpenJPA. You can have all these different providers, or the in-memory database guys have said you can have JPA-style persistence as well," he said.
He also said that RESTful Web services will make scalability more accessible for developers.
“We have figured out we like [RESTful services] a lot," said Zilka. "We have a customer in the travel industry doing hundreds of thousands of transactions a second based on us using RESTful Web services. I think the interfaces are getting to be very clean. Terracotta will have RESTful caching for applications, sort of like Memcached across the wire from your application that you can do gets and posts to. We'll bundle up our APIs as RESTful services over the next year. A RESTful approach leads to a lot of benefits."
Indeed, Embarcadero's Rozlog sees Web services as a killer app for IDEs. “For me, Web services and RESTful Web services are the perfect IDE thing because there is so much canned code that goes in it,” he said.
“Why would I want to rewrite that all the time? That's the perfect job for an IDE to say, 'Don't worry, I'll take care of that canned code for you.' It removes all that drudgery. It's not hard code to write, it's just time consuming. It's brain-dead work. You do templates and starters and all kinds of different things, but still it's just repetitive code.
"What could we do? We already have the ability to generate Web services. I'm thinking in the future we'll be able to generate RESTful Web services. I should be able to right mouse-click on any service and set a property, and say it's either RESTful or not, and the IDE should take care of the rest of that for us. That's what we've been researching.”

Source