We certainly started from a market-leading position in the application server space, and that's a position of strength. Most large corporations have decided that the app server is the appropriate place to put the majority of their mission-critical business logic. We're expanding out from that base, particularly into the integration space where Web services play an important role today. We're also expanding into portal technology and almost any other enterprise software you'd like to implement as middleware, which is essentially someplace between the database and the client, BEA will be offering products now and in the future. I think it's safe to say that BEA isn't synonymous with Web services. What are BEA's plans for the Web services market?
I would think that BEA should be pretty close to synonymous with Web services. We're one of the original founders, with Microsoft and IBM, of the Web Services Interoperability Organization (WS-I). We're actively involved in the Java Community Process around standardizing Web services interfaces with respect to Java and J2EE platforms. So if I were a developer, how would WebLogic Workshop help me?
If you want to build a Web service, consume a Web service, or expose any of your existing enterprise data using Web services, then WebLogic Workshop makes it easy for you to create and repackage Web services and get information into and out of a highly-scalable cluster of J2EE application servers.
WebLogic Workshop allows people to integrate those application servers into a Web services infrastructure across vendor boundaries and legacy applications. Workshop's role in that dance is to enable people to deal directly with the business logic of the Web services. Workshop handles the plumbing of getting the data in and out of the Enterprise JavaBeans that are the building blocks of the app server, without forcing the developer to understand the intricacies of Enterprise JavaBeans. Can you give us an update on where the Cajun/WebLogic Workshop project is today, and how it will impact Web services developers?
It's shipping, that's the big news. We're launching WebLogic Workshop, the project formerly known under its codename Cajun, as part of the WebLogic Platform 7.0, which will be generally available off of our Web site this week. We've got a bunch of advanced customers actively building applications on top of WebLogic Workshop, and are using WebLogic Workshop to build Web services on top of WebLogic Server. It sounds like this is for enterprise, mission-critical Web services, not internal Web services. Is that true?
We're seeing customers deploy this in one of two ways. One is for integration inside their firewalls with existing systems they have. That's where there's the most excitement and the most active development going on right now. Once you put a Web services front end on your legacy system, you've unlocked that legacy system for many other applications within your programming environment to use. You've lowered the cost for other people to consume the data that's going in and out of that legacy system.
There's another class of people who are using it for the, so to speak, .NET version of Web services, where a Web services is exposed over the Internet to trading partners. We're seeing a lot of small vendors investing heavily in that. The bulk of the lines of code that's going to be written and exposed as Web services though over the next two years will be for internal systems integration. Can you give me an example of the kind of Web service that can be built with Workshop?
Internally at BEA, we have a bug-tracking system for building our own products, and we've been exposing the APIs for that bug-tracking system as Web services. As soon as we did that, we were able to do all sorts of fancy things, such as include the list of bugs that a particular developer has in a window in his or her IDE. So we can pull information directly out of our bug tracking system and display that as an integrated window called My Current Bugs, without interfering with the underlying business logic of that core application. We could probably make it possible for our customers to enter service requests directly into the bug-tracking system as well.
We are firmly in the Java camp. The reason we are is it's an open, portable standard. It doesn't lock a customer into a single-vendor solution, unlike .NET. Once a customer has bought into .NET, they've locked in forever to a Microsoft-provided solution. Their costs are enormous and they give enormous price power to Microsoft to charge whatever it wants for .NET.
That said, we work very hard to interoperate with .NET Web services and IBM Web services and we work to make sure that we've tested the interoperability of our products so that if a customer buys products from both multiple vendors they will work together as advertised. What's BEA's stance on Web services security?
WebLogic Workshop utilized the underlying security framework of WebLogic Server 7.0. That makes it very flexible for customers to plug in their own authentication mechanisms.
We're working with standards bodies to develop security, encryption algorithms, and encryption standards. We certainly recognize that's the next big area for the whole industry to get together on.