Hi Guillaume,
my comments inline:
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.
Yeah, even if we are in degraded mode, it would be great to be able to
work with any (or at least a wide range) JMS broker.
- 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
I main expose the WS-N as a set of OSGi services (to register the
consumer, etc).
.
- 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.
It's just a way to "declare" the endpoint. In ServiceMix, we describe
the endpoint using the xbean.xml, The purpose is to provide a
declarative way (in a Spring beans, or blueprint) at least for the WS-N
server. It's more a configuration purpose.
Regards
JB
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<[email protected]> 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<[email protected]>
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
[email protected]
http://dankulp.com/blog
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
