TIP Main Page | TIP Framework | TIP Soap Generator | TIP Soap Generator Mapping Rules - Part IV
Mapping Rules for Session Facade
- Service Interface; abstract
- Service Interface; non-abstract
- Service Interface; Operations
- Service Interface; Inheritance
- Service Interface; parent is in external reference
Service Interface; abstract
Mapping Rule
If a session facade artifact has 'isAbstract=true', it will be mapped to nothing.
Example
In Test1 model, interface org.tmforum.tip.cbe.test.TestProblemInterface is abstract, no any WSDL file generated from it.
Service Interface; non-abstract
Mapping Rule
Every non-abstract session facade artifact is mapped to an XSD file (SOAP message definitions), and two WSDL files (one for HTTP binding, one for JMS binding). The targetNamespace of these files will be the image of package name under mapping rule TIP_Soap_Generator_Mapping_Rules_-_Part_I#Mapping Rule for Namespace.
Example
In SPM model, the session facade artifact org.tmforum.tip.service.problem.ServiceProblemInterface is mapped to
a) SOAP message definition file: service_problem_serviceprobleminterface_msg.xsd, where service_problem comes from the package name. serviceprobleminterface is the simple name of the session facade. The targetNamespace is http://www.tmforum.org/xml/tip/service/problem.
b) WSDL files: service_problem_serviceprobleminterface_ws.wsdl and service_problem_serviceprobleminterface_jms.wsdl. Their targetNamespace is http://www.tmforum.org/xml/tip/service/problem.
Service Interface; Operations
Mapping Rule
All (local or inherited) operations of a non-abstract session will be mapped to WSDL operations.
Please refer to mapping rules about operations and parameters:
TIP_Soap_Generator_Mapping_Rules_-_Part_III#Mapping_Rules_for_Parameters
TIP_Soap_Generator_Mapping_Rules_-_Part_III#Mapping_Rules_for_Operations
Service Interface; Inheritance
Mapping Rule
When map a non-abstract Service Interface (Session Facade) (to SOAP message definition file and WSDL file(s)), both of its local operations and all inherited operations will be mapped to WSDL operations. Note that the facade can inherit operations from an abstract session facade.
Note
Do we allow multiple inheritance in TIP models?
Example
In Test1 model, session facade org.tmforum.tip.service.test.ServiceTestProblemInterface extends org.tmforum.tip.cbe.test.TestProblemInterface.
TestProblemInterface is abstract, extends nothing. it has 3 local operations: acknowledgeTestProblems, commentTestProblems, and testExtDT.
ServiceTestProblemInterface is non-abstract, it has one local operation: testAssoc.
ServiceTestProblemInterface is mapped to an XSD file (service_test_servicetestprobleminterface_msg.xsd) and 2 WSDL files (service_test_servicetestprobleminterface_jms.wsdl and service_test_servicetestprobleminterface_ws.wsdl).
In the XSD file, we see the message elements for 4 operations are defined:
In every WSDL files, we see 4 WSDL operations declared.
<wsdl:portType name="ServiceTestProblemInterface">
<wsdl:documentation><p>The portType of the service interface</p><p>Implements the behviour coming from the inherited class</p>
</wsdl:documentation>
<wsdl:operation name="testAssoc">
<wsdl:documentation><p>The request-response operation</p><p>Testing passing of association classes</p>
</wsdl:documentation>
<wsdl:input name="testAssocRequest" message="tns:testAssocRequest"/>
<wsdl:output name="testAssocResponse" message="tns:testAssocResponse"/>
</wsdl:operation>
<wsdl:operation name="acknowledgeTestProblems">
<wsdl:documentation><p>The request-response operation</p><p>Acknowledge test problems. Simple request /reply</p>
</wsdl:documentation>
<wsdl:input name="acknowledgeTestProblemsRequest" message="tns:acknowledgeTestProblemsRequest"/>
<wsdl:output name="acknowledgeTestProblemsResponse" message="tns:acknowledgeTestProblemsResponse"/>
<wsdl:fault name="acknowledgeTestProblemsException" message="tns:acknowledgeTestProblemsException"/>
</wsdl:operation>
<wsdl:operation name="commentTestProblems">
<wsdl:documentation><p>The request-response operation</p><p>Comment test Problems. Simple request/reply</p>
</wsdl:documentation>
<wsdl:input name="commentTestProblemsRequest" message="tns:commentTestProblemsRequest"/>
<wsdl:output name="commentTestProblemsResponse" message="tns:commentTestProblemsResponse"/>
<wsdl:fault name="commentTestProblemsException" message="tns:commentTestProblemsException"/>
</wsdl:operation>
<wsdl:operation name="testExtDT">
<wsdl:documentation><p>The request-response operation</p><p>testing of external DT</p></wsdl:documentation>
<wsdl:input name="testExtDTRequest" message="tns:testExtDTRequest"/>
<wsdl:output name="testExtDTResponse" message="tns:testExtDTResponse"/>
</wsdl:operation>
</wsdl:portType>
Service Interface; parent is in external reference
This covers the use case of a ServiceInterface that inherits from another service interface that is not local to the project but present in external reference (module).
This is related to feature 57, that covers inheritance of service interface within the project.
Mapping Rule
same with mapping rule in TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Session Facade___Inheritance
Example
In Test2 model, service interface org.tmforum.tip.test.TestExternalSuperServiceInterface extends external service interface org.tmforum.tip.service.test.ServiceTestProblemInterface. The super interface is defined in Test1 model. Note that the ServiceTestProblemInterface extends interface org.tmforum.tip.cbe.test.TestProblemInterface.
TestProblemInterface has 3 local operations: acknowledgeTestProblems, commentTestProblems, and testExtDT.
ServiceTestProblemInterface has 1 local operation: testAssoc.
TestExternalSuperServiceInterface has 2 local operations: doComplexOperation, and doAnotherComplexOperation.
From TestExternalSuperServiceInterface interface, the 3 files are generated: 1 XSD file for messages(test_testexternalsuperserviceinterface_msg.xsd), and 2 WSDL files (test_testexternalsuperserviceinterface_ws.wsdl and test_testexternalsuperserviceinterface_jms.wsdl).
In generated XSD file, we see messags for all operations (local and inherited):
and in WSDL files, we see WSDL operations coming from local operation and inherited operations:
<wsdl:portType name="TestExternalSuperServiceInterface">
<wsdl:documentation><p>The portType of the service interface</p><p>Service Interface containing high level services using external objects.</p>
</wsdl:documentation>
<wsdl:operation name="doComplexOperation">
<wsdl:documentation><p>The request-response operation</p><p>test method simulating a complex operation acting on several objects</p>
</wsdl:documentation>
<wsdl:input name="doComplexOperationRequest" message="tns:doComplexOperationRequest"/>
<wsdl:output name="doComplexOperationResponse" message="tns:doComplexOperationResponse"/>
<wsdl:fault name="doComplexOperationException" message="tns:doComplexOperationException"/>
</wsdl:operation>
<wsdl:operation name="doAnotherComplexOperation">
<wsdl:documentation><p>The request-response operation</p><p>another test method simulating a complex operation acting on several objects</p>
</wsdl:documentation>
<wsdl:input name="doAnotherComplexOperationRequest" message="tns:doAnotherComplexOperationRequest"/>
<wsdl:output name="doAnotherComplexOperationResponse" message="tns:doAnotherComplexOperationResponse"/>
<wsdl:fault name="doAnotherComplexOperationException" message="tns:doAnotherComplexOperationException"/>
</wsdl:operation>
<wsdl:operation name="testAssoc">
<wsdl:documentation><p>The request-response operation</p><p>Testing passing of association classes</p>
</wsdl:documentation>
<wsdl:input name="testAssocRequest" message="tns:testAssocRequest"/>
<wsdl:output name="testAssocResponse" message="tns:testAssocResponse"/>
</wsdl:operation>
<wsdl:operation name="acknowledgeTestProblems">
<wsdl:documentation><p>The request-response operation</p><p>Acknowledge test problems. Simple request /reply</p>
</wsdl:documentation>
<wsdl:input name="acknowledgeTestProblemsRequest" message="tns:acknowledgeTestProblemsRequest"/>
<wsdl:output name="acknowledgeTestProblemsResponse" message="tns:acknowledgeTestProblemsResponse"/>
<wsdl:fault name="acknowledgeTestProblemsException" message="tns:acknowledgeTestProblemsException"/>
</wsdl:operation>
<wsdl:operation name="commentTestProblems">
<wsdl:documentation><p>The request-response operation</p><p>Comment test Problems. Simple request/reply</p>
</wsdl:documentation>
<wsdl:input name="commentTestProblemsRequest" message="tns:commentTestProblemsRequest"/>
<wsdl:output name="commentTestProblemsResponse" message="tns:commentTestProblemsResponse"/>
<wsdl:fault name="commentTestProblemsException" message="tns:commentTestProblemsException"/>
</wsdl:operation>
<wsdl:operation name="testExtDT">
<wsdl:documentation><p>The request-response operation</p><p>testing of external DT</p></wsdl:documentation>
<wsdl:input name="testExtDTRequest" message="tns:testExtDTRequest"/>
<wsdl:output name="testExtDTResponse" message="tns:testExtDTResponse"/>
</wsdl:operation>
</wsdl:portType>
Mapping Rules for Parameters
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Parameter___message name
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Parameter___isBulkPotential, the iterator case
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Parameter___isBulkPotential, the file case
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Parameter___multiplicity
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Parameter___direction
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Parameter___default value
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Parameter___passedbyId
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Parameter___isOrdered
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Parameter___isUnique
Parameter; message name
Mapping Rule
A parameter is mapped to a sub-element of a request message or a response message (refer to [TIP_Soap_Generator_Mapping_Rules_-_Part_II#Map Full Name to
Message File Name, WSDL Files Name, and Namespace]). For an operation, if we denote its short name as <OperationName>, then
• All its 'in' and 'inout' paramaters are mapped to sub-elements of message element named <OperationName>Request
• All its 'out' and 'inout' paramaters are mapped to one message element named <OperationName>Response
Note: all its exceptions declared in an operation, if any, are mapped to a single message element named <OperationName>Exception
Example
In Test2 model, we have an interface org.tmforum.tip.test.TestExternalInterface. The interface has an operation named
doComplexOperation. The request message and response message of the operation are defined in test_testexternalinterface_msg.xsd.
The request message is a global element named doComplexOperationRequest.
<xsd:element name="doComplexOperationRequest"> <xsd:annotation> <xsd:documentation> <p>The doComplexOperation request message XML schema.</p> <p>test method simulating a complex operation acting on several objects</p> </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element name="serviceTests" type="internal:ArrayOfEntityIdentifier" minOccurs="0"> <xsd:annotation> <xsd:documentation> <p>Input service tests by ids </p> </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="testData" type="test:ArrayOfTest" minOccurs="0"> <xsd:annotation> <xsd:documentation> <p>test data by value </p> </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="misc" type="xsd:string" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation> <p>misc data</p> </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element>
The response message is a global element named doComplexOperationResponse:
<xsd:element name="doComplexOperationResponse"> <xsd:annotation> <xsd:documentation> <p>The doComplexOperation response message XML schema.</p> <p>See request message comment for operation comment.</p> </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element name="misc" type="xsd:string" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation> <p>misc data</p> </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="testProblems" type="internal:ArrayOfEntityIdentifier" minOccurs="0"> <xsd:annotation> <xsd:documentation> <p>test problems by values </p> </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element>
Parameter; isBulkPotential, the iterator case
Related to issue #25 in Mantis [ Parameter: isBulkPotential|https://sourceforge.net/apps/mantisbt/openoss/view.php?id=25]
tipParameter attribute: isBulkPotential
This covers the use of the stereotype argument isBulkPotential on a parameter. This attribute should be linked with the bulkTransferPattern attribute of the operation stereotype.
If an operation has tipOperation:bulkTransferPattern=ITERATOR, then the generator knows how to handle the operation's bulkpotential parameters. Please refer to mapping rules related with operations of iterator pattern TIP_Soap_Generator_Mapping_Rules_-_Part_VI.
Parameter; isBulkPotential, the file case (not implemented in JOSIF 1.0)
Related to issue #25 in Mantis [ Parameter: isBulkPotential|https://sourceforge.net/apps/mantisbt/openoss/view.php?id=25]
This feature is not implemented in JOSIF 1.0.
Parameter; multiplicity
Related to issue #77 in Mantis [ Parameter: multiplicity|https://sourceforge.net/apps/mantisbt/openoss/view.php?id=77]
Mapping Rule
same with the mapping rule in TIP_Soap_Generator_Mapping_Rules_-_Part_I#Mapping Rule for Attributes, Association Ends, and Parameters
Note (2009, Sept 23) According to TIP Framework Team, there is a problem with passById as the entity ID is replaced by an entityIdentifier with no indication of the entity type. The basic idea is that we need to pass both the entity identifier and the type of the entity. In SOAP generator version 0.0.3, we simply map parameters with 'tipParameter:passedById=true' to sub-element of EntityIdentifier type or of ArrayOfEntityIdentifier type.
Example
exmple in previous section: parameters of doComplexOperation operation, interface org.tmforum.tip.test.TestExternalInterface, Test2 model.
Parameter; direction
Related to issue #78 in Mantis [ Parameter: direction|https://sourceforge.net/apps/mantisbt/openoss/view.php?id=78]
This covers the use of the direction property on a parameter. The 3 values need to be supported: in, out, inOut.
Mapping Rule
Parameters are mapped to Message elements. For an operation, we denote its short name as <OperationName>, then
• ‘In’ parameters will be put in <OperationName>Request element
• ‘InOut’ parameters will be put in <OperationName>Request element and <OperationName>Response element
• ‘Out’ parameters will be put in <OperationName>Response element
also refer to TIP_Soap_Generator_Mapping_Rules_-_Part_I#Mapping Rule for Attributes, Association Ends, and Parameters
Example
Refer to previous example
Parameter; default value
Related to issue #79 in Mantis [ Parameter: default value|https://sourceforge.net/apps/mantisbt/openoss/view.php?id=79]
Parameter; passedbyId
Related to issue #80 in Mantis [ Parameter: passedById|https://sourceforge.net/apps/mantisbt/openoss/view.php?id=80]
Mapping Rule
Example
exmple in previous section: parameters of doComplexOperation operation, interface org.tmforum.tip.test.TestExternalInterface, in Test2 model.
Parameter; isOrdered
Related to issue #329 in Mantis [ Parameter: isOrdered|https://sourceforge.net/apps/mantisbt/openoss/view.php?id=329]
The generator ignore this property.
Parameter; isUnique
Related to issue #330 in Mantis [ Parameter: isUnique|https://sourceforge.net/apps/mantisbt/openoss/view.php?id=330]
The generator ignore this property.
Mapping Rules for Operations
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Operation___bulkTransferPattern Iterator
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Operation___bulkTransferPattern File (Not implemented in JOSIF 1.0)
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Operation emitEvents + emittedEvents (Not implemented in JOSIF 1.0)
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Operation___isExtendable
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Operation___isIdempotent (Not implemented in JOSIF 1.0)
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Operation___isOneWay
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Operation___specific exceptions
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Commonly used directive – Create (Not implemented in JOSIF 1.0)
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Commonly used directive – Delete (Not implemented in JOSIF 1.0)
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Commonly used directive – Set (Not implemented in JOSIF 1.0)
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Commonly used directive – Get (Not implemented in JOSIF 1.0)
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Common exceptions support
- TIP_Soap_Generator_Mapping_Rules_-_Part_IV#Pre-defined exception support
Operation; bulkTransferPattern Iterator
Related to issue #18 in Mantis Operation: bulkTransferPattern Iterator
tipOperation: bulkTransferPattern (NONE, FILE, ITERATOR)
This covers the use of the bulkTransferPattern on the tipOperation stereotype with the value ITERATOR.
In this case, all the parameters of the operation marked bulkPotential will be transferred using an iterator transfer pattern.
Please refer to TIP_Soap_Generator_Mapping_Rules_-_Part_VI.
Operation; bulkTransferPattern File (Not implemented in JOSIF 1.0)
Related to issue #19 in Mantis Operation: bulkTransferPattern File
tipOperation: bulkTransferPattern (NONE, FILE, ITERATOR)
This covers the use of the bulkTransferPattern on the tipOperation stereotype with the value FILE. In this case, all the parameters of the oepration marked bulkPotential will be transferred using a file transfer pattern.
Operation emitEvents + emittedEvents (Not implemented in JOSIF 1.0)
Related to issue #20 in Mantis Operation: emitEvents + emittedEvents
tipOperation: emitEvents (true, false)
tipOperation: emittedEvents (a list of String?)
This covers the use of the emitsEvents attribute of the tipOperation stereotype, along with the emitted events one.
This is used for async operation, where response is provided through the emission of events.
Operation; isExtendable
Related to issue #21 in Mantis Operation: isExtendable
tipOperation: isExtendable (true, false)
This covers the support of the tipOperation:isExtendable stereotype attribute on operation. If the value of this attribute is true, the operation is extendable.
Mapping Rule
For an extendable operation, the generator will inject an additional sub-element extensionInfo into all of messages elements.
1) for oneWay operations, we add the extensionInfo sub-element to the request message.
2) for request-response operations, we add the extensionInfo sub-element to both request message and response message.
For the structure of the extensionInfo element, please refer to (TIP_Soap_Generator_Mapping_Rules_-_Part_I#Mapping Rule for Extendability).
Example
In Test1 model, org.tmforum.tip.service.test.ServiceTestProblemInterface has an extendable operation named acknowledgeTestProblems (inherited from interface TestProblemInterface). We can see a sub-element named 'extensionInfo' is added to both acknowledgeTestProblemsRequest and acknowledgeTestProblemsResponse.
The request message is:
<xsd:element name="acknowledgeTestProblemsRequest">
<xsd:annotation>
<xsd:documentation>
<p>The acknowledgeTestProblems request message XML schema.</p>
<p>Acknowledge test problems. Simple request /reply</p>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="problems" type="internal:ArrayOfEntityIdentifier">
<xsd:annotation>
<xsd:documentation>
<p/>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="trackingRecord" type="test:TrackingRecord">
<xsd:annotation>
<xsd:documentation>
<p/>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="extensionInfo" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
<p>A generic list of any type of elements. Used for vendor Extensions or loose element encapsulation from other namespaces.</p>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
The response message is:
<xsd:element name="acknowledgeTestProblemsResponse">
<xsd:annotation>
<xsd:documentation>
<p>The acknowledgeTestProblems response message XML schema.</p>
<p>See request message comment for operation comment.</p>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="ackProblems" type="internal:ArrayOfEntityIdentifier">
<xsd:annotation>
<xsd:documentation>
<p>acknowledged Problems</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="extensionInfo" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
<p>A generic list of any type of elements. Used for vendor Extensions or loose element encapsulation from other namespaces.</p>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Operation; isIdempotent (Not implemented in JOSIF 1.0)
Related to issue #22 in Mantis Operation: isIdempotent
tipOperation: isIdempotent
There is a need for the generators to add a boolean parameter for idempotent operations to indicate that the operation has already been done.
Operation; isOneWay
Related to issue #23 in Mantis Operation: isOneWay
tipOperatipn: isOneWay (true, false)
This covers the support of the oneWay property on operation.
Mapping Rule
For an ‘oneWay’ operation, only request message defined; In portType of WSDL, this operation has only wsdl:input part.
Note
because oneWay operation should have no any exception, the generator will not inject any exception for oneWay operation, if any.
Example
For Test2 model, we add an oneWay operation named ‘doOneWayOperation’ in org.tmforum.tip.test.TestOneWayOpInterface, Test1 model.
In generated message XSD file (test_testonewayopinterface_msg.xsd), we see only request message is generated, no response message. The request message is:
<xsd:element name="doOneWayOperationRequest">
<xsd:annotation>
<xsd:documentation>
<p>The doOneWayOperation request message XML schema.</p>
<p>test mapping rule of tipOperation:isOneWay</p>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="arg0" type="test2:ServiceTest">
<xsd:annotation>
<xsd:documentation>
<p/>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
In WSDL files (test_testonewayopinterface_ws.wsdl and test_testonewayopinterface_jms.wsdl), we see the corresponding operation definition in portType:
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:tns="http://www.tmforum.org/xml/tip/test" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" name="TestOneWayOpInterface" targetNamespace="http://www.tmforum.org/xml/tip/test">
<wsdl:types>
<xsd:schema>
<xsd:import namespace="http://www.tmforum.org/xml/tip/test" schemaLocation="test_testonewayopinterface_msg.xsd"/>
</xsd:schema>
</wsdl:types>
<wsdl:message name="doOneWayOperationRequest">
<wsdl:documentation><p>The operation one-way message.</p></wsdl:documentation>
<wsdl:part name="body" element="tns:doOneWayOperation"/>
</wsdl:message>
<wsdl:portType name="TestOneWayOpInterface">
<wsdl:documentation><p>The portType of the service interface</p><p/></wsdl:documentation>
<wsdl:operation name="doOneWayOperation">
<wsdl:documentation><p>The one-way operation</p><p>test mapping rule of tipOperation:isOneWay</p></wsdl:documentation>
<wsdl:input name="doOneWayOperationRequest" message="tns:doOneWayOperationRequest"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="TestOneWayOpInterfaceSoapHttpBinding" type="tns:TestOneWayOpInterface">
<wsdl:documentation><p>Web Service (SOAP/HTTP) profile binding definitions.</p></wsdl:documentation>
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsaw:UsingAddressing wsdl:required="true"/>
<wsdl:operation name="doOneWayOperation">
<soap:operation soapAction="doOneWayOperation" style="document"/>
<wsdl:input name="doOneWayOperationRequest">
<soap:body use="literal"/>
</wsdl:input>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="TestOneWayOpInterfaceWs">
<wsdl:documentation><p>This is a sample wsdl:service definition of the service interface
for an implementation using the WS profile (SOAP/HTTP binging).</p><p>This wsdl:service definition is usually used at implementation time
or WS registration/discovery of a specific WS instance.</p></wsdl:documentation>
<wsdl:port name="TestOneWayOpInterfaceHttpPort" binding="tns:TestOneWayOpInterfaceSoapHttpBinding">
<soap:address location="http://localhost/TestOneWayOpInterface"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Operation; specific exceptions
Related to issue #58 in Mantis Operation: specific exceptions
This covers the use case of an Operation having specific exceptions. These specific exceptions are exceptions declared in signature of the operation in TIP models.
Mapping Rule
If an operation has no exception declared, then
• There will no exception message defined for this operation
• There will no wsdl:fault for this operation in WSDL portType
If an operation has at least one exception, then
• There will be one (and only one) exception message defined for this operation. The message is an element named <OperationName>Exception. All exceptions declared will
listed in the element and enclosed by <xsd:Choice>
• There will be wsdl:fault for this operation in WSDL portType
Note
Concerning "operation has no exception", it was agreed this is not possible for request-reply type operations and this only applies to one-way messages.
Example (operation has at least one exception)
In Test1 model, org.tmforum.tip.cbe.test.TestProblemInterface has an operation named ‘acknowledgeTestProblems’ which has two exceptions declared:
Because this interface is abstract, we don’t generate WSDL for it. The interface org.tmforum.tip.service.test.ServiceTestProblemInterface is derived from it and is not abstract, we generate a WSDL for ServiceTestProblemInterface which contains all operations (local or inherited from TestProbleInterface).
In service_test_servicetestprobleminterface_msg.xsd, we see 3 messages are generated for the operation acknowledgeTestProblems:
• acknowledgeTestProblemsRequest
• acknowledgeTestProblemsResponse
• acknowledgeTestProblemsException
The exception message of ‘acknowledgeTestProblems’’ operation is:
<xsd:element name="acknowledgeTestProblemsException">
<xsd:annotation>
<xsd:documentation>
<p>The acknowledgeTestProblems exception message XML schema.</p>
<p>See request message comment for operation comment.</p>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:choice>
<xsd:element name="testFailureWithData" type="test:TestFailureWithData">
<xsd:annotation>
<xsd:documentation>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="testFailure" type="test:TestFailure">
<xsd:annotation>
<xsd:documentation>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:choice>
</xsd:complexType>
</xsd:element>
In service_test_servicetestprobleminterface_ws.wsdl and service_test_servicetestprobleminterface_jms.wsdl, we see that in portType 'ServiceTestProblemInterface', the operation 'acknowledgeTestProblems' has input, output, and fault.
<wsdl:portType name="ServiceTestProblemInterface"> <!--other operations--> <wsdl:operation name="acknowledgeTestProblems"> <wsdl:documentation><p>The request-response operation</p><p>Acknowledge test problems. Simple request /reply</p></wsdl:documentation> <wsdl:input name="acknowledgeTestProblemsRequest" message="tns:acknowledgeTestProblemsRequest"/> <wsdl:output name="acknowledgeTestProblemsResponse" message="tns:acknowledgeTestProblemsResponse"/> <wsdl:fault name="acknowledgeTestProblemsException" message="tns:acknowledgeTestProblemsException"/> </wsdl:operation> </wsdl:portType>
Example (operation has no exception)
In the interface org.tmforum.tip.service.test.ServiceTestProblemInterface, the operation 'testAssoc' has no any exception declared. So in service_test_servicetestprobleminterface_msg.xsd, we see only 2 messages are generated for it:
• testAssocRequest
• testAssocResponse
In service_test_servicetestprobleminterface_ws.wsdl and service_test_servicetestprobleminterface_jms.wsdl, we see that in portType 'ServiceTestProblemInterface', the operation 'testAssoc' has only input and output, no fault.
<wsdl:portType name="ServiceTestProblemInterface"> <!--other operations--> <wsdl:operation name="testAssoc"> <wsdl:documentation><p>The request-response operation</p><p>Testing passing of association classes</p></wsdl:documentation> <wsdl:input name="testAssocRequest" message="tns:testAssocRequest"/> <wsdl:output name="testAssocResponse" message="tns:testAssocResponse"/> </wsdl:operation> </wsdl:portType>
Commonly used directive – Create (Not implemented in JOSIF 1.0)
Related to issue #81 in Mantis Commonly used directive – Create
Commonly used directive – Delete (Not implemented in JOSIF 1.0)
Related to issue #82 in Mantis Commonly used directive – Delete
Commonly used directive – Set (Not implemented in JOSIF 1.0)
Related to issue #83 in Mantis Commonly used directive – Set
Commonly used directive – Get (Not implemented in JOSIF 1.0)
Related to issue #84 in Mantis Commonly used directive – Get
Common exceptions support
Related to issue #344 in Mantis Common exceptions support
Pre-defined exception support
Related to issue #345 in Mantis Pre-defined exception support
Mapping Rule
For every non-oneway operation, in its message XSD file, the generator generates predefined exceptions, as well as specific exceptions, if any.
Example
In TIP SPM model, the interface org.tmforum.tip.service.problem.ServiceProblemCreateInterface has an operation createServiceProblem operation. The exception message of the operation is:
<xsd:element name="createServiceProblemException">
<xsd:complexType>
<xsd:choice>
<!--exception declared in TIP SPM model-->
<xsd:element name="unableToNotify" type="exceptions1:UnableToNotify"></xsd:element>
<xsd:element name="capacityExceeded" type="exceptions1:CapacityExceeded"></xsd:element>
<xsd:element name="duplicate" type="exceptions1:Duplicate"></xsd:element>
<!--pre-defined exceptions-->
<xsd:element name="accessDenied" type="exceptions:AccessDenied"/>
<xsd:element name="communicationLoss" type="exceptions:CommunicationLoss"/>
<xsd:element name="internalError" type="exceptions:InternalError"/>
<xsd:element name="invalidInput" type="exceptions:InvalidInput"/>
<xsd:element name="notImplemented" type="exceptions:NotImplemented"/>
<xsd:element name="unableToComply" type="exceptions:UnableToComply"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
Mapping Rules for Bindings
For every non-abstract sesson facade in a TIP model, one WSDL file will be generated. In JOSIF 1.0, the binding used in the WSDL is HTTP binding.
HTTP Binding
Mapping Rule
pattern of the wsdl HTTP binding:
<wsdl:binding name="${shortName of session facade}SoapHttpBinding" type="tns:${shortName of session facade}">
<wsdl:documentation><p>Web Service (SOAP/HTTP) profile binding definitions.</p></wsdl:documentation>
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsaw:UsingAddressing wsdl:required="true"/>
<wsdl:operation name="${short name of an operation}">
<soap:operation soapAction="${short name of the operation}" style="document"/>
<wsdl:input name="${short name of the operation}Request">
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output name="${short name of the operation}Response">
<soap:body use="literal"/>
</wsdl:output>
<wsdl:fault name="${short name of the operation}Exception">
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<!--other operations omitted-->
</wsdl:binding>
Note that for an one-way operation, only <wsdl:input /> part presents. We have <wsdl:fault /> if there at lease one exception is declared or injected.
Example
From session facade org.tmforum.tip.cbe.test.TestBulkInterface, Test1 model, a WSDL with HTTP binding is generated:
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:tns="http://www.tmforum.org/xml/tip/cbe/test" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" name="TestBulkInterface" targetNamespace="http://www.tmforum.org/xml/tip/cbe/test">
<wsdl:types>
<xsd:schema>
<xsd:import namespace="http://www.tmforum.org/xml/tip/cbe/test" schemaLocation="cbe_test_testbulkinterface_msg.xsd"/>
</xsd:schema>
</wsdl:types>
<wsdl:message name="getTestProblemsByIteratorRequest">
<wsdl:documentation><p>The operation request message.</p></wsdl:documentation>
<wsdl:part name="body" element="tns:getTestProblemsByIteratorRequest"/>
</wsdl:message>
<wsdl:message name="getTestProblemsByIteratorResponse">
<wsdl:documentation><p>The operation response message.</p></wsdl:documentation>
<wsdl:part name="body" element="tns:getTestProblemsByIteratorResponse"/>
</wsdl:message>
<wsdl:message name="getTestProblemsByFileTransferRequest">
<wsdl:documentation><p>The operation request message.</p></wsdl:documentation>
<wsdl:part name="body" element="tns:getTestProblemsByFileTransferRequest"/>
</wsdl:message>
<wsdl:message name="getTestProblemsByFileTransferResponse">
<wsdl:documentation><p>The operation response message.</p></wsdl:documentation>
<wsdl:part name="body" element="tns:getTestProblemsByFileTransferResponse"/>
</wsdl:message>
<wsdl:message name="setTestProblemsByIteratorRequest">
<wsdl:documentation><p>The operation request message.</p></wsdl:documentation>
<wsdl:part name="body" element="tns:setTestProblemsByIteratorRequest"/>
</wsdl:message>
<wsdl:message name="setTestProblemsByIteratorResponse">
<wsdl:documentation><p>The operation response message.</p></wsdl:documentation>
<wsdl:part name="body" element="tns:setTestProblemsByIteratorResponse"/>
</wsdl:message>
<wsdl:message name="setTestProblemsByFileTransferRequest">
<wsdl:documentation><p>The operation request message.</p></wsdl:documentation>
<wsdl:part name="body" element="tns:setTestProblemsByFileTransferRequest"/>
</wsdl:message>
<wsdl:message name="setTestProblemsByFileTransferResponse">
<wsdl:documentation><p>The operation response message.</p></wsdl:documentation>
<wsdl:part name="body" element="tns:setTestProblemsByFileTransferResponse"/>
</wsdl:message>
<wsdl:portType name="TestBulkInterface">
<wsdl:documentation><p>The portType of the service interface</p><p>Used to test various bulk transfer patterns.
Warning: operate on an abstract class. So only the inherited service interfaces should really implement the behaviour.</p></wsdl:documentation>
<wsdl:operation name="getTestProblemsByIterator">
<wsdl:documentation><p>The request-response operation</p><p>Return a list of service problems. Bulk out argument, with iterator pattern.</p></wsdl:documentation>
<wsdl:input name="getTestProblemsByIteratorRequest" message="tns:getTestProblemsByIteratorRequest"/>
<wsdl:output name="getTestProblemsByIteratorResponse" message="tns:getTestProblemsByIteratorResponse"/>
</wsdl:operation>
<wsdl:operation name="getTestProblemsByFileTransfer">
<wsdl:documentation><p>The request-response operation</p><p>Return a list of service problems. Bulk out argument, with file transfer pattern.</p></wsdl:documentation>
<wsdl:input name="getTestProblemsByFileTransferRequest" message="tns:getTestProblemsByFileTransferRequest"/>
<wsdl:output name="getTestProblemsByFileTransferResponse" message="tns:getTestProblemsByFileTransferResponse"/>
</wsdl:operation>
<wsdl:operation name="setTestProblemsByIterator">
<wsdl:documentation><p>The request-response operation</p><p>Set a list of service problems. Bulk in argument, with iterator pattern.</p></wsdl:documentation>
<wsdl:input name="setTestProblemsByIteratorRequest" message="tns:setTestProblemsByIteratorRequest"/>
<wsdl:output name="setTestProblemsByIteratorResponse" message="tns:setTestProblemsByIteratorResponse"/>
</wsdl:operation>
<wsdl:operation name="setTestProblemsByFileTransfer">
<wsdl:documentation><p>The request-response operation</p><p>Set a list of service problems. Bulk in argument, with file transfer pattern.</p></wsdl:documentation>
<wsdl:input name="setTestProblemsByFileTransferRequest" message="tns:setTestProblemsByFileTransferRequest"/>
<wsdl:output name="setTestProblemsByFileTransferResponse" message="tns:setTestProblemsByFileTransferResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="TestBulkInterfaceSoapHttpBinding" type="tns:TestBulkInterface">
<wsdl:documentation><p>Web Service (SOAP/HTTP) profile binding definitions.</p></wsdl:documentation>
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsaw:UsingAddressing wsdl:required="true"/>
<wsdl:operation name="getTestProblemsByIterator">
<soap:operation soapAction="getTestProblemsByIterator" style="document"/>
<wsdl:input name="getTestProblemsByIteratorRequest">
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output name="getTestProblemsByIteratorResponse">
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="getTestProblemsByFileTransfer">
<soap:operation soapAction="getTestProblemsByFileTransfer" style="document"/>
<wsdl:input name="getTestProblemsByFileTransferRequest">
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output name="getTestProblemsByFileTransferResponse">
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="setTestProblemsByIterator">
<soap:operation soapAction="setTestProblemsByIterator" style="document"/>
<wsdl:input name="setTestProblemsByIteratorRequest">
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output name="setTestProblemsByIteratorResponse">
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="setTestProblemsByFileTransfer">
<soap:operation soapAction="setTestProblemsByFileTransfer" style="document"/>
<wsdl:input name="setTestProblemsByFileTransferRequest">
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output name="setTestProblemsByFileTransferResponse">
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="TestBulkInterfaceWs">
<wsdl:documentation><p>This is a sample wsdl:service definition of the service interface
for an implementation using the WS profile (SOAP/HTTP binging).</p><p>This wsdl:service definition is usually used at implementation time
or WS registration/discovery of a specific WS instance.</p></wsdl:documentation>
<wsdl:port name="TestBulkInterfaceHttpPort" binding="tns:TestBulkInterfaceSoapHttpBinding">
<soap:address location="http://localhost/TestBulkInterface"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>