On Sat, Oct 16, 2010 at 13:39, Ioannis Canellos<ioca...@gmail.com> wrote:
Hi all,
Service Mix is one thing and Camel is an other.
The fact that JBI failed to become widely accepted, does not mean that it
should be deprecated. It could become optional but I don't see why
deprecated.
I agree with Adrian the deprecated sounds really strong. For all existing
professional JBI users, the word deprecation means replacement. I really
can't see a production infrastructure built on "deprecated" software. So
deprecating JBI is like punishing all those who chose to invest on it.
Deprecation may be a bit strong, but the point is for our users to be aware
of what they should try to use in the future, because that's where we will
focus our efforts. If we plan on continuing adding new JBI components, or
new improvements to the existing components and all, then that clearly mean
that the JBI layer is not deprecated. If we don't really plan to do much
on
those but bug fixing, that means they should be put officially in
maintenance mode (if the term is preferred over the stronger deprecation).
Which ever term we choose, we should let our users know.
As a ServiceMix/Camel user I don't like the fact that binding components
have been discontinued, that serivcemix-eip is deprecated in favor of
camel
etc, since camel can't give me 100% of the functionality I want (yet).
Can
camel provide me with alternatives for all the existing servicemix-eips?
No.
Can camel provide me with alternatives for all existing service mix
binding
components? No. Is Camel as scalable as ServiceMix? No.
Servicemix-eip is deprecated since a long time, but we still ship it. The
point is that no-one has ever submitted a new feature on it and the code
hasn't changed at all since monthes. Is the component still used and
usable ? Of course. Is that where we're focusing our efforts to make things
even better? Not really.
For Camel scalability, I think since camel reintroduced the asynchronous
processing, there's no huge gap between camel and servicemix. My opinion
however, is that it would be easier to make Camel as scalable as ServiceMix
rather than make the jBI/NMR layer and components as easy to use as Camel.
I also do think, a non marginal portion of our users are switching to Camel
instead of the using JBI components and I don't see this tendency to
decrease. I also don't think ServiceMix should try to compete against
camel. Which means the camel components will get better and better while
the ServiceMix components will have a much lower improvement in the same
time. We should be honest with our users if that's the way it works and
pushing them where we think it's best for them. And I think the benefits
from using Camel over the JBI components exceeds the possible drawbacks.
It is totally understandable that Karaf / Camel combo is very strong and
easy to use, but that doesn't mean anything. Karaf is a really strong
runtime and it could be used as a base for any infrastructure. Does it
mean
that since I can use Karaf/Aries/OpenEJB/ActiveMQ/Jetty, Geronimo should
change focus or get deprecated? No.
Not sure how this is related. Geronimo's purpose is to provide a JEE
server. And if you look at the version 3.x in developement, it is actually
based on exactly those products. But dropping those products inside Karaf
certainly does not make a JEE server, and certainly not Geronimo.
Things I would love to see in Service Mix 5 are:
1) Improved management.
i) Full life cycle control of endpoints (servicemix or camel) via command
prompt, web console, jmx.
ii) Endpoint Life cycle bindings to certain events inside the BUS
(example:
on accept connection activate route X, on connection lost deactivate
route
X).
iii) Advanced endpoint (servicemix or camel) publishing via
command-prompt,
web console, jmx.
iv) A web based integration designer, where the user could draw EIPs and
ServiceMix would create the Endpoints, Camel Routes etc.
v) Advanced monitoring. (Example I want to know any given time even that
state of Jetty's connection pool).
2) Integration with third party software
i) Spring Batch would be interesting.
ii) The Apache Hadoop stack.
3) Cloud deployments.
i) Maybe it would be a good idea Cloud Mix to merge with Service Mix.
ii) Other similar cloud related things.
4) The Apache Bundle Repository
i) Make ServiceMix bundles an independent project, in a conjoined effort
with the rest of ASF projects that use OSGi, for faster bundle coverage
which would aid point 2 and also save resources.
Those ideas are indeed interesting. The problem is that when "servicemix
or
camel" for endpoints, there is necessarily a duplication of efforts, or we
need to chose one or the other. I don't really think we should start a
detailed roadmap discussion without agreeing about the vision of ServiceMix
first.
I really think a lot of people are confused. People were already confused
when we had only the servicemix-http compoennts (with the 2 sets of
endpoints) and servicemix-cxf components. Now, with camel-http,
camel-cxf,
cxf-nmr, things are even more confusing. I'd like to reduce our users
options (or at least better guide them) when it comes to implementing a new
project to make their life easier...
On Fri, Oct 15, 2010 at 2:21 PM, Charles Moulliard<cmoulli...@gmail.com
wrote:
If you think that keeping NMR (or at least a part of the API) is a
great
value, I would like to suggest that we think about the name of the
component
that we will propose to our users / customers
Does it make sense to keep the name NMR if the exchange is not longer
of
type XML = normalized, the routing made by Camel ?
We should investigate the pro/con to have NMR vs VM with Camel to
propose
a
clear way to interconnect components over OSGI Bundles and not two
endpoints
doing the same ?
This component could be improved to allow clustering beween SMX4 boxes
and
could be an alternative of using JMS for that purpose
CM
On 15/10/10 12:54, Jean-Baptiste Onofré wrote:
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
--
*Ioannis Canellos*
http://iocanel.blogspot.com
Integration Engineer @ Upstream S.A.<http://www.upstreamsystems.com>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
