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: axis-user@ws.apache.org; [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: 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: [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]
