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?
>
>>>
>>> 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?
>
>>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.
