Re: MessageExchange.getRole(): Role.PROVIDER vs. Role.CONSUMER
On 1/23/07, Rossmanith, Philipp <[EMAIL PROTECTED]> wrote: > 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/). > Agreed, this may be a good idea. -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
Re: MessageExchange.getRole(): Role.PROVIDER vs. Role.CONSUMER
On 1/23/07, Rossmanith, Philipp <[EMAIL PROTECTED]> wrote: Hi, Response between the lines... > > 1.) States of MEs > > == snipped >> 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? Yes, though read methods are not checked and only some write methods are. But as you said, the idea is that a component MUST not access the exchange (but the status) unless it is the owner. > > 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)". Yes, this map is used with the "original.copyFrom(me);" (line 548) which copy the received exchange back to the original one. > > 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. I find javadoc is a bit difficult to use when writing some general purpose informations. So i guess a new page is fine, but this is up to you. If you want to edit the wiki, please send a CLA to the ASF (fax or mail), sign in in confluence and i will grant you edit rights. 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. -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
RE: MessageExchange.getRole(): Role.PROVIDER vs. Role.CONSUMER
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
Re: MessageExchange.getRole(): Role.PROVIDER vs. Role.CONSUMER
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/
