TIP Soap Generator Mapping Rules - Part IV

Owned by Craig Gallen [Administrator] (Unlicensed)
Last updated: Feb 12, 2013Version comment
15 min read

JOSIF Main Page | JOSIF Framework | TIP Soap Generator | TIP Soap Generator Mapping Rules - Part IV

Mapping Rules for Session Facade

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 Rule for Attributes, Association Ends, and Parameters

TIP_Soap_Generator_Mapping_Rules_-_Part_III#Mapping_Rules_for_Operations CANNOT FIND THIS

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#Service Interface; 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

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#tipOperation; BulkTransferPattern - Iterator

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

refer to  TIP Soap Generator Mapping Rules - Part I#Mapping Rule for Attributes, Association Ends, and Parameters

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

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#tipOperation; BulkTransferPattern - Iterator

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>