Hi folks, Rajal, you've hit on one of the difficulties of using WS for building a distributed system. WS is not a design center, it's a set of communication protocols.
That is, there's no "there" there. Unlike OO systems (like CORBA, or COM, or even EJB) there's nothing to "hang your hat on" in terms of solving these kinds of problems. If this was a CORBA system, you could address this in a number of ways -- interface versioning, namespaces (CORBA modules), Naming Service hierarchies, etc. With WS, this is more difficult, since the underlying WS implementation is independent of the interaction protocol and metadata (SOAP/WSDL). 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 believe you will need to construct separate endpoints for each version, since as far as WSDL is concerned, these are different entities (the SOAP port and binding information is specific to one message type). 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...) This is a real challenge in building tightly-coupled distributed systems with WS -- it just doesn't provide all the QoS that we're used to in other distributed computing technologies. Another example is session management... good luck Jason > -----Original Message----- > From: Rajal Shah [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, December 17, 2002 5:10 PM > To: Axis User Mailing List > Subject: Design question on using Java classes v/s hashes or arrays > > > Folks > > I'm been struggling to find a good design approach to building our web > services and wanted to explore options with everyone. > > Suppose we have a web service which takes in say 3 parameters > as input and > it returns a list of records of a database with specific column/field > information. > > Now in a future version, I might have to enhance this service > to take in 4 > parameters as input. Also, in this new version the service > would return the > list of records with more column/field information then the previous > version. > > What I would like to do, is to publish the service interface > now (generating > the client stub using WSDL2Java) such that when we come out > with the new > version of the service - with 4 params and more column info - > I still want > the apps with the old client stub to still work as is and > retrieve the old > information from this updated web service. > > How can we achieve this? > > Here are some of the thoughts I had: > 1. One way to deal with this is to take input parameters as > an array or hash > and similarly each output record will be a hash/array with > the column name > and value. I don't like this idea simply cause we're > publishing the API and > by putting everything as an array/hash makes it look as if we're not > thinking enough.. (though this could be a viable option). > Plus I don't know, > if the XML->Java conversion will work for old client, when > there is more > information then what was published earlier? > > 2. Build the signature of the service method with 3 params > for now and then > provide another service method with 4 params later. This > overloading will do > the trick for the inputs. (I don't know if SOAP will allow that..) > > 3. Build a separate endpoint for every version. (yikes) > > > I hope someone can guide me on the right path with regards > the design of web > services. Thanks. > -- > Rajal > > >
