Thursday, March 04, 2004

The Web Service Dial Tone

Web Services are failing and I know why.

Most people I talk to think the lack of adoption is for one of two reasons:
1. The huge WS-* stack is too complicated and it reminds them of CORBA.
2. We haven't found a killer app for ws.

These are both interesting - but in my opinion, they are not the real reason why ws are failing. I firmly believe the answer is very simple; we haven't created a web services dial tone. When I plug my laptop into a network, it immediately sends a broadcast message to the network. Certain devices like routers, firewalls, gateways, etc. respond to the inquiry and pass on some information about their capability and service offerings. This transparent conversation creates a 'network dialtone' - it enables a device to plug into a network, discover the services and converse with them. This capability is at the heart of our TCP networks, but has not been realized in our 'web service networks'.

In order to create a ws-dialtone we need only a handful of capabilities.
1. Consumer-side applications need the ability to send a broadcast message to a network (UDP for web services).
2. Producer-side applications need to be able to listen to the broadcast and respond. They also need the capability to broadcast their availability.
3. UDP style broadcasts are limited to a sub-net. Thus, sub-net routing (via a soap router) is critical.

Much of this functionality is available via the WS-Discovery specification. However, a large number of people in the ws community view the aforementioned protocol as a tool to be used strictly in ad-hoc networks or for consumer hardware devices. And although this is a subset of the target audience, it has broader applicability in the enterprise environment.

As we continue our movement towards contract based development we will begin to see more emphasis on standardizing the contract. Today, our standardized contracts come in the form a platform like J2EE (technical contracts) or from industry working groups (business contracts). The combination of the standardized contract, the discoverable implementation and late binding will introduce a computing model that enables a service oriented system to automatically find producers for a predetermined piece of functionality and to bind to it. Imagine installing a workflow system and immediately after installation, the server found all of the other dependent services (LDAP, single sign-on, etc.) and registered the bindings to those services. This is the vision of a service oriented enterprise - it focuses on the simplified integration of systems by using ubiquitous protocols, standardized contracts and late binding on a dial tone network.

No comments: