----- Original Message -----
From: "Rajal Shah" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 19, 2002 10:27
Subject: RE: Design question on using Java classes v/s hashes or arrays


> Referring to more discussions on the Internet about versioning of web
> services, this is what I recommend:
>
> We need to create a versioning plan for our service that is extensible and
> one that also guarantees backward compatibility. I've tried out several
> approaches and that the best practices seem to suggest that we publish a
> different service for each version as shown in the diagram below.
>
>  (http://www.webservicesarchitect.com/content/articles/irani04.asp)
>
> This choice makes a few decisions:
> 1. We do not need to worry about the data objects to be extensible or
> flexible anymore. Instead of using hash tables or arrays we can flat out
go
> ahead and define our data objects as pure Java objects and deal with them
> solely for this version. Each subsequent version where you have to
> enhance/extend these objects, you can give them their own definition..
> 2. It makes more sense to decouple web services exchange data objects from
> the actual business data objects. Each web service version can then map
> their data objects in the business object appropriately and share the
> baseline functionality that way.
> 3. The baseline functionality could be a J2EE container and the Web
Services
> layer can act purely as a communication transportation mechanism with it
own
> published classes and data objects.
>

the problem with this is the classic interface versioning problem. While
having different endpoints lets you have multiple interfaces with different
signatures, you are all sharing a common behviour, the semantics. What if
version 1.0 of the interface has one action on, say, deleting an user (like
it is immediate), and version 2.0 changes the implementation details so the
transaction is queued?

Web services have the extra fun of implicit semantics -if a service is
colocated in San Jose off fat pipes, and version 2.0 is hosted out of the
netherlands instead, callers in the bay area will see a different implicit
behaviour (latency, frequency of errors), even if the implementation is
identical.

I talk about versioning a bit in http://iseran.com/Steve/papers/wstw/

-steve

Reply via email to