| QUESTION & ANSWER |
Hapner on Java Business Integration |
 |
By Michael Meehan, News Writer
21 Aug 2005 | SearchWebServices.com |
|
|
Mark Hapner is a distinguished engineer at Sun Microsystems Inc. He is lead architect of the J2EE (Java 2 Enterprise Edition) platform, co-lead of the Enterprise JavaBeans specification and lead for Java Message Service (JMS). Hapner, who is currently Sun's Web services strategist, also helped create the Java Business Integration (JBI) specification and is Sun's board member on the WS-I. In part two of this three part interview, Hapner addresses some of the criticisms against JBI and discusses the need for the Java platform to support an open architecture for an Enterprise Service Bus (ESB).
part 1 | part 3We've heard criticism that JBI is an incomplete standard more focused on Java than integration. How do you address that criticism and what is the case for JBI?
Mark Hapner: What JBI initially addresses is "First of all, what is a composite service?" This is something which is, at the top end, platform independent. If you look at JBI you'll see that the composite application descriptor that it describes and the way that it packages a composite application, there's nothing particularly Java about it. We needed to have a description to start the process, so it happened to have been done in the JCP [Java Community Process] as part of JBI. But what you'll see is there actually is a formal description of what a composite service application is and a standard for how it's packaged. So there's a way to create them in tools and then deploy them in a standard way to the infrastructure. Now if you have a composite application you need a platform to deploy it on and JBI doesn't invent these things. It's really just following the rule of what has already been done in the industry. The best thing that industry has to represent, to realize a composite application platform is an enterprise service bus or products that are more or less aligned with that architecture.
When you look at those you see that they are an infrastructure that allows [you] to bring together different integration technologies and then create an application that uses those in some composite way. Now most of the composite application products, the ESBs, have a more or less proprietary architecture and what we saw was that once you decide that composite applications are an important element of delivering service-oriented architecture, it makes sense that the Java platform should have an architecture for delivering support for composite applications.
We don't want to architect the individual integration technologies. How someone architects a BPEL engine is their business. What we want to do is make the Java platform bring that engine together with other integration technologies, either ones that have been standardized like BPEL or proprietary ones.
So does JBI only define how to create a Java-based ESB?
Hapner: JBI does two things. It has an initial description for what an application is, which is more or less platform independent.
The other thing JBI does is make an initial cut at how the community can cooperate on implementing a Java platform ESB. If you don't think ESBs are important for the Java platform, I think you'd be in the minority from the vision perspective in how the Java platform needs to evolve to support its developers.
Why aren't IBM and BEA backing the JBI standard?
Hapner: Some of the people who are talking about JBI from IBM and BEA haven't, I guess, read the spec because they haven't seen that it is platform independent.
We need to work together as a Java community to support an open architecture for an enterprise service bus. That's not something that's platform independent. I mean, that's an actual implementation architecture based on the Java platform for building out an enterprise service bus. When you get to that level you need to talk about physical APIs. You can't just do that with WSDL. You can't implement an application server with WSDL. That might be on the edge somewhere, but inside you actually have to have an architecture.
Is JBI the next step in the evolution of Web services standards and integration technologies?
Hapner: The focus is starting to change. We're seeing it through X-Query, BPEL, WS-CDL [Web services Choreography Description Language] and a number of these other activities that are beginning to get at an industry standard way to define the semantics and implement the semantics of a service. That's a good thing. We need to move beyond TCP/IP in effect and actually get to what it takes to implement something. It's pretty important to get the right technologies together to be productive and to some degree we're seeing that happening now in the application integration space. Certainly there's work to be done to ensure that we complete the protocol work and that we have the right qualities of service there, I don't mean to minimize that, but we do need to get on and start looking at what it takes to implement these services we expect to be leveraging all of this.
|
|
|
|
