Gopalan Suresh Raj
Web Cornucopia
Gopalan's Profile
Archives
« November 2009
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
Click me to subscribe Download Open ESB
Syndication
Search

Table of Contents
Tags
bpel choreography ejb esb http integration javacaps javaee javaone jax-ws jbi management openesb orchestration process-oriented rest sca service-oriented soa soap wsdl xml xsd
Links
 


 
Referrers

Today's Page Hits: 90

Map of Visitors
Locations of visitors to this page
Caveat Emptor
This is my personal weblog. The contents of this Weblog represent my personal opinion which may differ from the official views of my employer, Sun Microsystems, Inc. or any past employers. I do not speak for my employer or any past employers.
View Gopalan Suresh Raj's profile on LinkedIn
« JBI/SOA Tips: Evolvi... | Main | JBI/SOA Tips: What... »
Saturday May 19, 2007
May
19
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.


 

Posted at 11:26PM May 19, 2007 by Suresh Gopalan in A Tip a Day  |  Listen to this article Listen to this entry  |  Comments added Comments[2]
Tags:
Share This Post: del.icio.us | furl | simpy | slashdot | technorati | digg

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 20, 2007 at 02:57 AM 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 21, 2007 at 01:36 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Disclaimer: The contents of this Weblog represent my personal opinion which may differ from the official views of my employer, Sun Microsystems, Inc. or any past employers.

View blog top tags

Enter your email address:

Delivered by FeedBurner

[Valid RSS]