Re: ServiceMix Bean issues with send()
So, basically, there is no concept of consumer endpoint: an exchange is sent from a component to an endpoint. Inside servicemix components, we usually have this concept of consumer endpoint, but in such case, this means that the component has to dispatch the incoming exchange back to the endpoint that sent it. On 10/19/07, Andreas Schaefer [EMAIL PROTECTED] wrote: HI Guillaume I hope you are right even though I am not quite sure how you want to figure out the service name of the consumer. I still think it is a problem of the core. Even if we can fix the problem inside the Bean BC the problem may arise on other BCs as well. I think that we should not only have a source component but also a source service name or any form of internal identification of the source SU. BTW today I am at home and so we may can discuss this through IRC if you want. -Andy Guillaume Nodet wrote: I had some time to look at your test case on the plane and i think i found a fix. In all cases i'm quite sure that the problem comes from the component and not from the container. The fix is mainly to inject on the pojo a delivery channel that will track consumer exchanges sent by the bean. That way, the component will know about the exchange and will not throw an exception. 2007/10/19, Andreas Schaefer (2) [EMAIL PROTECTED]: Tomorrow I plan to try to fix this issue but if anyone sees a flaw in my design please stop beforehand. Today I finally resolved the problem of how does ServiceMix know to which component it should send the Message Exchange (ME) back even though it uses the wrong Service Name. Inside the AbstractFlow.doRouting() it uses the SourceId from the ME to find the correct Binding Component (BC). That is why in my test project the call goes back tot he Bean BC even though it tries to call a service that is actually based on a Script BC. This makes me hopeful that applying the same logic to the service name could fix the issue. That is what I want to do to fix it: - service name is removed from the packet and placed inside the ME (maybe also the endpoint) - the ME.setServiceName() is actually set on the MIRROR.serviceName member (so that I don't have to change the logic of switching the ME with its MIRROR) - the consumer's service name is set on the ME before the ME is sent onto the flow. This is either done on the Message Exchange Factory or on the Delivery Channel which is probably the better choice because then on the way back the service name of the provider can also be set if not already done). I just have to figure out how to obtain the service name of the sending SU from within the Delivery Channel. I think that should do the trick even though I don't know what the implications on the SYNCHRONOUS ME are and hope that I am not going to open Pandora's Box. Thanks - Andy -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: ServiceMix Bean issues with send()
HI Guillaume I hope you are right even though I am not quite sure how you want to figure out the service name of the consumer. I still think it is a problem of the core. Even if we can fix the problem inside the Bean BC the problem may arise on other BCs as well. I think that we should not only have a source component but also a source service name or any form of internal identification of the source SU. BTW today I am at home and so we may can discuss this through IRC if you want. -Andy Guillaume Nodet wrote: I had some time to look at your test case on the plane and i think i found a fix. In all cases i'm quite sure that the problem comes from the component and not from the container. The fix is mainly to inject on the pojo a delivery channel that will track consumer exchanges sent by the bean. That way, the component will know about the exchange and will not throw an exception. 2007/10/19, Andreas Schaefer (2) [EMAIL PROTECTED]: Tomorrow I plan to try to fix this issue but if anyone sees a flaw in my design please stop beforehand. Today I finally resolved the problem of how does ServiceMix know to which component it should send the Message Exchange (ME) back even though it uses the wrong Service Name. Inside the AbstractFlow.doRouting() it uses the SourceId from the ME to find the correct Binding Component (BC). That is why in my test project the call goes back tot he Bean BC even though it tries to call a service that is actually based on a Script BC. This makes me hopeful that applying the same logic to the service name could fix the issue. That is what I want to do to fix it: - service name is removed from the packet and placed inside the ME (maybe also the endpoint) - the ME.setServiceName() is actually set on the MIRROR.serviceName member (so that I don't have to change the logic of switching the ME with its MIRROR) - the consumer's service name is set on the ME before the ME is sent onto the flow. This is either done on the Message Exchange Factory or on the Delivery Channel which is probably the better choice because then on the way back the service name of the provider can also be set if not already done). I just have to figure out how to obtain the service name of the sending SU from within the Delivery Channel. I think that should do the trick even though I don't know what the implications on the SYNCHRONOUS ME are and hope that I am not going to open Pandora's Box. Thanks - Andy
Re: ServiceMix Bean issues with send()
I had some time to look at your test case on the plane and i think i found a fix. In all cases i'm quite sure that the problem comes from the component and not from the container. The fix is mainly to inject on the pojo a delivery channel that will track consumer exchanges sent by the bean. That way, the component will know about the exchange and will not throw an exception. 2007/10/19, Andreas Schaefer (2) [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomorrow I plan to try to fix this issue but if anyone sees a flaw in my design please stop beforehand. Today I finally resolved the problem of how does ServiceMix know to which component it should send the Message Exchange (ME) back even though it uses the wrong Service Name. Inside the AbstractFlow.doRouting() it uses the SourceId from the ME to find the correct Binding Component (BC). That is why in my test project the call goes back tot he Bean BC even though it tries to call a service that is actually based on a Script BC. This makes me hopeful that applying the same logic to the service name could fix the issue. That is what I want to do to fix it: - - service name is removed from the packet and placed inside the ME (maybe also the endpoint) - - the ME.setServiceName() is actually set on the MIRROR.serviceName member (so that I don't have to change the logic of switching the ME with its MIRROR) - - the consumer's service name is set on the ME before the ME is sent onto the flow. This is either done on the Message Exchange Factory or on the Delivery Channel which is probably the better choice because then on the way back the service name of the provider can also be set if not already done). I just have to figure out how to obtain the service name of the sending SU from within the Delivery Channel. I think that should do the trick even though I don't know what the implications on the SYNCHRONOUS ME are and hope that I am not going to open Pandora's Box. Thanks - Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHGADWs4gPTNnP0gkRAsNpAJ9knS8kX0NfIbAMW+uGgBjIN0i3zQCfceDi rdw1L46NBoZnzqQzLYILOEw= =VDq2 -END PGP SIGNATURE- -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: ServiceMix Bean issues with send()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomorrow I plan to try to fix this issue but if anyone sees a flaw in my design please stop beforehand. Today I finally resolved the problem of how does ServiceMix know to which component it should send the Message Exchange (ME) back even though it uses the wrong Service Name. Inside the AbstractFlow.doRouting() it uses the SourceId from the ME to find the correct Binding Component (BC). That is why in my test project the call goes back tot he Bean BC even though it tries to call a service that is actually based on a Script BC. This makes me hopeful that applying the same logic to the service name could fix the issue. That is what I want to do to fix it: - - service name is removed from the packet and placed inside the ME (maybe also the endpoint) - - the ME.setServiceName() is actually set on the MIRROR.serviceName member (so that I don't have to change the logic of switching the ME with its MIRROR) - - the consumer's service name is set on the ME before the ME is sent onto the flow. This is either done on the Message Exchange Factory or on the Delivery Channel which is probably the better choice because then on the way back the service name of the provider can also be set if not already done). I just have to figure out how to obtain the service name of the sending SU from within the Delivery Channel. I think that should do the trick even though I don't know what the implications on the SYNCHRONOUS ME are and hope that I am not going to open Pandora's Box. Thanks - Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHGADWs4gPTNnP0gkRAsNpAJ9knS8kX0NfIbAMW+uGgBjIN0i3zQCfceDi rdw1L46NBoZnzqQzLYILOEw= =VDq2 -END PGP SIGNATURE-
Re: ServiceMix Bean issues with send()
Hi Geeks
I am moving this thread to the DEV mailing list because it not about
using ServiceMix anymore. The problem is that when using the
asynchronous message exchange that the response is not sent back to
the calling SU but to the Provider Endpoint of the called SU.
I just keep on spinning here. I have a closer look at the
MessageExchangeImpl and saw that the Mirror references the same
packet and beside the ROLE and STATUS everything else is set or
retrieved from the packet. This means that always the MIRROR is
pointing to the same service, endpoint etc.
Creating a new ME it will be of role CONSUMER and the mirror is of
role PROVIDER. The Delivery Channel (DC) will send the ME using the
mirror and so the DC will send it to the target service PROVIDER
endpoint. When the response is sent back the DC will use the MIRROR
(of the MIRROR), which has not the role CONSUMER, but because of the
same packet it will use the same Service / Endpoint / Interface Name
meaning the message is sent back to the same service with the only
exception that the ME is send to the CONSUMER endpoint instead.
But shouldn't it be that the ME references the CONSUMER endpoint of
the caller (the service that created and sent the message originally)
and the MIRROR references the PROVIDER endpoint of the called service
(the service that received the original message) which most likely
are not the same SU.
This would mean that the addressing parts (service name, endpoint,
interface name) must be removed from the packet and kept separate
from the ME and its MIRROR. We might also need to swap the ME and
MIRROR so that the ME is pointing to the PROVIDER and the MIRROR
pointing to the CONSUMER. This means that the DC will use the ME
instead of the MIRROR to send the ME and NMR or the receiving DC must
swap the ME / MIRROR so that the Provider Endpoint receives the
MIRROR which is subsequently pointing back to the calling service.
Let me know what you think?
Thanks - Andy
On Oct 17, 2007, at 9:11 AM, Andreas Schaefer (2) wrote:
Hi Guillaume
I tried something new using the SCRIPT as the provider service
rather than another BEAN. Now I think I see a little bit more what
is going wrong. What is happening is that the response is handled
by the BeanComponent (which is good) but because it is using the
MIRROR member to which it sends the response to it fails because of
an unknown request (it should work because I fix that issue locally).
From my understanding I think the message is properly sent back to
the correct BC/SE, in this case the Bean Component, but because it
uses the MIRROR as the address it sends it to the wrong SU, which
in this case is the SCRIPT SU which is not even a BEAN. It seems to
me that the MIRROR is pointing to the consumer endpoint of the
provider SU rather than the consumer SU. That is my log output:
[Notes Andy]: Here I send the InOut Message to he Provider:
2007-10-17 08:51:53,515 [58-0:0-thread-1] INFO
ScriptInOutControllerBean - onMessageExchange() send new ME:
InOut[
id: ID:10.250.1.197-115aea91258-2:0
status: Active
role: consumer
service: {urn:scout}script-receiver-service
operation: IdontCare: 0
in: ?xml version=1.0 encoding=UTF-8?
receivertitleDontCareEvenMore/titleindex0/index/receiver
]
2007-10-17 08:51:53,515 [58-0:0-thread-1] DEBUG
BeanComponent - Created correlation id: ID:
10.250.1.197-115aea91258-2:0
2007-10-17 08:51:53,515 [58-0:0-thread-1] DEBUG
DeliveryChannelImpl- Send ID:
10.250.1.197-115aea91258-2:0 in DeliveryChannel{ID:
10.250.1.197-115aea91258-0:0}
[Notes Andy]: AS-LOG are log statements I added to Smx
2007-10-17 08:51:53,515 [58-0:0-thread-1] INFO
DeliveryChannelImpl- AS-LOG, doSend(), ME: InOut[
id: ID:10.250.1.197-115aea91258-2:0
status: Active
role: consumer
service: {urn:scout}script-receiver-service
operation: IdontCare: 0
in: ?xml version=1.0 encoding=UTF-8?
receivertitleDontCareEvenMore/titleindex0/index/receiver
]
2007-10-17 08:51:53,516 [58-0:0-thread-1] INFO
DeliveryChannelImpl- AS-LOG, doSend(), send exchange to
MIRROR: InOut[
id: ID:10.250.1.197-115aea91258-2:0
status: Active
role: provider
service: {urn:scout}script-receiver-service
operation: IdontCare: 0
in: ?xml version=1.0 encoding=UTF-8?
receivertitleDontCareEvenMore/titleindex0/index/receiver
]
2007-10-17 08:51:53,516 [58-0:0-thread-1] DEBUG
SedaFlow - Called Flow send
2007-10-17 08:51:53,518 [58-0:1-thread-1] DEBUG
SedaQueue -
[EMAIL PROTECTED] dequeued
exchange: InOut[
id: ID:10.250.1.197-115aea91258-2:0
status: Active
role: provider
service: {urn:scout}script-receiver-service
endpoint: in-out-receiver
operation: IdontCare: 0
in: ?xml version=1.0 encoding=UTF-8?
receivertitleDontCareEvenMore/titleindex0/index/receiver
]
2007-10-17 08:51:53,518
Re: ServiceMix Bean issues with send()
On 10/16/07, Andreas Schaefer (2) [EMAIL PROTECTED] wrote: Hi I try to figure out what is going wrong with the ServiceMix Bean component when used with an asynchronous message exchange (send()). There is a good chance to I do not understand how the message exchange should work. This is what I tried: - Bean SU 1 sends an In-Out ME to another Bean SU 2 with send() on the Delivery Channel - B SU 2 handles the message and puts in an Out normalized message and then sends the ME back with send() on its Delivery Channel What I see is that the Delivery Channel is sending the Mirror ME which is nearly the same but just has the opposite role (here consumer). This means that the message is sent back to the Consumer Bean Endpoint because that is the address set in the Mirror ME. Yeah. The thing is that in JBI, an exchange is sent from a component to an endpoint. In an InOut mep, the provider will send the exchange with the out message inside, the nmr will route it to the consumer component, which will dispatch it to the consumer endpoint. The endpoint processes the response and need to send back the exchange with a DONE status. The mirror stuff is used internally. Is my assumption right that when a message is read from the NMR that it goes through the Provider endpoint and when the message is sent back that it then goes first through the Consumer endpoint of the same service or should it go to the Consumer endpoint of the calling service? I don't understand what is the difference you make between Consumer endpoint of the same service and Consumer endpoint of the calling service ? Do you mean the POJO instance ? If the consumer endpoint of he SAME service is called then who is responsible on sending the message back to the calling service (B SU 1) and is there a way to do this automatically (meaning with having to code anything in the Bean SUs)? If you don't implement MessageExchangeListener and you want to use InOut asynchronously, then you need to use the @Callback annotation and the Destination. Else, I think the problem is that the component does not track that a given endpoint acts as a consumer and send an exchange, so that it can not route it back to the endpoint. This would require wrapping the DeliveryChannel or simply overriding the sendConsumerExchange method from the component. All exchanges sent from endpoints could be tracked, but we still don't have any way to call the bean, unless it has a @Callback. Can you post your beans, because servicemix-bean has different ways of writing a bean, so... Thank you Andreas Schaefer CEO of Madplanet.com Inc. [EMAIL PROTECTED] -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
