Hello Ian, thank you very much for answering so detailed to my WS-RF-newbie-questions. It clarifies a lot
the use of document-literal message-style in the WS-RF and Web Services in general. Regarding question #1: I believe, the use of inputs with zero parts is useful especially in case of WS-RF. As the WS-Resource we talk to is identified by wsa:ReferenceProperties(until yet, we'll see what the RefProp-Removal-Discussion will bring), we can send messages to a service using this identified WS-Resource without the need of any other parameter. An example could be: An E-Shop provides a ShoppingCart as WS-Resource. The ShoppingCart can be created, modified(adding,deleting articles), destroyed and finally ordered. Asuming the creation-operation of a ShoppingCart-Resource takes the customer-identity as a parameter and the stateful resource is bound to the identified customer after creation - say by a ResourceProperty "eshop:customerID". There would be no need for providing any other information to the ShoppingCart.order() - operation. (I'm not sure, if this is a real-world example, as normally a ShoppingCart is created without identifying the customer. The binding to the ordering customer is m,ost often done at ordertime (see amazon).) But I believe, it's a question of modeling the underlying workflow. At the moment, a developer has no chance to model the example described above with the WS-RF. Regarding question #2: I have seen the methodNameMap in the generated AbractService-Class and understand the mapping to service-operation a lot better now. Regarding the EPR-RefProp removal-discussion: I believe, the use of ReferenceParameters is as good as the use of ReferenceProperties for identifying the underlying stateful resource in WS-RF as long as the EPR-Parameters are not used for providing parameters to a Web Service - operation, because if this happens we are mixing data for the stateless web service with informations of the underlying WS-RF-infrastructure. I hope there will be no larger changes necessary to the WS-RF-Framework. Because at the moment I'm writing my master-thesis about "Modeling and Automating stateful Resources" - including the modeling of software, hardware and workflow(BPEL)-processes as WS-Resources to provide an automated infrastructure for so called "On Demand - Business". And my way to go for the implementation-part seems to be the WS-RF-project :-). Regards Michael > Hello Michael, > > I apologize for not getting back to you earlier. > > Regarding question #1, the reason we don't allow more than one part within > a message is because, in the tradition of the Globus WSRF/WSN impl, we are > requiring conformance to the WS-I Basic Profile 1.1 [1], which says the > following: > > R2204 A document-literal binding in a DESCRIPTION MUST refer, in each of > its soapbind:body element(s), only to wsdl:part element(s) that have been > defined using the element attribute. > > Since a WSRF Web service consists of one "most-derived" portType and a > corresponding binding, and all of the parts for the WSRF spec-defined > operations are defined using the 'element' attribute, the most-derived > binding is necessarily a document-literal binding, which WS-I defines as > "a wsdl:binding element whose child wsdl:operation elements are all > document-literal operations." > > WS-I also says: > > R2210 If a document-literal binding in a DESCRIPTION does not specify the > parts attribute on a soapbind:body element, the corresponding abstract > wsdl:message MUST define zero or one wsdl:parts. > > Because our most-derived binding is necessarily a doc-lit binding, the > messages it references must contain zero or one parts. So, Apollo's > Wsdl2Java should be permitting either zero or one parts (right now, it is > only accepting one). I'm not sure what the value of having an input or an > output with zero parts would be, but I guess there must be some use case > for it. > > Regarding question #2, WS-I section 4.7.6 says: > > " > The profile defines the "operation signature" to be the fully qualified > name of the child element of SOAP body of the SOAP input message described > by an operation in a WSDL binding. > > In the case of rpc-literal binding, the operation name is used as a > wrapper for the part accessors. In the document-literal case, since a > wrapper with the operation name is not present, the message signatures > must be correctly designed so that they meet this requirement. > > An endpoint that supports multiple operations must unambiguously identify > the operation being invoked based on the input message that it receives. > This is only possible if all the operations specified in the wsdl:binding > associated with an endpoint have a unique operation signature. > > R2710 The operations in a wsdl:binding in a DESCRIPTION MUST result in > operation signatures that are different from one another. > " > > So Apollo Wsdl2Java should not be allowing two operations that reference > the same element for their inputs. However, it should be aborting with an > error message instead of silently ignoring the second operation. I will > work on fixing this next week. > > Hopefully, this makes some sense. Let me know what you think. > > Regards, > Ian > > [1] http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html > > Michael Marks wrote: > > Hi, > > > > today I've got two problems concerning wsdl-interpretation during > generation > > of the Java(-Service-)Classes with the wsdl2JavaTask of apollo. > > > > First Question: > > > > If my wsdl-file contains message-elements with zero or more then one > > part-elements, a runtime-exception is thrown by the class OperationInfo, > > saying "Wsdl input element should have exactly one part.". > > WSDL1.1 specifies the number of part-elements in a message-elements with > "*" > > meaning zero till unbounded. > > > > If I encapsulate the part-elements in a new element and use this in the > > message-declaration, everything works fine. > > It seems the implementation differs in that point to the wsdl > > 1.1-specification. Is that so? Why is that so? > > > > example: > > <types> > > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; > > targetNamespace="http://bookstore.com/ShoppingCart"; > > xmlns="http://www.w3.org/2001/XMLSchema"; > > xmlns:tns="http://bookstore.com/ShoppingCart"; > > > > > xmlns:wsrl="http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceLifetime-1.2-draft-01.xsd"; > > > > > xmlns:wsbf="http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-BaseFaults-1.2-draft-01.xsd"; > > elementFormDefault="qualified"> > > > > <xs:element name="CustomerId" type="xs:string"/> > > <xs:element name="CustomerIdCreateCart" type="xs:string"/> > > > <xs:element name="CustomerIdOrderCart" type="xs:string"/> > > > <xs:element name="ProductId" type="xs:string"/> > > <xs:element name="Price" type="xs:int"/> > > <xs:element name="Quantity" type="xs:int"/> > > <xs:element name="ArticleOrder"> > > <xs:complexType> > > <xs:sequence> > > <xs:element ref="tns:ProductId"/> > > <xs:element ref="tns:Quantity"/> > > </xs:sequence> > > </xs:complexType> > > </xs:element> > > > > </xs:schema> > > </types> > > ... > > > > works fine > > ========= > > <message name="AddArticleRequest"> > > <part name="ArticleOrder" element="tns:ArticleOrder"/> > > </message> > > > > doesn't work > > ============= > > <message name="AddArticleRequest"> > > <part name="CustomerID" element="tns:CustomerId"/> > > <part name="Quantity" element="tns:Quantity"/> > > </message> > > > > > > > > > > > > > > > > Second Question: > > > > If a defined type-element is used in more then one messages for > different > > operations, only the last operation that uses the element in it's > > message-type is generated into the CustomerOperationsPortType. > > That means, i can't use defined type-elements more then one time and > have to > > define equivalent elements with an other, unique name. > > Why is that so? WSDL 1.1 don't specify such an restriction. > > > > example: > > > > (assuming the same type definitions as in the example for the first > > question) > > > > doesn't work > > ============= > > message-definitions: > > > > <message name="CreateCartRequest"> > > <part name="CustomerId" element="tns:CustomerId"/> > > </message> > > > > <message name="CreateCartResponse"> > > <part name="Created" element="xs:boolean"/> > > </message> > > > > ... > > > > <message name="OrderCartRequest"> > > <part name="CustomerId" element="tns:CustomerId"/> > > </message> > > > > <message name="OrderCartResponse"> > > <part name="TotalPrice" element="tns:Price"/> > > </message> > > > > operations-definitions: > > > > <operation name="CreateCart"> > > <input message="tns:CreateCartRequest"/> > > <output message="tns:CreateCartResponse"/> > > </operation> > > > > ... > > > > <operation name="OrderCart"> > > <input message="tns:OrderCartRequest"/> > > <output message="tns:OrderCartResponse"/> > > </operation> > > > > result: > > > > only the createCart-Operation is provided in the generated > > MyServiceCustomOperationsPortType.java, the orderCart-Operation is lost. > > > > > > works fine > > ============= > > message-definitions: > > > > <message name="CreateCartRequest"> > > <part name="CustomerId" element="tns:CustomerIdCreateCart"/> > > </message> > > > > <message name="CreateCartResponse"> > > <part name="Created" element="xs:boolean"/> > > </message> > > > > ... > > > > <message name="OrderCartRequest"> > > <part name="CustomerId" element="tns:CustomerIdOrderCart"/> > > </message> > > > > <message name="OrderCartResponse"> > > <part name="TotalPrice" element="tns:Price"/> > > </message> > > > > operations-definitions: > > > > <operation name="CreateCart"> > > <input message="tns:CreateCartRequest"/> > > <output message="tns:CreateCartResponse"/> > > </operation> > > > > ... > > > > <operation name="OrderCart"> > > <input message="tns:OrderCartRequest"/> > > <output message="tns:OrderCartResponse"/> > > </operation> > > > > result: > > > > both operations are provided in the generated > > MyServiceCustomOperationsPortType.java > > > > > > Any ideas? > > > > Thank You > > Michael > > --------------------------------------------------------------------- > 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]
