cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [DISCUSSION] Support WS-Notification in CXF
Date Fri, 08 Jul 2011 16:00:43 GMT
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 <jgenender@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 <asoldano@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message