Where Web Services Are Going

May 10, 2002

BEA's WebLogic Workshop, formerly known as Cajun, announced in February and currently in beta 2, promises to make Java-based Web services development accessible to many more developers. This Java-based Web services IDE provides visual representation of Web services; a design-time environment for building, testing, and debugging Web services; and a runtime framework providing a performing, scalable, and reliable Web services deployment environment on the WebLogic application server platform. Currently, the WebLogic Workshop beta is only available for Windows 2000. Look for the final release to be available for Windows, Linux, and other platforms in the coming months. The product and the standard on which it's built, Java Web services (JWS) Tags, were detailed in a recent OnJava.com article.

For more perspective on this product and JWS, as well as a comparison of WebLogic Workshop and .NET, O'Reilly Networks' Rael Dornfest and O'Reilly's senior Java editor Mike Loukides talked to BEA VP of engineering Adam Bosworth. Bosworth will deliver a keynote at O'Reilly's Emerging Technology conference entitled "Finally Living Up to the Vision of Web Services."

Rael Dornfest: What are you trying to do with WebLogic Workshop?

Adam Bosworth: We focused on essentially two things for WebLogic Workshop. Number one, we wanted to build the right architecture for an enterprise integration platform for Web services. We think that this year is the year of integrating within your own company, rather than the year of integrating with business partners.

Mike Loukides: That's what I'm hearing.

Bosworth: As I've said many times before publicly, we think that there are three key ingredients to the architecture for doing that: a coarse-grained messaging model, loose coupling, and asynchronous support. Those points, we believe, are fundamentally required.

Dornfest: OK, those are all well-taken.

Bosworth: At this point, the only point our customers need walking through at all is the loose coupling. Thinking through, "What do you do for a loosely coupled architecture, why is that so important?" It's something they're still working on.

The second thing we tried to do with WebLogic Workshop was to make it easy enough that the average developer did not focus on plumbing at all. They did not really think about SOAP. They don't really think about XML parsing. They don't think about any of the JAX interfaces. They don't think about maintaining correlations and managing their own state from point to point in a conversational Web service. What they think about is the application and business logic that they need to write, period.

In almost every technology there are really four phases of adoption. Phase one was some technology suddenly came to exist. It didn't do any good yet. Chips existed long before a PC. The ARPAnet existed long before the Internet.

Phase two is some disruptive innovation comes along and makes it possible to do something you just couldn't do before. In the case of the Internet, that's pretty self-evident. Phase three is that a platform comes along and makes it possible for you to do that without having to write all your sort of own super low-level, right-down-to-the-wire technology to do it. Someone who wrote a GUI app in 1984 before Windows, that was pre-platform.

And then phase four -- and interestingly, Web services moved extraordinarily quickly to phase four, in my opinion -- is that tools come out that basically don't make you think about the plumbing. The framework comes out and hides the plumbing and lets you just focus on your business logic. And I think we're at phase four already. I mean .NET is clearly making an attempt at doing that, and so are we. The big difference between us and .NET is that we built in support from the ground up for the asynchrony and for the loose coupling. These are very fundamental parts of WebLogic Workshop.

One other difference, I don't know if it's big or small, but we find that people really like it. We built a digital tool to go along with the source to show you exactly what the Web service is going to do, and you can edit and modify the Web service in either place -- individually or in source. The rest of what we did is pretty standard for what you do any time you go set up a phase four of any platform. You build an automatic test harness, you build debugging, you build a framework to make it really easy. So that's what WebLogic Workshop is. It's basically BEA getting very, very serious about making it possible for anyone with an app server to both consume Web services very easily and to extrude them --where the Web services are not just limited to simply synchronous SOAP/RPC services, but are very general, very conversational, fully asynchronous, loosly coupled Web services. Which is what we think people are going to need for the vast majority of what they're doing on integration.

Loukides: Now, one of the things that's come up in my conversations about WebLogic Workshop with some people at BEA is the notion that WebLogic Workshop is making development possible for a level of developers who may consider themselves Java developers or XML developers, but really don't have, realistically speaking, much of a chance of actually accomplishing anything. The people who have night school certificates and two-year degrees and they're basically coming out of the Visual Studio-type world. Is that, do you see that as a key part of the audience?

Bosworth: Actually, I do. Fundamentally, we have a lot of customers who are Java programmers, to the extent that they can build a JSP and even do the simple Java programming they need to do within the JSP. They're not Java programmers, in the sense of mastering anything resembling the complexity of the API sets and the deployment sets needed for J2EE. So effectively, they've been let into the anteroom of the house, but not into the warm living room.

Just to take the world's simplest example, the way that we build conversational Web services is, we maintain them in entity beans in the server. Since we need that, it's not acceptable that these these people can't get in the door, because they're very much the people that we care about. Sun has been working closely with me on this. It's my mission to try and increase the number of people who can use the Java platform by an order of magnitude. And we're certainly not doing that with WebLogic Workshop; I want to be really clear about that. WebLogic Workshop was focused on making it easy to build and consume Web services -- mostly build them. And it does that, I think; honestly, I think we hit that one out of the park. But at the same time, it does not make everything that you want to do in building an application easy, by a long shot.

Loukides: Speaking entirely from ignorance, how does it compare, then, to VB .NET? Is the VB guy going to look at WebLogic Workshop eventually and say, this is cool?

Bosworth: VB .NET has a wider slot. VB .NET is about everything you need to do to build an application. So there are certain problems VB .NET solves that we don't, some of which we never intend to solve. We are an enterprise server company. We want to make it easy to build servers to run your enterprises. We are never going to be in the business of helping customers build rich clients. Where they overlap, which is this issue of Web services, I think we did a significantly better job than VB .NET. There are some things we do to make it easy for the developer that were never done at VB that I think are actually fairly fundamental to Web services. For example, we exposed all of the services of the enterprise's control. So if you want to schedule something to run on the cluster, where it wants to wake up every 10 minutes, and it may wake up on a totally different machine on the cluster every 10 minutes, because you're load balancing ... you simply drag in a control, set it for 10 minutes, and wire some code to prevent the callback, and you're done. Now there's a lot of plumbing in what I just said, but you don't think about that plumbing.

Dornfest: This is great. I mean, there are a lot of tools out there saying, basically it's glue. You glue this on to your current application and expose it as a Web service. I think there's not much attention paid to the fact that you don't want just a Web service that has access to your database, you want a Web service that has access to business logic, which in turn knows what to do with that on the database level.

Bosworth: Exactly. And anyone in the enterprise actually is acutely aware of this.

Dornfest: I know you guys are very focused on the backend integration and really B2B stuff. What do you think of some of the focus -- from Hailstorm, etc. -- on the consumer end of Web services? Is this real in the near future or no?

Bosworth: There are two kinds of consumer devices that we're going to talk about: the PC and the non-PC. The problem with the PC directly exposing Web services is that the PC is fundamentally a request-response model and it does not work well for anything that happens to be supporting a messaging-oriented model internally. So you end up having to build sort of a synchronous transmission. But the other problem with Web pages just exposing Web services directly, is you have to take XML and map it at some point somewhere into HTML. What I'm seeing right now is that most customers are not thinking much about Web services as a consumer thing.

There are some exceptions. The financial community is definitely looking at this. They're looking at how would they build portals where you can stick a little piece that goes and talks directly to a Web service. So one of the things we did was to add in a portlet wizard that will automatically let you point to the WSDL, give you some choices, and then build a portlet that actually goes and interacts with that Web service -- builds a form to collect the information, or lets you build one, depending on how you want to set it up, and then goes and invokes the Web service and takes the result and formats it. So we are seeing some demand for that. But it's not what I would call mature, it's very much at an early adopter stage.

On the handheld devices, in my personal opinion, the synchronous request-response model does not work well. The latency on this device is bad and it's unreliable, at best. And when you have low and unreliable bandwidth, having a UI that basically encourages you to click and then goes out and talks to a server and then encourages you to click again and then goes out and talks to a server can be absolutely maddening.

I believe, frankly, that's why WAP has been such a non-event. It fundamentally was not the appropriate architecture for the bandwidth. I think a lot of people drank the Kool-Aid about 3G and just assumed you'd have always-on, always-high-speed bandwidth. But we know that's not true. To me, the role model for consumer devices is the RIM. The RIM basically has an async model, where messages get sent into it and it sends messages back out, but the UI at no time ever blocks. The UI's always about updating essentially an outgoing queue -- if you say I want to send mail or update my calendar -- or reflecting the results of a store that has been in the background getting updated from an incoming queue.

But whenever you actually go to look at anything, it's instant. And you understand that the thing that you're looking at may be stale. But at least you're looking instantaneously at it. If it's stale, it's stale because your communication lines aren't very good. And if you've tried to do it synchronously, you'd still have to sit there and wait until it came in, at which point you'd be as up date as you are. So my personal belief, and quite honestly I'm driving BEA in this direction, is that this the right model to think about for consumer devices is the messaging model. Now the reason this is a big deal is that makes it a very, very natural partner to Web services.

There are three natural parties that stand to benefit from this model. One is the devices themselves. One is the carriers. The carriers are frantically trying to figure how to do value-added packets on their wireless network so that they can charge for information services. Well, there's a myriad of information services that become possible, if you wire Web services up to the kind of UI that Blackberry represents.

And the carriers can then start to make money in two ways. The first way is they actually start charging for those data packets. The second one is that they can then route you, because they know how to bill, to content providers, who are basically providing those messaging services to their devices, and splitting the fees. And the content providers tend to benefit because unlike the Web, they have a model where there's a captive billing model, you come in through your phone.

Every customer I talk to, when they start with Web services, the vast majority of the use is not the early adopter portal, it's not the people thinking about devices, it's intra-enterprise integration to inter-enterprise integration. And the reason is that SOAP is missing the things you need for inter-enterprise integration, so you end up having to roll your own plumbing. And the plumbing is suspect from an interop point of view. It's missing security, which you really need for the B2B space, so people tend to use a VPN to work around that, or maybe SSL. And it's missing reliable messaging. And as long as SOAP is missing those two lynchpins, I think the B2B adoption is going to be a lot slower than the intra-enterprise adoption.

Loukides: Now, as far as reliable messaging, it seems to me that one of the things that's made SOAP attractive so far has been in fact that it doesn't have reliable messaging. You know, when you throw in reliable messaging, you up the ante, probably about a factor of 10 just in terms of the protocol support and the service support. In fact, actually, you turn SOAP into JMS.

Bosworth: Well, there's no doubt that's what you're doing. I don't want to beat around the bush. You're basically turning the Internet into a messaging backbone.

Loukides: Yes.

Bosworth: I'm not going to deny that. At the same time, most of the B2B customers I talk to actually see themselves as being stymied without that. So at least in the B2B area, a lot of the companies I talk to are just using a VPN and tunnelling queuing straight through it.

But honestly, I think it's going to come. I think you're going to see the Internet become a messaging network, not just a request-response network. To some degree, it already is; it's called mail. But mail's a little bit different, right? And we don't have some of the required delivery characteristics that we're going to have here. I understand the appeal. You know, if the Dave Winers of the world are going to say, "Oh, jeez, you've already made it too heavyweight with WSDL, now you've added in the protocol requirements for reliable messaging. I don't need that to talk to Frontier UserLand, and why are you doing this?" It has to be done so if you don't need it, you don't have to pay the price. But when I talk to the customers out there doing B2B, that's what they want. Right now, when they go out and buy an installation so they can go and talk to their business partner, they get a quote of $130,000 just to get started, and their immediate reaction is, "Why can't I just use Web services to do this and buy something a lot cheaper?"

Loukides: And the answer to that right now is that you don't have reliability and you're going to lose, you know, one message out of a thousand ...

Bosworth: Exactly, exactly. But I'm predicting that's going to get fixed, courtesy of the fact that we're all working very closely together. You're going to see very rapid evolution of SOAP in this direction, and a lot of specs very, very quickly come up to speed to do this. My personal opinion is you'll see the B2B stuff ready for prime time by the end of the year.

Loukides: : OK. That'll be pretty impressive.

Bosworth: Well, time will tell if I was too aggressive or not. I've been too aggresive in the past, but in this case, I talk to my colleagues at Microsoft and IBM and we're pretty determined to move this through quickly. If I had to predict, what does Web services do this year, I think on application integration we move from early adopter to mainstream by the end of the year. And B2B is going to be faster than people think.