Hi, Response between the lines...
> > 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. Yes, I forgot to mention that one. > > 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...) >From the spec: " MessageExchange instances are owned by either the initiator, servicer, or NMR. Creating or accepting a message exchange instance confers ownership on the creating (or accepting) component. Upon calling send() for a particular ME instance, the component surrenders ownership of the ME instance immediately. sendSync() causes ownership to be surrendered during the course of the call; when the call ends (returning true) the component resumes ownership of the ME instance. Ownership of an ME instance gives the owner the right to read from and write to the instance. When a component (or the NMR) doesn't have ownership of an ME instance, it MUST NOT read from or write to the instance, except for reading the message exchange status, which can be queried regardless of ownership. If a component that is not the current owner of the instance does attempt to call any method (other than getStatus()) on the instance an appropriate java.lang.IllegalStateException MUST be thrown." Ok. The CAN_OWNER flags are maintained along with the states; in a given state (which has been changed by accepting or sending an ME), it is or is not enabled, hence allowing or disallowing a component to change the ME. 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. I see, the one via "exchangesById.put(exchangeKey, me)". > > 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 ;-) Sure, can do. Alternatives: - A new "JBI in ServiceMix" page with the same structure as JBI, but describing how SM implements it (- Expanding the corresponding JavaDoc) Please let me know which place you consider the most appropriate, and I'll add our conversation there. On a side note, I like the structure of the Cocoon documentation, where general documentation is divided into a User and Developer part depending on whether you want to only use the framework or want to code (http://cocoon.apache.org/2.1/). > 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 ... Ok. Thanks! Ciao, Philipp This e-mail may contain confidential or privileged information. Any unauthorised copying, use or distribution of this information is strictly prohibited.
