Mapping PortTypes to tModels

One of the most interesting aspect in the BizTalk Server 2004 UDDI Publishing Wizard is the process of map a PortType to an UDDI equivalent,

The PortType element in a BizTalk Server 2004 orchestration is very similar to the PortType element in WSDL. Following the OASIS Standard when we provide discovery information to a Web Service using UDDI the PortType element in WSDL is mapped to a PortType tModel and the OverviewDoc of this tModel reference to a WSDL address.

In BizTalk Server 2004 a PortType is an abstraction that has the common qualities of a set of Ports.  A PortType have a communication pattern that indicates if a PortType is follow the One-Way or Request-Response approach.  A PortType also have a set of operations which has messages operations; in the case off One-Way PortType all operation has one message operations in the other case all operations have a Request and a Response message operations. A message operation works with a message that belongs to a MessageType. In the same way of PortTypes MesssageTypes abstract the common aspects to a set of messages.  A PortType can be associated with a set of roles. Roles are collections of port types, and each role either uses a service (as a consumer) or implements a service (as a provider). A role link can include either a uses or implements role, or one of each. A uses role consumes the services provided by an implements role. When you define a role link with one or both of these roles, it is assumed that the complementary role is being fulfilled by the partner with whom you are linking. If a role uses a service, it sends a message to a party that implements a service; conversely, if a role implements a service, it receives a message.

Well until here we have seen some relevant aspects of PortTypes. Now let’s check how to map a BizTalk Server 2004 PortType to an UDDI tModel.

The process of representing discovery information of a PortType in UDDI may be the following:

• For each relevant PortType a PortType tModel must be created (a relevant PortType is simply a PortType of the Ports of a BusinessService).
• The name of the tModel is the name of the PortType which is unique per MessageBox DB.
• The tModel have a reference to a categorization tModel indicating that the tModel is a BizTalk PortType.
• The tModel have a reference to a categorization tModel indicating if the PortType follows the One-Way or Request-Response communication pattern.
• The tModel have a reference to a categorization tModel referencing USED roles associated with the PortType.
• The tModel have a reference to a categorization tModel referencing the IMPLEMENTED roles associated with the PortType.
• For each PortType a WSDL file will be generated that contains the type, message and PortType sections.  That is, a WSDL without the binding and the service sections since the BusinessService are not necessarily tied to SOAP protocol. Using this WSDL file the application that consumes the BusinessService can explore all the relevant information to the Operations and MessageTypes. The generated WSDL file is very similar to the WSDL file that we obtain when export n orchestration to Web Service. 

Using this information the client applications can discover the communication pattern of a PortType, the roles that this PortType uses and implements and obtain a reference to a WSDL file that provides all the information to the PortType operations and the XML schema of the message that interact with the Port that belongs to the PortType.

Well in the orchestration used as example we have a PortType with the following structure.

When we export the orchestration to UDDI (Sample 1) a tModel for the PortType will be created with the following structure.

The Lab1_SimpleSample.In_PortTypeDesc.wsdl is a WSDL partial file showed below.