What makes a framework successful? Why are Web services confounding programmers? Questions about Web services' problems and promises were highlighted when Sean Rhody, editor-in-chief of Web Services Journal, was recently featured as a panelist on Rich Levin's PC TALK on WPEN-Radio, Philadelphia (950 AM). Sean joined Larry Perlstein, VP and research area director of the Gartner Group, and Steve Wilkes, principal technologist, AltoWeb, Inc., in discussing Web services. Their spontaneous dialogue suggests the directions that Web services may take. Here are some highlights from the program:

Rich Levin: Web services is really about making it easier for systems to talk to each other. What's the approach to bridging this divide?

Steve Wilkes: (describing how the new release of the AltoWeb Application Platform uses the J2EE architecture): You don't have to worry about the framework, but instead you can focus on the bits of the application that really matter: the decisions that you make in your business process, what data you want to access and how you want to present it. IT organizations using AltoWeb's platform have tested...(it ) as reducing the time of building applications down from 14 months to 8 weeks. Building Web services is a natural extension of AltoWeb's platform. AltoWeb is lowering the bar masterfully in that. Typically, to do something simple within our platform, you would not have to write any code at all, and to use a Web service or to deploy a business process as a Web service you would not have to write any code. It's as easy as saying, "I want to deploy this process," click, click, click, there you go, it's available, it can be publishable into a UDDI registry, and someone else from another department can go to that registry, find what they want to use, and select it within our platform, again without having to write any lines of code. Our platform is still extensible... but someone who doesn't understand code can actually see and use that business logic without getting into how it was written.

Levin: Isn't the measure of a framework's success, component-based or not, not so much whether manual coding is required but the degree to which manual coding is required?

Sean Rhody: I think that's absolutely correct. As we've watched the last 5 or 10 years of application development, the landscape's changed remarkably. The J2EE platform that's the basis for much of Web services world provides a lot of functionality that would otherwise have to be hand-coded. So, it's a question of moving the actual capabilities to focus more on the actual business logic than the underpinnings and the infrastructure that used to be common in programming.

Levin: The AltoWeb product, from the enterprise decision-maker's perspective, how does the IT organization judge whether they've gone further compared to competitive products in reducing the amount of code required, which reduces time-to-market, which increases ROI?

Rhody: That's largely going to be done through a case study or an individual trial, or comparisons in a magazine such as Web Services Journal. For most of the organizations, it's going to have to be a "show-me." I often see a lot of skepticism in the industry when it comes to products that are "the next best thing."

Levin: Why are developers stymied by Web services?

Rhody: They understand it, but there's a lot of legacy code out there and legacy applications that haven't been designed to take advantage of the new services that are offered. The ideal situation for a Web service is an application that's been designed in a particular fashion so that the business logic is separate from its presentation. One of the benefits of a Web service is its ability to really drive an application through various means so you can put it on a cell phone or on a PDA, a laptop, or even have one computer talk to another. So applications designed to easily be decoupled are perfect candidates for Web services. In the past, things that were written in Cobol or Fortran, or on a large mainframe, were poor candidates for that. Even tough we've had minicomputers and PCs for 20 years, there's a challenge to get some of those applications out to the Web and to interact with each other.

Levin: Will Web services succeed where past attempts to unify computing architectures failed, and if so, what is it about Web Services that's going to give it traction with the enterprise?

Larry Perlstein: Web services is going to succeed to an extent greater than we've seen in the past. We've moved to more powerful, more structurally sound types of architecture. Web services is the next step in that progression. Does it solve all the problems? No. Does it make everything really easy? No, certainly not. Will it be replaced by something else? Yes, I certainly think it will be, and it'll be yet another evolutionary step in the chain, but it's the best we have at the moment, and it's far better than what we've done in the past.

Levin: Is there a standard macro-approach that companies should use when building Web services? Something that would apply regardless of which technical underpinnings you're going to go with?

Perlstein: I think there is some sort of standard approach to it. It's very elemental, though... Most of the advice that you get today basically says, start with the standard technologies - SOAP, WSDL. XML - and look to UDDI as a directory service for it. I don't think that's sufficient, and as we gain more experience in doing this, or as vendors like AltoWeb build more sophistication into their platform so you don't have to worry about these things, we'll start coming up with a much richer definition of what it takes to deliver a well-formed Web service... Web services today is in its infancy and we'll see substantial and rapid development over the next five years or so.

Tune into the full discussion on the station's Webcast at www.rblevin.net/webcasts/PCT_12-9-01_100.rm and at www.PCTALKweb.Net (scroll down to the ARCHIVES section).

Show content is copyright (C) 2001
RBLevin@RBLevin.net & Levin Communications, all rights reserved worldwide, used with permission.