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.

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).

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.

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.

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.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#).

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.

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.

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.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.

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.

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 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.

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.

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.

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

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.

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.