7.3 WSDL to IDL Conversion

IDL specification is generated from a given WSDL according to the rules shown in the following sub-sections.

7.3.1 Generation of IDL Modules

A WSDL document may contain several different target namespaces associated with WSDL and XML constructs, which are translated to corresponding IDL constructs.

A WSDL description can contain multiple namespaces, including:

• The wsdl:definitions element can have its own target namespace.

• The wsdl:definition can use wsdl:import to import a wsdl namespace.

• Zero or more schema in the types section each have a target namespace (which is allowed, by WS-I profile, to be same as target namespace for the wsdl description).

• The schema in a types section can use xsd:import to import multiple namespaces.

An IDL module declaration is created from the WSDL <definitions> element.

The WSDL <definitions> element has two optional attributes, “targetNamespace? and “name.? An IDL module is generated for a WSDL file as described below:

2. If the targetNamespace attribute is not present, and the WSDL name attribute is present, the value of the WSDL name attribute is used as the IDL module name. No IDL typeprefix or #pragma prefix directive is generated in this case.

3. If neither targetNamespace nor the WSDL name attribute is present in the <definitions> element, then no IDL module is generated.

1. If the targetNamespace attribute is present for the WSDL <definitions> element, everything before the final “/? is mapped to IDL typeprefix or #pragma prefix directive in the generated IDL file. The portion of the targetNamespace after the final “/? is mapped as the IDL module name for the generated IDL definition. Any ‘:’ character is mapped

to an underscore ‘_’ character. If the generated module name contains a “.? or any special character, it is mapped to an underscore ‘_’ character.

Using the same algorithm as specified above to map from the target namespace value to an IDL module name and type prefix, the mapping from WSDL to IDL shall use a separate IDL module for each of the target namespaces that contain constructs that are mapped to IDL constructs.

For example:

<?xml version="1.0"?><definitions name="StockQuote" ...>

......</definitions>

is mapped to IDL as follows:

// OMG IDL

module StockQuote {……

};

The following WSDL construct maps as shown below

<?xml version="1.0"?><definitions name="StockQuote"

targetNamespace=?http://example.com/stockquote.wsdl?

... >......

</definitions>

In pre-CORBA 3.0 IDL using pragma prefix as shown below:

// OMG IDL

#pragma prefix “http_//example.com?

module stockquote_wsdl {……

};

Or in CORBA 3.0 or later IDL using typeprefix as shown below:

// OMG IDL

module stockquote_wsdl {

typeprefix stockquote_wsdl “http_//example.com?;……

};

7.3.2 Generation of IDL Interfaces

An IDL interface declaration is created for each WSDL <portType> defined in the WSDL file.

The value of the name attribute of WSDL <portType> element is used as the IDL interface name.

For example:

<portType name="StockQuotePortType">......

</portType>

is mapped to IDL as follows:

// OMG IDL

interface StockQuotePortType {……

};

7.3.3 Generation of IDL Operations

An IDL operation declaration is created for each WSDL <operation> element appearing inside a WSDL <portType> element.

The syntax of an IDL operation declaration is given below. It consists of operation name <op_name>, operation return type <return_type>, a comma separated list of parameters <parameter>, and optional raises and context expression, each of which is generated from the WSDL <operation> element as mentioned below:

<return_type> <op_name> ( <parameter> [, ]) [ raises ( exception_ name [, ] ) ] [ context ( context_name [, ] ) ];

Operation name:

The IDL operation name <op_name> is generated from the value of the name attribute in <operation> element in WSDL <portType> declaration.

Operation type:

WSDL defines four types of operations: One-way, Request-response, Solicit-response, and Notification. All of these are mapped to normal IDL operations. If only <input> message element exists in the <portType> element, then it is mapped to an IDL operation with return type void and with no output parameters. IDL oneway opera-tions are not used.

Data type of return value:

The return type of the IDL operation is determined based on the following rules:

• If the Operation is of Request-Response format, the return type is the first part under the element <wsdl:output> if that part doesn’t appear in the “parameterOrder? list. Otherwise the return type is void.

• If the Operation is of Solicit-Response format, the return type is the first part under the element <wsdl:input> if that part doesn’t appear in the “parameterOrder? list. Otherwise the return type is void.

• If it is One-Way or Notification, the return type is void.

Parameters:

An IDL <parameter> is generated for each WSDL <part> element appearing inside a WSDL <message> element.

The syntax of the IDL operation parameter is given below. IDL supports “in,? “out,? and “inout? parameter attributes.

inout data_type parameter_nameinout

IDL operation parameter generation is determined based on the following rules.

1. If the parameterOrder attribute is specified in the <wsdl:operation> element in <portType> declaration, parameter list is returned in the same order specified as the parts in the parameterOrder attribute. Each parameter type is determined as follows:

• Part that is specified in both a Request/Solicit message and a Response message will be an “inout? parameter.

• Part that is specified only in a Request/Solicit message will be an “in? parameter. One-Way, Notification will only have “in? parameters.

• Part that is specified only in Response message will be an “out? parameter.

2. If the parameterOrder attribute is not specified in the <wsdl:operation> element in <portType> declaration, it is determined as follows:

• Construct a list of all the parts in Request/Solicit/One-Way/Notification messages in the order of parts specified, excluding the first part of the Response message of Request/Solicit-Response operations.

• Use the list as if specified for the parameterOrder attribute and process accordingly.

If the <part> element specifies “element? attribute instead of “type,? it points to the Schema that defines the element. This becomes the “in? parameter if the ‘message’ is referred by <wsdl:input> element in a <wsdl:operation> element in <wsdl:portType>, or the “out? parameter if the ‘message’ is referred by <wsdl:output> element and appears in the parameterOrder attribute. If the <wsdl:output> element doesn’t appear in the parameter-Order attribute, then it becomes the return type.

Raises expressions:

If <wsdl:fault> exists in an <operation> element inside a <portType> element, it is mapped to an IDL User Exception, and a raises expression is generated for the corresponding IDL operation declaration. The generated raises expression lists all the mapped user exceptions for that IDL operation.

The name of the generated IDL User Exception is the value of the name attribute in the <wsdl:fault> element. The generated User Exception structure consists of mapped data members that are a list of “parts? that comprise the <wsdl:message> pointed to by the fault message name in <wsdl:fault> element (<wsdl:fault name="fault_message_name">).

Refer to Section 7.3.6, “Generation of User Exceptions,? on page 11 for an example mapping.

Context expressions:

Context expression is not generated. It is not necessary for SOAP.

The following is an example of mapping a WSDL <operation> element to an IDL operation.

</message>

</message>

</operation></portType>

The above WSDL fragment is mapped to an IDL operation as follows:

// OMG IDL

interface StockQuotePortType {wstring GetTradePrices(in wstring tickerSymbol, in long timePeriod, out float frequency);};

7.3.4 Generation of IDL Attributes

IDL attributes are not generated from WSDL.

7.3.5 Generation of IDL Typedef

An IDL typedef is generated for the XML schema type restrictions for XML schema data types used as the datatype of return values and parameters.

For example:

<xsd:simpleType name="Number"><xsd:restriction base="xsd:int"/>

</xsd:simpleType>

<xsd:simpleType name="AnotherNumber"><xsd:restriction base="Number"/></xsd:simpleType>

is mapped to the following IDL:

// OMG IDL

typedef long Number;typedef Number AnotherNumber;

7.3.6 Generation of User Exceptions

If <wsdl:fault> exists in an <operation> element inside a <portType> element, it is mapped to an IDL User Exception.

The name of the generated IDL User Exception is the value of the name attribute in the <wsdl:fault> element. The generated User Exception structure consists of mapped data members that are lists of “parts? that comprise the <wsdl:message> pointed to by the fault message name in <wsdl:fault> element (<wsdl:fault name="fault_message_name">).

For example:

</message>

</operation></portType>

is mapped to IDL as follows:

// OMG IDL

interface StockQuotePortType {

exception BadInput {wstring errorMessage;long errorCode;

};

GetTradePrices( … ) raises BadInput;};