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.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.
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.