JBI Message Exchange Pattern Redux

[Andreas Schaefer <an...@madplanet.com>]

Hi

I want to try to come up with a short docu about the JBI Message  
Exchange Patterns. Please check it out and let me know what you think:

Preamble:

Any active (if status is not in DONE or ERROR) Message Exchanges (ME)  
can be set to status ERROR and returned to the other party (send()).  
Any received inactive ME cannot be sent again meaning that the  
exchange ends there.

Consumer is the party that sends the ME for the first time meaning it  
is the party from where the ME originates. Provider is the other party  
in the ME.

Possible Exchanges:

1) Consumer sends an IN message to the Provider

	Applicable: ALL

2) Provider sends DONE ME back to the consumer

	Applicable: ALL except IN-OUT

3) Provider sends FAULT ME back to the consumer which HAS to sent back  
the ME with status DONE (or ERROR for that matter)

	Applicable: ALL except IN-ONLY

4) Provider sends OUT message back to the consumer which HAS to sent  
back the ME with status DONE

	Applicable: IN-OUT

5) Provider sends OUT message back to the consumer which either can:
	a) Consumer sends back a ME with status DONE
or
	b) Consumer sends back a FAULT to the Provider which has to sent back  
the ME with status DONE

A summary of the usages of the MEPs:

IN-ONLY:
The Consumer wants to send the ME but is not interested in any type of  
response except the acknowledgement of that it is done.

ROBUST-IN-ONLY:
The Consumer wants to send the ME but is interested to hear from the  
Provider in case of a FAULT (for example request not understood). This  
gives the Consumer a chance to react to such a fault and try  
alternatives.

IN-OUT:
The Consumer wants to send the ME and is interested to receive a  
response from the Provider which can be an OUT message or a FAULT. In  
case of a FAULT the Consumer can try alternatives.

Note: This MEP looks like the ROBUST-IN-ONLY except that the DONE  
message from the Provider is replaced by the OUT message.


IN-OPTIONAL-OUT:
The Consumer wants to send the ME but let the Provider decide if there  
is a response (OUT or FAULT) or not (DONE). In case of an OUT message  
the Consumer can send a FAULT back to the Provider to tell him about  
problems with his response (like Response not understood).

Note: This is the only MEP that allows the Consumer to respond to the  
response of a Provider even though I am not quite sure what it is good  
for because the Provider cannot react and send back a different  
response. It is still up to the Consumer to look for alternatives.

Thank you

Andreas Schaefer
CEO of Madplanet.com Inc.
andreas.schaefer@madplanet.com

Re: JBI Message Exchange Pattern Redux

[Daryl Richter <ng...@comcast.net>]

Andreas-

Nice writeup.  Thanks.

I have found that really understanding MEs is a major key to being  
able to understand how ServiceMix works.  Hopefully this will help  
many people.


On Nov 2, 2007, at 12:02 AM, Andreas Schaefer wrote:

> Hi
>
> I want to try to come up with a short docu about the JBI Message  
> Exchange Patterns. Please check it out and let me know what you think:
>
> Preamble:
>
> Any active (if status is not in DONE or ERROR) Message Exchanges  
> (ME) can be set to status ERROR and returned to the other party  
> (send()). Any received inactive ME cannot be sent again meaning  
> that the exchange ends there.
>
> Consumer is the party that sends the ME for the first time meaning  
> it is the party from where the ME originates. Provider is the other  
> party in the ME.
>
> Possible Exchanges:
>
> 1) Consumer sends an IN message to the Provider
>
> 	Applicable: ALL
>
> 2) Provider sends DONE ME back to the consumer
>
> 	Applicable: ALL except IN-OUT
>
> 3) Provider sends FAULT ME back to the consumer which HAS to sent  
> back the ME with status DONE (or ERROR for that matter)
>
> 	Applicable: ALL except IN-ONLY
>
> 4) Provider sends OUT message back to the consumer which HAS to  
> sent back the ME with status DONE
>
> 	Applicable: IN-OUT
>
> 5) Provider sends OUT message back to the consumer which either can:
> 	a) Consumer sends back a ME with status DONE
> or
> 	b) Consumer sends back a FAULT to the Provider which has to sent  
> back the ME with status DONE
>
> A summary of the usages of the MEPs:
>
> IN-ONLY:
> The Consumer wants to send the ME but is not interested in any type  
> of response except the acknowledgement of that it is done.
>
> ROBUST-IN-ONLY:
> The Consumer wants to send the ME but is interested to hear from  
> the Provider in case of a FAULT (for example request not  
> understood). This gives the Consumer a chance to react to such a  
> fault and try alternatives.
>
> IN-OUT:
> The Consumer wants to send the ME and is interested to receive a  
> response from the Provider which can be an OUT message or a FAULT.  
> In case of a FAULT the Consumer can try alternatives.
>
> Note: This MEP looks like the ROBUST-IN-ONLY except that the DONE  
> message from the Provider is replaced by the OUT message.
>
>
> IN-OPTIONAL-OUT:
> The Consumer wants to send the ME but let the Provider decide if  
> there is a response (OUT or FAULT) or not (DONE). In case of an OUT  
> message the Consumer can send a FAULT back to the Provider to tell  
> him about problems with his response (like Response not understood).
>
> Note: This is the only MEP that allows the Consumer to respond to  
> the response of a Provider even though I am not quite sure what it  
> is good for because the Provider cannot react and send back a  
> different response. It is still up to the Consumer to look for  
> alternatives.
>
> Thank you
>
> Andreas Schaefer
> CEO of Madplanet.com Inc.
> andreas.schaefer@madplanet.com
>
>

--
Daryl
http://itsallsemantics.com

"We want great men who, when fortune frowns, will not be discouraged."
     -- Colonel Henry Knox, 1776