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

Message Body has to stand alone

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.


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


 

Comments:

Good topic. However, I would like for you to clarify a couple of things: - As you stated, long running collaborations (or business processes) must persistently maintain state. - For any given BP instance, incoming messages will have the potential to transition a given BP from one state to the next. - Other than persisting some portions of the message header (like messageId and transactionId) in the BP context, how can you correctly correlate any given incoming message with any given long running BP?

Posted by David Hudgins on May 19, 2007 at 07:57 PM PDT #

Hello David

Please refer to the following entries that will answer your questions:
1. JBI/SOA Tips: What is a Conversation in a collaboration wire-design(http://blogs.sun.com/gopalan/entry/jbi_soa_tips_what_is1)
2. JBI/SOA Tips: Identify Shared Conversational State Upfront (http://blogs.sun.com/gopalan/entry/identify_shared_conversational_state_upfront)

You can always design collaborations that will handle business correlations as part of the message exchange rather than using the header to place information that will be required to process the collaboration.

Also, if you are interested in how this is handled in BPEL, please read the entry entitled BPEL: What is Correlation, message Property, Property Alias, and Correlation Set (http://blogs.sun.com/gopalan/entry/bpel_what_is_correlation_message)

Cheers
Gopalan.

Posted by Gopalan Suresh Raj on May 20, 2007 at 06:36 PM PDT #

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