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: 20

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: Messag... | Main | JBI/SOA Tips: The... »
Thursday May 24, 2007
May
24
JBI/SOA Tips: Use Separate MEPs for Business Responses

The wire is peer-to-peer meaning that in most cases the individual collaborating parties are interacting in a peer-to-peer way. They are not restricted to some kind of limited client/server functionality where you got the big guy and a small guy and the small guy has different concerns than the big guy. Each element in the infrastructure has to deal pretty much with the same set of wire-design concerns. Simple things in a client/server world do not work the same way in the wire-design world - like HTTP session cookies, pseudo-conversational modes, and so forth - because that implies that there is this hierarchical relationship elements that are collaborating with wire design. The wire is not hierarchical, its peer-to-peer. That means that any kind of correlation between interactions is in effect up to the business logic to resolve. You are moving information back and forth and you really cannot rely on simple things like HTTP sessions to keep correlations between messages sorted out. You are pushing that to the edge to keep these correlations resolved.


When dealing with stateful interactions, mandating a business response as part of a single request/response message exchange pattern (MEP) overly restricts the asynchronous collaboration that is required. Often the business response is not available quick enough to place the acknowledgment into the response. The only way the business response can fully be decoupled from messages that produce them is to place the acknowledgment in a separate message exchange pattern.

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


 

Posted at 02:10AM May 24, 2007 by Suresh Gopalan in A Tip a Day  |  Listen to this article Listen to this entry  |  Comments added Comments[0]
Tags:
Share This Post: del.icio.us | furl | simpy | slashdot | technorati | digg

Comments:

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]