On 10/26/07, MowPed <[EMAIL PROTECTED]> wrote: > > > > gnodet wrote: > > > > On 10/18/07, MowPed <[EMAIL PROTECTED]> wrote: > >> > >>> We've for the most part successfully deployed the Servicemix-wsn service > >>> engine to OpenESB. > >>> > >>>I have a couple of questions/issues related to using servicemix-wsn2005 > in > >>>OpenESB. > >>> > >>> 1) CreatePullPoint - the AbstractCreatePullpoint class uses a > >>> org.apache.activemq.util.IdGenerator class to generate ids used for > >>> queue > >>> names. The generated ids contain "dashes" (for example: > >>> ID-djfla-3580-1192736817437-1-0). An error occurs (Invalid name) when > >>> attempting to > >>> use the generated id for a JMS queue name within OpenESB. Is it > >>> possible to > >>> use some other ID generator? Or is possible to specify the actual queue > >>> name? > > > >>Please raise a JIRA for that. I think we should be able to use > >>another Id generator (but we'd have to create an interface for that) > >>and even specifify the queue used. > >>Btw, it sounds like you're not using ActiveMQ for the JMS layer. > >>Could you provide some informations on how you configure the SE ? > >>Maybe even on the web site, as other people may want to do the same > >>thing. > > > > Ok. I'll create a JIRA for this. You are correct that we are not using > > ActiveMQ for the JMS implementation. We're using Sun Java System Message > > Queue 4.1. To get servicemix to generate queues (for PullPoints) I had to > > modify the servicemix code to replace the "dash" with an "underscore" in > > the generated queue name. Other than that I have not noticed any issues > > with using the SJSMQ. The WSN service engine seems to correctly generate > > Topics and Queues (once the dash is removed) and send messages. However, > > we do not yet have extensive experience using WSN and the Sun JMS > > implementation. If we encounter any other issues we'll let you know. > > > > To use the WSN Service Engine with SJSMQ we simply created a JMS > > connection factory with the name jms/wsnotificationCF and set this as a > > property of the Service Engine (in other words override the original > > property value and we don't use a reference). It's a small issue that the > > connection factory name (the default property value) seems to be hardcoded > > in the WSNConfiguration class. Is there a way we can specify the default > > name? > >
The reason why ActiveMQ is hard coded a bit in the SE is that there is one feature in ws-notification that can not be easily achieved with pure jms and we rely on ActiveMQ specific features. This is when the producer is notified when it does not have to publish because there is no consumer on the topic: the requirement is to know when consumers come and go, which can not be done in a jms standard way. But this is an advance feature imho, and if given a non ActiveMQ factory, the component should be able to work in a degraded way. But this point, I do understand that it should be easy to use any other JMS provider and I think we should make that easier. You said you've done some modifications to allow that. Can this be done in a generic way ? If so, would you provide a patch ? > >>> > >>> 2) Subscribe/Notify > >>> > >>> For web services external to JBI we've had no issues with the > >>> Subscribe and > >>> Notify operations. > >>> > >>> For consumers that are internal JBI endpoints we've encountered > >>> the > >>> following: > >>> > >>> Case A) If we use the following request a subscription is > >>> successfully > >>> created. However, when the broker attempts to notify the consumer at > >>> the > >>> specified endpoint it uses the service-http binding and attempts to send > >>> the > >>> message over HTTP. An HTTP 302 status code is returned, since this is > >>> really a JBI endpoint. > >>> > >>> <b:Subscribe> > >>> <b:ConsumerReference> > >>> > >>> <add:Address>http://www.foo.com/service/endpoint</add:Address> > >>> </b:ConsumerReference> > >>> <b:Filter> > >>> <b:TopicExpression > >>> Dialect="http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple";> > >>> BrewProcess > >>> </b:TopicExpression> > >>> </b:Filter> > >>> </b:Subscribe> > >>> > >>> Case B) If we subscribe using the following message an error is > >>> generated > >>> indicating that the endpoint reference could not be resolved. No > >>> subscription is created. > >>> > >>> <b:Subscribe> > >>> <b:ConsumerReference> > >>> > >>> <add:Address>endpoint:http://www.foo.com/service/endpoint</add:Address> > >>> </b:ConsumerReference> > >>> <b:Filter> > >>> <b:TopicExpression > >>> Dialect="http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple";> > >>> BrewProcess > >>> </b:TopicExpression> > >>> </b:Filter> > >>> </b:Subscribe> > >>> > >>> > >>> In case A the OpenESB ComponentContext has no problem resolving the > >>> endpoint. But when servicemix-wsn processes the Notify request the > >>> message > >>> is sent through the service-mix http binding component for dispatch to > >>> the > >>> consumer. An HTTP Status error of 302 is generated. > >>> > >>> In Case B the OpenESB ComponentContext cannot resolve the consumer > >>> reference, presumably because it has no idea what "endpoint:" indicates. > >>> > >>> If I modify the JBISubscription class and remove "endpoint:" from the > >>> consumer reference before attempting to resolve the endpoint, then > >>> everything works as specified (a Subscription is created and Notify > >>> messages > >>> are successfully sent to the consumer endpoint). > >>> > >>> Is there another way to specify the consumer reference so that it can be > >>> successfully interpreted by both servicemix-wsn and OpenESB? > >>> > > > >>I don't think so, at least without any modifications. > >>The reason is that the WS-Notification SE will ask the NMR to resolve > >>the given EPR. Usually, EPR are resolved by components, which is what > >>happens in case A, but ServiceMix also provides endpoint resolution > >>from a WS-Addressing EPR in addition to the standard ones. > > > >>The JBI spec also defines a jbi-specific way to create EPR. For example: > >> <jbi:end-point-reference > >>xmlns:jbi="http://java.sun.com/xml/ns/jbi/end-point-reference"; > >> jbi:end-point-name="endpointName" > >> jbi:service-name="foo:serviceName" > >> xmlns:foo="urn:FooNamespace"/> > >> > >>So you can try that (ServiceMix support it), but I think if you put > >>that inside the WS-Addressing EPR, it won't work anymore, as the > >>WS-Notification broker will certainly send the full WS-Adressing EPR > >>instead of just the content. > >> > >>I'm not quite sure how OpenESB reacts, but it might be a good idea to > >>align things a bit there. > >> > > > > Yes we tried using the End-Point-Reference, but no luck. If I remember > > correctly the behaviour was the same. > > > > As a suggestion, in the code that validates the JBISubscription, when > > resolving the endpoint, if no endpoint can be found, strip the "endpoint:" > > from the address and try again to resolve the address. I know this would > > work for us. I don't know if this would have other negative implications. > > Do you want me to raise a JIRA for this? > > This would lead to problems in servicemix or even in openESB when using servicemix components. I'd rather enhance the WS-Notification SE so that it check if the EPR is a JBI EPR, in which case, it would extract it and use instead of the full EPR. Another solution would also be to translate any endpoint:// url to a JBI EPR and make the runtime resolve it, which should work too. Wanna raise a JIRA and provide a patch for that ? > >>Please report back any success of failures so that we can make that > >>work (if possible). > > > > As I mentioned before, after some small Servicemix code modifications, the > > service engine appears to be working according to the WS-N spec. So far > > it's mostly successful. Thanks for all the work. > > > >> > >> > >> > >> > >> > >> -- > >> View this message in context: > >> http://www.nabble.com/Servicemix-WSN-SE-deployed-to-OpenESB-tf4649656s12049.html#a13283404 > >> Sent from the ServiceMix - User mailing list archive at Nabble.com. > >> > >> > > > > > > -- > > Cheers, > > Guillaume Nodet > > ------------------------ > > Blog: http://gnodet.blogspot.com/ > > > > > > -- > View this message in context: > http://www.nabble.com/Servicemix-WSN-SE-deployed-to-OpenESB-tf4649656s12049.html#a13428817 > Sent from the ServiceMix - User mailing list archive at Nabble.com. > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
