I think that it‘s time for us to start learning from the successes of public Web services, such as Google maps, Ebay and Amazon. Let‘s face it, today enterprise SOA implementations are still in infancy. Most organizations are just testing waters, developing prototypes and implementing pilot projects.
At the same time, Google maps, Ebay and Amazon Web services have been tremendously successful. I know that Google maps example has already been overused by the “Web 2.0†hype, but it is indeed pretty amazing. I subscribe to Google maps mania blog and there are several new “mashup†applications being announced every day. So how do these service providers manage to keep their diverse array of clients happy?
I think that the most important distinction of a successful Web service provider is that it goes above and beyond just publishing WSDL and schema files. These service providers take time to develop detailed samples, documentation and clients libraries. For example, Ebay provides client libraries for Windows, Java, Perl and so on. Google maps is obviously JavaScript. Google search is exposed using WSLD/SOAP but there are also client libraries for Java and .NET that hide complexities of WSDL. Amazon provides entire Associate Engine application written in Perl to interface with its Web services.
This goes against the common view that WSDL /Schema of a service provides complete service definition. This view also suggests that all that a service provider needs to do is to announce its WSDL to the world (or to a community of customers/partners) and the world will immediately adopt the service. This approach shifts the responsibility of implementing the code to access a service (client library or SDK ) to the clients. And for a complex WSDL (or multiple WSDLs), this may mean a lot of effort (especially if we take testing into account). We all know how tricky it is to develop an elegant API . Code generators typically don‘t do a very good job, or they are too inflexible. Just look at code generators supplied with today‘s JAX -RPC implementations that all insist on generating Java objects from schema. Besides, letting the clients develop the code does not allow service provider to implement validations on the client side, as I pointed out in my previous entry.
I think that successful SOA implementations will rely on the clients libraries developed by service providers. These libraries will utilize features of the target language and incorporate some client-side logic. They will also ensure interoperability. These libraries could also take into account capabilities of the client‘s underlying application server or platform. For example, a client library can utilize WS-ReliableMessaging if the client’s application server supports it.
As a result, the role of WSDL will diminish greatly. WSDL has many problems, including its hard-to-comprehend name-based links, verbosity and incompleteness (for example, it does not explain if any of WS-* specs, such as WS-Security, must be used in order to be able to access a service). Client libraries can fix these problems and shield users of a service from having to deal with low-level details of WSDL and WS-* specs.
Tags: WSDL, Web services
Thx very good story and nice site.
This is a good example of “out of the box” thinking, and also a fair exposure of WSDL weaknesses, which I have had difficulty in explaining to several developers used to so called Java and J2EE standards. Is there something like a more detailed paper that provides some implementation guidelines as to how we can actually try this on a live project? That will be extremely helpful.