Return-Path: 
 <axis-dev-return-4896-apmail-xml-axis-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org
Received: (qmail 56761 invoked by uid 500); 7 Dec 2001 14:33:52 -0000
Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@xml.apache.org
list-help: <mailto:axis-dev-help@xml.apache.org>
list-unsubscribe: <mailto:axis-dev-unsubscribe@xml.apache.org>
list-post: <mailto:axis-dev@xml.apache.org>
Delivered-To: mailing list axis-dev@xml.apache.org
Received: (qmail 56723 invoked from network); 7 Dec 2001 14:33:49 -0000
Subject: Re: method mapping
To: axis-dev@xml.apache.org
X-Mailer: Lotus Notes Release 5.07a  May 14, 2001
Message-ID: <OF2A58A154.2A6F4066-ON86256B1B.004E52E0@raleigh.ibm.com>
From: "Greg Truty" <gtruty@us.ibm.com>
Date: Fri, 7 Dec 2001 08:32:44 -0600
X-MIMETrack: Serialize by Router on D04NM201/04/M/IBM(Release 5.0.8 |June 18,
 2001) at
 12/07/2001 09:32:50 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

There are other issues with methodName that may affect the decision of
which to use also.  I had mentioned this in an earlier note but methodName
is really used as a filter for what allowable methods can be dispatched.
This is broken in the case where overloaded methods are used (we have no
way of specifying one method vs. the other).   So, what we have now really
isn't sufficient.

If you look at ways of solving that problem,
- you can mangle the name and use the mangled name on the line (this would
work w/option 1 or 2).
- you can list the parameters with the method name (option 2 helps this in
that you have a separate element in within you can introduce another
parameter for arguement types).

Also... if we are going to do 3, I would think that having "new" vs "_new"
in the method name would be better (for checking allowability since at that
time, you really have the incoming operation which is "new", not "_new"),
and then, prior to dispatch (if you can't find the method, check the map).

I agree w/Sanjiva in that I don't really like option 1.

Regards...Greg

Greg Truty




                                                                                                   
                    Doug                                                                           
                    Davis/Raleigh/       To:     axis-dev@xml.apache.org                           
                    IBM@IBMUS            cc:                                                       
                                         Subject:     Re: method mapping                           
                    12/07/2001                                                                     
                    07:58 AM                                                                       
                    Please respond                                                                 
                    to axis-dev                                                                    
                                                                                                   
                                                                                                   



I like option 3:   (inside joke ;-)

<service name="myService" provider="java:RPC">
  <parameter name="className" value="myServiceClass"/>
  <parameter name="methodName" value="doit _new"/>
  <parameter name="scope" value="Session"/>
  <map type="methodName" name="new" map="_new"/>
</service>

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.

On a side note, I do like the idea of allowing people
to split the list of method names across multiple
elements - so we should allow:

<service name="myService" provider="java:RPC">
  <parameter name="className" value="myServiceClass"/>
  <parameter name="methodName" value="doit"/>
  <parameter name="methodName" value="_new"/>
  <parameter name="scope" value="Session"/>
  <map type="methodName" name="new" map="_new"/>
</service>

But that's a different topic.

-Dug


Russell Butek/Austin/IBM@IBMUS on 12/07/2001 08:38:23 AM

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

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



This note is mostly directed to Sam, Glen, Tom, Rich, and I; we were
chatting about it yesterday; but it might be of interest to others.  A
problem arises when a WSDL operation has the name of a Java keyword, like
"new".  This "new" operation becomes the Java method "_new".  In the SOAP
message, "new" is sent across the wire, but this string is used to search
for the method implementation.  Since there is no "new" method, we get a
method not found error.  Note that, while sending "_new" across the wire
works, it only works for us because we have Java mappings on both sides.
If the other side was implemented in a language where "new" was not a
keyword, then no mapping would take place and "_new" would not exist and we
would again get a method not found error.  What we need in cases like this
is a mapping from the WSDL operation name to the Java method name.  This
mapping would be in deploy.wsdd.

Per our chat yesterday, here's where I think we stand.  I'd like to tackle
this today (though I probably need someone to point me to the parts in the
runtime that will have to change) and get the JavaNames test back to where
it was.

For simplicity, I would suggest that we add a methodMap parameter.  Assume
we add a "new" operation to the AddressBook sample:

  <service name="AddressBook" provider="java:RPC">
      <parameter name="className" value
="samples.addr.AddressBookSOAPBindingSkeleton"/>
      <parameter name="methodName" value=" addEntry getAddressFromName
new"/>
      <parameter name="methodMap" value="addEntry getAddressFromName
_new"/>
      <parameter name="scope" value="Session"/>
  </service>

Sam wanted a new element "method" with an optional attribute "map" which
I'm guessing would change the above to look something like:

  <service name="AddressBook" provider="java:RPC">
      <parameter name="className" value
="samples.addr.AddressBookSOAPBindingSkeleton"/>
      <parameter name="scope" value="Session"/>
      <method name="addEntry"/>
      <method name="getAddressFromName"/>
      <method name="new" map="_new"/>
  </service>

Option 1 is closer to what we have today and it only requires one new line,
and only when necessary.  The obvious downside is, if only one method needs
mapping, we still have to list all methods in the "methodMap" parameter.

Option 2 is a bit cleaner and allows us to provide the mapping for only
those methods that need it.  But the one (or two) line(s) from above become
many lines and I would guess it would take a bit more to implement.
Besides, doing this only for method looks a bit odd to me; it would look
better if we changed all parameters to elements; more work.

I opt for option 1 since it will be a rare case that this is ever
encountered and I'd hate to complicate things to accommodate border
conditions.

Thoughts?

Russell Butek
butek@us.ibm.com