I see your point.. If business functionality changes though, then maybe you need to change the method name or something and deprecate the old method.. to solve the issue you bring up. (and work on your SLAs with the clients to make them understand the new behavior or provide both business logic options).
I am referring to the versioning of services for extending the functionality of a data object. And having 2 end points can serve the needs to backward compatibility and avoid me to define my objects as hashes. Your document is pretty comprehensive and well thought out! -- Rajal -----Original Message----- From: Steve Loughran [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 19, 2002 11:06 AM To: [EMAIL PROTECTED] Subject: Re: Design question on using Java classes v/s hashes or arrays ----- 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 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 > 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. >
