Architectural Overview of ebXML

The experiences of EDI taught us that in the real world, for business-to-business (B2B) collaboration to work successfully a lot more is required than just exchanging documents. One has to deal with issues surrounding business process semantics, negotiating terms and conditions, interoperability, security, reliability, and so on. The inner circle in Figure 7.1 shows the different areas surrounding business collaboration that two partners need to address and the steps the partners must go through to realize the B2B collaboration:

1. Process definition. A community or consortium of trading partners defines the business processes to be used in the community according to a well-known domain model and describes them in agreed-upon formats. In ebXML, this is realized using UML and XML. Examples of such consortiums are the Open Travel Alliance (www.opentravel.org), which includes more than one hundred key players in the travel industry; the Global Commerce Initiative (www.globalcommerceinitiative.org), a group of manufacturers and retailers of consumer goods; and the Automotive Industry Action Group (www.aiag.org), of key players in the automotive industry.

2. Partner discovery. For two partners to engage, there must be some form of discovery about each other's services and business processes. In ebXML, this is realized using a registry-repository.

3. Partner sign-up. Partners negotiate their business level and transaction level agreements. In ebXML, these are realized as a Collaboration-Protocol Profile (CPP) and Collaboration-Protocol Agreement (CPA).

4. Electronic plug-in. The trading partners configure their interfaces and software according to the agreed-upon business processes and details of the collaborating partner.

5. Process execution. Business services collaborate to do and execute the agreed-upon business processes.

6. Process management. The business processes defined in the process definition phase (1) and agreed upon in the partner sign-up phase (3) are monitored and facilitated by process management services.

7. Process evolution. The partners evaluate their existing processes, improve them through process re-engineering if necessary, and create new processes to meet the needs of the market. Process evolution brings us back to process definition, since the new processes will be defined according to the domain model and published in the community.

Figure 7.1: ebXML frameworks (adapted from the ebXML Business Process Specification Schema)

All of the above can be broadly categorized into two groups as Figure 7.2 shows: design time (things that need to be done before the actual collaboration can be realized) and runtime-(things that are involved in the physical B2B exchange). Let us look at this architecture in further detail.

Figure 7.2: Design-time and runtime components

Business Process Specifications

In an electronic exchange, a business document conveys complete intent about the product. For example, when you order books online, the request implicitly or explicitly specifies

• Who are the parties involved (the buyer and the seller).

• What commodity or product is involved.

• When events occur (e.g., credit checks, inspections, shipping).

• Where the product is located.

• How it is going to be handled, shipped, packaged, and so on.

The ebXML business-process model specifies how this information can be captured in an XML format partners can use to configure their ebXML services that execute the business process. The ebXML Business Process Specification Schema (BPSS) specifies this schema that is captured through some business process modeling. To model the business process using object-oriented principles, ebXML defines a complete methodology, called UN/CEFACT modeling methodology (UMM), based on UML and XML. In the grand scheme of things, BPSS is expected to be produced as a result of business modeling using UMM, but UMM is not required. Any business process editor is capable of producing the standard schema, using its own modeling techniques. A few tools already support this. Figure 7.3 shows the Bind Studio product that graphically models the collaboration between Flute Bank and OfficeMin (in which Flute Bank uses OfficeMin as its vendor for office supplies—see Chapter 11) to generate the BPSS and CPP/CPA documents.

Figure 7.3: Graphic process modeling and the Business Process Specification Schema

The BPSS document (schema instance) generated is an XML representation of the use cases. As Figure 7.4 shows it models a business process as a set of collaborations composed of discrete transactions. For example the document in Listing 7.1 shows how a collaboration is composed of a create order transaction between Flute Bank and OfficeMin, their roles (buyer, seller), and the states in that activity (success/failure).

Figure 7.4: Use cases map to collaborations grouped as discrete transactions (adapted from the ebXML Business Process Specification Schema)

Listing 7.1: The BPSS document

 <?xml version="1.0" encoding="UTF-8"?> <ProcessSpecification name="flutebank-officemin" uu version=                                                                                 "1.0">     <BusinessDocument name="Purchase Order" namespecificationElement=       "$namespace=publicid:org.xCBL:schemas/XCBL35/OrderRequest.xsd$type=OrderRequest"       specificationLocation="http://www.flutebank.com/db/schemalibrary/xCBL/XSDL3.5/                                                                    OrderRequest.xsd"/>     <BusinessTransaction name="Create Order" name                                                         pattern="BusinessTransaction">        <RequestingBusinessActivity isAuthorizationRequired="true"             isIntelligibleCheckRequired="false" isNonRepudiationReceiptRequired="true"             isNonRepudiationRequired="true" name="Create OrderRequest" name                      timeToAcknowledgeAcceptance="P6H" timeToAcknowledgeReceipt="P2H">           <DocumentEnvelope businessDocument="Purchase Order" businessDocumentIDRef=                                                                              "BPID_2">              <Attachment businessDocument="Delivery Instructions"                                                         businessDocumentIDRef="BPID_9"                      isAuthenticated="true" isConfidential="true" isTamperProof="true"                      mimeType="text/xml" name="Delivery Notes" name/>           </DocumentEnvelope>        </RequestingBusinessActivity>        <RespondingBusinessActivity isAuthorizationRequired="true"                                                    isIntelligibleCheckRequired="false"                isNonRepudiationReceiptRequired="false" isNonRepudiationRequired="true"                name="OrderResponse" name timeToAcknowledgeReceipt="P2H">           <DocumentEnvelope businessDocument="PO Acknowledgement"                                                         businessDocumentIDRef="BPID_3"                      isAuthenticated="false" isConfidential="false"                      isPositiveResponse="true"   isTamperProof="false"/>           <DocumentEnvelope businessDocument="PO Rejection" businessDocumentIDRef=                                                                               "BPID_4"                      isAuthenticated="false" isConfidential="false"                      isPositiveResponse="false" isTamperProof="false"/>        </RespondingBusinessActivity>     </BusinessTransaction> <BinaryCollaboration name="Firm Order" name>        <InitiatingRole name="buyer" name/>        <RespondingRole name="seller" name/>        <BusinessTransactionActivity businessTransaction="Create Order"                                                      businessTransactionIDRef="BPID_6"                      fromAuthorizedRole="buyer" fromAuthorizedRoleIDRef="BPID_12"                      isConcurrent="false" isLegallyBinding="false" name="Create Order"                      name timeToPerform="P1D" toAuthorizedRole="seller"                      toAuthorizedRoleIDRef="BPID_13"/>  <Start toBusinessState="Create Order" toBusinessStateIDRef="BPID_14"/>   <Success conditionGuard="Success" fromBusinessState="Create Order"                                                     fromBusinessStateIDRef="BPID_14"/>  <Failure conditionGuard="AnyFailure" fromBusinessState="Create Order"                                                     fromBusinessStateIDRef="BPID_14"/> </BinaryCollaboration> </ProcessSpecification> 

Partner Profiles and Agreements

For an organization to communicate with a business partner, it needs to know what the other end is capable of doing. We looked at how a business process can be modeled as business collaboration. The Collaboration-Protocol Profile describes an organization's functional and technical capabilities, such as:

• The business processes in which it can participate

• The roles played in the processes (e.g., seller, shipper)

• The transport protocols (e.g., HTTP, SMTP)

• The messaging protocols (ebXML messaging)

• The security aspects (digital signatures, etc.)

The concept of a Collaboration-Protocol Profile is a bit of a misnomer, since it doesn't refer to a protocol (as in networking protocol) but describes the information necessary for another partner to engage in a collaboration with it.

A CPP is an XML document that is governed by the schema defined in the ebXML collaboration protocol profile and agreement specifications. All partners register their CPP documents in an ebXML registry, so that other partners can discover them, understand the supported processes, and make choices where necessary (e.g., to HTTP or SMTP) on their side. Listing 7.2 shows a sample CPP used by OfficeMin.

Listing 7.2: The CPP document

 <?xml version="1.0" encoding="UTF-8"?> <CollaborationProtocolProfile xmlns="http://www.ebxml.org/namespaces/tradePartner"     xmlns:xlink="http://www.w3.org/1999/xlink"     xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xsi:schemaLocation="http://www.ebxml.org/namespaces/tradePartner                       http://ebxml.org/project_teams/trade_partner/cpp-cpa-v1_0.xsd" >     <PartyInfo>        <PartyId>urn:www.officemin.com</PartyId>        <PartyRef xlink:href="http://www.officemin.com/about.html" xlink:type="simple"/>        <CollaborationRole >           <ProcessSpecification xlink:href="flutebank-officemin"                                  name="Firm Order" xlink:type="simple" version="1.0"/>           <Role xlink:href="flutebank-officemin#seller" name="seller" xlink:type=                                                                             "simple"/>           <ServiceBinding channel package>              <Service type="uriReference">/flutebank-officemin/Firm Order/seller                                                                             </Service>           </ServiceBinding>        </CollaborationRole>        <Certificate cert>           <ds:KeyInfo/>        </Certificate>        <DeliveryChannel channel docExchange transport>           <Characteristics authenticated="false" authorized="false" confidentiality=                                                                                "false"                         nonrepudiationOfOrigin="false" nonrepudiationOfReceipt="false"                         secureTransport="false" syncReplyMode="none"/>        </DeliveryChannel>        <Transport transport>           <SendingProtocol version="1.0">HTTP</SendingProtocol>           <ReceivingProtocol version="1.0">HTTP</ReceivingProtocol>           <Endpoint type="allPurpose" uri="http://MACHINEB:80/bindpartner/servlet/                                                                   BindMessageRouter"/>        </Transport>        <DocExchange docExchange>           <ebXMLBinding version="1.0">              <ReliableMessaging deliverySemantics="OnceAndOnlyOncet"                                                                    idempotency="false"                         messageOrderSemantics="NotGuaranteed">                 <Retries>0<</Retries>                 <RetryInterval>0</RetryInterval>                 <PersistDuration>P</PersistDuration>              </ReliableMessaging>           </ebXMLBinding>        </DocExchange>     </PartyInfo>     <Packaging >        <ProcessingCapabilities generate="true" parse="true"/>        <SimplePart  mimetype="text/xml"/>     </Packaging> </CollaborationProtocolProfile> 

Figure 7.5 shows the key elements of the CPP. These are:

• PartyInfo. Specifies the organization described in the CPP.

• PartyId. A unique identifier, such as a D-U-N-S code, or an industry-specific identifier, such as an airline carrier code.

• PartyRef. Describes the business partner. It can be a URL or point to an item in the repository.

• CollaborationRole. Describes the business process supported and the roles derived from the BPSS XML document (see Listing 7.1).

• Certificate. Defines the digital certificate, such as an X.509 certificate, used by the organization for nonrepudiation or authentication.

• DeliveryChannel. Defines the transport and message protocols organization supports.

• Transport. Describes the details of the messaging transport protocol, such as type, version, and endpoint.

• DocExchange. Describes the semantics of the messaging service, such as how the message is encoded, retries, deliveries, digital envelope for encryption, and namespaces.

Figure 7.5: The XML elements in a Collaboration-Protocol Profile

A CPP is an XML document that defines the capabilities of a particular organization. An organization can be represented by multiple CPP documents.

The second aspect of collaboration deals with how CPP documents for two organizations intersect. The Collaboration-Protocol Agreement defines the system level agreement for data interchange between partners, in the sense that it narrows down a subset from what both partners can support to what both partners will actually support in the exchange. A good example is the transport protocol. OfficeMin may specify HTTP and SMTP in its Collaboration-Protocol Profile, but Flute Bank can do only HTTP. The Collaboration-Protocol Agreement specifies that the ebXML exchange between the two organization will occur using the messaging service over HTTP, based on the requirements for business processes that both partners mutually agree upon.

As Figure 7.6 shows, the CPA serves, in essence, as a sort of service level agreement that, once agreed to by both parties, can be enforced by the ebXML systems on both ends of the communication. Listing 7.3 shows a sample CPA between OfficeMin and Flute Bank.

Figure 7.6: A Collaboration-Protocol Agreement is agreed upon based on the Collaboration-Protocol Profile documents

Listing 7.3: The CPA document

 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE CollaborationProtocolAgreement SYSTEM "http://ebxml.org/project_teams/trade_                                                             partner/cpp-cpa-v1_0.dtd"> <CollaborationProtocolAgreement cpa xmlns="http://                                                 www.ebxml.org/namespaces/tradePartner"     xmlns:xlink="http://www.w3.org/1999/xlink"     xmlns:ds="http://www.w3.org/2000/09/xmldsig#">     <Status value="proposed"/>     <Start>2001-05-15T17:08:03.062</Start>     <End>2032-09-27T09:16:06.124</End>     <ConversationConstraints concurrentConversations="100" invocationLimit="10000"/>     <PartyInfo>        <PartyId>urn:www.officemin.com</PartyId>        <PartyRef xlink:href="" xlink:type="simple"/>        <CollaborationRole >           <ProcessSpecification xlink:href="flutebank-officemin" name="Firm Order"                                 xlink:type="simple" version="1.0"/>           <Role xlink:href="flutebank-officemin#seller" name="seller" xlink:type=                                                                             "simple"/>           <ServiceBinding channel package>              <Service type="uriReference">/flutebank-officemin/Firm Order/seller                                                                             </Service>           </ServiceBinding>        </CollaborationRole>        <Certificate cert>           <ds:KeyInfo/>        </Certificate>        <DeliveryChannel channel docExchange transport>           <Characteristics authenticated="false" authorized="false"                            confidentiality="false" nonrepudiationOfOrigin="false"                            nonrepudiationOfReceipt="false" secureTransport="false"                            syncReplyMode="none"/>        </DeliveryChannel>        <Transport transport>           <SendingProtocol version="1.0">HTTP</SendingProtocol>           <ReceivingProtocol version="1.0">HTTP</ReceivingProtocol>           <Endpoint type="allPurpose" uri="http://machine2:80/bindpartner/servlet/                                                                   BindMessageRouter"/>        </Transport>        <DocExchange docExchange>           <ebXMLBinding version="1.0">              <ReliableMessaging deliverySemantics="BestEffort" idempotency="false"                                 messageOrderSemantics="NotGuaranteed">                 <Retries>0</Retries>                 <RetryInterval>0</RetryInterval>                 <PersistDuration>P</PersistDuration>              </ReliableMessaging>           </ebXMLBinding>        </DocExchange>     </PartyInfo>     <PartyInfo>        <PartyId>urn:www.flutebank.com </PartyId>        <PartyRef xlink:href="" xlink:type="simple"/>        <CollaborationRole >           <ProcessSpecification xlink:href="flutebank-officemin" name="Firm Order"                                 link:type="simple" version="1.0"/>           <Role xlink:href="flutebank-officemin#buyer" name="buyer" xlink:type=                                                                             "simple"/>           <ServiceBinding channel package>              <Service type="uriReference">/flutebank-officemin/Firm Order/buyer                                                                             </Service>           </ServiceBinding>        </CollaborationRole>        <Certificate cert>           <ds:KeyInfo/>        </Certificate>        <DeliveryChannel channel docExchange transport>           <Characteristics authenticated="false" authorized="false"                            confidentiality="false" nonrepudiationOfOrigin="false"                            nonrepudiationOfReceipt="false" secureTransport="false"                            syncReplyMode="none"/>        </DeliveryChannel>        <Transport transport>           <SendingProtocol version="1.0">HTTP</SendingProtocol>>           <ReceivingProtocol version="1.0">HTTP</ReceivingProtocol>           <Endpoint type="allPurpose" uri="http://machineA:80/bindpartner/servlet/                                                                   BindMessageRouter"/>        </Transport>        <DocExchange docExchange>           <ebXMLBinding version="1.0">              <ReliableMessaging deliverySemantics="BestEffort" idempotency="false"                                 messageOrderSemantics="NotGuaranteed">                 <Retries>0</Retries>                 <RetryInterval>0</RetryInterval>                 <PersistDuration>P</PersistDuration>              </ReliableMessaging>           </ebXMLBinding>        </DocExchange>     </PartyInfo>     <Packaging >        <ProcessingCapabilities generate="true" parse="true"/>        <SimplePart  mimetype="text/xml"/>     </Packaging> </CollaborationProtocolAgreement> 

A CPA is an XML document that describes the agreement on the business conversation between two partners based on their CPP documents.

Figure 7.7 shows the key XML elements of a Collaboration-Protocol Agreement:

• Status. One partner generates a Collaboration-Protocol Agreement and offers it to the other for approval. The status element describes the stage of agreement the CPA has reached between them. It can take only the discrete values of proposed, agreed, and signed.

• Start and End. The Start and End elements represent the beginning and end of the period during which this Collaboration-Protocol Agreement is active.

• ConversationConstraints. This optional element describes the number of conversations that may be held under this CPA and the number that may be held concurrently.

• PartyInfo. This is the same as the PartyInfo in the Collaboration-Protocol Profile and is used to describe the information for each partner. Note that there must be two and only two PartyInfo elements in a CPA, because a CPA is between two business partners.

• PackagingInfo. Describes the ebXML (SOAP) message headers and the attachment and its associated properties for security, MIME content, namespaces, and so on.

• Signature. Describes the digital signature as per the XML-DSIG specifications and namespace (at www.w3.org/2000/09/xmldsig#).

Figure 7.7: The XML elements in a Collaboration-Protocol Agreement

JWSDL JSR-157, lead by Sybase and Cyclone Commerce, is a work in progress to provide a standard set of Java APIs for representing and manipulating CPP/CPA documents.

Having taken a look at the BPSS and CPP-CPA, let us redraw Figure 7.2 with more detail in it to elaborate on the design-time and runtime aspects of this collaboration. This is shown in Figure 7.8. Clearly, the registry is a central interaction point between the two partners. Let us now look at this in more detail.

Figure 7.8: Design-time and runtime components in detail

ebXML Registry-Repository Service

In Chapter 6, we talked about registries and their role in a business exchange. In this chapter, we will focus on the ebXML registry service and model. An ebXML registry is similar in concept to the UDDI registry but much broader in scope. In general, a registry is an important block in a business collaboration, because it serves as a central point where an organization can describe itself and its services, business semantics, and processes for other partners to retrieve.

The ebXML a registry is composed of two different concepts—registry and repository. Because of this, the ebXML registry is often referred to as the reg-rep. A registry is what we discussed when we were talking about UDDI, in that a registry stores information about items, not the items themselves. A repository, on the other hand, is where the items are physically stored; it serves as a database that is exposed by the services of a registry. Together, they provide key functions, including discovery-storage of information and discovery-storage of information assets. This is the fundamental difference between UDDI and ebXML.

The ebXML registry service is described by two specifications that separate the static and dynamic structures of the registry into two discrete, object-oriented views:

• The ebXML Registry Information Model (RIM) describes the registry's static representation in terms of a model or the blueprints for the registry's logical design.

• The ebXML Registry Services Specification describes the registry's dynamic structure in terms of its interfaces and API.

ebXML registry architecture is specified using UML notation and can be implemented in any programming language. This chapter gives you an overview of what is involved in the Registry Information Model. We will take a closer look at RIM and registry services in Chapter 12.

The Registry Information Model describes in terms of metadata the structures and relationships that can be stored in the registry. It is not a database schema or the registry content; it is simply an object-oriented roadmap of the data. To understand this further, recall the structures discussed about UDDI; namely, the tModels, businessEntity, businessService, and so on. That was the information model for UDDI. The ebXML information model is actually richer than the UDDI model and also more intuitive in terms of its terminology, as Figure 7.9 shows.

Figure 7.9: Relationships in the Registry Information Model

Figure 7.10 shows a more detailed view of the information model. Organizations have Users and Service objects that may be classified based on a ClassificationScheme. All items that represent stored metadata in the registry are subclasses of a RegistryObject. A RegistryObject can have AuditableEvents and Classifications associated with it.

Figure 7.10: ebXML Registry Information Model (source— ebXML RIM specifications)

The ebXML Registry Services Specification defines the registry service in abstract terms, using:

• A set of interfaces that must be exposed by the registry

• The set of operations that must be supported in each interface

• The parameters and responses that must be supported by each operation

These interfaces and operations are not defined in a particular programming language but are specified in abstract terms and use XML to describe the interactions. The ebXML registry is abstracted using the notion of a LifeCycleManager and a QueryManager interface, as Figure 7.11 shows. The LifeCycleManager is responsible for exposing operations relating to the creation and management of registry objects defined in the RIM. The QueryManager interface specifies operations for querying the registry and the underlying content in the repository. The client is abstracted using a RegistryClient interface that the registry can use for callbacks.

Figure 7.11: Registry interfaces

To understand how the abstractions are used, let us look at an example. The LifeCycleManager defines an operation called SubmitObjects, which clients can use to submit data to the registry, as Figure 7.11 shows. The operation takes a SubmitObjectRequest as an argument, and the registry responds by invoking the onResponse method in the RegistryClient. Each of these abstractions (SubmitObjectsRequest, RegistryResponse etc) is defined using an XML schema. The registry service itself can be implemented in any programming language, as long as the interface supports this schema.

The registry service interface schema is defined at www.oasis-open.org/committees/regrep/documents/2.0/schema/rs.xsd.

The implementation has to expose the services of the registry using concrete protocol bindings and a wire protocol, like any other Web service. The ebXML Registry Services Specification defines two bindings. The implementation is free to use either or both:

• SOAP bindings using the HTTP protocol, shown in Figure 7.12

  
  Figure 7.12: Registry bindings

• ebXML Messaging Service binding

The SOAP/HTTP bindings specify the services using a document-literal binding and work similar to UDDI. The ebXML messaging service, covered in the next section, facilitates asynchronous SOAP/XML messaging between two points. When using this binding for the interaction, clients can realize the benefits of the messaging service (e.g., reliability, asynchronous invocation) but need to go though an ebXML messaging implementation on their side.

The registry service is itself a Web service. In Chapter 5, we described how a WSDL service description can be separated into abstract and concrete representations. The ebXML registry uses this concept to break up the registry service into abstract and concrete descriptions:

• The abstract representation of the ebXML registry service describes its operations and messages using the WSDL at www.oasis-open.org/committees/regrep/documents/2.0/services/Registry.wsdl.

• The concrete description of the registry describes the bindings to SOAP using the WSDL at www.oasis-open.org/committees/regrep/documents/2.0/services/RegistrySOAPBinding.wsdl.

We will break off the topic of the ebXML registry at this point, hoping to have provided sufficient information without too much detail. We revisit ebXML registries in Chapter 12, when we talk about working with registries from Java. As a final thought, we will address an often-asked question by architects on the comparison between UDDI and ebXML registries.

UDDI or ebXML

Functionally, the ebXML registry is a superset of the UDDI registry, even though UDDI may seem to have a greater momentum at present. Both specifications are now under the umbrella of the OASIS consortium and offer overlapping functionality and feature sets. A bit of confusion often surrounds the two, and in this section, we will compare and contrast them.

Information Model In Chapter 6, we looked at the UDDI information model, and in Figure 7.10, we looked at the ebXML information model. Both models came about as a result of identifying use cases for the registry, which differ in their fundamental approach. The UDDI use cases are focused more on publishing organization and service information, whereas the ebXML use cases seek to address the broader issues of B2B collaboration. This difference is reflected in the models.

The forte of the UDDI Registry Information Model is the focus on business and service listings. However, this model does not address some of the interactions involved in the collaboration. The ebXML RIM is described in more intuitive terms and supports the storage of arbitrary content, represented by a RegistryObject. This is a powerful concept, because the physical content (such as XML documents describing the WSDL, Collaboration-Protocol Profile, Collaboration-Protocol Agreement, and Business Process Specification Schema) can be stored and retrieved from the registry.

• The UDDI Registry Information Model supports a fixed set of relationships between its primary entities (the company and the service). ebXML supports the creation of arbitrary associations between any two objects, which map well to the UML associations that may be described in a business model. So, for example, two XML schemas can be stored in the ebXML registry, and an association representing a version change (i.e., supersede) can be indicated.

Taxonomies and Classifications In Chapter 6, we showed how a taxonomy is represented by a tModel in a UDDI registry. tModels are overloaded, in that they have other uses (e.g., in Chapter 12, we show how a tModel can represent the WSDL service interface). UDDI inherently supports three taxonomies (NAICS, UNSPSC, and ISO 3166), and users may submit new tModels to proxy for additional taxonomies. The issue is that since there is no way to clearly represent this taxonomy, there is no way for clients to either browse or validate the usage. ebXML, on the other hand, supports internal and external taxonomies and browsing from the client.

Registry Queries The inquiry API for both registries has been derived from the information model, which is derived from the core use cases. This is reflected in how the client can query the registry. The UDDI client API (in XML) is simple and allows for search on a business, service, or tModel. The ebXML registry, on the other hand, supports the fixed set of queries on key objects in the information model as well as declarative queries, where SQL syntax may be retrieved to search, query, and retrieve content.

Security UDDI supports a simple password-based authentication scheme over HTTP for the publishing API. HTTPS is supported in UDDI v. 2.0. The ebXML registry, on the other hand, uses digital certificates for authentication and maintains audit trails on content (e.g., who changed specific objects, and when).

Internal and external taxonomies, queries for UDDI and declarative queries on ebXML, password-based user authentication in UDDI and digital-certificate-based authentication using JAXR are all covered further in Chapter 12.

Protocol Support A registry exposes itself with an XML interface and API, which need to be accessed using some transport protocol. UDDI supports the use of these XML APIs over SOAP/HTTP and SOAP/HTTPS. The ebXML registry supports the use of these API using SOAP/HTTP directly, as UDDI does, or the ebXML messaging service. The messaging service, discussed in the next section, is layered on SOAP 1.1 with attachments and HTTP. This also allows the client to interact asynchronously with the service and the service to asynchronously respond to the client.

The options provided by the ebXML registry give business partners greater flexibility in the mechanism and infrastructure to use.

WSDL for Registry The registry itself is a Web service and is capable of being described by a WSDL. The ebXML registry clearly describes its service interface using a WSDL, as mentioned earlier. This capability of describing the UDDI registry using WSDL has been added in UDDI v. 3.0.

An organization can expose an ebXML registry and can even register this as a Web service in UDDI—see www.ebxml.org/specs/rrUDDI.pdf.

ebXML Message Service

Successful collaboration between business partners must include a mechanism to handle the flow of requests from one end to another and take context (e.g., who is the requestor, committed service levels, privacy, prior fulfillment, and personalization) into account before determining the flow. This is the runtime component identified in Figure 7.8. The ebXML messaging service specification defines a reliable means to exchange business messages using SOAP without relying on proprietary technologies or solutions. It is a critical piece in the ebXML architecture, because it solves many of the problems inherent in the EDI messaging systems we described earlier in this chapter.

The messaging service defines two aspects of messaging:

1. How the message is packaged.

2. What different components are present in the messaging system to support the transport and processing of the message.

In Chapter 4, we talked about the concept of vertical extensibility in SOAP, in which other specifications extend SOAP by specifying schemas for the SOAP header. This is precisely what the ebXML messaging service does, by defining a packaging scheme using the SOAP envelope, as Figure 7.13 shows.

Figure 7.13: The ebXML message (source— ebXML Message Service Specification)

The message package is based on SOAP with attachments and consists of a MIME-multipart structure. The package contains the SOAP envelope and the payload, which may be any business document in any format. The specifications define the ebXML specific headers extensions contained in the header element of the SOAP message and processed by the messaging server on the receiving side. The MessageHeader is added to the message with a mustUnderstand=1 attribute, so that it is processed by the other end and contains the following subelements:

• From and To. Describe the PartyId and Role of the two parties involved in the message exchange. The PartyId and Role are based on the Collaboration-Protocol Agreement the parties have agreed upon for this exchange.

• CPAId. The Collaboration-Protocol Agreement between the two partners. It is a URI that points to the location in the reg-rep of the Collaboration-Protocol Agreement or another URL where the CPA may be mutually accessed.

• ConversationId. Collaborating business partners will typically exchange a group of messages creating a conversation. This element identifies the message as belonging to a particular conversation.

• Service. Refers to the service targeted by this message.

• Action. Refers to a particular task or action in the targeted service.

• MessageData. Contains metadata, such as the message ID, a timestamp, and time to live information about the message.

• DuplicateElimination. Tells the receiver that it should check if the message is a duplicate.

• Description. Provides a human-readable description of the message.

For example, Listing 7.4 shows the SOAP message containing the ebXML message headers from Flute Bank to OfficeMin. What is not shown is the actual message payload, the business document. The payload would be part of the MIME attachment in the SOAP message.

Listing 7.4: The ebXML SOAP message

 <?xml version="1.0" encoding="UTF-8"?> <soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"> <soap-env:Header>     <eb:MessageHeader xmlns:eb=http://www.ebxml.org/namespaces/messageHeader         eb:version="1.0" soap-env:mustUnderstand="1">        <eb:From>             <eb:PartyId eb:type="URI">                 http://www.flutebank.com/ordersupplies             </eb:PartyId>        </eb:From>        <eb:To>            <eb:PartyId eb:type="URI">                http://www.officemin.com/processorders            </eb:PartyId>        </eb:To>     <eb:CPAId>              http://www.flutebank.com/agreements/agreementwithofficemin.xml     </eb:CPAId>        <eb:ConversationId>www.flute.com/orders/829202</eb:ConversationId>        <eb:Service eb:type="">purchaseorderservice</eb:Service>        <eb:Action>Purchaseorder</eb:Action>        <eb:MessageData>           <eb:MessageId>                  89fcfba5-fac8-4ddd-94b1-ba74339d42de           </eb:MessageId>           <eb:Timestamp>1031591106992</eb:Timestamp>        </eb:MessageData>     </eb:MessageHeader> </soap-env:Header> <soap-env:Body/> </soap-env:Envelope> 

The ebXML messaging specifications define three logical architecture levels between the business application and the network protocols that carry this SOAP message, as Figure 7.14 shows:

• The message service interface

• The message service handler

• The transport interface

Figure 7.14: ebXML messaging system modules

The message service interface is the portion of the service that applications interact with. It forms an application interface for business applications to invoke the message handler. The message service handler (MSH) is the software system that handles the message and contains basic services, such as authentication, header parsing, encryption, and message packaging. The messaging specifications define these abstract areas of functionality, how they must act, and how the service as a whole must act. For example, the specifications define how authentication information can be included in the ebXML message headers using digital signatures and how the service must provide reliable messaging functionality.

The specifications do not define any particular implementation of these abstractions. What they define is the behavior of the messaging service and the functional areas it must support. For example, the specifications do not define an API for the message service interface. A vendor who provides the messaging software will provide the API to interact with the service. (For Java applications, this is where JAXM comes in, which we cover in Chapter 11). However, what the specifications define is the bindings with HTTP and SMTP, as Figure 7.15 shows. If two vendors conform to these bindings for the SOAP message, which is an XML document and an attachment, they will not need to bother about what technology the other is implemented in. The message package, the transport, the format on the wire, and the communication, which together form an ebXML reliable messaging protocol, are standardized by the specifications.

Figure 7.15: ebXML messaging

Earlier, we mentioned how the Collaboration-Protocol Agreement forms an agreement between two business partners, and the messaging service is required to enforce it at runtime. Typically, the implementation will be configured to point to the location of the CPA between the parties in an ebXML registry-repository. When the service is invoked to send the message, it will validate that the message conforms to the agreement between the two partners.

As with registries, we will again pause in our discussion on the messaging service and resume it in Chapter 11, where we talk about implementing XML messaging.