Mailing-List: contact axis-user-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-user@xml.apache.org
From: "Rajal Shah" <rashah@cisco.com>
To: "Axis User Mailing List" <axis-user@xml.apache.org>
Subject: Design question on using Java classes v/s hashes or arrays
Date: Tue, 17 Dec 2002 14:09:59 -0800
Message-ID: <OBELIPNDODLCFINONIHPIEABCDAA.rashah@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal

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