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:13:14 GMT
By "type of service" what I really should have said
was "type of provider" - but...
-Dug

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




Mime
View raw message