doc/lit support

[Mike Perham <Mi...@webifysolutions.com>]

Any comments?  My main point is that WSDL must be treated as a
first-class citizen going forward.  Axis can adequately handle simple
doc/lit services which are generated from a java class but cannot handle
WSDL written by hand.  This is a major flaw and will become a major
interoperability problem going forward as web services and doc/lit
messages grow in popularity.

WSDL is the public face to a web service.  When you are designing a java
component to be used by arbitrary clients, what do you want to get
absolutely right?  The interface - make sure it throws the right
exceptions, uses publically available classes as arguments, etc.  In the
same manner, it is my belief that professionally developed web services
have their WSDL hand tuned to get the message schemas, faults,
attachment bindings, etc exact.  Creating the WSDL and messages at
runtime from the Java code simply will not work because the schema
definitions contain more information than the Java code itself.
maxOccurs and choice are examples.  So a client which uses the
hand-tuned WSDL will often simply not work with an Axis server.  I would
appreciate axis-dev's feedback here; am I missing something or is there
a better way to describe the problem?

mike

-----Original Message-----
From: Davanum Srinivas [mailto:dims@yahoo.com] 
Sent: Thursday, October 09, 2003 10:20 AM
To: axis-user@ws.apache.org
Subject: RE: Axis doc/lit - impossible?


Mike,

Please start a discussion in the axis-dev@ mailing list about your
thoughts on extracting metadata for the web service from existing wsdl.

Thanks,
dims

--- Mike Perham <Mi...@webifysolutions.com> wrote:
> Exactly!  It's my belief that there are fundamental issues with Axis 
> 1.1 that preclude solid support for arbitrary doc/lit WSDL.  See the 
> bug I opened yesterday for this exact discussion:
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23677
> 
> 
> -----Original Message-----
> From: Thomas Bayer [mailto:bayer@oio.de]
> Sent: Thursday, October 09, 2003 4:54 AM
> To: axis-user@ws.apache.org
> Subject: Re: Axis doc/lit - impossible?
> 
> 
> Taking a WSDL document with an arbitrary schema doesn't work and can't

> work. I have found no facility to do the binding. Perhaps a binding 
> framework could be used, but for the generation of the response there 
> is no store for a mapping or a schema nor there is code that can 
> produce a response obeying the rules in an arbitrary schema.


=====
Davanum Srinivas - http://webservices.apache.org/~dims/

AW: doc/lit support

[Thomas Bayer <ba...@oio.de>]

Hi,

doc/lit style services and WSDL don't have allways arbitrary handwritten
schemas. It is an awfull lot of work to handwrite an interoperable WSDL. And
the main point is not to support every schema. It is more important that
with doc/lit the body can be validated against the schema inside the WSDL
document. This is the great advantage over section 5 rpc/encoded web
services. You can't validate a body against the schema information in WSDL
with rpc/encoded cause of the encoding rules, multirefs, ...
RPC/literal has the advantage, that parts of the body can be described with
schema. But a message can contain several parts and every part has it's own
schema-type.
Doc/Lit goes farther than RPC/literal in that the message has only one part
and can be therefore described using one schema. The wrapped style is a
special doc/lit style imposing some more conventions. Conventions for the
WSDL and the included schema. Axis obeys these restrictions and can
therefore generate proper WSDL in doc/lit out of deployed services, generate
client or server code. Even there are some bugs mentioned already in
bugzilla.

So we can get a lot of benefits if Axis obeys the rules and conventions and
the bugs are fixed. If Axis could map every schema, Axis would be inflated.
Perhaps its possible to use a binding framework and make the support for
arbitrary schemas plugable. But I guess that a decent support for Doc/Lit
and Wrapped using these conventions should have priority. After that binding
facilities and schema repositories can be addressed if needed.

The rules and conventions for wrapped for example makes it easy to support
interoperability and proper WSDL2Java and Java2WSDL support:

- Only one part per message
- The part name is parameters
- No Attributes
- The wrapper element is named after the method
- The response wrapper is named method + "Response"
- The parameters are contained in child-elements of the wrapper
- ...

I hope SOAP is not about writing WSDL and schema by hand. WS-I and other
efforts should ensure, that there are conventions making doc/lit simple. For
arbitrary schemas and the Doc/Lit style a RPC programming modell is not
suitable. Web Services supporting user defined schema could be created using
the message provider.

Thomas



> > Any comments?  My main point is that WSDL must be treated as a
> > first-class citizen going forward.  Axis can adequately handle simple
> > doc/lit services which are generated from a java class but cannot handle
> > WSDL written by hand.  This is a major flaw and will become a major
> > interoperability problem going forward as web services and doc/lit
> > messages grow in popularity.

Re: doc/lit support

[Steve Loughran <st...@iseran.com>]

Mike Perham wrote:
> Any comments?  My main point is that WSDL must be treated as a
> first-class citizen going forward.  Axis can adequately handle simple
> doc/lit services which are generated from a java class but cannot handle
> WSDL written by hand.  This is a major flaw and will become a major
> interoperability problem going forward as web services and doc/lit
> messages grow in popularity.

sounds like it.

> 
> WSDL is the public face to a web service.  When you are designing a java
> component to be used by arbitrary clients, what do you want to get
> absolutely right?  The interface - make sure it throws the right
> exceptions, uses publically available classes as arguments, etc.  In the
> same manner, it is my belief that professionally developed web services
> have their WSDL hand tuned to get the message schemas, faults,
> attachment bindings, etc exact.  Creating the WSDL and messages at
> runtime from the Java code simply will not work because the schema
> definitions contain more information than the Java code itself.
> maxOccurs and choice are examples.  So a client which uses the
> hand-tuned WSDL will often simply not work with an Axis server.  I would
> appreciate axis-dev's feedback here; am I missing something or is there
> a better way to describe the problem?
> 
> mike

I believe in WSDL first too; even though WSDL 1.1 is ugly as anything.

If we need to fix Axis then so be it; its doc-lit support is weak 
compared to .NET, and anything you can do to help is great. If you help 
enough we even give you commit access to the code :)

The first step will be more test cases to replicate the problems. Then 
comes the patches.

1. Call.java already uses WSDL metadata to populate the call object -if 
that needs extending, then there is already a place to start.

2. I wonder if focusing on SOAP1.2, WSDL1.2 is the best forward looking 
tactic.

Re: doc/lit support

[Davanum Srinivas <di...@yahoo.com>]

See http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23677 a bit more details.

-- dims

--- Mike Perham <Mi...@webifysolutions.com> wrote:
> Any comments?  My main point is that WSDL must be treated as a
> first-class citizen going forward.  Axis can adequately handle simple
> doc/lit services which are generated from a java class but cannot handle
> WSDL written by hand.  This is a major flaw and will become a major
> interoperability problem going forward as web services and doc/lit
> messages grow in popularity.
> 
> WSDL is the public face to a web service.  When you are designing a java
> component to be used by arbitrary clients, what do you want to get
> absolutely right?  The interface - make sure it throws the right
> exceptions, uses publically available classes as arguments, etc.  In the
> same manner, it is my belief that professionally developed web services
> have their WSDL hand tuned to get the message schemas, faults,
> attachment bindings, etc exact.  Creating the WSDL and messages at
> runtime from the Java code simply will not work because the schema
> definitions contain more information than the Java code itself.
> maxOccurs and choice are examples.  So a client which uses the
> hand-tuned WSDL will often simply not work with an Axis server.  I would
> appreciate axis-dev's feedback here; am I missing something or is there
> a better way to describe the problem?
> 
> mike
> 
> -----Original Message-----
> From: Davanum Srinivas [mailto:dims@yahoo.com] 
> Sent: Thursday, October 09, 2003 10:20 AM
> To: axis-user@ws.apache.org
> Subject: RE: Axis doc/lit - impossible?
> 
> 
> Mike,
> 
> Please start a discussion in the axis-dev@ mailing list about your
> thoughts on extracting metadata for the web service from existing wsdl.
> 
> Thanks,
> dims
> 
> --- Mike Perham <Mi...@webifysolutions.com> wrote:
> > Exactly!  It's my belief that there are fundamental issues with Axis 
> > 1.1 that preclude solid support for arbitrary doc/lit WSDL.  See the 
> > bug I opened yesterday for this exact discussion:
> > 
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23677
> > 
> > 
> > -----Original Message-----
> > From: Thomas Bayer [mailto:bayer@oio.de]
> > Sent: Thursday, October 09, 2003 4:54 AM
> > To: axis-user@ws.apache.org
> > Subject: Re: Axis doc/lit - impossible?
> > 
> > 
> > Taking a WSDL document with an arbitrary schema doesn't work and can't
> 
> > work. I have found no facility to do the binding. Perhaps a binding 
> > framework could be used, but for the generation of the response there 
> > is no store for a mapping or a schema nor there is code that can 
> > produce a response obeying the rules in an arbitrary schema.
> 
> 
> =====
> Davanum Srinivas - http://webservices.apache.org/~dims/


=====
Davanum Srinivas - http://webservices.apache.org/~dims/