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 submitDocumentrequestAsomeArg/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 submitDocumentrequestBsomeOtherArg/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]
Re: axis 1 - message style service and custom wsdl file
Mark, If the request contains: s:Body xmlns:s=[soapNamespace] submitDocument xmlns=[yourNamespace] requestAsomeArg/requestA /submitDocument /s:Body Then a WS-I compliant server will use the yourNamespace}submitDocument element as the message signature and dispatch it accordingly. If you have defined the contents of the submitDocument element to be a choice or a substitution group, then it will not qualify as wrapped doc/literal. The wrapped convention requires that the wrapper element be defined as a sequence. My guess is that you will experience a lot of interop issues with a service like this. You would do better to define two separate operations for requestA and requestB. Anne Anne On 9/12/07, Mark Airey [EMAIL PROTECTED] wrote: 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 submitDocumentrequestAsomeArg/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 submitDocumentrequestBsomeOtherArg/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]
RE: axis 1 - message style service and custom wsdl file
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 submitDocumentrequestAsomeArg/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 submitDocumentrequestBsomeOtherArg/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]
Re: axis 1 - message style service and custom wsdl file
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 submitDocumentrequestAsomeArg/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 submitDocumentrequestBsomeOtherArg/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]
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 submitDocumentrequestAsomeArg/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 submitDocumentrequestBsomeOtherArg/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]
RE: axis 1 - message style service and custom wsdl file
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 submitDocumentrequestAsomeArg/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 submitDocumentrequestBsomeOtherArg/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]
Re: axis 1 - message style service and custom wsdl file
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: 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 submitDocumentrequestAsomeArg/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 submitDocumentrequestBsomeOtherArg/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
Re: axis 1 - message style service and custom wsdl file
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: 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
Re: axis 1 - message style service and custom wsdl file
thanks Anne for your comments. re. 2 - : is that a standard? I see, that axis generates a wsdl with a wrapper tag for each operation in the service (in case of a message style implementation). But is that a documented must do? I understand the advantages, but still think this is a little overhead, if I just want to switch from the usual binding to a raw xml implementation. Obviously the wsdl should be pure semantics and not depending upon the style of implementation. --- oliver charlet software development 11-041 Olsztyn, Poland [EMAIL PROTECTED] --- Anne Thomas Manes schrieb: Some more guidance on this: There are a couple of reasons why you might have to use a wrapper element: 1- If you want to send more than one root element in a single SOAP message 2- If you want your service to expose more than one operation Hope this helps, Anne On 9/7/07, Anne Thomas Manes [EMAIL PROTECTED] wrote: Oliver, Your WSDL message definition is not valid. It should be: message name="operationA" part name="content" element="xsd:any"/ /message Alternatively, you might want to define a wrapper element for your message content, in which case you would define the message thus: message name="operationA" part name="content" element="tns:operationA" / /message and you would also have to define the operationA element in your types section: types xsd:schema targetNamespace="[tns]" xsd:element name="operationA type="xsd:anyType"/ /xsd:schema /types Anne On 9/7/07, Oliver Charlet [EMAIL PROTECTED] wrote: Hi y'all, I am having trouble to get to work a setup that seems to be rare, but which for me is rather practical: 1) I have a wsdl, that defines a schema for the input of a message, i.e. I want the content of the soap body to of that schema. This wsdl is used to communicate with the users of the service - of course. 2) I don't want a Java Binding, because I simply want to take the raw XML from the body and do something with it (like serializing to filesystem). 3) So I create a "bottom up" service implementation, that uses the message style Element[] operationA(Element[] elms) signature. 4) I use the wsdlFile tag to serve the original wsdl to the user, when he asks for it using ...?wsdl on the Service URL now the problem: When I do 3), Axis would theoretically create a generated wsdl, that would define my operation message part as: message name="operationA" part element="operationA" type="xsd:anyType"/ /message that means, that in my case the actual payload of the incoming message would need to be inserted into the operationA-Tag that was defined by axis at the time of deployment as shown above. After I do 4), axis still expects that Tag "operationA" to be inside the soap body. But now I have a service that does not reflect the published wsdl, which after 4) is the original one defining the payload to be an instance of the schema inside it - without the operationA-Tag. That means, that any user trying to access my service, reading the public wsdl will get an error, because axis expects a different soap message. This is a little complicated to explain - but still I hope, that someone can give me a hint on how to do this the right way. Again here is what I want to achieve: - have an initial wsdl - create a "generic" service implementation handling pure XML, avoiding generation of XML-JAVA bindings - publish the initial wsdl instead of the generated one - make this scenario work... Thanks for any help :oliver -- --- oliver charlet software development 11-041 Olsztyn, Poland [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]
Re: axis 1 - message style service and custom wsdl file
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 On 9/10/07, Oliver Charlet [EMAIL PROTECTED] wrote: thanks Anne for your comments. re. 2 - : is that a standard? I see, that axis generates a wsdl with a wrapper tag for each operation in the service (in case of a message style implementation). But is that a documented must do? I understand the advantages, but still think this is a little overhead, if I just want to switch from the usual binding to a raw xml implementation. Obviously the wsdl should be pure semantics and not depending upon the style of implementation. --- oliver charlet software development 11-041 Olsztyn, Poland [EMAIL PROTECTED] --- Anne Thomas Manes schrieb: Some more guidance on this: There are a couple of reasons why you might have to use a wrapper element: 1- If you want to send more than one root element in a single SOAP message 2- If you want your service to expose more than one operation Hope this helps, Anne On 9/7/07, Anne Thomas Manes [EMAIL PROTECTED] wrote: Oliver, Your WSDL message definition is not valid. It should be: message name=operationA part name=content element=xsd:any/ /message Alternatively, you might want to define a wrapper element for your message content, in which case you would define the message thus: message name=operationA part name=content element=tns:operationA / /message and you would also have to define the operationA element in your types section: types xsd:schema targetNamespace=[tns] xsd:element name=operationA type=xsd:anyType/ /xsd:schema /types Anne On 9/7/07, Oliver Charlet [EMAIL PROTECTED] wrote: Hi y'all, I am having trouble to get to work a setup that seems to be rare, but which for me is rather practical: 1) I have a wsdl, that defines a schema for the input of a message, i.e. I want the content of the soap body to of that schema. This wsdl is used to communicate with the users of the service - of course. 2) I don't want a Java Binding, because I simply want to take the raw XML from the body and do something with it (like serializing to filesystem). 3) So I create a bottom up service implementation, that uses the message style Element[] operationA(Element[] elms) signature. 4) I use the wsdlFile tag to serve the original wsdl to the user, when he asks for it using ...?wsdl on the Service URL now the problem: When I do 3), Axis would theoretically create a generated wsdl, that would define my operation message part as: message name=operationA part element=operationA type=xsd:anyType/ /message that means, that in my case the actual payload of the incoming message would need to be inserted into the operationA-Tag that was defined by axis at the time of deployment as shown above. After I do 4), axis still expects that Tag operationA to be inside the soap body. But now I have a service that does not reflect the published wsdl, which after 4) is the original one defining the payload to be an instance of the schema inside it - without the operationA-Tag. That means, that any user trying to access my service, reading the public wsdl will get an error, because axis expects a different soap message. This is a little complicated to explain - but still I hope, that someone can give me a hint on how to do this the right way. Again here is what I want to achieve: - have an initial wsdl - create a generic service implementation handling pure XML, avoiding generation of XML-JAVA bindings - publish the initial wsdl instead of the generated one - make this scenario work... Thanks for any help :oliver -- --- oliver charlet software development 11-041 Olsztyn, Poland [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]
Re: axis 1 - message style service and custom wsdl file
got it. thanks a lot! :oliver --- oliver charlet software development 11-041 Olsztyn, Poland [EMAIL PROTECTED] --- Anne Thomas Manes schrieb: 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 On 9/10/07, Oliver Charlet [EMAIL PROTECTED] wrote: thanks Anne for your comments. re. 2 - : is that a standard? I see, that axis generates a wsdl with a wrapper tag for each operation in the service (in case of a message style implementation). But is that a documented must do? I understand the advantages, but still think this is a little overhead, if I just want to switch from the usual binding to a raw xml implementation. Obviously the wsdl should be pure semantics and not depending upon the style of implementation. --- oliver charlet software development 11-041 Olsztyn, Poland [EMAIL PROTECTED] --- Anne Thomas Manes schrieb: Some more guidance on this: There are a couple of reasons why you might have to use a wrapper element: 1- If you want to send more than one root element in a single SOAP message 2- If you want your service to expose more than one operation Hope this helps, Anne On 9/7/07, Anne Thomas Manes [EMAIL PROTECTED] wrote: Oliver, Your WSDL message definition is not valid. It should be: message name="operationA" part name="content" element="xsd:any"/ /message Alternatively, you might want to define a wrapper element for your message content, in which case you would define the message thus: message name="operationA" part name="content" element="tns:operationA" / /message and you would also have to define the operationA element in your types section: types xsd:schema targetNamespace="[tns]" xsd:element name="operationA type="xsd:anyType"/ /xsd:schema /types Anne On 9/7/07, Oliver Charlet [EMAIL PROTECTED] wrote: Hi y'all, I am having trouble to get to work a setup that seems to be rare, but which for me is rather practical: 1) I have a wsdl, that defines a schema for the input of a message, i.e. I want the content of the soap body to of that schema. This wsdl is used to communicate with the users of the service - of course. 2) I don't want a Java Binding, because I simply want to take the raw XML from the body and do something with it (like serializing to filesystem). 3) So I create a "bottom up" service implementation, that uses the message style Element[] operationA(Element[] elms) signature. 4) I use the wsdlFile tag to serve the original wsdl to the user, when he asks for it using ...?wsdl on the Service URL now the problem: When I do 3), Axis would theoretically create a generated wsdl, that would define my operation message part as: message name="operationA" part element="operationA" type="xsd:anyType"/ /message that means, that in my case the actual payload of the incoming message would need to be inserted into the operationA-Tag that was defined by axis at the time of deployment as shown above. After I do 4), axis still expects that Tag "operationA" to be inside the soap body. But now I have a service that does not reflect the published wsdl, which after 4) is the original one defining the payload to be an instance of the schema inside it - without the operationA-Tag. That means, that any user trying to access my service, reading the public wsdl will get an error, because axis expects a different soap message. This is a little complicated to explain - but still I hope, that someone can give me a hint on how to do this the right way. Again here is what I want to achieve: - have an initial wsdl - create a "generic" service implementation handling pure XML, avoiding generation of XML-JAVA bindings - publish the initial wsdl instead of the generated one - make this scenario work... Thanks for any help :oliver -- --- oliver charlet software development 11-041 Olsztyn, Poland [EMAIL PROTECTED] --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: axis 1 - message style service and custom wsdl file
Some more guidance on this: There are a couple of reasons why you might have to use a wrapper element: 1- If you want to send more than one root element in a single SOAP message 2- If you want your service to expose more than one operation Hope this helps, Anne On 9/7/07, Anne Thomas Manes [EMAIL PROTECTED] wrote: Oliver, Your WSDL message definition is not valid. It should be: message name=operationA part name=content element=xsd:any/ /message Alternatively, you might want to define a wrapper element for your message content, in which case you would define the message thus: message name=operationA part name=content element=tns:operationA / /message and you would also have to define the operationA element in your types section: types xsd:schema targetNamespace=[tns] xsd:element name=operationA type=xsd:anyType/ /xsd:schema /types Anne On 9/7/07, Oliver Charlet [EMAIL PROTECTED] wrote: Hi y'all, I am having trouble to get to work a setup that seems to be rare, but which for me is rather practical: 1) I have a wsdl, that defines a schema for the input of a message, i.e. I want the content of the soap body to of that schema. This wsdl is used to communicate with the users of the service - of course. 2) I don't want a Java Binding, because I simply want to take the raw XML from the body and do something with it (like serializing to filesystem). 3) So I create a bottom up service implementation, that uses the message style Element[] operationA(Element[] elms) signature. 4) I use the wsdlFile tag to serve the original wsdl to the user, when he asks for it using ...?wsdl on the Service URL now the problem: When I do 3), Axis would theoretically create a generated wsdl, that would define my operation message part as: message name=operationA part element=operationA type=xsd:anyType/ /message that means, that in my case the actual payload of the incoming message would need to be inserted into the operationA-Tag that was defined by axis at the time of deployment as shown above. After I do 4), axis still expects that Tag operationA to be inside the soap body. But now I have a service that does not reflect the published wsdl, which after 4) is the original one defining the payload to be an instance of the schema inside it - without the operationA-Tag. That means, that any user trying to access my service, reading the public wsdl will get an error, because axis expects a different soap message. This is a little complicated to explain - but still I hope, that someone can give me a hint on how to do this the right way. Again here is what I want to achieve: - have an initial wsdl - create a generic service implementation handling pure XML, avoiding generation of XML-JAVA bindings - publish the initial wsdl instead of the generated one - make this scenario work... Thanks for any help :oliver -- --- oliver charlet software development 11-041 Olsztyn, Poland [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]
Re: axis 1 - message style service and custom wsdl file
Oliver, Your WSDL message definition is not valid. It should be: message name=operationA part name=content element=xsd:any/ /message Alternatively, you might want to define a wrapper element for your message content, in which case you would define the message thus: message name=operationA part name=content element=tns:operationA / /message and you would also have to define the operationA element in your types section: types xsd:schema targetNamespace=[tns] xsd:element name=operationA type=xsd:anyType/ /xsd:schema /types Anne On 9/7/07, Oliver Charlet [EMAIL PROTECTED] wrote: Hi y'all, I am having trouble to get to work a setup that seems to be rare, but which for me is rather practical: 1) I have a wsdl, that defines a schema for the input of a message, i.e. I want the content of the soap body to of that schema. This wsdl is used to communicate with the users of the service - of course. 2) I don't want a Java Binding, because I simply want to take the raw XML from the body and do something with it (like serializing to filesystem). 3) So I create a bottom up service implementation, that uses the message style Element[] operationA(Element[] elms) signature. 4) I use the wsdlFile tag to serve the original wsdl to the user, when he asks for it using ...?wsdl on the Service URL now the problem: When I do 3), Axis would theoretically create a generated wsdl, that would define my operation message part as: message name=operationA part element=operationA type=xsd:anyType/ /message that means, that in my case the actual payload of the incoming message would need to be inserted into the operationA-Tag that was defined by axis at the time of deployment as shown above. After I do 4), axis still expects that Tag operationA to be inside the soap body. But now I have a service that does not reflect the published wsdl, which after 4) is the original one defining the payload to be an instance of the schema inside it - without the operationA-Tag. That means, that any user trying to access my service, reading the public wsdl will get an error, because axis expects a different soap message. This is a little complicated to explain - but still I hope, that someone can give me a hint on how to do this the right way. Again here is what I want to achieve: - have an initial wsdl - create a generic service implementation handling pure XML, avoiding generation of XML-JAVA bindings - publish the initial wsdl instead of the generated one - make this scenario work... Thanks for any help :oliver -- --- oliver charlet software development 11-041 Olsztyn, Poland [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]
