Some thoughts on a WSDL->Java mapping for Axis

[Russell Butek <bu...@us.ibm.com>]

I've been exploring Axis and the draft JAX RPC spec (JSR 101).  That spec
presents a very reasonable WSDL-to-Java mapping.  If Axis will follow that
mapping, and Sam Ruby tells me it's a reasonable thing to do, then Axis
will have to change a bit.  This note describes my initial efforts and it's
intended to get you folks thinking about WSDL->Java.

I wish y'all could see JAX RPC right now.  Unfortunately, it's still a
draft and only its expert group member companies are allowed to look at it
at the moment.  I'm going through channels to get Sun to open it up, but
until then I'm going to have to do some talking from the clouds.  Is anyone
from Sun reading this?  Is there a way to expedite this process?  Like post
the draft here?

I've started writing a WSDL->Java emitter and I ran AddressBook.wsdl
through it.  Here are the results: (See attached file: AddressBook.zip).
The big changes:

- Unfortunately I've lost the packaging of this stuff into samples.addr.
My infant emitter isn't that smart, yet.

- AddressBook.wsdl in this zip file is slightly different than in the
sample.  I'm not sure the complex types are legal WSDL as they are, so I
added the <all>...</all> tags which I believe make it legal.  I'm still
floundering with this language, so please slap me up if I did wrong.

- AddressBookProxy is replaced by the interface AddressBook and the stub
AddressBookStub.  (I could have left the name of the implementation
"AddressBookProxy", but since the spec uses the term "stub" I thought the
suffix "Stub" would be more appropriate.)

- Changes I've made to Main.java to accommodate the above are bracketed
with // RJB BEGIN ... // RJB END.

- AxisFault.  According to JAX RPC, the stub methods must throw
java.rmi.RemoteException.  So either the proxy/stub implementation must
throw RemoteException instead of AxisFault (this RemoteException could
contain the AxisFault), or AxisFault must extend RemoteException.  My
example assumes AxisFault extends RemoteException:  (See attached file:
AxisFault.java) (look for // RJB BEGIN ... // RJB END for my changes).

- complex types (Address and Phone).  Axis assumes these will be beanish,
meaning they have accessor methods.  JAX RPC doesn't require accessors.  It
only provides public elements (which the Axis sample does not).  In my
example I've provided both public elements and accessors, which looks a bit
strange, but there it is.  If the beanishness of complex types is essential
to Axis, we may have to try to influence JAX RPC to add accessors.

- Internationalization issues.  While this isn't part of JAX RPC, I thought
I'd throw it in since it affects the stub implementation.  In short, there
should be no English strings in generated code.  It is much easier to
internationalize product code than generated code, and even if Apache
doesn't internationalize Axis, anyone who picks up the source could.  There
are two English strings in AddressBookProxy:

1.  In every stub method:  "throw new AxisFault("A URL must be specified
via AddressBookProxy.setEndPoint(URL).");"  A possible replacement would be
a subclass of AxisFault which means what this text says.  In my example I
created (See attached file: NoEndPointException.java).
2.  In the constructor:  "throw new IllegalArgumentException("Exception
configurizing bean serialization: "+ex)".  I've created a subclass of
AxisFault for this one, too:  (See attached file:
SerializationException.java).


I have no fond attachments to the suggestions I've made here.  There are a
variety of ways to merge Axis with JAX RPC.  This is just an attempt to
start describing some of the issues I've found so far.

Russell Butek
butek@us.ibm.com