RE: Design question on using Java classes v/s hashes or arrays

[Rajal Shah]

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.

 

As always, very open to dialog on all issues.

--

Rajal

-----Original Message-----
From: Bill de hÓra [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 19, 2002 9:33 AM
To: [EMAIL PROTECTED]
Subject: Re: Design question on using Java classes v/s hashes or arrays


Garbis, Jason wrote:

> Your option 1 below, is pretty distasteful, since you're bypassing any typechecking, and (more importantly) excluding
important information from the WSDL metadata. That is, a user would
have to consult some external metadata to understand what is and
isn't valid input. This defeats the purpose of using WSDL.

I belive a dictionary/data driven approach is a good choice when the
interface is unstable or likely to change. Typechecking depends on
the nature of the keys used and the argument being passed in.


> Or, could you change the XML type definition for the input message to support optional fields? Then, in the handler that receives this invocation, you'll have to figure out which set of input parameters are actually in the SOAP message, and dispatch it to the appropriate resource (e.g. Java class).
> (This assumes you even want to write this dispatching code...)

That would be one approach- it sounds very like a generic method,
the most specific version of the.method is selected for the
arguments supplied. It's a way to work around the fact that
SOAP/WSDL doesn't offer much by the way of polymorphism. It's not
btw, a million miles away from using a dictionary. Another option is
not to use a custom interface, instead see if the service can be
described in terms of HTTP methods, which are stable, polymorphic
and highly generic and bind the WSDL to that.


> This is a real challenge in building tightly-coupled distributed systems with WS

It is, but, the point of using WS is to build loosely coupled
systems with coarse grained messages. Another take is that tightly
coupling systems through fine grained method calls is not a good
approach for building web distributed systems the problems Rajal is
running into simply reflect that it's an antipattern at best.

(As an aside, not using a finegrained approach is no evidence of
'not thinking enough'- far from it)

Bill de hÓra
--
Propylon
www.propylon.com