RE: Web Service Lifecycle Management - Any Pointers?

Hi Stephen,

Since you are specifically asking for pointers I guess it's ok for me to
point you to documents and products from my company. HP sees management
of the lifecycle of services (and their artifacts like XSD/WSDL) as an
integral part of SOA Governance (see
http://www.mercury.com/us/solutions/soa/governance/). More specifically,
the HP Systinet 2 product (http://www.systinet.com/products/systinet_2)
provides rich support for this and is the industry-leading solution in
that space. The links above will give you access to white papers and
data sheets that should provide more information about guidelines, best
practices and software to support the lifecycle management requirements
that you describe very well.

Regards,

William

-----Original Message-----
From: www-ws-request@w3.org [mailto:www-ws-request@w3.org] On Behalf Of
sthomas2@ups.com
Sent: Thursday, March 29, 2007 5:46 AM
To: www-ws@w3.org
Subject: Web Service Lifecycle Management - Any Pointers?


Hi Folks,

For those that don't want to read a long post, my request can be
summarized: Does anyone have any good pointers to material (papers,
studies, guidelines, etc.) on lifecycle management of web services? I'm
especially interested in how to architect and/or design web services so
that it will be easy (dare I say feasible?) to upgrade and eventually
retire them in the future?

To elaborate, it seems to me that lifecycle management of web services
presents some unique challenges, and I don't know if anyone is really
addressing those challenges. Especially interesting are the
relationships between consumers and producers of web services. (I
realize that there are several products for managing the deployment of
web services and related aspects of their lifecycle, but those appear to
be focused strictly on the producers/developers of the services.) Since
web services are primarily software products (in the sense that most of
the effort required to create them resembles traditional software
development), the first thought might be to treat web service lifecycles
the same as software product lifecycles. But there are at least a couple
of characteristics of web services that suggest that this approach won't
work very well. First, web services are not used the same way as
traditional software products. Second, the economic model for web
services is likely to differ from that of traditional software. To
appreciate those differences, consider the problem of retiring an
obsolete web service using a "Windows 95" model.

Windows 95 is a traditional software product running on a standalone
computer. At some point Microsoft can declare that the product is no
longer supported, and Microsoft can free up the resources required to
provide that support. Windows 95 users, however, can still continue to
use the product as much as they wish. Although they might not be able to
receive support for the product, as long as it was working adequately
for them before the end-of-life point, it will continue to work
adequately after the end-of-life. Satisfied customers remain
(relatively) satisfied customers.

In a web service world, of course, the situation is entirely different.
The consumer of a web service requires that the web service producer
continue to support the service for as long as the consumer wants to use
it. If a producer withdraws supports for a particular service (e.g. by
dedicating the server resources to a new service), then the consumer
immediately stops working. Satisfied consumers suddenly become very
dissatisfied consumers.

The economic models of traditional software and web services also have a
major impact on lifecycle management. When a customer purchases Windows
95, Microsoft immediately receives the revenue for that transaction.
Although Microsoft undoubtedly wants to keep its customers as satisfied
as possible, in the narrowest sense there is no real cost to Microsoft
to replace Windows 95 with a new product. (I'm ignoring second order
effects like preserving brand equity, etc.) With web services, however,
the economic model is likely based on transactions. If the service
producer is generating revenue from web services, it is likely doing so
incrementally with each individual use of the service. (Amazon, for
example, gets revenue whenever someone uses a web service to purchase a
book.) For web service producers, there is a real economic cost to
discontinuing a web service, even if discontinuing the service allows
them to introduce newer services.

It seems to me, therefore, that once a web service is deployed it may be
extremely difficult to ever retire that service. Indeed, the problem
could be even more severe because for the same reasons it may be
difficult for the producer to simply upgrade the service. (It is easy to
imagine cases where poorly developed web service clients only work with,
say, SOAP 1.2 and break when the producer upgrades to, say, SOAP 2.0.
This might be true even if SOAP 2.0 is ostensibly backwards-compatible
with SOAP 1.2, because that backwards-compatibly assumes good coding
practices on the part of client developers. Unfortunately, such
practices cannot be enforced.)

So what do web service producers do about this problem? Are there steps,
guidelines, best practices, etc. that developers can employ to at least
minimize the problem, even if they can't eliminate it entirely? Have
folks already solved this problem and I'm just not looking in the right
place? Any pointers, comments, suggestions would be appreciated.

Thanks,

Stephen

Received on Friday, 30 March 2007 19:05:51 UTC