axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <...@us.ibm.com>
Subject Re: method mapping
Date Fri, 07 Dec 2001 14:55:55 GMT
Actually, let me expand a little on this...
What I disliked about opt 2 is that it seemed like
we were making axis deal with what I could call
a provider specific element.  Opt 3 avoided that.
Going the Ant approach would definitely be
preferable over option 2 and could get Axis
out of that business forever.  Very appealing...
-Dug

---
yup - it can go either way.  it depends on how much
work you want to make new provider writers to do.
I can see advantages in both.
-Dug


Sam Ruby/Raleigh/IBM@IBMUS on 12/07/2001 09:33:07 AM

Please respond to axis-dev@xml.apache.org

To:   axis-dev@xml.apache.org
cc:
Subject:  Re: method mapping



Doug Davis wrote:
>
> What I didn't like about option 2 (and is nice about
> options 1 (and 3)) is that it doesn't introduce a
> 'method' element - which is really tied to a specific
> type of service (RPC and somewhat to messaging).  Opts 1
> and 3 keep it generic - everything is just parameters.
> Opt 3 does introduce a new element, but its generic and
> can be used by anything by simply changing the
> "type" of mapping.

I'm a fan of schemas that express the semantics in a rich and verifiable
manner.

There are ways of implementing this in a general manner.  One such way is
the way that Ant introspects tasks - simply define setters for every
attribute  in which the specific service simply defines setters for the
attributes it wants to accept.  Or the services can provide descriptors
(this is the approach Excalibur takes to options).

- Sam Ruby




Mime
View raw message