SOA Tips: Use Correlation Values to Reference Shared State

Share conversational state on the wire using self-defined correlations in the message. This ensures that subsequent processes in the collaboration tail can correlate the response to a specific request. The identifier(s) placed in the Message Property of the WSDL can serve as correlation identifier(s) that tie together message instances with a particular conversation.

To learn more about this, read this blog entry of mine entitled What is Correlation, message Property, Property Alias, and Correlation Set

Tags: bpel choreography ejb esb http integration javacaps javaee jax-ws jbi management orchestration process-oriented rest sca service-oriented soa soap wsdl xml xsd roa xml schema

SOA Tips: Identify Shared Conversational State Upfront

We like to think of the net as a RESTful environment that is stateless, but in reality, when doing eBusiness Collaborations we have to understand how to deal with shared state. The fundamental mechanism for referring to shared state is the conversational context and the business correlation that ties the messages together. In fact, business correlation is the way we link to the implied shared state that the roles in the collaboration assume exist, and is being consistently moved forward through message exchanges.
It is important that this conversational shared state is something that is made visible through your wire design. The transitions that the shared state goes through is well defined by the semantics of the conversation.The more visible the transitions are, the easier it is to synchronize the shared state between the collaborations whatever that shared state may be – whether it is some book purchase activity that you’re trying to collaborate over, or its a Purchase Order that you are trying to push, through some eBusiness purchasing system.

Conversations always have an implied semantic shared state that participants can share and refer to in the message body to keep track of message relationships. Identify element(s) in the message that can serve as a shared state-holder, for e.g., unique business specific identifiers that are customer specific, like Social Security Numbers, Insurance Claim Numbers, Purchase Order identifiers, etc. Ensure that these values are easy to find in the message body by clearly defining XPath queries to extract the identifier(s) from within each message.

The figure above shows a new Purchase Order activity. As you already know, a Purchase Order is a business document that defines a service level agreement (SLA) between a buyer and a seller. The buyer agrees to buy a certain set of items at a particular price, and the seller agrees to provide these items at a particular price, and ship it to the specified address by a given date, so on, and so forth.

Normally, the buyer creates a new Purchase Order, assigns a Purchase Order Identifier to the document and sends it across the wire to the Seller. The Seller receives the new Purchase Order, assigns his own Purchase Order Identifier to it and returns it back to the Buyer as an agreement that he is willing to fulfill the order. In this message exchange, the shared state is the Purchase Order Identifiers that each of them assigned to the document. In any further conversations between them, if they have to refer to this Purchase Order document, they have to exchange both the Order IDs that each of them assigned to the document. This is the shared state that uniquely identifies that document in both their systems.

Tags: bpel choreography ejb esb http integration javacaps javaee jax-ws jbi management orchestration process-oriented rest sca service-oriented soa soap wsdl xml xsd roa xml schema

SOA Tips: What is a Conversation in a collaboration wire-design

When doing wire-design for global collaborations, you have to think about how to establish Conversation. Typically in a eBusiness context, a single delivery of the message is not enough to achieve the business purpose. There is some interaction of messages involved between collaborating partners that ends up resulting in some unit of activity. These interactions of messages can therefore span multiple HTTP sessions that require a business-level correlation and are essentially peer-to-peer message exchanges.

So when designing global collaborations for wire-centric integration, you have to think about:

1. the roles of the participants,
2. what correlations you are trying to establish between them,
3. what is the lifecycle of this conversation – what starts the conversation, what maintains the conversation, what completes the conversation, and
4. the shared state that is implied to exist within the context of the conversation.

The conversation is a new computing context that you will have to think of in wire design.

Tags: bpel choreography ejb esb http integration javacaps javaee jax-ws jbi management orchestration process-oriented rest sca service-oriented soa soap wsdl xml xsd roa xml schema

SOA Tips: Protocol Is Not Part of the Business Message

In designing global collaborations for wire-centric integration, particular attention has to be paid to persistence of transactional business information. Transactional business information that is required by a service for processing long running collaborations should be made persistent for a number of reasons, for e.g., to handle failures, for manageability, reliability, performance, for compliance, and support for audits. Persistence of business information is also required to provide for state-management of services, processes, or composites. This includes supporting long-term transactions, or multi party/multi-partner collaborations.

A message has a header and a body. However, when you want to persist the business data in a data store for further processing, you only persist the message body since the message body contains the business data. Therefore the Message body has to stand alone – do not place information that you will need to reuse to process a collaboration in the Message header.

Tags: bpel choreography ejb esb http integration javacaps javaee jax-ws jbi management orchestration process-oriented rest sca service-oriented soa soap wsdl xml xsd roa xml schema

SOA Tips: Evolving Global Collaborations – Version Number Message Wrappers

In wire-centric integration for global collaborations, your Information model evolves over time. XML Schema and WSDL help you document those changes over time, and at any point in time, they help you validate your information model at that instance in time.

Explicitly add a version number attribute to the first element of both the request and the response message. This will ensure the Message Exchange Pattern (MEP) and the schema of the exchanged messages evolve in tandem.

Over the years so much has been said about evolution and there are tomes of literature on the subject if you look around. Every organization has come up with their own solution to evolve their schemas and WSDLs based on a combination of facilities for evolution provided in the XML Schema specification, and their internal policies. Without over-simplifying the complexities involved in providing for versioning your information model, it is safe to say that adding a version number attribute to the first element of both the request and response message wrappers will allow you to have complete control over how to evolve your Message Exchange Patterns over time.

Assuming you have this simple mechanism in place, you have multiple approaches over how to evolve your collaborations over time. For one, as soon as the service receives the message, the whole message is not parsed, but an XPath query is executed on the message that looks for the value of the version number attribute of the first element of the message. Based on the version number, the message can now be routed to the appropriate version of the collaboration that can handle the message. I will, however, leave this topic for a more in-depth article on Evolving Service Collaborations for Wire-Centric Integration in the near future.

Tags: bpel choreography ejb esb http integration javacaps javaee jax-ws jbi management orchestration process-oriented rest sca service-oriented soa soap wsdl xml xsd roa xml schema

SOA Tips: For Large Messages Use MTOM

If the exchanged Business Objects are large and contain multiple different types of binary content, use Message Transmission Optimization Mechanism (MTOM) which uses XML-binary Optimized Packaging (XOP) to transmit binary data.

Create a wrapper message that can contain multiple different types of files.

The wrapped message can then serve as a virtual message.

Use multi-part MIME to physically carry the message so at any point, you don’t have to parse the entire message at once.

This ensures efficient transmission of large binary data between the service and its consumers.

Tags: bpel choreography ejb esb http integration javacaps javaee jax-ws jbi management orchestration process-oriented rest sca service-oriented soa soap wsdl xml xsd roa xml schema

SOA Tips: Use Unique Element to ‘Wrap’ Each Business Message

Fine-grained interfaces kill system performance. Coarse-grained interfaces reduce the cost of data processing and improves network latency.

You have to exchange rich business documents that effect complete state changes in the system rather than exchanging multiple small documents that only effect small state changes in a system.

Business messages may contain one or more business objects that they carry.

When designing global collaborations for wire-centric integration, if you have a complicated interchange that has multiple business objects to it, aggregate these messages together by wrapping them.

Ensure that the container of the wrapped messages has a unique top-level element name.

This wrapper can serve as an open-ended container that sets the business context for what to do with these messages and ensures these messages are self-defining.

Tags: bpel choreography ejb esb http integration javacaps javaee jax-ws jbi management orchestration process-oriented rest sca service-oriented soa soap wsdl xml xsd roa xml schema