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]
