It's best to avoid overloaded methods. They are not allowed by WS-I Basic Profile or by SOAP 1.2.
The goal of WS-I is to help make interoperability feasible. A few years ago, basic interoperability between SOAP stacks was extremely difficult. The SOAP 1.1 and WSDL 1.1 specs were never vetted by a standards body. They contain numerous ambiguities, inconsistencies, and even a few errors. Without solid specifications, vendors had to fill in the blanks. It was a mess. When WS-I defines a profile, it sifts through the specifications, identifies any possible opportunity for vendor-specific interpretation, and defines rules that clarify exactly how it should be interpreted. It also addresses issues related to using multiple specifications in concert, such as WS-ReliableMessaging and WS-Security (the upcoming Reliable Secure Profile). Unfortunately, WS-I decided to punt in regards to XML Schema guidelines. Issues related to proper processing of nulls vs zero-occurring elements, abstract types, substitution groups, choice, union, etc, have never been addressed. And these structures still cause a lot of interop issues. As a general rule, it's best to keep your schemas as simple as possible. The reason you're using SOAP in the first place is to support interop. (If not, you should stick with RMI.). Now -- I understand your desire to use overloaded methods in Java. Theoretically, a SOAP framework should provide a clean separation of concern between the external interface (WSDL and XML Schema) and the internal implementation, and you should be able to map the separate WSDL operations to a set of overloaded methods in your Java class. But that would require a lot more finesse on your part when configuring the service. The "preferred" development model maps a single operation to a single method. Axis2 does give you a fair amount of flexibility in the way you define your message signature, using URL, SOAPAction, wsa:Action, and element QName... Anne On 9/12/07, Mark Airey <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
