You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Freeman Fang <fr...@gmail.com> on 2011/07/08 11:36:39 UTC
[DISCUSSION] Support WS-Notification in CXF
Hi Team,
Recently we're discussing on Servicemix Dev mailling list about
redesign ws-notification component, previously it was designed as JBI
ServiceEngine and need work together with BindingComponet(like
servicemix-cxf-bc or servicmeix-http) over JBI bus, we currently want
to make it working without any JBI stuff and we believe this is more
natural as ws-notification[2] actually is wsdl based and we think move
the ws-notification into CXF is more reasonable.
Though no concrete idea now, my gut feeling is that we can leverage
our jms transport to do this.
How about we support WS-Notification in CXF? Any feedback is
appreciated.
[1]http://servicemix.396122.n5.nabble.com/DiSCUSS-WS-Notification-td4563871.html
[2]http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn
Best Regards
Freeman
---------------------------------------------
Freeman Fang
FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Re: [DISCUSSION] Support WS-Notification in CXF
Posted by Jeff Genender <jg...@apache.org>.
I stated interceptors just because the CXF's architecture is wrapped around that (no pun intended) ;-)
But plugability will be important or at least an API with hooks would work. This way someone can use Camel or roll their own implementation, and we can let CXF just care about the WSDL-Java wrapper. When i said interceptor, I meant something similar to WS-Security was what i had in mind, and then an API can be pluggable for hooks. Just an idea that seems to play well with what is already there.
Jeff
On Jul 8, 2011, at 10:43 AM, Guillaume Nodet wrote:
> Then I think we are in agreement. All the code related to ws-addressing
> support in WS-Notification would have to be rewritten when getting rid of
> JBI. However, if you were talking about CXF interceptors, I'm not sure
> that's the right way to go, as implementing a web service purely using
> interceptors might be a bit more complicated than just using wsdl -> java
> and filling the gaps. That does not prevent the introduction of
> pluggability in any way though.
>
> On Fri, Jul 8, 2011 at 18:24, Jeff Genender <jg...@apache.org> wrote:
>
>> Oh its not meant to be harsh... please don't take it personally... ;-) I am
>> well aware of its implementation since we dissected the heck out of it ;-)
>> You also seem to be aware of its issues too from your response below ;-)
>>
>> We tried to leverage it on a project that needed to make extensive use of
>> pub/sub along with pull points and it was extremely lacking in its delivery.
>> Hence we more or less rolled our own.
>>
>> Yes you are spot on with the WS-Addressing... that was a *big* area of
>> trouble we had and an area we also had to skirt to some degree.
>>
>> I really think the WS-Notification needs a much more pluggable approach to
>> the entire model (which is what we ended up writing to a degree). Its
>> somewhat hard to genericize the pub/sub implementation, especially when the
>> pull point is somewhat open season on what you can place in its return. I
>> think the interceptor pattern works real well and hence becomes a perfect
>> complement to the CXF architecture. Areas for interception are synchronous
>> vs asynchronous (i.e. pull point immediate return value vs. pub/sub), etc.
>>
>> Just my 3.14159 cents ;-)
>>
>> Jeff
>>
>>
>> On Jul 8, 2011, at 10:00 AM, Guillaume Nodet wrote:
>>
>>> That's a bit harsh. It is functional and implements all the required
>> bits
>>> afaik. There are some missing stuff such as complex topics expressions
>>> though.
>>>
>>> Most of the problem come from WS-Addressing: it is heavily used in
>>> WS-Notification, but given the component was designed to work inside the
>> JBI
>>> bus, the behavior is not the one you would necessarily expect when using
>>> pure web services and where ws-addressing would target http services, not
>>> services in the JBI bus. Also, I agree the component has been
>> disfunctional
>>> in ServiceMix 4, but mostly due to the fact that the underllying
>>> ws-addressing related JBI piece of code had a behavior change between 3.x
>>> and 4.x.
>>> And fwiw, the ws-notification component completely rely on JMS for the
>>> implementation.
>>>
>>> Do you have more detailed problems / missing features ?
>>>
>>> On Fri, Jul 8, 2011 at 16:07, Jeff Genender <jg...@apache.org>
>> wrote:
>>>
>>>>
>>>> On Jul 8, 2011, at 7:47 AM, Guillaume Nodet wrote:
>>>>
>>>>> We're not talking about implementing something new here. We have an
>>>>> existing code base in ServiceMix that we may work on to remove the ties
>>>> onto
>>>>> JBI. We were just wondering if CXF would be a better place for it. I
>>>> have
>>>>> really no problems with keeping it in ServiceMix fwiw.
>>>>>
>>>>
>>>> Well... lets be honest... the SMX version is pretty much non-functional
>> and
>>>> it only implements a subset of WSN. I think it probably should be
>>>> re-written from scratch.
>>>>
>>>> Jeff
>>>>
>>>>
>>>>> Now if someone wants to start implementing a new WS-Eventing service,
>>>> that's
>>>>> completely unrelated to this issue.
>>>>>
>>>>> Also, we don't actually use it internally in ServiceMix, so ServiceMix
>>>> has
>>>>> no requirements, but our we have some users that do use it, that's all.
>>>>>
>>>>> On Fri, Jul 8, 2011 at 14:40, Alessio Soldano <as...@redhat.com>
>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>> I'm not sure of the exact requirements in ServiceMix, in any case I
>>>>>> suggest evaluating the WS-Eventing spec from WS-ResourceAccess
>>>>>> http://www.w3.org/2002/ws/ra/ which is at CR level atm and is being
>>>>>> finalized *really* soon.
>>>>>> Cheers
>>>>>> Alessio
>>>>>>
>>>>>> On 07/08/2011 11:36 AM, Freeman Fang wrote:
>>>>>>> Hi Team,
>>>>>>>
>>>>>>> Recently we're discussing on Servicemix Dev mailling list about
>>>> redesign
>>>>>>> ws-notification component, previously it was designed as JBI
>>>>>>> ServiceEngine and need work together with BindingComponet(like
>>>>>>> servicemix-cxf-bc or servicmeix-http) over JBI bus, we currently want
>>>> to
>>>>>>> make it working without any JBI stuff and we believe this is more
>>>>>>> natural as ws-notification[2] actually is wsdl based and we think
>> move
>>>>>>> the ws-notification into CXF is more reasonable.
>>>>>>>
>>>>>>> Though no concrete idea now, my gut feeling is that we can leverage
>> our
>>>>>>> jms transport to do this.
>>>>>>>
>>>>>>> How about we support WS-Notification in CXF? Any feedback is
>>>> appreciated.
>>>>>>>
>>>>>>> [1]
>>>>>>
>>>>
>> http://servicemix.396122.n5.nabble.com/DiSCUSS-WS-Notification-td4563871.html
>>>>>>>
>>>>>>> [2]http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn
>>>>>>>
>>>>>>> Best Regards
>>>>>>> Freeman
>>>>>>> ---------------------------------------------
>>>>>>> Freeman Fang
>>>>>>>
>>>>>>> FuseSource
>>>>>>> Email:ffang@fusesource.com
>>>>>>> Web: fusesource.com
>>>>>>> Twitter: freemanfang
>>>>>>> Blog: http://freemanfang.blogspot.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Alessio Soldano
>>>>>> Web Service Lead, JBoss
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ------------------------
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>
>>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>
>>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: [DISCUSSION] Support WS-Notification in CXF
Posted by Guillaume Nodet <gn...@gmail.com>.
Then I think we are in agreement. All the code related to ws-addressing
support in WS-Notification would have to be rewritten when getting rid of
JBI. However, if you were talking about CXF interceptors, I'm not sure
that's the right way to go, as implementing a web service purely using
interceptors might be a bit more complicated than just using wsdl -> java
and filling the gaps. That does not prevent the introduction of
pluggability in any way though.
On Fri, Jul 8, 2011 at 18:24, Jeff Genender <jg...@apache.org> wrote:
> Oh its not meant to be harsh... please don't take it personally... ;-) I am
> well aware of its implementation since we dissected the heck out of it ;-)
> You also seem to be aware of its issues too from your response below ;-)
>
> We tried to leverage it on a project that needed to make extensive use of
> pub/sub along with pull points and it was extremely lacking in its delivery.
> Hence we more or less rolled our own.
>
> Yes you are spot on with the WS-Addressing... that was a *big* area of
> trouble we had and an area we also had to skirt to some degree.
>
> I really think the WS-Notification needs a much more pluggable approach to
> the entire model (which is what we ended up writing to a degree). Its
> somewhat hard to genericize the pub/sub implementation, especially when the
> pull point is somewhat open season on what you can place in its return. I
> think the interceptor pattern works real well and hence becomes a perfect
> complement to the CXF architecture. Areas for interception are synchronous
> vs asynchronous (i.e. pull point immediate return value vs. pub/sub), etc.
>
> Just my 3.14159 cents ;-)
>
> Jeff
>
>
> On Jul 8, 2011, at 10:00 AM, Guillaume Nodet wrote:
>
> > That's a bit harsh. It is functional and implements all the required
> bits
> > afaik. There are some missing stuff such as complex topics expressions
> > though.
> >
> > Most of the problem come from WS-Addressing: it is heavily used in
> > WS-Notification, but given the component was designed to work inside the
> JBI
> > bus, the behavior is not the one you would necessarily expect when using
> > pure web services and where ws-addressing would target http services, not
> > services in the JBI bus. Also, I agree the component has been
> disfunctional
> > in ServiceMix 4, but mostly due to the fact that the underllying
> > ws-addressing related JBI piece of code had a behavior change between 3.x
> > and 4.x.
> > And fwiw, the ws-notification component completely rely on JMS for the
> > implementation.
> >
> > Do you have more detailed problems / missing features ?
> >
> > On Fri, Jul 8, 2011 at 16:07, Jeff Genender <jg...@apache.org>
> wrote:
> >
> >>
> >> On Jul 8, 2011, at 7:47 AM, Guillaume Nodet wrote:
> >>
> >>> We're not talking about implementing something new here. We have an
> >>> existing code base in ServiceMix that we may work on to remove the ties
> >> onto
> >>> JBI. We were just wondering if CXF would be a better place for it. I
> >> have
> >>> really no problems with keeping it in ServiceMix fwiw.
> >>>
> >>
> >> Well... lets be honest... the SMX version is pretty much non-functional
> and
> >> it only implements a subset of WSN. I think it probably should be
> >> re-written from scratch.
> >>
> >> Jeff
> >>
> >>
> >>> Now if someone wants to start implementing a new WS-Eventing service,
> >> that's
> >>> completely unrelated to this issue.
> >>>
> >>> Also, we don't actually use it internally in ServiceMix, so ServiceMix
> >> has
> >>> no requirements, but our we have some users that do use it, that's all.
> >>>
> >>> On Fri, Jul 8, 2011 at 14:40, Alessio Soldano <as...@redhat.com>
> >> wrote:
> >>>
> >>>> Hi,
> >>>> I'm not sure of the exact requirements in ServiceMix, in any case I
> >>>> suggest evaluating the WS-Eventing spec from WS-ResourceAccess
> >>>> http://www.w3.org/2002/ws/ra/ which is at CR level atm and is being
> >>>> finalized *really* soon.
> >>>> Cheers
> >>>> Alessio
> >>>>
> >>>> On 07/08/2011 11:36 AM, Freeman Fang wrote:
> >>>>> Hi Team,
> >>>>>
> >>>>> Recently we're discussing on Servicemix Dev mailling list about
> >> redesign
> >>>>> ws-notification component, previously it was designed as JBI
> >>>>> ServiceEngine and need work together with BindingComponet(like
> >>>>> servicemix-cxf-bc or servicmeix-http) over JBI bus, we currently want
> >> to
> >>>>> make it working without any JBI stuff and we believe this is more
> >>>>> natural as ws-notification[2] actually is wsdl based and we think
> move
> >>>>> the ws-notification into CXF is more reasonable.
> >>>>>
> >>>>> Though no concrete idea now, my gut feeling is that we can leverage
> our
> >>>>> jms transport to do this.
> >>>>>
> >>>>> How about we support WS-Notification in CXF? Any feedback is
> >> appreciated.
> >>>>>
> >>>>> [1]
> >>>>
> >>
> http://servicemix.396122.n5.nabble.com/DiSCUSS-WS-Notification-td4563871.html
> >>>>>
> >>>>> [2]http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn
> >>>>>
> >>>>> Best Regards
> >>>>> Freeman
> >>>>> ---------------------------------------------
> >>>>> Freeman Fang
> >>>>>
> >>>>> FuseSource
> >>>>> Email:ffang@fusesource.com
> >>>>> Web: fusesource.com
> >>>>> Twitter: freemanfang
> >>>>> Blog: http://freemanfang.blogspot.com
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Alessio Soldano
> >>>> Web Service Lead, JBoss
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> ------------------------
> >>> Guillaume Nodet
> >>> ------------------------
> >>> Blog: http://gnodet.blogspot.com/
> >>> ------------------------
> >>> Open Source SOA
> >>> http://fusesource.com
> >>
> >>
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSSION] Support WS-Notification in CXF
Posted by Jeff Genender <jg...@apache.org>.
Oh its not meant to be harsh... please don't take it personally... ;-) I am well aware of its implementation since we dissected the heck out of it ;-) You also seem to be aware of its issues too from your response below ;-)
We tried to leverage it on a project that needed to make extensive use of pub/sub along with pull points and it was extremely lacking in its delivery. Hence we more or less rolled our own.
Yes you are spot on with the WS-Addressing... that was a *big* area of trouble we had and an area we also had to skirt to some degree.
I really think the WS-Notification needs a much more pluggable approach to the entire model (which is what we ended up writing to a degree). Its somewhat hard to genericize the pub/sub implementation, especially when the pull point is somewhat open season on what you can place in its return. I think the interceptor pattern works real well and hence becomes a perfect complement to the CXF architecture. Areas for interception are synchronous vs asynchronous (i.e. pull point immediate return value vs. pub/sub), etc.
Just my 3.14159 cents ;-)
Jeff
On Jul 8, 2011, at 10:00 AM, Guillaume Nodet wrote:
> That's a bit harsh. It is functional and implements all the required bits
> afaik. There are some missing stuff such as complex topics expressions
> though.
>
> Most of the problem come from WS-Addressing: it is heavily used in
> WS-Notification, but given the component was designed to work inside the JBI
> bus, the behavior is not the one you would necessarily expect when using
> pure web services and where ws-addressing would target http services, not
> services in the JBI bus. Also, I agree the component has been disfunctional
> in ServiceMix 4, but mostly due to the fact that the underllying
> ws-addressing related JBI piece of code had a behavior change between 3.x
> and 4.x.
> And fwiw, the ws-notification component completely rely on JMS for the
> implementation.
>
> Do you have more detailed problems / missing features ?
>
> On Fri, Jul 8, 2011 at 16:07, Jeff Genender <jg...@apache.org> wrote:
>
>>
>> On Jul 8, 2011, at 7:47 AM, Guillaume Nodet wrote:
>>
>>> We're not talking about implementing something new here. We have an
>>> existing code base in ServiceMix that we may work on to remove the ties
>> onto
>>> JBI. We were just wondering if CXF would be a better place for it. I
>> have
>>> really no problems with keeping it in ServiceMix fwiw.
>>>
>>
>> Well... lets be honest... the SMX version is pretty much non-functional and
>> it only implements a subset of WSN. I think it probably should be
>> re-written from scratch.
>>
>> Jeff
>>
>>
>>> Now if someone wants to start implementing a new WS-Eventing service,
>> that's
>>> completely unrelated to this issue.
>>>
>>> Also, we don't actually use it internally in ServiceMix, so ServiceMix
>> has
>>> no requirements, but our we have some users that do use it, that's all.
>>>
>>> On Fri, Jul 8, 2011 at 14:40, Alessio Soldano <as...@redhat.com>
>> wrote:
>>>
>>>> Hi,
>>>> I'm not sure of the exact requirements in ServiceMix, in any case I
>>>> suggest evaluating the WS-Eventing spec from WS-ResourceAccess
>>>> http://www.w3.org/2002/ws/ra/ which is at CR level atm and is being
>>>> finalized *really* soon.
>>>> Cheers
>>>> Alessio
>>>>
>>>> On 07/08/2011 11:36 AM, Freeman Fang wrote:
>>>>> Hi Team,
>>>>>
>>>>> Recently we're discussing on Servicemix Dev mailling list about
>> redesign
>>>>> ws-notification component, previously it was designed as JBI
>>>>> ServiceEngine and need work together with BindingComponet(like
>>>>> servicemix-cxf-bc or servicmeix-http) over JBI bus, we currently want
>> to
>>>>> make it working without any JBI stuff and we believe this is more
>>>>> natural as ws-notification[2] actually is wsdl based and we think move
>>>>> the ws-notification into CXF is more reasonable.
>>>>>
>>>>> Though no concrete idea now, my gut feeling is that we can leverage our
>>>>> jms transport to do this.
>>>>>
>>>>> How about we support WS-Notification in CXF? Any feedback is
>> appreciated.
>>>>>
>>>>> [1]
>>>>
>> http://servicemix.396122.n5.nabble.com/DiSCUSS-WS-Notification-td4563871.html
>>>>>
>>>>> [2]http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn
>>>>>
>>>>> Best Regards
>>>>> Freeman
>>>>> ---------------------------------------------
>>>>> Freeman Fang
>>>>>
>>>>> FuseSource
>>>>> Email:ffang@fusesource.com
>>>>> Web: fusesource.com
>>>>> Twitter: freemanfang
>>>>> Blog: http://freemanfang.blogspot.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Alessio Soldano
>>>> Web Service Lead, JBoss
>>>>
>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>
>>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: [DISCUSSION] Support WS-Notification in CXF
Posted by Guillaume Nodet <gn...@gmail.com>.
That's a bit harsh. It is functional and implements all the required bits
afaik. There are some missing stuff such as complex topics expressions
though.
Most of the problem come from WS-Addressing: it is heavily used in
WS-Notification, but given the component was designed to work inside the JBI
bus, the behavior is not the one you would necessarily expect when using
pure web services and where ws-addressing would target http services, not
services in the JBI bus. Also, I agree the component has been disfunctional
in ServiceMix 4, but mostly due to the fact that the underllying
ws-addressing related JBI piece of code had a behavior change between 3.x
and 4.x.
And fwiw, the ws-notification component completely rely on JMS for the
implementation.
Do you have more detailed problems / missing features ?
On Fri, Jul 8, 2011 at 16:07, Jeff Genender <jg...@apache.org> wrote:
>
> On Jul 8, 2011, at 7:47 AM, Guillaume Nodet wrote:
>
> > We're not talking about implementing something new here. We have an
> > existing code base in ServiceMix that we may work on to remove the ties
> onto
> > JBI. We were just wondering if CXF would be a better place for it. I
> have
> > really no problems with keeping it in ServiceMix fwiw.
> >
>
> Well... lets be honest... the SMX version is pretty much non-functional and
> it only implements a subset of WSN. I think it probably should be
> re-written from scratch.
>
> Jeff
>
>
> > Now if someone wants to start implementing a new WS-Eventing service,
> that's
> > completely unrelated to this issue.
> >
> > Also, we don't actually use it internally in ServiceMix, so ServiceMix
> has
> > no requirements, but our we have some users that do use it, that's all.
> >
> > On Fri, Jul 8, 2011 at 14:40, Alessio Soldano <as...@redhat.com>
> wrote:
> >
> >> Hi,
> >> I'm not sure of the exact requirements in ServiceMix, in any case I
> >> suggest evaluating the WS-Eventing spec from WS-ResourceAccess
> >> http://www.w3.org/2002/ws/ra/ which is at CR level atm and is being
> >> finalized *really* soon.
> >> Cheers
> >> Alessio
> >>
> >> On 07/08/2011 11:36 AM, Freeman Fang wrote:
> >>> Hi Team,
> >>>
> >>> Recently we're discussing on Servicemix Dev mailling list about
> redesign
> >>> ws-notification component, previously it was designed as JBI
> >>> ServiceEngine and need work together with BindingComponet(like
> >>> servicemix-cxf-bc or servicmeix-http) over JBI bus, we currently want
> to
> >>> make it working without any JBI stuff and we believe this is more
> >>> natural as ws-notification[2] actually is wsdl based and we think move
> >>> the ws-notification into CXF is more reasonable.
> >>>
> >>> Though no concrete idea now, my gut feeling is that we can leverage our
> >>> jms transport to do this.
> >>>
> >>> How about we support WS-Notification in CXF? Any feedback is
> appreciated.
> >>>
> >>> [1]
> >>
> http://servicemix.396122.n5.nabble.com/DiSCUSS-WS-Notification-td4563871.html
> >>>
> >>> [2]http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn
> >>>
> >>> Best Regards
> >>> Freeman
> >>> ---------------------------------------------
> >>> Freeman Fang
> >>>
> >>> FuseSource
> >>> Email:ffang@fusesource.com
> >>> Web: fusesource.com
> >>> Twitter: freemanfang
> >>> Blog: http://freemanfang.blogspot.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Alessio Soldano
> >> Web Service Lead, JBoss
> >>
> >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSSION] Support WS-Notification in CXF
Posted by Jeff Genender <jg...@apache.org>.
On Jul 8, 2011, at 7:47 AM, Guillaume Nodet wrote:
> We're not talking about implementing something new here. We have an
> existing code base in ServiceMix that we may work on to remove the ties onto
> JBI. We were just wondering if CXF would be a better place for it. I have
> really no problems with keeping it in ServiceMix fwiw.
>
Well... lets be honest... the SMX version is pretty much non-functional and it only implements a subset of WSN. I think it probably should be re-written from scratch.
Jeff
> Now if someone wants to start implementing a new WS-Eventing service, that's
> completely unrelated to this issue.
>
> Also, we don't actually use it internally in ServiceMix, so ServiceMix has
> no requirements, but our we have some users that do use it, that's all.
>
> On Fri, Jul 8, 2011 at 14:40, Alessio Soldano <as...@redhat.com> wrote:
>
>> Hi,
>> I'm not sure of the exact requirements in ServiceMix, in any case I
>> suggest evaluating the WS-Eventing spec from WS-ResourceAccess
>> http://www.w3.org/2002/ws/ra/ which is at CR level atm and is being
>> finalized *really* soon.
>> Cheers
>> Alessio
>>
>> On 07/08/2011 11:36 AM, Freeman Fang wrote:
>>> Hi Team,
>>>
>>> Recently we're discussing on Servicemix Dev mailling list about redesign
>>> ws-notification component, previously it was designed as JBI
>>> ServiceEngine and need work together with BindingComponet(like
>>> servicemix-cxf-bc or servicmeix-http) over JBI bus, we currently want to
>>> make it working without any JBI stuff and we believe this is more
>>> natural as ws-notification[2] actually is wsdl based and we think move
>>> the ws-notification into CXF is more reasonable.
>>>
>>> Though no concrete idea now, my gut feeling is that we can leverage our
>>> jms transport to do this.
>>>
>>> How about we support WS-Notification in CXF? Any feedback is appreciated.
>>>
>>> [1]
>> http://servicemix.396122.n5.nabble.com/DiSCUSS-WS-Notification-td4563871.html
>>>
>>> [2]http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn
>>>
>>> Best Regards
>>> Freeman
>>> ---------------------------------------------
>>> Freeman Fang
>>>
>>> FuseSource
>>> Email:ffang@fusesource.com
>>> Web: fusesource.com
>>> Twitter: freemanfang
>>> Blog: http://freemanfang.blogspot.com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Alessio Soldano
>> Web Service Lead, JBoss
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: [DISCUSSION] Support WS-Notification in CXF
Posted by Guillaume Nodet <gn...@gmail.com>.
We're not talking about implementing something new here. We have an
existing code base in ServiceMix that we may work on to remove the ties onto
JBI. We were just wondering if CXF would be a better place for it. I have
really no problems with keeping it in ServiceMix fwiw.
Now if someone wants to start implementing a new WS-Eventing service, that's
completely unrelated to this issue.
Also, we don't actually use it internally in ServiceMix, so ServiceMix has
no requirements, but our we have some users that do use it, that's all.
On Fri, Jul 8, 2011 at 14:40, Alessio Soldano <as...@redhat.com> wrote:
> Hi,
> I'm not sure of the exact requirements in ServiceMix, in any case I
> suggest evaluating the WS-Eventing spec from WS-ResourceAccess
> http://www.w3.org/2002/ws/ra/ which is at CR level atm and is being
> finalized *really* soon.
> Cheers
> Alessio
>
> On 07/08/2011 11:36 AM, Freeman Fang wrote:
> > Hi Team,
> >
> > Recently we're discussing on Servicemix Dev mailling list about redesign
> > ws-notification component, previously it was designed as JBI
> > ServiceEngine and need work together with BindingComponet(like
> > servicemix-cxf-bc or servicmeix-http) over JBI bus, we currently want to
> > make it working without any JBI stuff and we believe this is more
> > natural as ws-notification[2] actually is wsdl based and we think move
> > the ws-notification into CXF is more reasonable.
> >
> > Though no concrete idea now, my gut feeling is that we can leverage our
> > jms transport to do this.
> >
> > How about we support WS-Notification in CXF? Any feedback is appreciated.
> >
> > [1]
> http://servicemix.396122.n5.nabble.com/DiSCUSS-WS-Notification-td4563871.html
> >
> > [2]http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn
> >
> > Best Regards
> > Freeman
> > ---------------------------------------------
> > Freeman Fang
> >
> > FuseSource
> > Email:ffang@fusesource.com
> > Web: fusesource.com
> > Twitter: freemanfang
> > Blog: http://freemanfang.blogspot.com
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSSION] Support WS-Notification in CXF
Posted by Alessio Soldano <as...@redhat.com>.
Hi,
I'm not sure of the exact requirements in ServiceMix, in any case I
suggest evaluating the WS-Eventing spec from WS-ResourceAccess
http://www.w3.org/2002/ws/ra/ which is at CR level atm and is being
finalized *really* soon.
Cheers
Alessio
On 07/08/2011 11:36 AM, Freeman Fang wrote:
> Hi Team,
>
> Recently we're discussing on Servicemix Dev mailling list about redesign
> ws-notification component, previously it was designed as JBI
> ServiceEngine and need work together with BindingComponet(like
> servicemix-cxf-bc or servicmeix-http) over JBI bus, we currently want to
> make it working without any JBI stuff and we believe this is more
> natural as ws-notification[2] actually is wsdl based and we think move
> the ws-notification into CXF is more reasonable.
>
> Though no concrete idea now, my gut feeling is that we can leverage our
> jms transport to do this.
>
> How about we support WS-Notification in CXF? Any feedback is appreciated.
>
> [1]http://servicemix.396122.n5.nabble.com/DiSCUSS-WS-Notification-td4563871.html
>
> [2]http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn
>
> Best Regards
> Freeman
> ---------------------------------------------
> Freeman Fang
>
> FuseSource
> Email:ffang@fusesource.com
> Web: fusesource.com
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
>
>
>
>
>
>
>
>
>
>
--
Alessio Soldano
Web Service Lead, JBoss
Re: Exception(Unexpected end of file from server) of CXF
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
I believe this is the same issue as I encountered recently, please see
my post here[1]
[1]http://cxf.547215.n5.nabble.com/Caused-by-java-net-SocketException-Unexpected-end-of-file-from-server-td4715340.html
Freeman
On 2011-7-8, at 下午6:34, xuhb wrote:
> Recently I always encounter a "Unexpected end of file from server"
> Exception at CXF client side. it seems this exception is caused by
> the CXF Serverside has unexcepted release the http connection ;
>
> I tried some effort to to use a simple test case to regenerate such
> a exception; Following is a simple test case which will cause such a
> exception.
>
> keypoint of the test case:
> 1)MTOM enabled;
> 2)Using Jetty-Transport at serverside, and using SUN JDK's http
> client at client side;
> 3)the service logical is simple: first consume all attachment and
> close it; then wait for a long time (about 10 miniutes);
> In practice, there is no such a service which will block for so long
> time, but in the simple test case, I must use such a long time to
> force such a exception occurs;
>
> 4)set the client side 's receiveTime to a infinite time(almost) to
> avoid receive time out exception. then the client will block to wait
> service , but after about 7 minutes a ""Unexpected end of file from
> server" Exception will raised at client side;
>
> Other key points I have tried:
> 1)At first I guess maybe this is the jetty-server's problem: I guess
> it will release connection silently while the servlet-handler
> execute too long time;
> But unfortunately it 's not so .
>
> Because I tried another simple test case, which doesnt generate such
> a exception . The only difference is: there is no attachment in xml
> data; Also the service will wait a very long time( 10minutes,
> 20minutes I have tried) . And the client will blocking util service
> returned;
>
> Ps: the stack of the Exception is :
>
> org.apache.cxf.interceptor.Fault: Could not send Message.
> at org.apache.cxf.interceptor.MessageSenderInterceptor
> $
> MessageSenderEndingInterceptor
> .handleMessage(MessageSenderInterceptor.java:64)
> ...
> Caused by: java.net.SocketException: SocketException invoking http://localhost:9000/service/moreattachmentsrpcliteral
> : Unexpected end of file from server
> ...
> at org.apache.cxf.transport.http.HTTPConduit
> $WrappedOutputStream.mapException(HTTPConduit.java:1385)
> at org.apache.cxf.transport.http.HTTPConduit
> $WrappedOutputStream.close(HTTPConduit.java:1370)
> ...
> Caused by: java.net.SocketException: Unexpected end of file from
> server
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:763)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626)
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:760)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626)
> at
> sun
> .net
> .www
> .protocol
> .http.HttpURLConnection.getInputStream(HttpURLConnection.java:983)
> at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:
> 367)
> at org.apache.cxf.transport.http.HTTPConduit
> $WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1490)
> at org.apache.cxf.transport.http.HTTPConduit
> $WrappedOutputStream.handleResponse(HTTPConduit.java:1448)
> at org.apache.cxf.transport.http.HTTPConduit
> $WrappedOutputStream.close(HTTPConduit.java:1356)
> ... 35 more
---------------------------------------------
Freeman Fang
FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Re: Exception(Unexpected end of file from server) of CXF
Posted by Willem Jiang <wi...@gmail.com>.
On 7/8/11 6:34 PM, xuhb wrote:
> Recently I always encounter a "Unexpected end of file from server" Exception at CXF client side. it seems this exception is caused by the CXF Serverside has unexcepted release the http connection ;
>
> I tried some effort to to use a simple test case to regenerate such a exception; Following is a simple test case which will cause such a exception.
>
> keypoint of the test case:
> 1)MTOM enabled;
> 2)Using Jetty-Transport at serverside, and using SUN JDK's http client at client side;
> 3)the service logical is simple: first consume all attachment and close it; then wait for a long time (about 10 miniutes);
> In practice, there is no such a service which will block for so long time, but in the simple test case, I must use such a long time to force such a exception occurs;
>
What kinds of response does your client expect?
> 4)set the client side 's receiveTime to a infinite time(almost) to avoid receive time out exception. then the client will block to wait service , but after about 7 minutes a ""Unexpected end of file from server" Exception will raised at client side;
>
> Other key points I have tried:
> 1)At first I guess maybe this is the jetty-server's problem: I guess it will release connection silently while the servlet-handler execute too long time;
> But unfortunately it 's not so .
>
> Because I tried another simple test case, which doesnt generate such a exception . The only difference is: there is no attachment in xml data; Also the service will wait a very long time( 10minutes, 20minutes I have tried) . And the client will blocking util service returned;
>
Did you have a chance to catch the under layer TCP transport between the
server and client. It's easy to tell the difference of your two test
case if you catch the packages between the client and server.
> Ps: the stack of the Exception is :
>
> org.apache.cxf.interceptor.Fault: Could not send Message.
> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
> ...
> Caused by: java.net.SocketException: SocketException invoking http://localhost:9000/service/moreattachmentsrpcliteral: Unexpected end of file from server
> ...
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1385)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1370)
> ...
> Caused by: java.net.SocketException: Unexpected end of file from server
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:763)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626)
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:760)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:983)
> at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:367)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1490)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1448)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1356)
> ... 35 more
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: Exception(Unexpected end of file from server) of CXF
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
I believe this is the same issue as I encountered recently, please see
my post here[1]
[1]http://cxf.547215.n5.nabble.com/Caused-by-java-net-SocketException-Unexpected-end-of-file-from-server-td4715340.html
Freeman
On 2011-7-8, at 下午6:34, xuhb wrote:
> Recently I always encounter a "Unexpected end of file from server"
> Exception at CXF client side. it seems this exception is caused by
> the CXF Serverside has unexcepted release the http connection ;
>
> I tried some effort to to use a simple test case to regenerate such
> a exception; Following is a simple test case which will cause such a
> exception.
>
> keypoint of the test case:
> 1)MTOM enabled;
> 2)Using Jetty-Transport at serverside, and using SUN JDK's http
> client at client side;
> 3)the service logical is simple: first consume all attachment and
> close it; then wait for a long time (about 10 miniutes);
> In practice, there is no such a service which will block for so long
> time, but in the simple test case, I must use such a long time to
> force such a exception occurs;
>
> 4)set the client side 's receiveTime to a infinite time(almost) to
> avoid receive time out exception. then the client will block to wait
> service , but after about 7 minutes a ""Unexpected end of file from
> server" Exception will raised at client side;
>
> Other key points I have tried:
> 1)At first I guess maybe this is the jetty-server's problem: I guess
> it will release connection silently while the servlet-handler
> execute too long time;
> But unfortunately it 's not so .
>
> Because I tried another simple test case, which doesnt generate such
> a exception . The only difference is: there is no attachment in xml
> data; Also the service will wait a very long time( 10minutes,
> 20minutes I have tried) . And the client will blocking util service
> returned;
>
> Ps: the stack of the Exception is :
>
> org.apache.cxf.interceptor.Fault: Could not send Message.
> at org.apache.cxf.interceptor.MessageSenderInterceptor
> $
> MessageSenderEndingInterceptor
> .handleMessage(MessageSenderInterceptor.java:64)
> ...
> Caused by: java.net.SocketException: SocketException invoking http://localhost:9000/service/moreattachmentsrpcliteral
> : Unexpected end of file from server
> ...
> at org.apache.cxf.transport.http.HTTPConduit
> $WrappedOutputStream.mapException(HTTPConduit.java:1385)
> at org.apache.cxf.transport.http.HTTPConduit
> $WrappedOutputStream.close(HTTPConduit.java:1370)
> ...
> Caused by: java.net.SocketException: Unexpected end of file from
> server
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:763)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626)
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:760)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626)
> at
> sun
> .net
> .www
> .protocol
> .http.HttpURLConnection.getInputStream(HttpURLConnection.java:983)
> at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:
> 367)
> at org.apache.cxf.transport.http.HTTPConduit
> $WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1490)
> at org.apache.cxf.transport.http.HTTPConduit
> $WrappedOutputStream.handleResponse(HTTPConduit.java:1448)
> at org.apache.cxf.transport.http.HTTPConduit
> $WrappedOutputStream.close(HTTPConduit.java:1356)
> ... 35 more
---------------------------------------------
Freeman Fang
FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Exception(Unexpected end of file from server) of CXF
Posted by xuhb <xu...@tongtech.com>.
Recently I always encounter a "Unexpected end of file from server" Exception at CXF client side. it seems this exception is caused by the CXF Serverside has unexcepted release the http connection ;
I tried some effort to to use a simple test case to regenerate such a exception; Following is a simple test case which will cause such a exception.
keypoint of the test case:
1)MTOM enabled;
2)Using Jetty-Transport at serverside, and using SUN JDK's http client at client side;
3)the service logical is simple: first consume all attachment and close it; then wait for a long time (about 10 miniutes);
In practice, there is no such a service which will block for so long time, but in the simple test case, I must use such a long time to force such a exception occurs;
4)set the client side 's receiveTime to a infinite time(almost) to avoid receive time out exception. then the client will block to wait service , but after about 7 minutes a ""Unexpected end of file from server" Exception will raised at client side;
Other key points I have tried:
1)At first I guess maybe this is the jetty-server's problem: I guess it will release connection silently while the servlet-handler execute too long time;
But unfortunately it 's not so .
Because I tried another simple test case, which doesnt generate such a exception . The only difference is: there is no attachment in xml data; Also the service will wait a very long time( 10minutes, 20minutes I have tried) . And the client will blocking util service returned;
Ps: the stack of the Exception is :
org.apache.cxf.interceptor.Fault: Could not send Message.
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
...
Caused by: java.net.SocketException: SocketException invoking http://localhost:9000/service/moreattachmentsrpcliteral: Unexpected end of file from server
...
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1385)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1370)
...
Caused by: java.net.SocketException: Unexpected end of file from server
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:763)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:760)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:983)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:367)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1490)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1448)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1356)
... 35 more
Exception(Unexpected end of file from server) of CXF
Posted by xuhb <xu...@tongtech.com>.
Recently I always encounter a "Unexpected end of file from server" Exception at CXF client side. it seems this exception is caused by the CXF Serverside has unexcepted release the http connection ;
I tried some effort to to use a simple test case to regenerate such a exception; Following is a simple test case which will cause such a exception.
keypoint of the test case:
1)MTOM enabled;
2)Using Jetty-Transport at serverside, and using SUN JDK's http client at client side;
3)the service logical is simple: first consume all attachment and close it; then wait for a long time (about 10 miniutes);
In practice, there is no such a service which will block for so long time, but in the simple test case, I must use such a long time to force such a exception occurs;
4)set the client side 's receiveTime to a infinite time(almost) to avoid receive time out exception. then the client will block to wait service , but after about 7 minutes a ""Unexpected end of file from server" Exception will raised at client side;
Other key points I have tried:
1)At first I guess maybe this is the jetty-server's problem: I guess it will release connection silently while the servlet-handler execute too long time;
But unfortunately it 's not so .
Because I tried another simple test case, which doesnt generate such a exception . The only difference is: there is no attachment in xml data; Also the service will wait a very long time( 10minutes, 20minutes I have tried) . And the client will blocking util service returned;
Ps: the stack of the Exception is :
org.apache.cxf.interceptor.Fault: Could not send Message.
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
...
Caused by: java.net.SocketException: SocketException invoking http://localhost:9000/service/moreattachmentsrpcliteral: Unexpected end of file from server
...
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1385)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1370)
...
Caused by: java.net.SocketException: Unexpected end of file from server
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:763)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:760)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:983)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:367)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1490)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1448)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1356)
... 35 more
Re: [DISCUSSION] Support WS-Notification in CXF
Posted by Daniel Kulp <dk...@apache.org>.
I definitely support this and kind of thought about doing this last year
sometime to make it more usable outside of SMX.
Not sure where in the code though.
In reality, it's really not much different than an STS. For 2.4, we did put a
sample STS in the examples with most of the framework part in the rt-ws-
security module. We could definitely do something similar.
Dan
On Friday, July 08, 2011 12:31:14 PM Guillaume Nodet wrote:
> I think the main reason is that WS-Notification is part of the WS-* area.
> It's just that CXF may be a more intuitive place for such a codebase.
> The current implementation rely on JBI, so ServiceMix was definitely a good
> place. If we get rid of the JBI dependency to move to a pure JAX-WS
> service, it may be better to move it to CXF. It's really just a matter of
> where people would search for such a component first.
>
> Note that we haven't voted on anything yet in ServiceMix, and there's no
> need to vote if CXF does not want the codebase anyway. So we're just
> really starting the discussion.
>
> On Fri, Jul 8, 2011 at 12:25, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> > Hi Freeman,
> >
> > It seems like WS-Notification really is just a web service application
> > that can run on CXF. Do you see a reason for it to be integrated into
> > the CXF codebase?
> >
> > - Dennis
> >
> > On 07/08/2011 09:36 PM, Freeman Fang wrote:
> >> Hi Team,
> >>
> >> Recently we're discussing on Servicemix Dev mailling list about
> >> redesign
> >> ws-notification component, previously it was designed as JBI
> >> ServiceEngine and need work together with BindingComponet(like
> >> servicemix-cxf-bc or servicmeix-http) over JBI bus, we currently want
> >> to make it working without any JBI stuff and we believe this is more
> >> natural as ws-notification[2] actually is wsdl based and we think
> >> move the ws-notification into CXF is more reasonable.
> >>
> >> Though no concrete idea now, my gut feeling is that we can leverage
> >> our
> >> jms transport to do this.
> >>
> >> How about we support WS-Notification in CXF? Any feedback is
> >> appreciated.
> >>
> >> [1]http://servicemix.396122.**n5.nabble.com/DiSCUSS-WS-**
> >> Notification-td4563871.html<http://servicemix.396122.n5.nabble.com/DiS
> >> CUSS-WS-Notification-td4563871.html>
> >> [2]http://www.oasis-open.org/**committees/tc_home.php?wg_**abbrev=wsn
> >> <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn>
> >>
> >> Best Regards
> >> Freeman
> >> ------------------------------**---------------
> >> Freeman Fang
> >>
> >> FuseSource
> >> Email:ffang@fusesource.com
> >> Web: fusesource.com
> >> Twitter: freemanfang
> >> Blog: http://freemanfang.blogspot.**com
> >> <http://freemanfang.blogspot.com>
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: [DISCUSSION] Support WS-Notification in CXF
Posted by Guillaume Nodet <gn...@gmail.com>.
I think the main reason is that WS-Notification is part of the WS-* area.
It's just that CXF may be a more intuitive place for such a codebase.
The current implementation rely on JBI, so ServiceMix was definitely a good
place. If we get rid of the JBI dependency to move to a pure JAX-WS
service, it may be better to move it to CXF. It's really just a matter of
where people would search for such a component first.
Note that we haven't voted on anything yet in ServiceMix, and there's no
need to vote if CXF does not want the codebase anyway. So we're just
really starting the discussion.
On Fri, Jul 8, 2011 at 12:25, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Hi Freeman,
>
> It seems like WS-Notification really is just a web service application that
> can run on CXF. Do you see a reason for it to be integrated into the CXF
> codebase?
>
> - Dennis
>
>
>
> On 07/08/2011 09:36 PM, Freeman Fang wrote:
>
>> Hi Team,
>>
>> Recently we're discussing on Servicemix Dev mailling list about redesign
>> ws-notification component, previously it was designed as JBI ServiceEngine
>> and need work together with BindingComponet(like servicemix-cxf-bc or
>> servicmeix-http) over JBI bus, we currently want to make it working without
>> any JBI stuff and we believe this is more natural as ws-notification[2]
>> actually is wsdl based and we think move the ws-notification into CXF is
>> more reasonable.
>>
>> Though no concrete idea now, my gut feeling is that we can leverage our
>> jms transport to do this.
>>
>> How about we support WS-Notification in CXF? Any feedback is appreciated.
>>
>> [1]http://servicemix.396122.**n5.nabble.com/DiSCUSS-WS-**
>> Notification-td4563871.html<http://servicemix.396122.n5.nabble.com/DiSCUSS-WS-Notification-td4563871.html>
>> [2]http://www.oasis-open.org/**committees/tc_home.php?wg_**abbrev=wsn<http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn>
>>
>> Best Regards
>> Freeman
>> ------------------------------**---------------
>> Freeman Fang
>>
>> FuseSource
>> Email:ffang@fusesource.com
>> Web: fusesource.com
>> Twitter: freemanfang
>> Blog: http://freemanfang.blogspot.**com <http://freemanfang.blogspot.com>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSSION] Support WS-Notification in CXF
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Freeman,
It seems like WS-Notification really is just a web service application
that can run on CXF. Do you see a reason for it to be integrated into
the CXF codebase?
- Dennis
On 07/08/2011 09:36 PM, Freeman Fang wrote:
> Hi Team,
>
> Recently we're discussing on Servicemix Dev mailling list about
> redesign ws-notification component, previously it was designed as JBI
> ServiceEngine and need work together with BindingComponet(like
> servicemix-cxf-bc or servicmeix-http) over JBI bus, we currently want
> to make it working without any JBI stuff and we believe this is more
> natural as ws-notification[2] actually is wsdl based and we think move
> the ws-notification into CXF is more reasonable.
>
> Though no concrete idea now, my gut feeling is that we can leverage
> our jms transport to do this.
>
> How about we support WS-Notification in CXF? Any feedback is appreciated.
>
> [1]http://servicemix.396122.n5.nabble.com/DiSCUSS-WS-Notification-td4563871.html
>
> [2]http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn
>
> Best Regards
> Freeman
> ---------------------------------------------
> Freeman Fang
>
> FuseSource
> Email:ffang@fusesource.com
> Web: fusesource.com
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
>
>
>
>
>
>
>
>
>
>
Re: [DISCUSSION] Support WS-Notification in CXF
Posted by Jeff Genender <jg...@apache.org>.
JMS would probably be the only real way to do this.
I think this is a very good idea to remove the JBI dependency in WSN. That would make it much more usable.
Yes... I have had more than a couple of clients asking for a full WSN implementation in CXF. So I would believe there is interest out there. WSN will become more important as cloud based ESBs become more prevalent. I am actually a believer that WSN should live in CXF rather than SMX.
Jeff
On Jul 8, 2011, at 3:36 AM, Freeman Fang wrote:
> Hi Team,
>
> Recently we're discussing on Servicemix Dev mailling list about redesign ws-notification component, previously it was designed as JBI ServiceEngine and need work together with BindingComponet(like servicemix-cxf-bc or servicmeix-http) over JBI bus, we currently want to make it working without any JBI stuff and we believe this is more natural as ws-notification[2] actually is wsdl based and we think move the ws-notification into CXF is more reasonable.
>
> Though no concrete idea now, my gut feeling is that we can leverage our jms transport to do this.
>
> How about we support WS-Notification in CXF? Any feedback is appreciated.
>
> [1]http://servicemix.396122.n5.nabble.com/DiSCUSS-WS-Notification-td4563871.html
> [2]http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn
>
> Best Regards
> Freeman
> ---------------------------------------------
> Freeman Fang
>
> FuseSource
> Email:ffang@fusesource.com
> Web: fusesource.com
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
>
>
>
>
>
>
>
>
>