Introduction
In the recent years the presence of the Service Oriented Architecture (SOA) has redefined the concept of application. An application is no longer an opaque, procedural implementation mechanism. Instead, it is an orchestrated sequence of messaging, routing, processing, and transformation events capable of processing the exposed declarative properties of rich (XML) documents. BizTalk Server 2004 implements some of the most important SOA concepts applied to the integration environments. Well the main idea behind the BizTalk-UDDI Wizard is to add another important SOA concept to BizTalk: Discovery.
Discovery is one of the most important features required by all SOA based technologies. In the Web Services environments there are several technologies to provide discovery support like: WSIL, WS-Discovery and, one of the most popular, UDDI. UDDI is typically associated with Web Services; however its data model permits to represent almost any kind of information. Some technology providers uses UDDI to, for example, discover CORBA objects among other potentialities. However is a fact that the UDDI data model is very flexible to represent SOA based concepts.
The benefits of add discovery potentialities to BizTalk Server 2004 are obvious. Using UDDI publish BizTalk elements like orchestrations, Ports, Messages among others so it can be discovered dynamically by client applications. Also adds powerful categorization and interoperability features to BizTalk Server 2004. Well, if I continue explaining you the benefits of integrating UDDI and BizTalk I can't write the conclusions of this article, I think that we better continue with an overview of UDDI.
UDDI Overview
Universal Description Discovery & Integration (UDDI) defines a series of concepts that makes possible to publish and discovery information related with a set of services and their organizations. UDDI is typically associated with Web Services; however its data model permits to represent other type of information. Some technology providers uses UDDI to, for example, discover CORBA objects among other potentialities. Using UDDI the companies can provide discovery information of a set of resources and also discover information to interact with other services
The main component of UDDI is the registry in which the providers publish the information related with their organizations, services etc and make it available to discover by other programs. The UDDI registry is comprised by a set of UDDI nodes. Each UDDI node is member of exactly one UDDI registry and manipulates a well-defined set of UDDI data. Between the nodes of a UDDI registry may occur replication processes. The UDDI registry defines its information based of a set of primary concepts that we explore later. Using these concepts we can model the information related to our services and also other information that is used to categorize and identifies the services. One of the most remarkable potentialities of UDDI is the categorization features. In UDDI is possible to associate almost all elements in the model with set of categories that are relevant to the model creator. UDDI is the ideal components to dynamically discover services based of some keywords or well-defined feature, discover the transport protocol and, for example, the policy that describes the security requirements of services among other things.
One of the aspects that become UDDI so powerful is that the basic set of concepts makes possible to construct very complex models in different ways. The UDDI data model is formed fundamentally by four elements:
- BusinessEntity: Is one of the top-level data structures within UDDI, used to represent businesses and providers within UDDI. It contains descriptive information about the business or provider and about the services it offers. This would include information such as names and descriptions in multiple languages, contact information and classification information. Service descriptions and technical information are expressed within a BusinessEntity by contained BusinessService and BindingTemplate structures.
- BusinessServices: Each BusinessService structure represents a logical grouping of services. At the service level, there is still no technical information provided about those services; rather, this structure allows the ability to assemble a set of services under a common rubric. Each BusinessService is the logical child of a single businessEntity and contains descriptive information - again, names, descriptions and classification information -- outlining the purpose of the individual services found within it. For example, a BusinessService structure could contain a set of Purchase Order Web services (submission, confirmation and notification) that are provided by a business. At the BusinessService level no contact information should be provided. That is that when we define a BusinessService we don't have to set its entry points. This information is provided by the Binding Templates.
- tModels: Technical Models, or tModels for short, are used in UDDI to represent unique concepts or constructs. They provide a structure that allows re-use and, thus, standardization within a software framework. The UDDI information model is based on this notion of shared specifications and uses tModels to engender this behavior. For this reason, tModels exist outside the parent-child containment relationships between the BusinessEntity, BusinessService and BindingTemplate structures. TModels are typically used with two main purposes. The first is to represent specifications like HTTP or SOAP that are referenced by other items in a UDDI model. The second area is to categorize information. These tModels defines a set of values that later are used to categorize other Items. For example, a tModel may represent communication patterns and some possible values are: One-Way, Request-Response, Solicit-Response among others. Using this tModel we can, for instance, set the communication pattern followed by a BizTalk port.
- BindingTemplate: The BindingTemplate structure represents an individual Web service. In contrast with the businessService and businessEntity structures, which are oriented toward auxiliary information about providers and services, a bindingTemplate provides the technical information needed by applications to bind and interact with the Web service being described. It must contain either the access point for a given service or an indirection mechanism that will lead one to the access point.
The following figure shows the main concepts in UDDI.
![UDDI.gif]()
Figure 1: UDDI Data Model.
Mapping BizTalk elements to UDDI
To provide discovery support to BizTalk Server 2004 orchestration must exists a map between BizTalk elements to UDDI elements. The objective of this section is to explain the representation in UDDI of a set of key BizTalk concepts.
The key of this model relies in map some BizTalk Server 2004 elements to UDDI elements. The possibility to map elements from one data model to the other makes possible to represents BizTalk elements in UDDI in a way that can be discovered by process that interact with those elements.
One of the most interesting features from BizTalk Server 2004 is that some orchestrations can be exported to Web Services (asmx). Publishing Web services enables you to create a Web service that can submit messages to BizTalk Server for use by orchestrations and other send adapters. You create published Web services using the BizTalk Web Services Publishing Wizard. With this feature we can obtain a Web Services interface to a group of orchestrations. The methods in the Web Services are typically associated with a port's operations and when we invoke a method we send a SOAP messages that contains the data that activated the orchestrations. Is evident that exists a correspondence between the WSDL and orchestration elements. Messages Types, Port Types, messages and ports all have a WSDL equivalent. This similarity makes the Web Services generation process to easy. The main problem is the service equivalent. When we export an orchestration to Web Service for every public port that we select an .asmx Web Service is created with the operation equivalent to that port.
Another fantastic feature of BizTalk Server 2004 is the BPEL4WS support. BPEL4WS becomes in one of the most important Standard to Web Service orchestration. BPEL4WS is now supported by many vendors like Collaxa, IBM among others.
With BizTalk Server 2004 a group of orchestrations with a set of well defined charasteritics can be exported to BPEL4WS. A BPEL4WS process itself is described in WSDL.
Using these two features of BizTalk Server 2004 is extremely easy to obtain an UDDI representation of a group of orchestrations since exists a WSDL equivalent to the orchestrations. However the discovery process is not necessarily associated with a Web Services. There are a great number of processes that are not ready to move to Web Services environments I don't think that is a great idea to restrict the discovery process to the orchestrations that receive the input messages using the SOAP protocol. It is very common that a orchestration are associated with ports that receive messages in non-XML format like .pdf or others. Even if the orchestration does not present any problem to use SOAP protocol may exists other factors like infrastructure and organization interests that makes impossible to adopt the Web Service approach.
Well due the fact that BizTalk Server 2004 manages all the concepts present in the Service Oriented Architecture (SOA) and the notion of service is really present in one or a group of BizTalk orchestrations would be very interesting provide a representation of BizTalk elements in UDDI. Using this feature the orchestrations can now dynamically discover the activation ports of a service, the input messages schemas, the output locations among other interesting aspects.
Defining Business Services
A BusinessService represents the main unit to be discovery by client applications. The notion of BusinessService tries to abstract a business identity that is formed combining a set of orchestrations. The organizations may want to provide discovery information about its business process. May be a very common scenario in which a single business process groups together a set of orchestrations. This is due by the fact that one orchestration as part of its logic may deliver some messages that in turn activated other orchestrations. Also one orchestrations can explicit invoke another orchestrations as part of its logic. In both cases exists a relation between the caller and called orchestrations. The main difference is that in one case the relation is explicit (when the orchestration is invoked as part of the process). To the business purposes each single orchestrations does not have a meaning itself, however the business acquire sense when we combine a set of orchestration. An illustrative example could a classic shopping process in which may be involved an inventory actualization process and a credit card check process. What is really relevant to consumer applications, which will use a repository to discover business information, is that a service receives some types of messages using a predefined protocol for some address and produces a series of outputs. The inputs and outputs are derived from the orchestration's ports that are involved in the business process as a whole. Note that not all the input and output of the service may be relevant as discovery information. When we export a series of schemas to Web Service we can achieve a similar goal, however always using SOAP as input and output. Well resuming, for this version the relevant discovery information is that a BusinessService has a series of input and output ports. If the BusinessService is contained in a single orchestrations then all the input and output ports belongs to this orchestrations. If the BusinessService is the results of a combination of orchestrations then the inputs and outputs ports may belong to different orchestrations and has a relevance to the BusinessService purpose.
The following figure shows a BusinessService concept.
![BusinessService.gif]()
Figure 2: The BusinessService concept.
Defining a BusinessService makes possible to combine a set of orchestrations into a single unit that have a relevant identity to the discovery process.
Mapping BusinessService to uddi:BusinessService
This is a very simple mapping but is the main discovery unit in this architecture. A Business is directly mapped to a BusinessService in UDDI which in turn belongs to an organization which is the owner of the BusinessService. The only relevant information to a BusinessService is its name and description. Both are properties of the BusinessService. Well the map is showed in the following table.
| BizTalk |
UDDI |
| BusinessService |
BusinessService |
| Name |
BusinessService Name |
| Description |
BusinessService description |
Note that the BusinessService itself does not contain any information about communication and transport. This information is provided by the bindings. Suppose that we export the sample orchestration as a BusinessService the uddi:BusinessService created is showed below.
<?xml version="1.0" encoding="utf-8"?>
<serviceDetail xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" operator="UDDIRep" truncated="false" generic="2.0" xmlns="urn:uddi-org:api_v2">
<businessService serviceKey="59a60f97-4d5e-4a3c-9908-ced1ba0e296b" businessKey="7785706a-34f3-41c9-b027-02982f210598">
<name xml:lang="en">Lab1_SimpleSampleService</name>
<description xml:lang="en">A short description...</description>
<bindingTemplates>
<bindingTemplate>
...The BindingTemplate for theinput location
</bindingTemplate>
<bindingTemplate>
...The BindingTemplate for theoutput location
</bindingTemplate>
</bindingTemplates>
<categoryBag>
<keyedReference tModelKey="uuid:ad941f90-207a-4a8b-a298-fafdb21f4780" keyName="Biztalk Orchestration" keyValue="BusinessService" />
</categoryBag>
</businessService>
</serviceDetail>
Categorization schemes
One of the main advantages of use UDDI to publish BizTalk Server elements is the possibility to have these elements organized in categories. Using this feature we can query an UDDI registry to find a PortType that follows the Request-Response communication pattern and implements a "Provider" role, great. To categorize BizTalk elements we uses a set of well-defined tModels that must be deployed to the UDDI registry (these tModels are deployed to an UDDI registry when you run the UDDIRegConfig tool provided in the installation package). The following table describes the main categorization schemes.
|
tModel's name |
Description |
Valid values |
|
Biztalk_Types |
This tModel contains the different types used in the discovery process. |
PortTypes, Ports, Roles, BusinessService. |
|
Implemented_Roles |
This tModels contains the roles implemented by a set of orchestrations. |
The role's name. |
|
Used_Roles |
This tModels contains the roles used by a set of orchestrations. |
The role's name. |
|
BizTalk_PortTypeReference |
Follows the same idea of the PortType reference tModel uses when we publish a WSDL file in UDDI. |
The tModel's keys of the PortType tModels |
|
Communication_Pattern. |
Represent the communication pattern followed by a PortType |
OneWay, RequestResponse. |
|
Communication_Direction. |
Represents the communication direction followed by a Port. |
Send, Receive, Send-Receive, Receive-Send. |
|
Transport. |
Represent the transport used in Send or Receive locations. |
The transport identifier ex: HTTP, JMS. |
Mapping PortTypes to uddi:tModels
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 operations 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.
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.
|
BizTalk |
UDDI |
|
PortType |
PortType tModel |
|
PortType name |
TModel name |
|
Operations and MessageTypes |
OverviewDoc: Location of a WSDL document |
|
IMPLEMENTED Roles |
KeyedReference in CategoryBag.with the value of the roles |
|
USED Roles |
KeyedReference in CategoryBag with the value of the roles |
|
Communication Pattern |
KeyedReference in CategoryBag with the value of the communication pattern. |
|
Type |
KeyedReference in CategoryBag indicating that this tModel represents a PortType |
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. The following example gives us a more intuitive idea of the mapping process.
Suppose that we have a PortType with the following structure:
<om:Element Type="PortType" OID="e1231583-469c-4d3b-ae4d-34a3193753aa" ParentLink="Module_PortType" LowerBound="12.1" HigherBound="19.1">
<om:Property Name="Synchronous" Value="False" />
<om:Property Name="TypeModifier" Value="Public" />
<om:Property Name="ReportToAnalyst" Value="True" />
<om:Property Name="Name" Value="In_PortType" />
<om:Property Name="Signal" Value="True" />
<om:Element Type="OperationDeclaration" OID="20750b13-caed-4b45-ab11-7ad78eca49e0" ParentLink="PortType_OperationDeclaration" LowerBound="14.1" HigherBound="18.1">
<om:Property Name="OperationType" Value="OneWay" />
<om:Property Name="ReportToAnalyst" Value="True" />
<om:Property Name="Name" Value="MainOp" />
<om:Property Name="Signal" Value="True" />
<om:Element Type="MessageRef" OID="cae1d3cf-3524-47f2-957d-f7f656a63b87" ParentLink="OperationDeclaration_RequestMessageRef" LowerBound="16.13" HigherBound="16.22">
<om:Property Name="Ref" Value="Lab1_SimpleSample.InMsgType" />
<om:Property Name="ReportToAnalyst" Value="True" />
<om:Property Name="Name" Value="Request" />
<om:Property Name="Signal" Value="True" />
</om:Element>
</om:Element>
</om:Element>
When we export the orchestration to UDDI a tModel for the PortType will be created with the following structure.
<?xml version="1.0" encoding="utf-8"?>
<tModelDetail xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" operator="UDDIRep" generic="2.0" truncated="false" xmlns="urn:uddi-org:api_v2">
<tModel tModelKey="uuid:c811daba-7046-40c4-8601-2e7c419b01b5" operator="UDDIRep" authorizedName="LAURA\Administrator">
<name>Lab1_SimpleSample.In_PortType</name>
<description xml:lang="en" />
<overviewDoc>
<overviewURL>http://localhost/wsdls/Lab1_SimpleSample.In_PortTypeDesc.wsdl</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference tModelKey="uuid:a035a07c-f362-44dd-8f95-e2b134bf43b4" keyName="OneWay communication pattern" keyValue="OneWay" />
<keyedReference tModelKey="uuid:ad941f90-207a-4a8b-a298-fafdb21f4780" keyName="Biztalk Port Types" keyValue="PortTypes" />
<keyedReference tModelKey="uuid:779f5b2f-4553-49c4-bce8-1a001bfac0e6" keyName="" keyValue="uuid:cbe5def4-e786-4c40-9404-632dd2b6562b" />
</categoryBag>
</tModel>
</tModelDetail>
The Lab1_SimpleSample.In_PortTypeDesc.wsdl produced is a WSDL partial file showed below.
<definitions xmlns:s1="http://Lab1_SimpleSample.InSchema" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:s0="http://tempuri.org" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://tempuri.org" xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<s:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org">
<s:import namespace="http://Lab1_SimpleSample.InSchema" />
<s:element name="MainOp" nillable="true" type="s0:MainOp" />
<s:complexType name="MainOp">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded" ref="s1:Fields" />
</s:sequence>
</s:complexType>
</s:schema>
<s:schema elementFormDefault="qualified" targetNamespace="http://Lab1_SimpleSample.InSchema">
<s:element name="Fields" type="s:string" />
</s:schema>
</types>
<message name="MainOpIN">
<part name="parameters" element="s0:MainOp" />
</message>
<portType name="Lab1_SimpleSample.In_PortType">
<operation name="MainOp">
<input message="s0:MainOpIN" />
</operation>
</portType>
</definitions>
Mapping Port to uddi:PortBinding tModel
The information provided by a port may be interesting to the discovery point of view. What is really relevant to discovery is the data that describes the send and receives locations. The locations contain data that indicates the address where to send or receive messages such as file:///d:\temp\input.xml or http://testsite.org . The locations also contain data that identifies the transport protocol used to deliver the messages. The Port belongs to a PortType that describes its relevant qualities and which is mapped to an UDDI tModels as we have explained in the section above. Well; the address information is mapped directly to a bindingTemplate but is absolutely necessary to store the information relative to the used protocol. An interesting solution to this problem is to create a tModel per Port and location's transport pair. A little more detail about the solutions: any ports may have a set of locations and each location contains information about the address and transport used and, of course, all the Ports belong to a BusinessService. A Port can contain a number of locations that uses, for instance, HTTP as protocol for different address. Since to be fine, due the fact that the relevant information to store is the address and the protocol, think about group together the locations that use the same transport protocol and belongs to the same ports. Using this solution a tModel is created for each pair Port Transport where Transport is the protocol used by one location in the Port. Is very simple, this idea makes possible to eliminate redundancies in the model because only one tModel will be created for all locations that uses the same transport in a Port. Check out the steps in the map:
- For each pair transport protocol Port a tModel must be created.
- The tModel's name will be PortName_TransportName.
- The tModel have a reference to a categorization tModel indicating what transport protocol the tModel represents.
- The tModel have a reference to a categorization tModel indicating what direction the tModel represents (Send, Receive, Send-Receive, Receive-Send).
- The tModel have a reference to a categorization tModel indicating the PortType to which the Port belongs.
|
BizTalk |
UDDI |
|
Port |
PortBinding tModel |
|
Name |
Port's name _ Transport's name |
|
Port's PortType |
KeyedReference in CategoryBag.with the value of the PortType. |
|
Communication directions |
KeyedReference in CategoryBag.with the value of the communication direction. |
|
Transport protocol |
KeyedReference in CategoryBag.with the value of the transport protocol. |
Suppose that we have a Port that uses a FILE transport and has the following structure.
<om:Element Type="PortDeclaration" OID="aae167bd-d64d-4bb6-8192-d4cf23d1e8bb" ParentLink="ServiceDeclaration_PortDeclaration" LowerBound="29.1" HigherBound="31.1">
<om:Property Name="PortModifier" Value="Implements" />
<om:Property Name="Orientation" Value="Unbound" />
<om:Property Name="PortIndex" Value="-1" />
<om:Property Name="IsWebPort" Value="False" />
<om:Property Name="OrderedDelivery" Value="False" />
<om:Property Name="DeliveryNotification" Value="None" />
<om:Property Name="Type" Value="Lab1_SimpleSample.In_PortType" />
<om:Property Name="ParamDirection" Value="In" />
<om:Property Name="ReportToAnalyst" Value="True" />
<om:Property Name="Name" Value="In_Port" />
<om:Property Name="Signal" Value="True" />
<om:Element Type="PhysicalBindingAttribute" OID="f85f9b70-e0e7-48a5-be23-fe7fe5c90b11" ParentLink="PortDeclaration_CLRAttribute" LowerBound="29.1" HigherBound="30.1">
<om:Property Name="InPipeline" Value="Microsoft.BizTalk.DefaultPipelines.XMLReceive" />
<om:Property Name="OutPipeline" Value="Microsoft.BizTalk.DefaultPipelines.XMLTransmit" />
<om:Property Name="TransportType" Value="FILE" />
<om:Property Name="URI" Value="C:\In.xml" />
<om:Property Name="IsDynamic" Value="False" />
<om:Property Name="Signal" Value="False" />
</om:Element>
</om:Element>
The tModel produced is the following:
<?xml version="1.0" encoding="utf-8"?>
<tModelDetail xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" operator="UDDIRep" generic="2.0" truncated="false" xmlns="urn:uddi-org:api_v2">
<tModel tModelKey="uuid:fa417a6f-d649-447b-a39c-324187f5a937" operator="UDDIRep" authorizedName="LAURA\Administrator">
<name>Lab1_SimpleSample.Lab1_Orch_In_Port_FILE</name>
<categoryBag>
<keyedReference tModelKey="uuid:7deb4dfa-d705-4d9f-a700-0e520f516519" keyName="PortType reference" keyValue="uuid:c811daba-7046-40c4-8601-2e7c419b01b5" />
<keyedReference tModelKey="uuid:72158fcb-f4aa-4129-8b20-33b3a74ce01c" keyName="FILEtransport" keyValue="FILE" />
<keyedReference tModelKey="uuid:ee3c21aa-6b7e-4ed6-aff0-399d8a469103" keyName="Receive direction" keyValue="Receive" />
<keyedReference tModelKey="uuid:779f5b2f-4553-49c4-bce8-1a001bfac0e6" keyName="" keyValue="uuid:cbe5def4-e786-4c40-9404-632dd2b6562b" />
</categoryBag>
</tModel>
</tModelDetail>
As you can see the produced tModel contains a set of categories that indicates that it is a receive Port that uses a FILE protocol as transport and that belongs to the PortType represented by the uuid:cbe5def4-e786-4c40-9404-632dd2b6562b tModel's key.
Mapping location's address to uddi:bindingTemplate
The minimal information that will be mapped to a Business Service's bindingTemplate is only the location's address. Both input and output address will be mapped to bindingTemplate' AccessPoint and in the tModelInstanceInfo put a reference to the PortBinding tModel that have the same protocol of the location.
Suppose that we have an input port that are associated with a receive location that uses the FILE transport protocol with the address file://c:\In.xml. The BindingTemplate produced for this information is the following.
<?xml version="1.0" encoding="utf-8"?>
<bindingDetail xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" generic="2.0" operator="UDDIRep" truncated="false" xmlns="urn:uddi-org:api_v2">
<bindingTemplate serviceKey="59a60f97-4d5e-4a3c-9908-ced1ba0e296b" bindingKey="a2f7dc33-d463-4c63-b4df-a7f36da03175">
<accessPoint URLType="other">C:\In.xml</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey="uuid:fa417a6f-d649-447b-a39c-324187f5a937" />
</tModelInstanceDetails>
</bindingTemplate>
</bindingDetail>
We set the URL type to other due the increase number of adapters developed for BizTalk Server 2004. Must of the UDDI registries come with a fixed set of transports. The transport information is specified in the PortBinding tModels.
Where are We?
Until here we have explored the concepts of the model that makes possible map BizTalk Server 2004 elements to UDDI. This is the model that follows the BizTalk Server 2004 UDDI Publishing wizard that we plan to explain in the next article. Using this model we can publish BizTalk items to an UDDI registry in a way that they can be discovered by client applications.
Using UDDI we can attribute metadata to a set of orchestrations and then makes queries based of this metadata to discover key aspects of orchestrations. Adding discovery capabilities to BizTalk Server 2004 we add another level of abstraction in which we define the data relevant to discovery by the potential clients. This feature is called by various authors the reification of data, in English making data "real". That is, not necessarily all the elements in a set of orchestrations are relevant to the discovery point of view. Integrating BizTalk Server 2004 and UDDI adds a set of benefits to the SOA-based potentialities of BizTalk. Now we can publish that communicates via non SOAP-based protocols like FILE or MSMQ.
Another important benefit of adding discovery features to BizTalk Server 2004 is categorization. In UDDI BizTalk elements are associated with a set of categories and later use this categorization information in searches.h categorization schemes makes possible to have the BizTalk Server 2004 elements operly classified and organized
The implementations of the most popular UDDI registries are based on Web Services to facilitate the platform independence. When we publish BizTalk Server 2004 elements in UDDI this information becomes available to different types of clients, no matter the environments in which they are developed. Using these potentialities we add another interoperability option to BizTalk Server 2004. We can develop some J2EE based applications that query the UDDI registry to find information referred to some BizTalk applications. Using discovery we makes very flexible the dynamic interoperability between other integration platforms, like WebLogic Integration, WebLogic Server Process Editions, WebSphere Integration or TIBCO, with BizTalk Server 2004.
Using UDDI to publish BizTalk Server 2004 information adds a number of benefits to BizTalk developers. We can now build applications that dynamically query the UDDI registry to find the location where some process receive input messages or send output messages, the schema of input and output messages, the transport adapters used among other things.
Well, I hope that you have enjoyed this article. In the next part we cover the implementation and uses of the BizTalk Server 2004 Publishing Wizard.