axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Walker, Jeff" <Jeff.Wal...@fmr.com>
Subject RE: axis 1 - message style service and custom wsdl file
Date Wed, 12 Sep 2007 18:24:44 GMT
Anne,
I hear what you say. On reflection your right, multiple operations are
safer, but type derivation is allowed in schema, and consequently, in
wsdl/soap. So I thought it was worth offering as an alternative.
-jeff

 

-----Original Message-----
From: Anne Thomas Manes [mailto:atmanes@gmail.com] 
Sent: Wednesday, September 12, 2007 2:06 PM
To: axis-user@ws.apache.org; marka@informatics.jax.org
Subject: Re: axis 1 - message style service and custom wsdl file

The SOAP spec doesn't specify how to deal with substitution groups;
therefore, different frameworks handle them in different ways. (i.e.,
interoperability problems).

But I also recommend avoiding type derivation. Rich OO environments
like Java can handle them easily, but it's a different issue when
dealing with other languages.

A multiple operation model is the safer, more interoperable solution.

Anne

On 9/12/07, Mark Airey <marka@informatics.jax.org> wrote:
> Hi Jeff,
>
> So, are you saying ditch the substitution group and just go with type
> derivation?  If I declare the base type abstract will this still work?
> In this model the wrapped element would always have the same name, but
I
> could determine the type and take the appropriate actions?  So is it
the
> fact that a substitution group allows the elements be have different
> names that makes it less interoperable?  This is a much easier change
> then moving to a multiple operation model.  I like the ability to keep
a
> single operation and extend it by adding request types......  This
> service is essentially a wrapper around a library of DataFactory
> implementations.
>
> Thanks,
> Mark
>
>
> Walker, Jeff wrote:
> > So,
> > Setup the operation to take a BaseRequest and a return a
BaseResponse
> > type in the portType section of your wsdl file. Make sure it isn't
> > abstract in the schema, and then use the extension mechanism in
schema
> > to create your RequestA and RequestB complex types extending from
that
> > BaseRequest. The request object in your implementation can be
checked
> > using the instanceof operator. This way, the Axis engine does all of
the
> > schema validation work, and you get to play with the Java object you
> > expected, after you cast it down, of course.
> > -jeff
> >
> >
> > -----Original Message-----
> > From: Mark Airey [mailto:marka@informatics.jax.org]
> > Sent: Wednesday, September 12, 2007 10:27 AM
> > To: axis-user@ws.apache.org
> > Subject: Re: axis 1 - message style service and custom wsdl file
> >
> > Hi,
> >
> >   This is something that I have been attempting to understand
myself.  I
> >
> > am developing a wrapped style service that publishes one operation,
but
> > this operation looks at the wrapped element to determine what to do.
> > For example if the request is
> > <submitDocument><requestA>someArg</requestA></submitDocument>
my
service
> >
> > sees the requestA element, validates it against the proper schema,
and
> > instantiates ClassA to gather and return data.  If  the request is
> > <submitDocument><requestB>someOtherArg</requestB></submitDocument>
my
> > service sees the requestB element, validates it against the proper
> > schema, and instantiates ClassB to gather and return data.  I have
> > defined a substitution group for the valid request elements.  Is
this
> > WS-I compliant?  It works for me, but I have had some trouble
getting an
> >
> > automated test tool to generate a client it can use via the wsdl.
> >
> > Mark
> >
> >
> >> Oliver,
> >>
> >> The WS-I Basic Profile specifies that each operation must have a
> >> unique signature. (The SOAP and WSDL specifications don't address
this
> >> issue, therefore it's unspecified.) On a practical level, the SOAP
> >> engine requires some means to determine how to dispatch the
request,
> >> therefore it needs some type of signature.
> >>
> >> Per the WS-I BP, an operation's signature is defined as the
qualified
> >> name of the child element of the SOAP Body element. If you define
the
> >> input message part for one of your operations as element="xsd:any",
> >> you would have no way to differentiate that operation from any
other
> >> operation. Therefore, if you want to expose multiple operations in
the
> >> service, you must define unique wrapper elements for each one.
> >>
> >> Axis follows the WS-I BP signature requirements. Axis2 allows for
> >> other methods to specify the signature, such as the SOAPAction
header
> >> or a WSA Action value.
> >>
> >> Anne
> >>
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org


Mime
View raw message