Does integration with Oracle's database technology undercut the loosely coupled SOA message the software division is trying to send? How do you draw the line between them being complementary products and tightly coupled systems that violate the principles of SOA design?
Our middleware runs with any number of databases. When we ship our products, we certify with and test with DB2, SQL Server and so on. We ship drivers to connect to those things and test them. We think about middleware as a marketplace we are going after; same with database. What you do in middleware is not necessarily what you want to do for your database. Those are very separate patterns we think about in Oracle, and it's a huge business for us. We don't develop something in middleware that only runs with the Oracle database. We want our middleware to be the best middleware for our database customers.
There's no infringement on loose coupling and SOA principles from the database. What happens is a synergy takes place when you have both of these things in your portfolio. For example, we have a common infrastructure that we use to propagate notification and events across all the tiers of an application -- from a caching layer tier we call our Web cache, the J2EE tier and the database tier. And so what happens is, let's say, an Oracle Real Application Cluster instance comes offline or online. That creates an event and that event is propagated through an infrastructure that we use through the middle tier.
What happens is if you were using an Oracle database with Oracle middleware, you get better quality of service because we've stepped up to support those events. When you use DB2, it doesn't generate those events. We're still in our middleware using that same infrastructure. We get this benefit internally to allow us to provide better quality with Oracle products, but we're really committed that we're working with other databases. It doesn't enter into any more tight coupling though in terms of SOA; it just doesn't happen.
Two years ago, we were very aware of that marketing perception, but in terms of middleware, I think we've proven that middleware is an important business for us that a lot of people are using. In some senses, we have turned back and are going back to Oracle's database people and saying, 'Hey, you should use our middleware because it's better.' So we have something people should make use of, but we're definitely sensitive that the inverse message not come through that our middleware needs the database. What does Oracle need to add to flesh out its SOA-enabled product set?
Probably at the top of the list is if you go to Web services management as a catch phrase -- meaning how do you define, impose and manage your policies of how you consume Web services and how you allow others to consume your Web services. Right now, I'd say Oracle's at the front of how we do that in terms of the platform solution. That problem is most important to customers right now, as driven from a security standpoint. How do you impose your security policies? How do you deal with access control? Things like that. So it's being driven from a security identity management use case perspective because that is what people think is most important.
Over the horizon is what Gartner would call governance. So you have a lot of use cases and a lot of need for dealing with auditability, tracking of things. As you move toward a service-oriented model, how do you do that most effectively? Use cases over the horizon would be much broader in how they come together in dealing with these policies. Your corporate policies need to apply to applications that are built of services -- some of which you host, some of which others host and how you define them. The other pieces, if you look at the service component architecture announcement we did, [should focus on] how you make it easier for people to develop these services and how you deploy and maintain these services. I think you'll see a lot of innovation and movement in that space, with vendors trying to provide a standard solution. A lot of different software products call themselves SOA management platforms. What constitutes actual SOA management? What bells and whistles shouldn't be in an SOA management platform?
I think we're providing out of the box the most complete management solution for services right now. There are other middleware vendors that partner with solution providers in the space, but I think we have the best packaged solution. When you build services or you consume services, to go back to an analogy, when Java first came out, there was a security solution they called 'sandbox.' In other words, I'm the programmer, I can read my own sandbox, and I can protect things.
What happened was, with Java 2, there was a big shift in security from depending on your developers to deal with that problem to enabling your IT department to manage the problem. In SOA, if I want to make sure that someone passes me a valid certificate, I can write code to do that, but how does my IT department manage that and impose their policy on services? The most pertinent thing right now is security, but there will be other things such as auditability. If I have 1,000 people using my service, how do I bill those people and how do I make sure they are getting what they pay for individually? As you build more to this architecture and start exposing your services and consuming other services, a key problem is how you manage and impose the policies. What's the most interesting open source work being done at the moment? What's the most radical open source initiative that you'd like to capitalize on at Oracle?
Oracle has been doing Linux development and support for years. I think the more interesting stuff is the EJB 3.0 reference implementation work being done as an open source project under the Sun/Glassfish umbrella. All that code that is our commercial persistence solution and our TopLink product that forms the base for EJB 3.0 persistence is now available to everyone, open source. That's one [project].
Then there are three projects on Eclipse that we are also leading: EJB tooling, BPEL [Business Process Execution Language] tooling and JavaServer Faces componentry. Those are all Eclipse projects, and if you look at them, they have a common theme that these are aimed at being best-of-breed tooling for standard runtimes. In other words, EJB 3.0 is a standard and the runtime is provided through the reference implementation. But if you're partnering with people like JBoss, that would be EJB tooling because we want it to be best-of-breed tooling delivered through Eclipse.
In terms of other interesting open source stuff, we like Spring a lot. We find a lot of people using it. There are lots of Apache projects going on. It'll be interesting to see where Geronimo goes.