Agree Rob: MEP is an important value as I said in my previous e-mail.
I think that the most important limitation in JBI is the XML based messages.
The NMR could provide quite the same features than JBI (async behavior,
MEP, etc) without the requirement of the XML messaging.
My purpose was most to flag JBI as deprecated (because it's the case).
ServiceMix NMR is a good place to provide the MEP and async support (as
it does currently).
Regards
JB
On 10/15/2010 12:38 PM, Rob Davies wrote:
I'm still of the opinion that there is a lot of value in JBI - the message
exchange part at least It would be interesting to do a clean API for the NMR
without any JBI considerations, and then see if we could retro fit JBI message
exchanges over it - I'd be happy to volunteer to try do the JBI retro fit ;)
On 15 Oct 2010, at 10:27, Guillaume Nodet wrote:
Let me reformulate my thoughts about that.
I think the NMR has some real value, providing this asynchronous bus inside
OSGi, based on endoints registered in the OSGi registry, thus allowing
bundles to communicate with each other in a very nice and scalable way.
What I'm not sure about is if we need to have a custom API for that. Most
of this API has been designed with support for JBI in mind, but if this very
point goes away, there's room for a much cleaner API, maybe reusing parts of
Camel API for exchanges, keeping what the value is (asynchronous bus based
on endpoints registered in the OSGI registry) and making it integrate better
in camel (by avoiding a transformation step which may be unnecessary,
etc...).
I don't think we should drop the concept of the NMR, just that if we
officially deprecate the JBI layer, a new NMR could have a cleaner API. On
the other hand, having a separate API also allows several version of camels
to inter-operate nicely within the bus, which in itself is a really good
point too.
Anyway, this discussion is a good way to pin down where the value is and how
we can make things better in the future.
On Fri, Oct 15, 2010 at 10:48, Chris Custine<chris.cust...@gmail.com>wrote:
Johan, its 2:40 AM and I know you are in the same time zone... shouldn't we
be sleeping :-)
Ade did a great job laying out the case for this in a recent blog post, so
I
will just point you to it:
http://trenaman.blogspot.com/2010/08/easy-useful-nmr-monsieur-nodet-vous.html
<
http://trenaman.blogspot.com/2010/08/easy-useful-nmr-monsieur-nodet-vous.html
This
explains the NMR usage between OSGi bundles quite well. I have talked to
several people recently who are using this exact architecture. I think
this
would be similar to what we have talked about wrt an OpenNMS like event
bus.
Cheers, and good night ;-)
Chris
--
Chris Custine
FuseSource - Open Source Integration:: http://fusesource.com
My Blog :: http://blog.organicelement.com
On Fri, Oct 15, 2010 at 02:36, Johan Edstrom<seij...@gmail.com> wrote:
Chris,
Can you elaborate even more on this?
I know you've explained it to me - but I think it needs even more
clarification?
/je
On Oct 15, 2010, at 2:31 AM, Chris Custine wrote:
I would never want to hide the NMR inside of Camel and take away the
ability
to wire up endpoints via OSGi services. Some of the statements people
are
making here don't seem to take this into consideration, so I just want
to
point this out. It is true that you can reproduce much of the async
message
flow by various means using Camel without the NMR, but now you are
integrating non Camel components only via external bindings and
protocols.
I think the value is in integrating these things more closely and as
first
class citizens inside the ESB, and do that using the NMR. To force
everyone
into using Camel just to utilize the NMR seems rather short sighted to
me
considering how many people use (and very much like) the NMR and OSGi
combination.
So the added value of NMR in this case is very poor/limited. I don't
think
that we need anymore NMR in the future except if we have features
present
in NMR that camel cannot implement.
You are assuming that everyone who uses ServiceMix must also want to
use
Camel, and I am reasonably certain that this is not always the case. I
may
be misinterpreting some of this, but I think we should be careful not
go
overboard here.
Chris
--
Chris Custine
FuseSource - Open Source Integration:: http://fusesource.com
My Blog :: http://blog.organicelement.com
On Fri, Oct 15, 2010 at 01:50, Moulliard, Charles<
cmoulli...@fusesource.com
wrote:
Hi,
The vm:// component of camel plays the same role as NMR to
interconnect
camel routes deployed in different bundles. So the added value of NMR
in
this case is very poor/limited. I don't think that we need anymore NMR
in
the future except if we have features present in NMR that camel cannot
implement.
Charles
On Fri, Oct 15, 2010 at 9:25 AM, Johan Edstrom<seij...@gmail.com>
wrote:
+1
I'm often accused of being an NMR lover, the concept is great.
It is also something that sets it apart from say the hump.
/je
On Oct 15, 2010, at 1:14 AM, Guillaume Nodet wrote:
On Thu, Oct 14, 2010 at 20:14, Adrian Trenaman<
trena...@progress.com
wrote:
Bengt is spot on, and has beaten me to the post on this.
Here's my take:
* By definition, Karaf is a pure, generic container for OSGi
goodness.
Lets
keep it that way: clean and simple, and applicable in many
settings.
* ServiceMix, as Guillaume points out, has a great reputation in
the
area
of ESB and 'enterprise integration in general'. It should evolve to
provide
all the smarts that pull in Camel, CXF, ActiveMQ and other great
integration
kits over Karaf into one deployment runtime that is absolutely
focused
on
solving the problem of enterprise integration.
* While JBI adoption is on the decline, the ServiceMix NMR is a
great
device for high-perf, in-memory, inter-bundle asynchronous
communication. We
should continue to bring this goodness forward.
While I think there is some value in the NMR, I'm quite not sure
about
having to maintain an API which is really similar as the Camel one.
i
think
that slight modifications to Camel could bring it to the same level
as
the
NMR, so I'm wondering if we should try to enhance camel to provide
the
missing feature we need.
AFAIK, there are a few connectors for the NMR, such as the camel one
and
the
CXF one, but CXF has a clean integration in Camel already, so I'm
not
entirely sure if the cxf/nmr one is needed. Obviously, the camel
one
would
be useless if we switch to Camel.
I think another key problem would be the integration of technologies
such
as
Ode (BPEL) which heavily rely on WSDL descriptions. Camel is a bit
poor
at
describing endpoint as WSDL. Camel also does not offer a way to
expose
endpoints on something that would look like a protocol agnostic bus:
endpoints are internal to routes. I guess we'd need to discuss
such
things with the Camel community, but I think the value of the NMR
could
be
refactored into Camel. The NMR concept is nice, I'm just
challenging
the
need of a different API for it.
Not sure though ...
* While I feel 'deprecate' may be too strong a word for the classic
JBI
stuff, I do think we need to promote Camel wherever we can and void
user
distraction into difficult areas of JBI. So, if deprecation is what
is
called for, then let's make it so.
Best,
Ade.
On 14/10/2010 19:09, Bengt Rodehav wrote:
Very interesting post Guillaume,
I have the exact same experience that you describe. A few years
ago
we
started using ServiceMix as an ESB. The JBI support (and the hope
that
it
would become a "standard") was one of the important reasons for
this.
JBI in itself turned out to be unnecessary complex and since JBI
hasn't
caught on at all it is not a compelling reason for us anymore. I
started
to
look at ServiceMix 4 as a good, OSGi based, deployment container.
As
an
integration platform we turned to Camel - exactly as you
described.
Camel
is
much easier to use and has many more supported components. A
pretty
good
combination I thought. Then Karaf came along which was a much
better
fit
for
us since we merely used ServiceMix 4 as a deployment container.
The
combination of Karaf and Camel is a very compelling platform and I
like
it
a
lot.
I still follow the development of ServiceMix (we still have a
ServiceMix 3
application in production) but I'm not at all sure what is being
targeted.
Is it an integration platform? A deployment container?
I think Karaf is better suited for pure deployment and Camel is
better
suited for integration purposes. However, I think there is a need
for
something more complete than Karaf in terms of integrating other
open
source
projects (like Camel, Karaf, Aries, OpenJPA...). I think many use
ServiceMix
(and Karaf+Camel) as an ESB or integration platform. But, I have a
hunch
(since I'm exploring it myself) that it could also be an option
for
"normal"
enterprise applications (kind of like an application server).
One of the problems I encounter is to integrate various versions
of
all
the
open source projects I use. Currently I'm waiting for Camel 2.5
and
iPOJO
1.8. Prior to that I needed a Karaf 2.x version. But all of these
projects
are not always coordinated and it's quite a big job to find your
own
working
"version mix". ServiceMix could take that on. It would mean
creating
a
larger stack (larger than only Karaf) of enterprise/integration
software
components that would be tested together.
Just a thought..
/Bengt
2010/10/14 Guillaume Nodet<gno...@gmail.com>
I've had an interesting discussion today with jbonofre about
ServiceMix
future so I think we should get that on the dev list, hence this
mail
to
start the discussion. I've heard more and more people wondering
about
the
value in ServiceMix compared to Karaf + Camel for example. I
wonder
what
your feedback is, how you feel about the future of ServiceMix and
what
we
should do as a community.
As for my personal opinion, I think ServiceMix has a very strong
brand
as
an
open source ESB, but since ServiceMix 4.x, people tend to be
confused
about
it. I think there are several path forward.
The first thing to state is that the JBI spec did not fulfill its
promises.
For various reasons (mostly political I think), the specs has not
been
backed by enough big vendors. JBI 2.0 will never happen so the
JBI
spec
is
kinda dead. The second fact is that more and more users tend to
start
new
projects directly with Camel for a lot of valid reasons, mainly
its
ease
of
use and tons of connectors. That does not mean they don't use
ServiceMix
as
the runtime, just that they tend to let aside some features such
as
the
JBI
or NMR layer.
Given those facts, I think one possible future would be to
officially
deprecate the JBI layer and components (i.e. maintaining those
for
compatibility, but not necessarily add new features) and focus on
more
value
added such as better integration with third party projects (Ode,
Hise,
etc...) and maybe more tooling (monitoring, etc...).
Anyway, it's just my personal opinion and feedback, but i'd like
to
here
what other think about that, so that we can move forward. I'm
sure
there
are a lot of different ways for ServiceMix' future, but the most
important
thing to me is to come up with a clear position that we all agree
on
and
be
in a better position to move forward and bring ServiceMix to the
next
level.
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Johan Edstrom
j...@opennms.org
They that can give up essential liberty to purchase a little
temporary
safety, deserve neither liberty nor safety.
Benjamin Franklin, Historical Review of Pennsylvania, 1759
Johan Edstrom
j...@opennms.org
They that can give up essential liberty to purchase a little temporary
safety, deserve neither liberty nor safety.
Benjamin Franklin, Historical Review of Pennsylvania, 1759
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
