cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [DiSCUSS] WS-Notification
Date Wed, 05 Oct 2011 19:20:22 GMT
On Wed, Oct 5, 2011 at 19:45, Jean-Baptiste Onofré <jb@nanthrax.net> wrote:

> Hi Dan (and Guillaume),
>
> I think it makes more sense to include WS-N in CXF. As the current
> implementation is tied to ActiveMQ, I think it would required some
> enhancement to:
> - use a pure JMS implementation, allowing us to use ActiveMQ and any other
> JMS broker (WebSphere MQ Series for instance)
>

Yes, we discussed that, but a few features that are not provided by a pure
JMS layer are needed (mostly the ability to know when consumers on a give
topic subscribe / unsubscribe, and also composite destinations).
I think it's a definitely a nice to have to be able to work with another JMS
broker in a degraded mode or something like that, but from a pure
WS-Notification pov, it's really an implementation detail.


> - use a fully OSGi compliant implementation
>

You mean be able to deploy it as a bundle, or something more than that ?  I
guess the main services could be exposed as OSGi services.


> - be able to describe the WS-N endpoint (poll, etc) in Spring/Blueprint CXF
> and in Camel
>

I'm not so sure about the real need.  That was possible with the servicemix
component, but afaik, most users used it in a pure web services standard
way.  But it should not be so difficult to add it back by leveraging jaxb.


>
> I'm ready to help on these topics ;)
>
> My 0.02$
> Regards
> JB
>
>
> On 10/05/2011 06:31 PM, Daniel Kulp wrote:
>
>>
>> Just wanted to mention that Guillaume and I have been chatting a bit about
>> the
>> code on the CXF IRC channel today.   He ran into some differences with
>> various
>> JAX-WS implementations:
>>
>> http://irclogs.dankulp.com/**logs/irclogger_log/cxf?date=**
>> 2011-10-05,Wed&sel=128#l124<http://irclogs.dankulp.com/logs/irclogger_log/cxf?date=2011-10-05,Wed&sel=128#l124>
>>
>> that required some "less clean" code.   Nothing major.   We also talked
>> about
>> the JMS stuff currently being tied to ActiveMQ and options around that:
>>
>> http://irclogs.dankulp.com/**logs/irclogger_log/cxf?date=**
>> 2011-10-05,Wed&sel=194#l190<http://irclogs.dankulp.com/logs/irclogger_log/cxf?date=2011-10-05,Wed&sel=194#l190>
>>
>> That last stuff is definitely not critical (tied to ActiveMQ is perfectly
>> fine
>> for now as long as we mention that).
>>
>> Dan
>>
>>
>>
>>
>> On Wednesday, October 05, 2011 6:13:15 PM Guillaume Nodet wrote:
>>
>>> On Wed, Oct 5, 2011 at 18:01, Daniel Kulp<dkulp@apache.org>  wrote:
>>>
>>>> On Wednesday, October 05, 2011 5:22:01 PM Guillaume Nodet wrote:
>>>>
>>>>> I've started to re-architect the WS-Notification implementation to
>>>>> get
>>>>>
>>>>
>>>> rid
>>>>
>>>>  of JBI and be pure JAX-WS based.
>>>>> The results are available at https://github.com/gnodet/wsn .
>>>>> I think there was a consensus to move the code base to CXF, but I
>>>>> just
>>>>>
>>>>
>>>> want
>>>>
>>>>  to make sure everyone agree.
>>>>>
>>>>
>>>> I definitely agree.  :-)   Very excited about that prospect.  :-)
>>>>
>>>> How close to ready is it?   Is it something that we can get into CXF
>>>> shortly
>>>> for inclusion with CXF 2.5?
>>>>
>>>
>>> The code is really the same than in ServiceMix, only the JBI bits have
>>> been
>>> replaced by JAX-WS.
>>> A few tests would definitely help, but the code base itself is mostly
>>> done.
>>> I recall some users would have been interested in having more features
>>> like
>>> complex topics or such, but not having those features does not mean the
>>> base
>>> service is not usable.
>>>
>>>  Also, I'd like to keep the implementation lightweight and keep it
>>>>> pure
>>>>>
>>>>
>>>> JAXWS
>>>>
>>>>  based if possible.
>>>>>
>>>>
>>>> I'm quite a bit less excited about this.   I would say pure jaxws + cxf-
>>>> common-utilities is fine as it should likely use the CXF logging stuff,
>>>> CXF XML utilities (DOMUtils, etc...), etc...  duplicating stuff from
>>>> common to just avoid a dep is silly to me.
>>>>
>>>
>>> Yeah, I meant I'd like to be independent of the jaxws provider.
>>> The code is currently using slf4j for logging though.
>>>
>>>  Dan
>>>>
>>>>  On Fri, Jul 8, 2011 at 10:20, Guillaume Nodet<gnodet@gmail.com>
>>>>>  wrote:
>>>>>
>>>>>> Just want to start a discussion on WS-Notification because I've
>>>>>> had a
>>>>>> chat last week with a ServiceMix user about that.
>>>>>>
>>>>>> That component is not heavily used, but we always have a few
>>>>>> users
>>>>>> reporting bugs and such.   This component is really the only one
>>>>>> which is no replacement in Camel.   Given WS-Notification is
>>>>>> really just an implementation of a WSDL, I wonder if it would
>>>>>> be easier to simply port it to a pure CXF web service so that
>>>>>> it would not be tied to JBI anymore, and would also solve a
>>>>>> bunch of problems related to the behavior of
>>>>>> WS-Addressing inside the JBI bus (which is not really what users
>>>>>> expect when using WS-Notification).
>>>>>>
>>>>>> So I'd like to gauge the interest in re-architecting this
>>>>>> component to make it more easily consumable without JBI / NMR,
>>>>>> just as a JAX-WS web service (if possible even with no ties to
>>>>>> CXF).    We could then maybe plan a few enhancements such as
>>>>>> the use of non simple topics definitions and such.
>>>>>>
>>>>>> --
>>>>>> ------------------------
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org
>>>> http://dankulp.com/blog
>>>> Talend - http://www.talend.com
>>>>
>>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.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