Where Web Services Are Going
Pages: 1, 2, 3
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.
|
Related Reading 
Java Web Services |
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.
