axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sadiq, Waqar" <waqar.sa...@eds.com>
Subject RE: Some thoughts on a WSDL->Java mapping for Axis
Date Thu, 09 Aug 2001 14:58:05 GMT

Hi,

I have been out of the loop of JAX-RPC but I think it is a must for key Axis
developers to be involved with JAX-RPC, not only to make sure that the two
are inline with each other, but also to avoid duplication of effort and
bring implementation experience to JAX-RPC.

Thanks,

Waqar Sadiq
EDS EIT ESAI - Enterprise Consultant
MS H3-4C-22
5400 Legacy Drive
Plano, TX 75024

phone:     +01-972-797-8408 (8-837)
e-mail:    waqar.sadiq@eds.com
fax:       +01-972-605-4071



-----Original Message-----
From: Sam Ruby [mailto:rubys@us.ibm.com]
Sent: Thursday, August 09, 2001 9:07 AM
To: jcp@apache.org; Jim Driscoll; rahuls@eng.sun.com
Cc: axis-dev@xml.apache.org
Subject: Some thoughts on a WSDL->Java mapping for Axis


What's the best way for us to collaborate on an open source implementation
of JAX RPC?

My thoughts:

1) While JAX RPC can clearly be layered on top of existing SOAP
applications, I'd like Axis to minimize the need for such a layer.

2) I'd hate to see duplicate work, and completing implementations.

Concrete example: Glen and I have been discussing ways to handle output
parameters.  This is a concept which has no native Java equivalent.  We
were starting down the path of inventing our own solution, but I would much
rather follow someone else's lead here.

My preference would be direct Axis involvement by the key developers in the
JAX RPC community.

Thoughts?

- Sam Ruby

---------------------- Forwarded by Sam Ruby/Raleigh/IBM on 08/09/2001
09:54 AM ---------------------------





Russell Butek/Austin/IBM@IBMUS on 08/09/2001 09:31:19 AM

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

To:   axis-dev@xml.apache.org
cc:

Subject:  Some thoughts on a WSDL->Java mapping for Axis




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




*******Attachment(s) have been removed*******


Mime
View raw message