On 1/23/07, Rossmanith, Philipp <[EMAIL PROTECTED]> wrote:
Hi,
I tried to find out where the Role of a MessageExchange is being set. I got
stuck with the following, and was hoping that someone might help me out with
clarifying the issue(s).
1.) States of MEs
==================
A MessageExchange (ME) has an array of possible states (int [][]states), which
differs depending on the type of the ME. It is only being set in the
constructor of MessageExchangeImpl.
When being sent, the method:
>
public void handleSend(boolean sync) throws MessagingException
<
changes the state depending on the current status/logical state of the ME by
consulting and reassigning the current state. Every row of the array
corresponds to a description of a state with all possible succeeding states -
depending on the value of the ExchangeStatus and whether there is a Fault a new
state is selected.
The state is also changed in the handleAccept method which is called
when the message
is given to a component using the DeliveryChannel.accept method.
The array of states determines the role of a MessageExchange. A Role.PROVIDER
indicates that an ME is being sent from a consumer to a provider, whereas a
Role.CONSUMER means that the ME goes from the provider to the consumer. *)
Note that the role for a given instance of the MessageExchangeImpl class will
never change. The hack is that the consumer component and the
provider component
will be given two different objects (the mirror property). This is
mainly needed to ensure
that a exchange ownership is enforced (a component can not modify the exchange
if it is not the owner). This is controlled by the CAN_OWNER flag and
checked at
several locations (setProperty, setMessage, setStatus, etc...)
Correct?
2.) Duplicity of MessageExchange instances
===========================================
What I didn't get is that from "JBI Components: Part 1 (Theory)" I concluded
that all messages related to ONE interaction between a Consumer and a Provider go through
the same MessageExchange instance/MessageInstanceImpl object. **)
I don't think this is a requirement. The data should be the same of course.
Even for a component, the exchange is not always the same: for example when
the exchange is serialized in the jms / jca flow. Hence, when using
sendSync, a
hack is needed (in the delivery channel) to copy the data from the
received response
to the original object.
However, in the code, it seems that the STATES_PROVIDER states are only
assigned to a _new_ instance - while copying the ExchangePacket and assigning
the ME from which it was copied as mirror.
Correct? Why?
See above.
3.) Documenting the above and SM JavaDoc
=========================================
Where in the SM pages/documentation would be the best place to contribute
findings/investigations such as the above? Also, which one is the official SM
JavaDoc: http://incubator.apache.org/servicemix/maven/... or
http://servicemix.goopen.org/maven/... or http://XXX/...?
Maybe somewhere near http://servicemix.org/site/how-stuff-works.html
If you have any idea to improve the organization of the docs, please stand up
and speak ;-)
The javadocs for 3.0 release are deployed at
http://incubator.apache.org/servicemix/dist/servicemix-3.0-incubating/site/
I think the other ones should be removed, but there may be links
pointing there ...
Thanks in advance,
Ciao,
Philipp Rossmanith
*) From DefaultBroker.java:
// If we found a destination, or this is a reply
if (exchange.getEndpoint() != null || exchange.getRole() ==
Role.CONSUMER)
**) "This serves as a container for the messages and state of a service invocation (i.e.,
"calling" a particular operation). There are separate MessageExchange subtypes for each
supported MEP. New message exchange instances are created using a JBI-provided
MessageExchangeFactory."
ITC Analyst
Systems Integration
T-Systems ITC Iberia S.A.U.
Edifici 22@
Sancho d'Àvila 110-130
08018 Barcelona
Office: + 34 93 501 56 22
Main: + 34 93 501 50 00
Email: [EMAIL PROTECTED]
Internet: www.t-systems.com
This e-mail may contain confidential or privileged information. Any unauthorised
copying, use or distribution of this information is strictly prohibited.
--
Cheers,
Guillaume Nodet
------------------------
Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/
