I guess this is really not an Axis discussion per se, but something that
interests me as I attempt to learn more about developing web services.
What is the goal of WS-I? It is to attempt to ensure that clients
interpret the wsdl and schemas the same way? It doesn't really matter
how the server side handles it because that is within your control. I
guess the model I am going after is an overloaded method. If I follow
the operation method is it possible to assign different operations to
the same method of my service endpoint class? Is this done by assigning
the same value for the soapAction attribute of different soap:operation
elements in the binding element of the wsdl?
Thanks for participating in the discussion. I am learning. Also, if
you have suggestions for better understading WS-I issues/guidelines...
I am open and eager to digesting them.
Mark
Walker, Jeff wrote:
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:[EMAIL PROTECTED]
Sent: Wednesday, September 12, 2007 2:06 PM
To: [email protected]; [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
Sent: Wednesday, September 12, 2007 10:27 AM
To: [email protected]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
