> 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 > behardcoded > > > 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 ? >
Yes, I'll investigate a generic way to name the queue for pull-points. If may be difficult to do since other references (ex. subscriptions and publishers) seem to follow the same naming format. > > >>> > > >>> 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 thatit 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 ? When I said "strip the endpoint", I should have said temporarily remove "endpoint:" from the consumer reference address, so the reference can be resolved. The consumer reference endpoint with the prefix "endpoint:" would still be associated with subscription (and therefore the notify operation still works). I agree with you that the best solution would be to get WS-Notification SE to recognize JPI End-point-references. I'll have a look and see if I can come with a proposal for you. In the meantime I'll raise a JIRA. > > > >>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/ > -- View this message in context: http://www.nabble.com/Servicemix-WSN-SE-deployed-to-OpenESB-tf4649656s12049.html#a13442938 Sent from the ServiceMix - User mailing list archive at Nabble.com.
