The Java EE 5 platform has no shortage of critics who see it as too complex and difficult for developers working on Web services and SOA projects, but the platform also has its evangelists, one of whom is Kevin Schmidt, director of SOA at Sun Microsystems Inc. In a two-part Q&A, Schmidt talks first about the capabilities he sees Java EE 5 bringing to SOA. In the second part, he answers some of the criticisms leveled at the platform.

Read Part 2

What does Java EE 5 offer the Web services and SOA developer?
With Java EE 5 there are a number of things that have been done to make building the services to support an SOA much easier with the added capability to orchestrate and use those services. We're seeing that not only in Java EE 5 itself, but in other things we're doing around Java EE 5. Specifically, what are those things around Java EE 5?
Part of it is what Sun acquired from SeeBeyond with its Composite Application Platform. It provides the ability to build Java EE 5 applications that orchestrate with BPEL, XSLT and other technologies running in a J2EE environment. Java EE 5 makes enhancements to the Web services stack, enhancement to the programming model through annotations, which make it much easier for the developer to build the services and additional things around EJB 3.0.

Something else that we are developing as part

of the Glassfish open source application server is embedding a JBI (Java Business Integration) runtime to allow developers to use other technologies -- such as a business process engine, business rules engine, other languages for doing transformations alongside Java EE -- to take advantage of Java EE where it's very strong for building the services that interact with your different systems for leveraging code and components that you've written in Java. But it's also able to augment that with the other technologies all side-by-side, with consistent tooling and a consistent runtime. That allows the developer to build a variety of services for an SOA. Then the developer would be able to pull those services into the SOA application. Vendors supporting Java EE 5 all point to EJB 3.0 as one of its strengths for SOA, what does it mean to developers?
It's a significant improvement in the ease with which they can build the service components that are going to be part of the SOA. It eliminates a lot of the difficulties and complexities of the prior EJB specifications. Some of the tooling we've built that runs alongside EJB 3.0, including NetBeans 5.5, makes it easier to build EJB components that you expose as Web services. It also helps you to build the underlying components that get built into the services supporting an SOA. Or you can build those services directly and expose them as Web services. What about linking Web services?
For linking Web services there are facilities in Java EE for both positioning and exposing Web services as well as invoking them with the tooling provided by NetBeans. NetBeans makes it easy to discover a WSDL, bring that into your application and then call it. The developer is given a very unified experience for doing this. They don't have to know the underlying detail about how the files are technically being made. It hides all of that for them, but also the JBI runtime and process service engine that is part of JBI provides the ability to orchestrate the services you've built within Java EE as well as external services. You can orchestrate them together using business process execution language. This allows you to build larger applications. This is much more agile than writing Java code by itself. What would be a business example of how an SOA application could be pulled together that way?
There might be a public service or you might have a business partner that is exposing a Web service that provides some capability for you. You might have a business partner that provides a credit check. You may be a bank processing loans. As part of your process you have business logic that is unique to your organization that is already written in Java or you would like to write in Java. You can create those services in Java and then call out to this credit check service from Java. Or, what is more common is they create a business process for the loan approval application where they will orchestrate the services within their own organization and with external organizations, such as calling out for a credit check. What about linking to the Microsoft platform?
That's certainly an area where we've done a lot of work in our JAX-WS (Java API for XML Web Services) and Web services technology that provides for interoperability with components that are created with Microsoft technology. In the example we just talked about, the business partner could very well have written their credit check service using .NET. With JAX-WS, calling out to the .NET application and being able to work with it in a seamless way is provided. At the same time, it's not just an external business partner that might have Microsoft technology. We know it's the case today that organizations have a variety of technologies that they're building applications with. So they may be using .NET to build some applications that they want to orchestrate to create a larger application. It's certainly possible to make those calls from Java or a higher level language like BPEL. JBoss advocates an approach they call "Java EE a la carte," meaning that developers only need to use the parts of Java EE 5 that they need for their specific application, and ignore the rest. Is that a workable way to use the platform?
It is certainly something we believe is workable. We are actively looking at ways to provide what a business needs by providing components of Java EE 5, so you use just what you need. A prime example is JBI. Ultimately you'll have a wide variety of service engines and binding components that will be available to you, but you'll be able to pick and chose just the ones that you want. Similarly, we're looking at how we could provide a component of Java EE based on what they need for their application.

For more information Read about Java EE 5 vendor support Special report: Java EE 5 faces the SOA test, part 1

What about the criticism from some analysts that the Java EE 5 platform is too complex for SOA development, does breaking it down into components answer that problem?
That is certainly a very valuable approach. It does provide for what is considered to be a lighter-weight solution. Often times when you talk about lightweight versus heavyweight, it all depends on the individual's perspective. The way that you would build an application and use a subset of Java EE that runs in a full Java EE container may still be lightweight because you're not configuring each and every part that Java EE provides. Certainly when you build a Java EE application you're not required to use of every part of the standard. So a lot of that depends on someone's perspective, what's lightweight versus heavyweight. So developers are not forced to use the whole Java EE 5 package regardless of whether it works for them or not?
Today with what we have with Glassfish we don't have the ability to completely turn off various components, but it is something we are actively looking at. Certainly when you build an application, you are not required to use EJBs. You can build an application that uses a subset of Java EE for just the purposes you need. You're not forced to use the entire spec when you build an application.