> -----Original Message-----
> From: Bill de hÓra [mailto:dehora@xxxxxxxxxx]
> Sent: Thursday, December 19, 2002 12:33 PM
> To: axis-user@xxxxxxxxxxxxxx
> 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
>
>
>
>
|
