RE: Design question on using Java classes v/s hashes or arrays
-Original Message- From: Bill de hÓra [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 19, 2002 12:33 PM 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. Yup, the issue is more of a design preference (as well as system requirement) as to compile vs. runtime type checking. A related issue is that somewhere we have to define the valid input output structures, as well as the semantics. I lean towards trying to do this fully within the metadata of the system (e.g. WSDL in this case) rather than exernally. This reminds me of my CORBA days, when I would (half-jokingly) demonstrate the only interface you'll ever need: CORBA IDL: Any do-it(in Any); 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. I disagree that this is the point of WS -- this is one major use case, but people are also using WS for fine-grained interfaces (e.g. as the universal Application Adapter mechanism). Granted WS are inefficient and immature, but because it's univerally accepted, this is where the momentum is. (actually, I think that XML is a conspiracy of the hardware manufacturers to boost sales -- hey, let's promote the LEAST efficient data representation possible...) 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. Not necessarily -- if you're exposing WS to an external client over the Internet, you are correct. If you are using WS internally as a universal connecting technology, fine-grained interfaces and tight-coupling is fine. This is using WS to address the same problems that CORBA did -- except now there is no imposition of any particular technology other than WS. So (e.g.) your VB developers can easily make use of a CORBA server without knowing anything about it. --Jason (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
RE: Design question on using Java classes v/s hashes or arrays
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
