axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajal Shah" <ras...@cisco.com>
Subject RE: Design question on using Java classes v/s hashes or arrays
Date Thu, 19 Dec 2002 18:27:10 GMT
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:dehora@eircom.net]
Sent: Thursday, December 19, 2002 9:33 AM
To: axis-user@xml.apache.org
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







Mime
View raw message