--------------------------------------------------------------- Wayne McNeil Office: (902) 496-7325 Email: [EMAIL PROTECTED]
"Guillaume Nodet" <[EMAIL PROTECTED]> wrote on 26/10/2007 12:44:33 PM: > 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/ > ----------------------------------------------------------------------- This communication, including any attached documentation, is intended only for the person or entity to which it is addressed, and may contain confidential, personal, and/or privileged information. Any unauthorized disclosure, copying, or taking action on the contents is strictly prohibited. If you have received this message in error, please contact us immediately so we may correct our records. Please then delete or destroy the original transmission and any subsequent reply. Thank you. La présente communication, y compris toute pièce qui y a été jointe, est destinée uniquement à la personne ou à l’entité à laquelle elle a été adressée, et contient des renseignements à caractère confidentiel et personnel. Toute diffusion ou reproduction non autorisée ou toute intervention entreprise relativement à son contenu est strictement interdite. Si vous avez reçu ce message par erreur, veuillez nous le signaler immédiatement afin que nous puissions effectuer la correction à nos dossiers. Veuillez par la suite supprimer ou détruire le contenu de la transmission originale ainsi que toute réponse ultérieure. Merci. -----------------------------------------------------------------------
