You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by "Soti, Dheeraj" <ds...@harris.com> on 2005/03/24 01:08:07 UTC
Which Style of WSDL should I use
Hi,
I have to expose our middle-tier (J2EE) APIs as web service which will be
consumed by a .NET clients (and possibly Java clients as well). I came across an
article http://www-128.ibm.com/developerworks/webservices/library/ws-whichwsdl/
<http://www-128.ibm.com/developerworks/webservices/library/ws-whichwsdl/> that
explained all the possible styles beautifully but also raised few questions in
mind. I will appreciate if someone will share his experience with me.
* WS-I says no to RPC/encoded but as per the article it has some benefits
like Polymorphism and datagraph which is true in my business case as well. I
have a class that can have members of itself. Will I have problems using
doc/literal(wrapped)
* WS-I also advises not to use overloaded methods but doesn't that put
additional load on client. For example I have a method createContent(Content
ct). I have 3 different implementations of Content so I'll have to add three
methods createContentofType1/2/3. Or should I consider this as a tradeoff for
being interop?
Thanks
Dheeraj
Re: Which Style of WSDL should I use
Posted by "Tim K. (Gmane)" <tk...@ugcs.net>.
As usual, excellent answer from Anne! Keep contributing to this list, we
all appreciate it.
Tim
Anne Thomas Manes wrote:
> One of the most important concepts to understand about the web
> services framework (WSF) is that it should not be used like a
> distributed object system. Web services communicate by exchanging
> messages -- it's more like JMS than RMI. The WSF doesn't support
> remote references, remote object garbage collection, or any of the
> other distributed object features you've come to rely upon in RMI. The
> fundamental purpose of the WSF is to enable interoperability across
> dissimilar systems that don't necessarily understand concepts such as
> method overloading, object inheritance, and polymorphism. Hence web
> service interfaces should not expose these OO concepts.
>
> For best interoperability with .NET, you should use document/literal
> with the wrapped programming convention. (Axis "wrapped" style.) You
> should flatten your object graph. You should not expose Java
> collections, such as maps and lists. You should convert all your
> collections into arrays. And you should not use overloaded methods.
> Each operation should have a different operation name. You should also
> expose a "chunky" interface rather than a "chatty" interface -- in
> other words, you should not expose getter and setter operations for
> every member in your object class. This goes back to the
> differentiation between message exchange versus distributed object
> systems. When using distributed objects, the object resides on the
> server side, and the client invokes operations on the object using a
> proxy. The client does not have its own copy of the object. When using
> a message exchange system, the client side application should have its
> own object -- not just a proxy. (And -- btw -- that object may be
> different from the server's object.) When the client communicates with
> the server, it simply passes data, not behavior. It's much more
> loosely coupled.
>
> You may find that it's necessary to build an abstraction layer between
> your WSDL interface and your middle tier applications. (This is a much
> better idea than trying to expose your rich datagraph directly.) This
> abstraction layer performs the necessary mapping between the
> document-oriented WSDL interface and the application's object model.
> It also provides much better insulation for flexibility and change.
>
> The "wrapped" style is defined in the JAX-RPC 1.1 spec, in section
> 6.4.1 Java Mapping of Literal Representation. (note that JAX-RPC 1.1
> was originally designed around rpc/encoded, and added only cursory
> support for rpc/literal and document/literal at the last minute. So I
> wouldn't rely on JAX-RPC for definite recommendations for best
> practices.)
>
> The "wrapped" style supports a programming model that makes
> document/literal feel like RPC style. "Wrapped" style is very similar
> to RPC/literal, except for two important distinctions:
> 1- .NET supports "wrapped" style, but it doesn't support RPC/literal
> 2- "wrapped" style defines a schema of the full soap body (which makes
> it very easy to validate), while RPC/Literal defines a schema only of
> a portion of the soap body (which makes validation slightly more
> complicated).
>
> Please see my blog entry for a definition of the "wrapped" style:
> http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html
>
> Anne
>
>
> On Wed, 23 Mar 2005 16:34:31 -0800, Tim K. (Gmane) <tk...@ugcs.net> wrote:
>
>>Good questions, I would like to know too ...
>>
>>In addition, is wrapped doc/literal Axis specific? It doesn't seem to be
>>standard JAX-RPC. I guess my bigger question is: Is it possible to have
>>RPC-like web services (exposing lots of methods the client can call) and
>>use doc/literal encoding? If so, what's the approach?
>>
>>Tim
>>
>>Soti, Dheeraj wrote:
>>
>>>Hi,
>>>
>>>I have to expose our middle-tier (J2EE) APIs as web service which will
>>>be consumed by a .NET clients (and possibly Java clients as well). I
>>>came across an article
>>>_http://www-128.ibm.com/developerworks/webservices/library/ws-whichwsdl/_
>>>that explained all the possible styles beautifully but also raised few
>>>questions in mind. I will appreciate if someone will share his
>>>experience with me.
>>>
>>> * WS-I says no to RPC/encoded but as per the article it has some
>>> benefits like Polymorphism and datagraph which is true in my
>>> business case as well. I have a class that can have members of
>>> itself. Will I have problems using doc/literal(wrapped)
>>> * WS-I also advises not to use overloaded methods but doesn't that
>>> put additional load on client. For example I have a method
>>> createContent(Content ct). I have 3 different implementations of
>>> Content so I'll have to add three methods
>>> createContentofType1/2/3. Or should I consider this as a tradeoff
>>> for being interop?
>>>
>>>Thanks
>>>
>>>Dheeraj
>>>
>>
>>
>
Re: Which Style of WSDL should I use
Posted by Anne Thomas Manes <at...@gmail.com>.
One of the most important concepts to understand about the web
services framework (WSF) is that it should not be used like a
distributed object system. Web services communicate by exchanging
messages -- it's more like JMS than RMI. The WSF doesn't support
remote references, remote object garbage collection, or any of the
other distributed object features you've come to rely upon in RMI. The
fundamental purpose of the WSF is to enable interoperability across
dissimilar systems that don't necessarily understand concepts such as
method overloading, object inheritance, and polymorphism. Hence web
service interfaces should not expose these OO concepts.
For best interoperability with .NET, you should use document/literal
with the wrapped programming convention. (Axis "wrapped" style.) You
should flatten your object graph. You should not expose Java
collections, such as maps and lists. You should convert all your
collections into arrays. And you should not use overloaded methods.
Each operation should have a different operation name. You should also
expose a "chunky" interface rather than a "chatty" interface -- in
other words, you should not expose getter and setter operations for
every member in your object class. This goes back to the
differentiation between message exchange versus distributed object
systems. When using distributed objects, the object resides on the
server side, and the client invokes operations on the object using a
proxy. The client does not have its own copy of the object. When using
a message exchange system, the client side application should have its
own object -- not just a proxy. (And -- btw -- that object may be
different from the server's object.) When the client communicates with
the server, it simply passes data, not behavior. It's much more
loosely coupled.
You may find that it's necessary to build an abstraction layer between
your WSDL interface and your middle tier applications. (This is a much
better idea than trying to expose your rich datagraph directly.) This
abstraction layer performs the necessary mapping between the
document-oriented WSDL interface and the application's object model.
It also provides much better insulation for flexibility and change.
The "wrapped" style is defined in the JAX-RPC 1.1 spec, in section
6.4.1 Java Mapping of Literal Representation. (note that JAX-RPC 1.1
was originally designed around rpc/encoded, and added only cursory
support for rpc/literal and document/literal at the last minute. So I
wouldn't rely on JAX-RPC for definite recommendations for best
practices.)
The "wrapped" style supports a programming model that makes
document/literal feel like RPC style. "Wrapped" style is very similar
to RPC/literal, except for two important distinctions:
1- .NET supports "wrapped" style, but it doesn't support RPC/literal
2- "wrapped" style defines a schema of the full soap body (which makes
it very easy to validate), while RPC/Literal defines a schema only of
a portion of the soap body (which makes validation slightly more
complicated).
Please see my blog entry for a definition of the "wrapped" style:
http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html
Anne
On Wed, 23 Mar 2005 16:34:31 -0800, Tim K. (Gmane) <tk...@ugcs.net> wrote:
> Good questions, I would like to know too ...
>
> In addition, is wrapped doc/literal Axis specific? It doesn't seem to be
> standard JAX-RPC. I guess my bigger question is: Is it possible to have
> RPC-like web services (exposing lots of methods the client can call) and
> use doc/literal encoding? If so, what's the approach?
>
> Tim
>
> Soti, Dheeraj wrote:
> > Hi,
> >
> > I have to expose our middle-tier (J2EE) APIs as web service which will
> > be consumed by a .NET clients (and possibly Java clients as well). I
> > came across an article
> > _http://www-128.ibm.com/developerworks/webservices/library/ws-whichwsdl/_
> > that explained all the possible styles beautifully but also raised few
> > questions in mind. I will appreciate if someone will share his
> > experience with me.
> >
> > * WS-I says no to RPC/encoded but as per the article it has some
> > benefits like Polymorphism and datagraph which is true in my
> > business case as well. I have a class that can have members of
> > itself. Will I have problems using doc/literal(wrapped)
> > * WS-I also advises not to use overloaded methods but doesn't that
> > put additional load on client. For example I have a method
> > createContent(Content ct). I have 3 different implementations of
> > Content so I'll have to add three methods
> > createContentofType1/2/3. Or should I consider this as a tradeoff
> > for being interop?
> >
> > Thanks
> >
> > Dheeraj
> >
>
>
Re: Which Style of WSDL should I use
Posted by "Tim K. (Gmane)" <tk...@ugcs.net>.
Good questions, I would like to know too ...
In addition, is wrapped doc/literal Axis specific? It doesn't seem to be
standard JAX-RPC. I guess my bigger question is: Is it possible to have
RPC-like web services (exposing lots of methods the client can call) and
use doc/literal encoding? If so, what's the approach?
Tim
Soti, Dheeraj wrote:
> Hi,
>
> I have to expose our middle-tier (J2EE) APIs as web service which will
> be consumed by a .NET clients (and possibly Java clients as well). I
> came across an article
> _http://www-128.ibm.com/developerworks/webservices/library/ws-whichwsdl/_
> that explained all the possible styles beautifully but also raised few
> questions in mind. I will appreciate if someone will share his
> experience with me.
>
> * WS-I says no to RPC/encoded but as per the article it has some
> benefits like Polymorphism and datagraph which is true in my
> business case as well. I have a class that can have members of
> itself. Will I have problems using doc/literal(wrapped)
> * WS-I also advises not to use overloaded methods but doesn't that
> put additional load on client. For example I have a method
> createContent(Content ct). I have 3 different implementations of
> Content so I'll have to add three methods
> createContentofType1/2/3. Or should I consider this as a tradeoff
> for being interop?
>
> Thanks
>
> Dheeraj
>