A year from now, what will people be saying about the JBI specification and its impact?
Oracle has been at the table and very involved in JBI from the beginning. Us and JBoss have been the two major vendors, other than Sun, involved in that. It enables the Java platform to be the integration platform of choice, and we're very committed to a lot of things about it. It provides a standard way to plug in what they call service engines, for example, a BPEL [Business Process Execution Language] engine or XSLT transform. It provides a standard way to combine binding components and binding of specific transports. It has some overlap with the [recently announced] Service Component Architecture stuff. It's not a huge overlap, mostly addressing stuff outside of JBI.
I think a year from now you'll see people interested in how the JBI spec evolves and how that meshes together with SCA, which is language independent of what SCA is addressing -- things like the deployment packaging of modules and the definition of wiring between services that aren't really within the JBI specifications. A year from now, you'll see how JBI addresses the plugability, the architectural implementation, the service provider interfaces in the Java platform itself, while SCA addresses the larger scale issues of how you build service-oriented applications, how you deploy them and so on. But I think they fit together, and I think after a year that will be obvious. What is the value of the recently announced SOA programming model using Service Component Architecture and Service Data Objects?
To step back, if you break it up into Service Data Objects and Service Component Architecture, with Service Data Objects, we have in our existing product stack, something we call service beans, service interfaces, which is 99% of SDO. It's the same architectural context and construct, and is kind of a superset of what SDO has in it. So a lot of discussions around SDO are the degree to which SDO should be extended to accommodate some of the stuff we already have in our stack, what the right things are to standardize, etc. We very much like SDO and are working on it.
SCA is also an example if you look at some of the things we are doing. We have a BPEL engine. You can define services with an ESB; you can address routing, definitions. There's a rules engine that folds into it, so you can pull out the rules-based logic of how routing is done. You take all that stuff and lump it together. We have to solve what we already have on our plates -- where we're working to address the issues that SCA addresses from a standards perspective. In other words, I have service 'A,' 'B' and 'C.' How do I build an application from those services, wire them together, use native transports for them? We have those solutions in place, and we like SCA because it combines with what we were already doing in the space. Where in the Oracle product line is it likely to surface?
For us, it's strategic because we wanted a standard to emerge that meets what we perceive to be real live customer environments today. As an example, we use the Web service invocation framework as a mechanism to get to what's called the native transport level on a service. We have a mechanism to use the existing transport, so you can knit together an EJB without going through the entire SOAP stack to call an EJB as a service. This is one of the aspects of SCA also -- how to do the binding and do that in a declarative way. So we already have mechanisms that we're using in our products today. The benefit we see from it is, with conceptually minor pushing, what we have will be based on a standard that we are actively working with other members to do.
It's really just working on solving customer problems people have today, and this is the reality of the situation. You want to use EJBs, you want to call a Web services that you wrote and is deployed on .NET. How do you do all that, how do you assemble it? To us, it just fits with what we've already been doing. It's better I think for our customers and for us, if over the course of the next year, there is a real standard for a component model and architecture that you build services to. Right now, Web services don't include a component model per se. This allows you to service that component concept lifecycle, who's calling whom, and how and what transports are used in a first class way, which is kind of a missing piece. What's your favorite proposed or ratified Web services standard? Least favorite?
I'm not sure I have any personal favorites. There's such a huge set of these things. One of the things that's happened, and this is somewhat reflected in SCA, is that Microsoft has basically declared what's in Vista. They're cast in concrete pretty much and they're at least bounded. That addresses the interoperability and protocol layer, but how do you build applications out of these things? That's what SCA is moving toward. In terms of lower level stuff, one of the ones we're most interested in seeing become a real standard is policy. There is no formalized standard for it, and it's an important piece that's missing. I think we're very interested in seeing that progress. It's not keeping anybody from doing anything right now, but it'll be good to have as a real standard.