How do you think the Oracle Application Server stacks up against its competitors in terms of J2EE 1.4 support, and do you have plans to add any additional J2EE 1.4 or EJB 3.0 functionality in the near future?
One of the key things we are doing is we are the co-spec lead on EJB 3.0 (the Java EE 5 solution for Enterprise Java Beans). EJB 3.0 is focused on really simplifying the development experience for EJB. EJB is an incredibly complex specification, so it has this reputation for being difficult for developers to evolve. It is really focused on simplifying that, and does it by using annotations to annotate what we call plain old Java objects. That metadata about the Java class is easy to tag and use.
The EJB 3.0 reference implementation is provided by Oracle. If you go to the Sun Glassfish project on Java.net and you look at the work that is being done on the next generation of EJB 3.0, what you'll see is Oracle.toplink. What we've done is take our existing TopLink product, which is the basis for persistence in our existing release of products, and provided that production quality offering of ours as the reference implementation for EJB 3.0.
You can download previews from our Web site; it's incredibly cool. The only one that comes remotely close to what we're doing in the space is JBoss through their Hibernate stuff. EJB is influenced by Hibernate and TopLink as a solution. But every programmer is going against the reference implementation delivered through Sun's reprogramming against Oracle code that provides reference implementation.
And then in our own products, we have value added on top of that for things like improved performance through caching, clustering, specific extensions of the technology to force Oracle as an example, a back-end database and so on. What we've been calling 'TopLink essentials' is what we've been calling EJB 3.0 and the rest is part of value-add. Is the Java application server market in a bit of a holding pattern awaiting Java EE 5? And what does Java EE 5 need to deliver to prove itself ready to take next generation applications?
No, I don't think it's in a holding pattern waiting on EE 5. For example, we have a product out there that includes EJB 3.0 functionality that's not in a holding pattern waiting for it. The recent acquisition of SolarMetric by BEA [Systems] is an indication that they're behind the eight ball on any kind of solution in this space.
No, I don't think the vendors are sitting around waiting for EE 5 to solve any of their problems. This is particularly true in the Web services space. In J2EE 1.4, for example, when you build an EJB you can expose and display Web services in a standard and portable manner across app servers. But it was a bit weaker in terms of how the data binding aspects are done. There's no solution for security in a standard stack and so on. Presumably, those would be solved by the next Java plug, but we're not sitting around waiting for that Java plug to show up and do that. With our Web services manager, as an example, you can apply Web services security as a gateway mechanism in front of a service or as an agent embedded with a service.
So we're not sitting around waiting for this to be standardized as part of the EE spec. I don't think it's inhibiting any of the vendors from innovating on top of the base platform. People want portability and standardization. J2EE 1.4 is a good example. We had a Web services offering in our Java platform -- our app server solution -- for years, as did BEA and IBM. But our approaches were more or less proprietary. Here's a Web service and here's how you pass an object to that service. But as of EE 5 there's a standard way to do it -- and once you do it in that standard way, then your service can be deployed and you can deploy to other app servers and have guaranteed portability. So just a tradeoff between the portability and innovation. So you want the platform to evolve and standardize stuff, but I don't think it inhibits vendors from moving forward. Vendors often haggle over nuanced differences between competing products. What sorts of big differentiators do you see for the next generation of middleware?
The key things moving forward are going to center around how you can address service-oriented applications. That will center around ease of development, quality of service, reliability, availability and so on, and how easy it is to evolve from where you are into a service-oriented architecture and then how easy it is to build applications that are service oriented.
People are building service-oriented applications, exposing services, and yet when you build these things, how do you actually compose them and build applications out of them? You can define processes that knit them together using BPEL [Business Process Execution Language], but how do you pull these together into systems services that together solve the problem? Much like an object-oriented program consists of objects working together to solve a problem? How do you pull together a set of services solving together a business problem? How do you impose your security policies on those things? Those are issues not standardized today. What you'll see is vendors differentiating on those things. What will set Oracle apart from everyone else with a Java application server, integrated development environment and some sort of integration middleware?
What will set us apart in terms of SOA and so on is interoperability. I think interoperability is very difficult; Oracle has invested a tremendous amount of time and effort to ensure that services that are built using Oracle technology will interoperate with services built by Microsoft or other service technology. The same thing [is true for] general quality of service issues.
So performance, reliability and manageability issues -- those are really key to people, and from an Oracle standpoint, when your paycheck is dependent on an Oracle database being up and running at all times, it's important to have the facilities to ensure that that is always happening. That's more and more important in middleware and some of the issues that SOA is bringing to the plate are even more challenging. As soon as you start building and consuming services that are posted elsewhere or knit together across multiple companies, to be able to apply your corporate policies on those services is important. This will be a big differentiating factor for us moving forward.
The last thing I would say is in the area of innovation. I think EJB 3.0 is an example of innovation that we're bringing to the table. We have innovations in terms of how XML objects and XML are mapped and so on. When you fit these systems together and XML is the frame connecting them, you still have to deal with the mismatches between systems and how you make that connection for doing innovative things. Things in BPEL and how that moves forward and so on is the summary of how you'll see how we differentiate from others.