You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by MowPed <mo...@gmail.com> on 2007/10/18 22:54:47 UTC
Servicemix WSN SE deployed to OpenESB
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?
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?
--
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.
Re: Servicemix WSN SE deployed to OpenESB
Posted by Guillaume Nodet <gn...@gmail.com>.
The WS-Notification engine only use the JMS api, but it still leverage some
activemq specific features, mainly for the "on demand" publishing.
So in effect, when you publish a message or create a subscriber, the
WS-Notification broker will send a jms message to the given topic or create
topic subscriber. So the link is the topic name. If you publish a message
using the WSN broker, you can directly receive it by subscribing to the same
topic using jms. The opposite is true too. So this is really a bridge
between the WS-Notification spec and JMS.
I also the use case for using WS-Notification and JMS at the same time, but
using WS-Notification over soap, over jms sounds a bit weird to me. It
would be the same as using WS-ReliableMessaging over JMS: it just does not
bring any value.
On Dec 14, 2007 6:21 PM, clymbon <cl...@gmail.com> wrote:
>
>
> gnodet wrote:
> >
> > Is there a real need for you to use WS-Notification on top of JMS ?
> > WS-Notification brings to the http layer the semantics of JMS, but
> there's
> > no real added value compared to just using JMS imho.
> > The ServiceMix WS-Notification SE uses ActiveMQ underneath, and fwiw,
> you
> > can communicate from one to the other directly without going through JBI
> > for
> > that.
> >
>
> You're right - I don't really care about JMS at all. But let me see if
> I've
> go this straight...
>
> What I care about is using a MoM rather than HTTP for the publication of
> messages to my subscribers, in the hope (yet to be proven) that it will
> perform better for distributing my notifications to subscribers.
>
> When I wrote that I wanted to use WS-Notification over JMS over MoM, this
> was based on the understanding that the SericeMix WS-Notification SE used
> JMS as an API to ActiveMQ. But I'm unclear as to how things are put
> together. I guess from your response that my assumption was wrong, and
> that
> the ServiceMix WS-Notification SE uses a "native" API to ActiveMQ. Am I
> understanding you correctly? If so, that's fine with me, I want to use
> ActiveMQ, I don't really care about JMS.
>
> Or were you asking why I would use WS-Notification at all, rather than
> just
> writing my application to go straight to JMS or some underlying MoM API
> for
> my publish/subscribe application? That's a different question, and the
> answer has to do with trying to stick to WS-* standards. Frankly, the
> case
> for using WS-Notification, or WS-anyghing for that matter, is still rather
> weak. But that's another whole debate - for various reasons I'm trying to
> stick to web service standards for this project. (For now, anyway!)
>
> Just trying to figure out all my options here...
>
> Thanks,
>
> Duncan
>
>
> --
> View this message in context:
> http://www.nabble.com/Servicemix-WSN-SE-deployed-to-OpenESB-tp13283404s12049p14339703.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Servicemix WSN SE deployed to OpenESB
Posted by clymbon <cl...@gmail.com>.
gnodet wrote:
>
> Is there a real need for you to use WS-Notification on top of JMS ?
> WS-Notification brings to the http layer the semantics of JMS, but there's
> no real added value compared to just using JMS imho.
> The ServiceMix WS-Notification SE uses ActiveMQ underneath, and fwiw, you
> can communicate from one to the other directly without going through JBI
> for
> that.
>
You're right - I don't really care about JMS at all. But let me see if I've
go this straight...
What I care about is using a MoM rather than HTTP for the publication of
messages to my subscribers, in the hope (yet to be proven) that it will
perform better for distributing my notifications to subscribers.
When I wrote that I wanted to use WS-Notification over JMS over MoM, this
was based on the understanding that the SericeMix WS-Notification SE used
JMS as an API to ActiveMQ. But I'm unclear as to how things are put
together. I guess from your response that my assumption was wrong, and that
the ServiceMix WS-Notification SE uses a "native" API to ActiveMQ. Am I
understanding you correctly? If so, that's fine with me, I want to use
ActiveMQ, I don't really care about JMS.
Or were you asking why I would use WS-Notification at all, rather than just
writing my application to go straight to JMS or some underlying MoM API for
my publish/subscribe application? That's a different question, and the
answer has to do with trying to stick to WS-* standards. Frankly, the case
for using WS-Notification, or WS-anyghing for that matter, is still rather
weak. But that's another whole debate - for various reasons I'm trying to
stick to web service standards for this project. (For now, anyway!)
Just trying to figure out all my options here...
Thanks,
Duncan
--
View this message in context: http://www.nabble.com/Servicemix-WSN-SE-deployed-to-OpenESB-tp13283404s12049p14339703.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Servicemix WSN SE deployed to OpenESB
Posted by Guillaume Nodet <gn...@gmail.com>.
Is there a real need for you to use WS-Notification on top of JMS ?
WS-Notification brings to the http layer the semantics of JMS, but there's
no real added value compared to just using JMS imho.
The ServiceMix WS-Notification SE uses ActiveMQ underneath, and fwiw, you
can communicate from one to the other directly without going through JBI for
that.
Anyway, you'd need to create a SU for the JMS BC (either the OpenESB one or
the servicemix one) and wire it with the WS-NotificationBroker.
On Dec 14, 2007 5:27 PM, clymbon <cl...@gmail.com> wrote:
>
> MowPed wrote:
> > We've for the most part successfully deployed the Servicemix-wsn
> service
> > engine to OpenESB.
>
> My questions:
>
> 1) Have you succeeded in getting servicemix-wsn2005 working in OpenESB?
>
> 2) If so can you provide tips on what must be done to get this to work?
>
> 3) I understand this is a Service Engine, not a Binding Component. I want
> to publish my notification
> messages outside the JBI engine, to subscribers on other machines. I want
> to do this using JMS
> and a MoM implementation (e.g. ActiveMQ) - in the hopes of getting better
> performance. Since
> this is an SE not a BC, how do I do this? Do I have to write or use
> another
> BC? If so, how do I
> configure it? (The ServiceMix documentation provides some information on
> exposing the
> pub/sub service using SOAP/HTTP, but nothing on exposing it via JMS/MQ)
>
> Any information on your experience would be much appreciated before I
> launch
> into this!
>
> Oh, one last question:
>
> 4) Anybody aware of any other implementations of WS-Notification (or any
> other standards-based
> publish/subscribe technology suitable for use in a WS-based SOA
> environment)?
>
> Background to my questions:
>
> We have an existing WS-Notification based application implemented
> using Muse. We would like to try a different implementation to see if we
> get better performance.
> (We are pushing the performance limits of this technology with our
> application.) It
> appears that servicemix-wsn2005 is about the only other open source
> implementation there is.
>
> I started trying to get it running in ServiceMix, but the documentation is
> bad and even the "basic"
> examples don't build and run. Realizing it's an open-source project, I
> could bite the bullet and try
> to get it working, but we already have begun another project in OpenESB,
> so
> I'd rather just use that.
>
>
> Thanks,
>
> Duncan
>
>
> --
> View this message in context:
> http://www.nabble.com/Servicemix-WSN-SE-deployed-to-OpenESB-tp13283404s12049p14339070.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Servicemix WSN SE deployed to OpenESB
Posted by clymbon <cl...@gmail.com>.
MowPed wrote:
> We've for the most part successfully deployed the Servicemix-wsn service
> engine to OpenESB.
My questions:
1) Have you succeeded in getting servicemix-wsn2005 working in OpenESB?
2) If so can you provide tips on what must be done to get this to work?
3) I understand this is a Service Engine, not a Binding Component. I want
to publish my notification
messages outside the JBI engine, to subscribers on other machines. I want
to do this using JMS
and a MoM implementation (e.g. ActiveMQ) - in the hopes of getting better
performance. Since
this is an SE not a BC, how do I do this? Do I have to write or use another
BC? If so, how do I
configure it? (The ServiceMix documentation provides some information on
exposing the
pub/sub service using SOAP/HTTP, but nothing on exposing it via JMS/MQ)
Any information on your experience would be much appreciated before I launch
into this!
Oh, one last question:
4) Anybody aware of any other implementations of WS-Notification (or any
other standards-based
publish/subscribe technology suitable for use in a WS-based SOA
environment)?
Background to my questions:
We have an existing WS-Notification based application implemented
using Muse. We would like to try a different implementation to see if we
get better performance.
(We are pushing the performance limits of this technology with our
application.) It
appears that servicemix-wsn2005 is about the only other open source
implementation there is.
I started trying to get it running in ServiceMix, but the documentation is
bad and even the "basic"
examples don't build and run. Realizing it's an open-source project, I
could bite the bullet and try
to get it working, but we already have begun another project in OpenESB, so
I'd rather just use that.
Thanks,
Duncan
--
View this message in context: http://www.nabble.com/Servicemix-WSN-SE-deployed-to-OpenESB-tp13283404s12049p14339070.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Servicemix WSN SE deployed to OpenESB
Posted by MowPed <mo...@gmail.com>.
Any comments?
--
View this message in context: http://www.nabble.com/Servicemix-WSN-SE-deployed-to-OpenESB-tf4649656s12049.html#a13425593
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Servicemix WSN SE deployed to OpenESB
Posted by MowPed <mo...@gmail.com>.
> On 10/26/07, MowPed <mo...@gmail.com> wrote:
> >
> >
> >
> > gnodet wrote:
> > >
> > > On 10/18/07, MowPed <mo...@gmail.com> 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.
Re: Servicemix WSN SE deployed to OpenESB
Posted by Wa...@medavie.bluecross.ca.
---------------------------------------------------------------
Wayne McNeil
Office: (902) 496-7325
Email: wayne.mcneil@medavie.bluecross.ca
"Guillaume Nodet" <gn...@gmail.com> wrote on 26/10/2007 12:44:33 PM:
> On 10/26/07, MowPed <mo...@gmail.com> wrote:
> >
> >
> >
> > gnodet wrote:
> > >
> > > On 10/18/07, MowPed <mo...@gmail.com> 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.
-----------------------------------------------------------------------
Re: Servicemix WSN SE deployed to OpenESB
Posted by Guillaume Nodet <gn...@gmail.com>.
On 10/26/07, MowPed <mo...@gmail.com> wrote:
>
>
>
> gnodet wrote:
> >
> > On 10/18/07, MowPed <mo...@gmail.com> 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/
Re: Servicemix WSN SE deployed to OpenESB
Posted by MowPed <mo...@gmail.com>.
gnodet wrote:
>
> On 10/18/07, MowPed <mo...@gmail.com> 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.
Re: Servicemix WSN SE deployed to OpenESB
Posted by Guillaume Nodet <gn...@gmail.com>.
On 10/18/07, MowPed <mo...@gmail.com> 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.
>
> 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.
Please report back any success of failures so that we can make that
work (if possible).
>
>
>
>
>
> --
> 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/