By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Read Part 1
The critics of the Java EE 5 platform say it has added complexity rather than reducing it. What facets inside the platform reduce complexity and which ones are still too complex?
There have been significant improvements around EJBs, with EJB 3.0 and annotations that simplify the complexity. The tooling with NetBeans makes it easy to build components. NetBeans provides a variety of different project types and wizards that allow you to say, "I want to create this type of components," and the tooling does the majority of the work for you in building the templates by using annotations to simply write your code or business logic rather than having to know a lot of the details about the specification. The tooling aids in building servlets and building JSP, and building Web applications. What specifically does annotations do for Web services development
Annotations allow you to specify in your source file various types of metadata that is necessary for building the application. In the past, the user would have to know more specifically and work with descriptors to define metadata for a fully working application. Annotations allow you to, in a declarative way, specify this metadata in your source file, so you don't need to worry about all of those specifics. The annotations provide keywords and constructs for you to define that information in a very clear way and then our tooling will help automatically create those annotations for you. So again, the developer doesn't have to know what all the annotations are that have to be put in. We provide them, but they also can be modify them as needed. But out of the box the annotations and the tooling simplify that experience for the developer. Do you see value in Ruby and Spring in service-oriented design and development?
There are many folks who see value in them, so there certainly is value because developers are using them. They provide a different approach that many folks see as being lighter weight. So there is value and there is benefit. We think Java EE still has a very significant role and can work well beside these other languages where they are used. The portability enabled by the virtual machine in Java EE 5 has been called a dinosaur by some analysts who say it has little to do with the interface-centric world of SOA, which doesn't have to be portable. Do you see portability getting de-emphasized in future revs of the platform or do you think it will remain an important concept in a more loosely coupled IT infrastructure?
I think portability is important. It's the foundation of the specification. Portability allows you to have multiple vendors implementing the spec, giving customer choice through competition, allows innovation and creates better products for the entire community and customer base. Portability in adherence to standards is something that is important and is the foundation of Java EE. What is the critical different between enterprise class SOA and traditional Web application design and how does Java EE 5 support those differences?
When you talk about enterprises there are many factors that come into play that Java EE 5 provides for just by the nature of having the container and the transactions around pooling resources. Traditionally, enterprise class requires security, manageability, management of the services and resources. Those are things that are important to the enterprise and are features Java EE 5 provide for. Is the Java EE 5 approach to Web services too API-centric?
The services that you build with Java EE 5 when you use JAX-WS can be loosely coupled like services built with any other technology or language. I don't see that Java EE 5 introduces any tighter coupling than any other technology. The service that you build is really a matter of how you define your WSDL and how finely grained or coarsely grained you make your services, and the architecture you use to define the interfaces between the services. So loosely coupled, tightly coupled shouldn't really be a factor for Java EE 5. On the lightweight side, there's also the advocates of Ruby on Rails. Are you looking to integrate them into Java EE 5 development or are they just going to go their own way?
Certainly you can integrate them at various API levels or potentially using Web services or more RESTful type interfaces. There are certainly ways to interoperate or integrate between the two worlds. You've mentioned Glassfish, several times, what's going on in Glassfish right now?
There's a significant amount of activity around Glassfish. There was an update to the Java EE 5 SDK on Oct. 30th. It was an update to what had been released at JavaOne earlier this year. That update provided improved performance, improved stability. One of the key things we've done was to have a GA release of the JBI runtime and the BPEL service engine. There's another update to the Java EE 5 SDK coming soon with an additional service engine for JBI, additional binding components. We don't have a lot of specifics yet, but we are looking at modularizing Java EE 5 in terms of allowing people to use various parts of it.
Work is continuing on that project on JAX-WS, on interoperability, support for WS-star specifications. Work continues on complete interoperability with .NET Web services and other technologies and tools. Beyond .NET what are the other technologies and tools you're looking at?
Certainly AXIS, the Apache project, is something that is very widely used. It's used as the foundation of WebSphere and also WebLogic for building Web services and SOA applications. Summing up, what capabilities does Java EE 5 provide for SOA development?
Java EE 5 does provide capabilities for building the services and building applications out of those services. We see that there are other languages that companies are looking to be able to orchestrate. What we're doing by including a JBI engine inside Java EE 5, we give integrated, unified access to other technologies to be able to build the larger applications, leveraging Java EE in many places where it is the best approach, but using other languages where appropriate as well.