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

Identify Shared Conversational State

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.


Like this write-up? Subscribe to receive more like it.


Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

Gopalan Suresh Raj, a Senior Software Architect, Published Author, and a Public Speaker, is a member of Sun Microsystems, Inc.'s Research and Architecture team. For the past several years he has been designing solutions using Java and C++.

Contact him at Gopalan.Raj@Sun.com  or Suresh.Gopalan@oracle.com

His personal public profile is available at: https://profiles.google.com/ipersist/

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today