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.