Web Services Face Some Growing Pains
Web Services Face Some Growing Pains
Web services have seen significant developments in standards, usage models and core technologies. A roundtable meeting of technology providers and consultants, convened in December by eWEEK Labs and excerpted here, examines the effects on enterprise plans.
Where are we with Web services?
Liebow: Were in a thoroughly mainstream market. Were seeing lots of customers in many different industries pick up the technology and realize significant operating savings.
Were seeing a set of standards that are available today, that are mature enough today to expose existing applications to being connected for both back-office- and front-office-type applications and to realize significant value right now.
Has the enthusiasm for Web standards overrun what the technology is really able to support?
Ericson: Its the right technology for building a service-oriented architecture. At the same time, theres some retooling thats necessary. Well probably see emerging tools in support of a service-oriented life cycle that support the promise of loosely coupled systems and continuous integration. Well see that some of the traditional tools do not carry over.
Where is the services technology in terms of its readiness to make a difference in the enterprise IT space?
Farrell: When we talk about service-oriented architectures, were not just talking about Web services. Those are important, and a good implementation, but one of the definitions of a service-oriented architecture is abstracting the interface from the implementation. Web services can lead to a forced relationship of service-oriented architecture only in the context of Web services. We believe theyre much more than that.
You need to focus on how we continue to implement these abstracted interfaces to allow clients to access a single interface regardless of the implementation behind it.
JSR [Java Specification Request] 227 is a good example of that in the scope of data binding. Submitted earlier this year by Oracle, it basically gives an abstract interface to bind data to any business service. That could be a Web service, it could be an Enterprise JavaBean, it could be a Java class, it could be anything that you want it to be.
So the point is that an enterprise application with certain data requirements could be much more isolated from the specific technology thats used to store and make available that data?
Farrell: Exactly. Web services are definitely prevalent for connectivity right now, and building reusable services to run in complex n-tier environments or in a grid environment will end up being a big benefit for the user. It will give the user a lot of control.
Doug, I know that youve made it a focus of your efforts at RDS Strategies to look at the areas in which the pieces of this puzzle are, or are not, available and really fitting together. Whats your take on what weve heard so far?
Kaye: Well, I think Im the only nonvendor on the panel today, so let me take the contrarian view: I think that were at a very early stage with Web services. I think most of whats out there, in retrospect, could be categorized as trivial implementationsRPC [remote procedure call]-based. In terms of really multivendor or standards-based implementations, there are some big missing pieces.
One of the biggest, and one that we think will be resolved quickly, is security. WS-Security is going to do a lot, but a Gartner [Inc.] report [last year] suggested that if you control the authentication mechanisms on all ends of the system, then securitys going to be in pretty good shape rather quickly. If you have to go into an environment where you have to deal with security policies that are controlled by multiple organizations, thats not doable today in Web services.
You mean it requires technologies that arent considered part of the Web services archipelago?
Kaye: Theyre not yet standardized. The technologies for virtually all of Web services are in existence, all the way up the stack. Its a matter of agreeing on which ones were going to use. Oracle, IBM, Microsoft, everyone will have a solution as quickly as possible, but theyre not necessarily going to be compatible.
The problem now is that were entering a world where "co-opetition" is about to end, where vendors have a great deal of vested interest in proprietary technologies.
Gordon, it seems as if Sonic views its role as building a platform that offers a fairly high level of abstraction, with standards defining enabling technologies. Am I beginning from a right assumption there?
Van Huizen: We think in terms of SOA [service-oriented architecture] first and Web services second. We think that Web services promise to increase interoperability between applications, and theyve begun to do that in a somewhat- limited way as has been discussed. They will do so in an increasingly rich way moving forward.
But the model of a service-oriented architecture really offers, or can offer, a systematic architectural approach to incrementally connecting applications. And thats really the fundamental premise here.
Liebow: Im not sure if I should be happy here about some of the comments [made earlier]. I think the word used was "trivial." Ill name one [example thats not]: Visa [International Service Association], with a simple Web services implementation on the dispute resolution end of their business.
This was a customer that wanted to do a Web services implementation but couldnt touch their front end because they run tens of thousands of transactions a second. They looked at the back end in terms of the number of transactions that end up as a dispute, and their goal was to see how quickly they could resolve these disputes with a simple Web services implementation. Within 13 weeks, we had that implementation up and running and in deployment, and [Visa has] saved $238 million.
And what did Web services bring to the party that made that kind of savings and quick response possible?
Liebow: They could have done it with an alternative technology, but by making it a Web services implementationby achieving those savings in the first three monthsthey have proven to their membership, the banks and to their own management that Web services is doable, that its a real technology.
Connie, I hardly need to ask what Sun [Microsystems Inc.s] position is on the role of standards in making the industry more competitive?
Weiss: Our customers keep telling us that they are just overwhelmed with the number of specifications that are out there. Theyre confused about why some specifications are not in open-standards organizations. They want solutions, they want answers, they want to bring together their heterogeneous systems and reduce their cost of investment in these systems and get into the Web services mode. Customers ... are getting more and more hooked on this stuff, saying, "We can do so much with this little bit. Think how much more we can do if we can get the full stack into an open-standards arena, developed through the industry."
What is making some of the noise thats causing customers concern?
Weiss: Sometimes specifications are announced that are not put into open-standards organizationsthat are actually competing with work thats going on in open-standards organizations. They become more de facto, more owned by one or two companies, and that really isnt building an industry. Thats not building the infrastructure thats needed to make these standards successful.
Farrell: I think I have to disagree with the comments on how the co-opetition is going to go away. ... What you get from time to time is a hiccup, where two companies actually disagree on how it actually is done, or someone gets frustrated with the process and tries to do things a different way. But I think that, in general, it does work.
Blum: There are new standards that enable the kind of value proposition of simple Web services, for doing point-to-point application integration, to get the kind of economies of scale and simplicity for connecting multiple applications in more complex scenarios.
And the kind of standards that you have in mind are ... ?
Blum: In particular, WS-ReliableMessaging and WS-Addressing and also the content thats managed by UDDI [Universal Description, Discovery and Integration]. The content that is managed by registries is becoming more robust. So what we see are sort of intermediary-oriented approaches, things like what was referred to as an ESB [enterprise services bus].
If you look at it today and you look at all the various components, good usage of standards exists. But there are some componentssuch as the registry thats used to manage them, such as having a way of addressing things thats over and above the transportthat WS-Addressing is going to enable. You can imagine a generation of much more pure Web-services-oriented intermediaries or what you might call a pure Web services ESB.
Youve introduced here the label of the enterprise services bus, and I want to surface that idea to the rest of the group. One of the key questions that I remember being discussed in 1988, when we talked about an object marketplace, was that instead of having to put together an application and sell it as a package, youd instead be able to buy objects from various sources and assemble them dynamically.
Now were talking about consuming services across the Internet. Is it going to happen in 2004that people will be able to start discovering and consuming services that were not originally designed to work with one another?
Van Huizen: Ive been an advocate of the bus model for a couple of years now, but Id express it a bit differently. You said "consuming services across the Net." I see a services bus as building a net of collaborating services, and I think thats a really important distinction. I think what were going to see across the enterprise is a set of applications exposed as services and a set of intermediary services that perform functions like security, compliance checking and so onservices that can be configured as if they were building blocks across a network.
I think the danger when talking about Web services is that people often think of a composite application as one calling another calling another, and thats a fairly inflexible model. As soon as you need to introduce something like a new compliance-checking step into a business process, you have to go back and modify all the applications that would be affected.
An ESB model allows you to introduce that processing step without disrupting applications, by implementing it as a service on the bus and then reconfiguring the bus to route through it. I think thats a real distinction from the component-based application model.
Mark, youve been talking to developers about the things they need to know to implement services as part of the design of the tools youve been providing. Is this something developers are ready to take on?
Ericson: Preparing for integrating ad hoc Web servicesto me, thats a large part of what service-oriented architecture is about. One of the bright spots is the WS-I basic profile and the forthcoming testing tools. The testing tools are not just for vendors to improve the interoperability of their platforms, but for an end user deploying a Web services endpoint to test for the interoperability of the endpoint theyre about to expose.
Van Huizen: Theres a potential peril, actually, of Web services development, which is that it can promote a proliferation of highly noninteroperable interfaces across the enterprise. Being able to more quickly develop an interface that runs SOAP [Simple Object Access Protocol] over HTTP doesnt necessarily solve the challenge. Theres an architectural discipline that needs to be instilled to reinforce this notion of interoperable interfaces.
Doug, what about that? Are we suffering from a surfeit of enablement?
Kaye: Well, let me clarify what I said earlier. Theres a great deal of value today in simple Web services, and all of the vendors have great examples of that. But as you go up the complexity stack to more complex applications, you fairly quickly come to a point where you must go beyond [currently defined] standards.