You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2010/10/14 16:35:07 UTC
[DISCUSS] ServiceMix future
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
Re: [DISCUSS] ServiceMix future
Posted by diwakar <di...@nsn.com>.
Hi,
Thanks for the post Paul.
Will ASF at least maintain Servicemix 3.x with JBI (no need for
new feature development)?
With Best Regards,
Diwakar
--
View this message in context: http://servicemix.396122.n5.nabble.com/DISCUSS-ServiceMix-future-tp3212177p5713316.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] ServiceMix future
Posted by paul perez <pa...@pymma.com>.
Hello
Thanks for this discussion on JBI. Here is our 2 pence to the discussion.
To be as fair as possible, I'm one of OpenESB community leader which relies
mainly on JBI.
Here is not a discussion on what is the best ESB but just to expose the
reason why we believe in JBI and the impact it has on IT organisation and
development.
http://pymma.com/index.php?option=com_content&view=category&layout=blog&id=82&Itemid=574
Link to the document
Thanks for your welcome
All the best
Paul Perez
--
View this message in context: http://servicemix.396122.n5.nabble.com/DISCUSS-ServiceMix-future-tp3212177p5708286.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] ServiceMix future
Posted by Johan Edstrom <se...@gmail.com>.
I think raw CXF if quite important...
The speed on large streams for example is not yet up to par compared to "native" cxf.
Not to mention I don't think we should "Enforce" anything :)
On Oct 15, 2010, at 1:18 AM, Jean-Baptiste Onofré wrote:
> Guillaume has greatly summarize our discussion.
>
> Our discussion starts from some facts:
> 1/ JBI is dead. The JBI 2.0 specification will never be released. It's not due to technical leaks but, as Guillaume said, mainly due to politic reasons.
> 2/ All that we can do with JBI could be achieved by Camel: if Camel could manage most of message format (stream, binary, etc), of course it can manage XML payload like JBI does. JBI imposes the XML message format whereas Camel supports it and the developers just need to use it (eventually using a Normalizer pattern). The MEP is defined in the Camel route itself (depending of the from(), to(), etc statements).
> 3/ The maintenance cycle on the ServiceMix components is lower than the Camel components. As it's more simple to write Camel components, the Camel components scope is larger than the ServiceMix components one. There are only one component present in ServiceMix which is not available in Camel: servicemix-smpp. I'm gonna submit a patch to Camel proposing a camel-smpp component.
> 4/ in the past, I had in mind to add WSDL publication in all ServiceMix components to be able to use WS-BPEL in ODE. To be honest, after thinking about that, I'm not sure if the best way to add BPM in ServiceMix (see later :)).
>
> As Guillaume, ServiceMix is really a great brand in OpenSource ESB. We didn't speak about deleting ServiceMix project, but more adopt a clear position.
>
> My vision is the following:
> - ServiceMix 3 should be marked as deprecated and unmaintained release.
> - ServiceMix 4 should stay as it is currently: based on Karaf, adding ActiveMQ, Camel, CXF and NMR/JBI
> - I propose to preparate ServiceMix 5. ServiceMix 5 is clearly an ESB,
> In ServiceMix 5, the JBI layer should be set as deprecated. It means that we always provide the JBI features but not installed by default. The users could installed it for backward compatibility if required.
> ServiceMix 5 is a complete ESB, based on OSGi, gathering:
> - Apache Felix + Apache Karaf
> - Apache ActiveMQ: more than a message broker, ActiveMQ could be the cluster and fail-over player
> - Apache Camel: the integration and mediation layer, providing the components and routing bases
> - Apache CXF: I think that CXF directly ServiceMix will not make sense. CXF will be provided by Camel CXF components, that is enough.
> - BPM: ServiceMix 5 should embed a BPM engine. ODE requires the usage of XML as it's based on WS-BPEL. I think that Activiti could be more interesting as it's based on BPMN2.
> - Tooling: ServiceMix 5 should provide more friendly tooling. Especially, starting to the fact that we use Camel, we can provide a web tool to see, design and monitor the Camel components and routes.
> - Extensions: why not thinking about integrating (as optional or not) others technologies. For example, I'm thinking about extending the Aries usage, providing DOSGI using CXF, or supporting EJB3 using OpenEJB/Geronimo. We have no limit to provide extra features to give a full scoped ESB (I don't see any others ESBs that is able to cover or extend as ServiceMix).
>
> So, ServiceMix is not dead at all !!! More over, I think that, with a clear position, providing and gathering differents technologies, ServiceMix will an awesome platform, ESB oriented but very extensible.
>
> So welcome to the new area of ServiceMix 5 :)
>
> Regards
> JB
>
> On 10/14/2010 04:35 PM, Guillaume Nodet wrote:
>> 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.
>>
>>
Johan Edstrom
joed@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
Re: [DISCUSS] ServiceMix future
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Guillaume has greatly summarize our discussion.
Our discussion starts from some facts:
1/ JBI is dead. The JBI 2.0 specification will never be released. It's
not due to technical leaks but, as Guillaume said, mainly due to politic
reasons.
2/ All that we can do with JBI could be achieved by Camel: if Camel
could manage most of message format (stream, binary, etc), of course it
can manage XML payload like JBI does. JBI imposes the XML message format
whereas Camel supports it and the developers just need to use it
(eventually using a Normalizer pattern). The MEP is defined in the Camel
route itself (depending of the from(), to(), etc statements).
3/ The maintenance cycle on the ServiceMix components is lower than the
Camel components. As it's more simple to write Camel components, the
Camel components scope is larger than the ServiceMix components one.
There are only one component present in ServiceMix which is not
available in Camel: servicemix-smpp. I'm gonna submit a patch to Camel
proposing a camel-smpp component.
4/ in the past, I had in mind to add WSDL publication in all ServiceMix
components to be able to use WS-BPEL in ODE. To be honest, after
thinking about that, I'm not sure if the best way to add BPM in
ServiceMix (see later :)).
As Guillaume, ServiceMix is really a great brand in OpenSource ESB. We
didn't speak about deleting ServiceMix project, but more adopt a clear
position.
My vision is the following:
- ServiceMix 3 should be marked as deprecated and unmaintained release.
- ServiceMix 4 should stay as it is currently: based on Karaf, adding
ActiveMQ, Camel, CXF and NMR/JBI
- I propose to preparate ServiceMix 5. ServiceMix 5 is clearly an ESB,
In ServiceMix 5, the JBI layer should be set as deprecated. It means
that we always provide the JBI features but not installed by default.
The users could installed it for backward compatibility if required.
ServiceMix 5 is a complete ESB, based on OSGi, gathering:
- Apache Felix + Apache Karaf
- Apache ActiveMQ: more than a message broker, ActiveMQ could be the
cluster and fail-over player
- Apache Camel: the integration and mediation layer, providing the
components and routing bases
- Apache CXF: I think that CXF directly ServiceMix will not make sense.
CXF will be provided by Camel CXF components, that is enough.
- BPM: ServiceMix 5 should embed a BPM engine. ODE requires the usage of
XML as it's based on WS-BPEL. I think that Activiti could be more
interesting as it's based on BPMN2.
- Tooling: ServiceMix 5 should provide more friendly tooling.
Especially, starting to the fact that we use Camel, we can provide a web
tool to see, design and monitor the Camel components and routes.
- Extensions: why not thinking about integrating (as optional or not)
others technologies. For example, I'm thinking about extending the Aries
usage, providing DOSGI using CXF, or supporting EJB3 using
OpenEJB/Geronimo. We have no limit to provide extra features to give a
full scoped ESB (I don't see any others ESBs that is able to cover or
extend as ServiceMix).
So, ServiceMix is not dead at all !!! More over, I think that, with a
clear position, providing and gathering differents technologies,
ServiceMix will an awesome platform, ESB oriented but very extensible.
So welcome to the new area of ServiceMix 5 :)
Regards
JB
On 10/14/2010 04:35 PM, Guillaume Nodet wrote:
> 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.
>
>
Re: [DISCUSS] ServiceMix future
Posted by Johan Edstrom <se...@gmail.com>.
Oh, and opennms is about 80% osgi now.
I just have been swamped.
On Oct 15, 2010, at 2:48 AM, Chris Custine 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 <se...@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 <
>> cmoulliard@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 <se...@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 <trenaman@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<gn...@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
>>>>>
>>>>> joed@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
>>
>> joed@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
joed@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
Re: [DISCUSS] ServiceMix future
Posted by James Strachan <ja...@gmail.com>.
Finally catching up on this monster thread after travel, jetlag and
getting behind on mail.
Very interesting stuff BTW!
On 15 October 2010 10:27, Guillaume Nodet <gn...@gmail.com> 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...).
Totally agreed. The NMR provides something Camel does not; using the
OSGi registry as a registry of endpoints which can be accessed from
any technology or class loader and supporting different versions of
Camel along with JBI support too.
BTW I don't think we should deprecate "JBI"; it should always be an
optional add on for ServiceMix. ServiceMix should be about integrating
anything; so we should absolutely support JBI components. Though we
should maybe encourage folks to use more Camel and maybe deprecate
some JBI components in favour of the Camel ones etc.
Though I see the NMR in ServiceMix as being what JBI should have been;
reusing the OSGi registry to act as a registry of endpoints; something
Camel doesn't really do as it tends to focus locally within a bundle
for its registry.
I like the idea of the NMR having a tiny API (so who knows it could
get standardised in an OSGi spec one day); but making it very
Camel-like to minimise wrapping makes sense too :). The implementation
of the NMR could just reuse Camel for example but keep the API simple
& small?
> 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.
Agreed
--
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/
Open Source Integration
Re: [DISCUSS] ServiceMix future
Posted by Chris Custine <ch...@gmail.com>.
I agree with this 100% Guillaume. I stated it differently, but this is
exactly what I was thinking.
--
Chris Custine
Sent from my mobile phone
On Oct 15, 2010 3:33 AM, "Guillaume Nodet" <gn...@gmail.com> 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.custine@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 <se...@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 <
>> > cmoulliard@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 <se...@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 <
>> trenaman@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<gn...@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
>> > >>>
>> > >>> joed@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
>> >
>> > joed@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
Re: [DISCUSS] ServiceMix future
Posted by davsclaus <ci...@yahoo.dk>.
The Camel survey is still in progress. It runs until the end of this month.
Apache CXF did a survey 1-2 months ago. They kinda started the survey trend
:)
I am sure Hadrian can help us setup a survey on SMX as well.
--
View this message in context: http://servicemix.396122.n5.nabble.com/DISCUSS-ServiceMix-future-tp3212177p3216032.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] ServiceMix future
Posted by Lars Heinemann <lh...@apache.org>.
It would be really neat then if the message exchange stuff would be the same for Camel and SMX.
Lars
Am 15.10.2010 um 12:38 schrieb Rob Davies:
> 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 <ch...@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 <se...@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 <
>>>> cmoulliard@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 <se...@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 <
>>> trenaman@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<gn...@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
>>>>>>>
>>>>>>> joed@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
>>>>
>>>> joed@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
>
Re: [DISCUSS] ServiceMix future
Posted by Bengt Rodehav <be...@rodehav.com>.
Another angle to all of this is to look at possible competitors. I've
recently started looking at Eclipse Virgo + Gemini which I think is worth
comparing with. It seems like Gemini is similar to Apache Aries while Virgo
is a "modular open source application server based on OSGi". Not sure if the
Apache equivalence would be Karaf+Aries or perhaps even ServiceMix. However,
on one of the last slides in one of their presentations (
http://archive.eclipse.org/technology/phoenix/webinars/100831_VirgoSlides.pdf)
they state that in the future they want to support more "server types" on
top of Virgo. On the list of server types is "Integration" which seems
related to what is in scope for ServiceMix.
I think it's of great value to be able to use the same platform for both
enterprise applications and integration focused applications. It's important
for developers to be able to reuse the skills from one application type to
the other. A common platform is therefore of great importance - so is
tooling. In this area I think that Eclipse will be a fierce competitor to
Apache. One of the challenges I have is to find a development (and
production) platform that is easy enough to put in the hands of our
developers. Keep in mind that OSGi in itself is possibly too complex for
many developers.
/Bengt
2010/10/16 Bengt Rodehav <be...@rodehav.com>
> Apache Camel did a survey less than two weeks ago. You could always ask
> them if it was useful or not...
>
> /Bengt
>
> 2010/10/16 Lars Heinemann <lh...@apache.org>
>
> Or maybe we should join the hype and go for a ServiceMix Survey ;)
>>
>> Lars
>>
>>
>> Am 16.10.2010 um 18:23 schrieb Charles Moulliard:
>>
>> > It could be interesting that we create a wiki page to discuss ServiceMix
>> 5 content ;-)
>> >
>> > On 16/10/10 16:35, Bengt Rodehav wrote:
>> >> I agree with Guillaume 100%.
>> >>
>> >> I'm sure there are lots of things in ServiceMix that provides a lot of
>> value
>> >> - scalability seems to be one of them. However, being a ServieMix user
>> >> myself (that lately favours Karaf+Camel instead), I know for sure that
>> the
>> >> vision and purpose with ServiceMix is not crystal clear. A clear vision
>> for
>> >> ServiceMix - that differentiate it from other projects like Karaf and
>> Camel
>> >> - is essential. Otherwise, I think ServiceMix will loose a large
>> portion of
>> >> its installed base.
>> >>
>> >> What Camel does well (and Camel does a lot of things really well)
>> should not
>> >> be duplicated in ServiceMix. It's a real waste with competent
>> resources.
>> >> Instead ServiceMix should find its unique value proposition. I think
>> that
>> >> value proposition really needs to be discussed.
>> >>
>> >> Some of the value I see in ServiceMix (some now and some possible in
>> the
>> >> future) are:
>> >>
>> >> - Umbrella project. It can be of great value if ServiceMix coordinates
>> >> versions of other projects and get them to work together. You would
>> then
>> >> have a working ESB and/or a platform for developing enterprise
>> applications
>> >> depending on what other projects are embraced.
>> >>
>> >> - OSGi glue. Like the specifications and bundles that ServiceMix
>> provides
>> >> today. This could be part of ServiceMix or it could be moved to an
>> >> independent project (like suggested by Ioannis). Either way, there is a
>> need
>> >> for this glue.
>> >>
>> >> - Scalability.
>> >>
>> >> - Improve on "production readiness". Among other things, this includes
>> >> tooling of different sorts. For deploying, monitoring, measuring and
>> >> managing. I think this is important when customers compare OSS products
>> with
>> >> commercial products. Although many OSS products have both functionality
>> and
>> >> quality in par with the commercial products, the "finishing touch" is
>> often
>> >> lacking. This is often in the area of tooling but also concerns
>> >> documentation. The umbrella project view is also important here.
>> Commercial
>> >> products often include "everything" and you can turn to one vendor to
>> get
>> >> the new release. With OSS you have to coordinate everything your self
>> which
>> >> is a risk for a company. If ServiceMix could decrease that risk than it
>> >> would be able to compete better with commercial software than if the
>> >> alternative would be Karaf+Camel+ActiveMQ+....that the customers would
>> have
>> >> to handle on their own.
>> >>
>> >> Isn't it time to perform a survey to really find out what the installed
>> user
>> >> base thinks? Some questions could be:
>> >>
>> >> - What type of applications do you target with ServiceMix? Integration,
>> >> enterprise applications or other (please specify)?
>> >>
>> >> - Is your use of ServiceMix increasing, decreasing or unchanged?
>> >>
>> >> - What are ServiceMix most valuable features?
>> >>
>> >> - What other options does ServiceMix compete with?
>> >>
>> >> - ... and so on....
>> >>
>> >> /Bengt
>> >>
>> >>
>> >>
>> >> 2010/10/16 Guillaume Nodet<gn...@gmail.com>
>> >>
>> >>> On Sat, Oct 16, 2010 at 13:39, Ioannis Canellos<io...@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<
>> cmoulliard@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.custine@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<se...@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<
>> >>>>>>>>>>>
>> >>>>>>>>>> cmoulliard@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<
>> >>> seijoed@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<
>> >>>>>>>>>>>>> trenaman@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<gn...@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
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> joed@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
>> >>>>>>>>>>
>> >>>>>>>>>> joed@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
>> >>>
>> >
>>
>>
>
Re: [DISCUSS] ServiceMix future
Posted by Bengt Rodehav <be...@rodehav.com>.
Apache Camel did a survey less than two weeks ago. You could always ask them
if it was useful or not...
/Bengt
2010/10/16 Lars Heinemann <lh...@apache.org>
> Or maybe we should join the hype and go for a ServiceMix Survey ;)
>
> Lars
>
>
> Am 16.10.2010 um 18:23 schrieb Charles Moulliard:
>
> > It could be interesting that we create a wiki page to discuss ServiceMix
> 5 content ;-)
> >
> > On 16/10/10 16:35, Bengt Rodehav wrote:
> >> I agree with Guillaume 100%.
> >>
> >> I'm sure there are lots of things in ServiceMix that provides a lot of
> value
> >> - scalability seems to be one of them. However, being a ServieMix user
> >> myself (that lately favours Karaf+Camel instead), I know for sure that
> the
> >> vision and purpose with ServiceMix is not crystal clear. A clear vision
> for
> >> ServiceMix - that differentiate it from other projects like Karaf and
> Camel
> >> - is essential. Otherwise, I think ServiceMix will loose a large portion
> of
> >> its installed base.
> >>
> >> What Camel does well (and Camel does a lot of things really well) should
> not
> >> be duplicated in ServiceMix. It's a real waste with competent resources.
> >> Instead ServiceMix should find its unique value proposition. I think
> that
> >> value proposition really needs to be discussed.
> >>
> >> Some of the value I see in ServiceMix (some now and some possible in the
> >> future) are:
> >>
> >> - Umbrella project. It can be of great value if ServiceMix coordinates
> >> versions of other projects and get them to work together. You would then
> >> have a working ESB and/or a platform for developing enterprise
> applications
> >> depending on what other projects are embraced.
> >>
> >> - OSGi glue. Like the specifications and bundles that ServiceMix
> provides
> >> today. This could be part of ServiceMix or it could be moved to an
> >> independent project (like suggested by Ioannis). Either way, there is a
> need
> >> for this glue.
> >>
> >> - Scalability.
> >>
> >> - Improve on "production readiness". Among other things, this includes
> >> tooling of different sorts. For deploying, monitoring, measuring and
> >> managing. I think this is important when customers compare OSS products
> with
> >> commercial products. Although many OSS products have both functionality
> and
> >> quality in par with the commercial products, the "finishing touch" is
> often
> >> lacking. This is often in the area of tooling but also concerns
> >> documentation. The umbrella project view is also important here.
> Commercial
> >> products often include "everything" and you can turn to one vendor to
> get
> >> the new release. With OSS you have to coordinate everything your self
> which
> >> is a risk for a company. If ServiceMix could decrease that risk than it
> >> would be able to compete better with commercial software than if the
> >> alternative would be Karaf+Camel+ActiveMQ+....that the customers would
> have
> >> to handle on their own.
> >>
> >> Isn't it time to perform a survey to really find out what the installed
> user
> >> base thinks? Some questions could be:
> >>
> >> - What type of applications do you target with ServiceMix? Integration,
> >> enterprise applications or other (please specify)?
> >>
> >> - Is your use of ServiceMix increasing, decreasing or unchanged?
> >>
> >> - What are ServiceMix most valuable features?
> >>
> >> - What other options does ServiceMix compete with?
> >>
> >> - ... and so on....
> >>
> >> /Bengt
> >>
> >>
> >>
> >> 2010/10/16 Guillaume Nodet<gn...@gmail.com>
> >>
> >>> On Sat, Oct 16, 2010 at 13:39, Ioannis Canellos<io...@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<
> cmoulliard@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.custine@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<se...@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<
> >>>>>>>>>>>
> >>>>>>>>>> cmoulliard@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<
> >>> seijoed@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<
> >>>>>>>>>>>>> trenaman@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<gn...@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
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> joed@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
> >>>>>>>>>>
> >>>>>>>>>> joed@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
> >>>
> >
>
>
Re: [DISCUSS] ServiceMix future
Posted by Lars Heinemann <lh...@apache.org>.
Or maybe we should join the hype and go for a ServiceMix Survey ;)
Lars
Am 16.10.2010 um 18:23 schrieb Charles Moulliard:
> It could be interesting that we create a wiki page to discuss ServiceMix 5 content ;-)
>
> On 16/10/10 16:35, Bengt Rodehav wrote:
>> I agree with Guillaume 100%.
>>
>> I'm sure there are lots of things in ServiceMix that provides a lot of value
>> - scalability seems to be one of them. However, being a ServieMix user
>> myself (that lately favours Karaf+Camel instead), I know for sure that the
>> vision and purpose with ServiceMix is not crystal clear. A clear vision for
>> ServiceMix - that differentiate it from other projects like Karaf and Camel
>> - is essential. Otherwise, I think ServiceMix will loose a large portion of
>> its installed base.
>>
>> What Camel does well (and Camel does a lot of things really well) should not
>> be duplicated in ServiceMix. It's a real waste with competent resources.
>> Instead ServiceMix should find its unique value proposition. I think that
>> value proposition really needs to be discussed.
>>
>> Some of the value I see in ServiceMix (some now and some possible in the
>> future) are:
>>
>> - Umbrella project. It can be of great value if ServiceMix coordinates
>> versions of other projects and get them to work together. You would then
>> have a working ESB and/or a platform for developing enterprise applications
>> depending on what other projects are embraced.
>>
>> - OSGi glue. Like the specifications and bundles that ServiceMix provides
>> today. This could be part of ServiceMix or it could be moved to an
>> independent project (like suggested by Ioannis). Either way, there is a need
>> for this glue.
>>
>> - Scalability.
>>
>> - Improve on "production readiness". Among other things, this includes
>> tooling of different sorts. For deploying, monitoring, measuring and
>> managing. I think this is important when customers compare OSS products with
>> commercial products. Although many OSS products have both functionality and
>> quality in par with the commercial products, the "finishing touch" is often
>> lacking. This is often in the area of tooling but also concerns
>> documentation. The umbrella project view is also important here. Commercial
>> products often include "everything" and you can turn to one vendor to get
>> the new release. With OSS you have to coordinate everything your self which
>> is a risk for a company. If ServiceMix could decrease that risk than it
>> would be able to compete better with commercial software than if the
>> alternative would be Karaf+Camel+ActiveMQ+....that the customers would have
>> to handle on their own.
>>
>> Isn't it time to perform a survey to really find out what the installed user
>> base thinks? Some questions could be:
>>
>> - What type of applications do you target with ServiceMix? Integration,
>> enterprise applications or other (please specify)?
>>
>> - Is your use of ServiceMix increasing, decreasing or unchanged?
>>
>> - What are ServiceMix most valuable features?
>>
>> - What other options does ServiceMix compete with?
>>
>> - ... and so on....
>>
>> /Bengt
>>
>>
>>
>> 2010/10/16 Guillaume Nodet<gn...@gmail.com>
>>
>>> On Sat, Oct 16, 2010 at 13:39, Ioannis Canellos<io...@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<cmoulliard@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.custine@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<se...@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<
>>>>>>>>>>>
>>>>>>>>>> cmoulliard@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<
>>> seijoed@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<
>>>>>>>>>>>>> trenaman@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<gn...@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
>>>>>>>>>>>>>
>>>>>>>>>>>>> joed@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
>>>>>>>>>>
>>>>>>>>>> joed@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
>>>
>
Re: [DISCUSS] ServiceMix future
Posted by Charles Moulliard <cm...@gmail.com>.
It could be interesting that we create a wiki page to discuss
ServiceMix 5 content ;-)
On 16/10/10 16:35, Bengt Rodehav wrote:
> I agree with Guillaume 100%.
>
> I'm sure there are lots of things in ServiceMix that provides a lot of value
> - scalability seems to be one of them. However, being a ServieMix user
> myself (that lately favours Karaf+Camel instead), I know for sure that the
> vision and purpose with ServiceMix is not crystal clear. A clear vision for
> ServiceMix - that differentiate it from other projects like Karaf and Camel
> - is essential. Otherwise, I think ServiceMix will loose a large portion of
> its installed base.
>
> What Camel does well (and Camel does a lot of things really well) should not
> be duplicated in ServiceMix. It's a real waste with competent resources.
> Instead ServiceMix should find its unique value proposition. I think that
> value proposition really needs to be discussed.
>
> Some of the value I see in ServiceMix (some now and some possible in the
> future) are:
>
> - Umbrella project. It can be of great value if ServiceMix coordinates
> versions of other projects and get them to work together. You would then
> have a working ESB and/or a platform for developing enterprise applications
> depending on what other projects are embraced.
>
> - OSGi glue. Like the specifications and bundles that ServiceMix provides
> today. This could be part of ServiceMix or it could be moved to an
> independent project (like suggested by Ioannis). Either way, there is a need
> for this glue.
>
> - Scalability.
>
> - Improve on "production readiness". Among other things, this includes
> tooling of different sorts. For deploying, monitoring, measuring and
> managing. I think this is important when customers compare OSS products with
> commercial products. Although many OSS products have both functionality and
> quality in par with the commercial products, the "finishing touch" is often
> lacking. This is often in the area of tooling but also concerns
> documentation. The umbrella project view is also important here. Commercial
> products often include "everything" and you can turn to one vendor to get
> the new release. With OSS you have to coordinate everything your self which
> is a risk for a company. If ServiceMix could decrease that risk than it
> would be able to compete better with commercial software than if the
> alternative would be Karaf+Camel+ActiveMQ+....that the customers would have
> to handle on their own.
>
> Isn't it time to perform a survey to really find out what the installed user
> base thinks? Some questions could be:
>
> - What type of applications do you target with ServiceMix? Integration,
> enterprise applications or other (please specify)?
>
> - Is your use of ServiceMix increasing, decreasing or unchanged?
>
> - What are ServiceMix most valuable features?
>
> - What other options does ServiceMix compete with?
>
> - ... and so on....
>
> /Bengt
>
>
>
> 2010/10/16 Guillaume Nodet<gn...@gmail.com>
>
>> On Sat, Oct 16, 2010 at 13:39, Ioannis Canellos<io...@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<cmoulliard@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.custine@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<se...@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<
>>>>>>>>>>
>>>>>>>>> cmoulliard@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<
>> seijoed@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<
>>>>>>>>>>>> trenaman@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<gn...@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
>>>>>>>>>>>>
>>>>>>>>>>>> joed@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
>>>>>>>>>
>>>>>>>>> joed@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
>>
Re: [DISCUSS] ServiceMix future
Posted by Bengt Rodehav <be...@rodehav.com>.
I agree with Guillaume 100%.
I'm sure there are lots of things in ServiceMix that provides a lot of value
- scalability seems to be one of them. However, being a ServieMix user
myself (that lately favours Karaf+Camel instead), I know for sure that the
vision and purpose with ServiceMix is not crystal clear. A clear vision for
ServiceMix - that differentiate it from other projects like Karaf and Camel
- is essential. Otherwise, I think ServiceMix will loose a large portion of
its installed base.
What Camel does well (and Camel does a lot of things really well) should not
be duplicated in ServiceMix. It's a real waste with competent resources.
Instead ServiceMix should find its unique value proposition. I think that
value proposition really needs to be discussed.
Some of the value I see in ServiceMix (some now and some possible in the
future) are:
- Umbrella project. It can be of great value if ServiceMix coordinates
versions of other projects and get them to work together. You would then
have a working ESB and/or a platform for developing enterprise applications
depending on what other projects are embraced.
- OSGi glue. Like the specifications and bundles that ServiceMix provides
today. This could be part of ServiceMix or it could be moved to an
independent project (like suggested by Ioannis). Either way, there is a need
for this glue.
- Scalability.
- Improve on "production readiness". Among other things, this includes
tooling of different sorts. For deploying, monitoring, measuring and
managing. I think this is important when customers compare OSS products with
commercial products. Although many OSS products have both functionality and
quality in par with the commercial products, the "finishing touch" is often
lacking. This is often in the area of tooling but also concerns
documentation. The umbrella project view is also important here. Commercial
products often include "everything" and you can turn to one vendor to get
the new release. With OSS you have to coordinate everything your self which
is a risk for a company. If ServiceMix could decrease that risk than it
would be able to compete better with commercial software than if the
alternative would be Karaf+Camel+ActiveMQ+....that the customers would have
to handle on their own.
Isn't it time to perform a survey to really find out what the installed user
base thinks? Some questions could be:
- What type of applications do you target with ServiceMix? Integration,
enterprise applications or other (please specify)?
- Is your use of ServiceMix increasing, decreasing or unchanged?
- What are ServiceMix most valuable features?
- What other options does ServiceMix compete with?
- ... and so on....
/Bengt
2010/10/16 Guillaume Nodet <gn...@gmail.com>
> On Sat, Oct 16, 2010 at 13:39, Ioannis Canellos <io...@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 <cmoulliard@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.custine@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<se...@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<
> > >>>>>>>
> > >>>>>> cmoulliard@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<
> seijoed@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<
> > >>>>>>>>>>
> > >>>>>>>>> trenaman@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<gn...@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
> > >>>>>>>>>
> > >>>>>>>>> joed@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
> > >>>>>>
> > >>>>>> joed@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
>
Re: [DISCUSS] ServiceMix future
Posted by Guillaume Nodet <gn...@gmail.com>.
On Sat, Oct 16, 2010 at 13:39, Ioannis Canellos <io...@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 <cmoulliard@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.custine@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<se...@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<
> >>>>>>>
> >>>>>> cmoulliard@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<se...@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<
> >>>>>>>>>>
> >>>>>>>>> trenaman@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<gn...@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
> >>>>>>>>>
> >>>>>>>>> joed@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
> >>>>>>
> >>>>>> joed@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
Re: [DISCUSS] ServiceMix future
Posted by Ioannis Canellos <io...@gmail.com>.
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.
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.
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.
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.
On Fri, Oct 15, 2010 at 2:21 PM, Charles Moulliard <cm...@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.custine@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<se...@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<
>>>>>>>
>>>>>> cmoulliard@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<se...@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<
>>>>>>>>>>
>>>>>>>>> trenaman@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<gn...@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
>>>>>>>>>
>>>>>>>>> joed@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
>>>>>>
>>>>>> joed@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>
Re: [DISCUSS] ServiceMix future
Posted by Charles Moulliard <cm...@gmail.com>.
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<ch...@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<se...@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<
>>>>> cmoulliard@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<se...@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<
>>>> trenaman@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<gn...@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
>>>>>>>>
>>>>>>>> joed@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
>>>>>
>>>>> joed@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
>>
Re: [DISCUSS] ServiceMix future
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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<ch...@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<se...@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<
>>>> cmoulliard@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<se...@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<
>>> trenaman@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<gn...@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
>>>>>>>
>>>>>>> joed@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
>>>>
>>>> joed@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
>
Re: [DISCUSS] ServiceMix future
Posted by Rob Davies <ra...@gmail.com>.
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 <ch...@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 <se...@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 <
>>> cmoulliard@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 <se...@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 <
>> trenaman@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<gn...@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
>>>>>>
>>>>>> joed@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
>>>
>>> joed@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
Re: [DISCUSS] ServiceMix future
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <ch...@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 <se...@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 <
> > cmoulliard@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 <se...@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 <
> trenaman@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<gn...@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
> > >>>
> > >>> joed@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
> >
> > joed@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
Re: [DISCUSS] ServiceMix future
Posted by Chris Custine <ch...@gmail.com>.
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 <se...@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 <
> cmoulliard@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 <se...@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 <trenaman@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<gn...@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
> >>>
> >>> joed@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
>
> joed@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
>
>
>
>
>
>
Re: [DISCUSS] ServiceMix future
Posted by Johan Edstrom <se...@gmail.com>.
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 <cmoulliard@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 <se...@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 <trenaman@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<gn...@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
>>>
>>> joed@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
joed@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
Re: [DISCUSS] ServiceMix future
Posted by Chris Custine <ch...@gmail.com>.
I forgot to add, that particularly in the case of
clustering/DOSGI/grid/large scale environments, etc., having too much
routing functionality tied up down at the camel level just doesn't make much
sense. Having the NMR and other generic requirements as a container
supplied services will allow centralized administration and configuration
and make much more sense in this case. So this is another reason I don't
like the idea of shifting NMR like responsibilities up to a higher level in
the stack.
Chris
--
Chris Custine
FuseSource - Open Source Integration:: http://fusesource.com
My Blog :: http://blog.organicelement.com
On Fri, Oct 15, 2010 at 02:31, Chris Custine <ch...@gmail.com>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 <
> cmoulliard@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 <se...@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 <trenaman@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<gn...@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
>> >
>> > joed@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
>> >
>> >
>> >
>> >
>> >
>> >
>>
>
>
Re: [DISCUSS] ServiceMix future
Posted by ra...@gmail.com.
+1!
Eliminating the NMR, or moving it out of the global scope, assumes that everyone is using 1 and only 1 Camel route to cover each integration scenario. No one is communicating Camel to Camel via the NMR?
How would inter-service communication be handled if the NMR is omitted? How would the ability to decouple - a fundamental SOA principle - be affected?
Apologies if I'm missing out on something...
-----Original Message-----
From: Chris Custine <ch...@gmail.com>
Date: Fri, 15 Oct 2010 02:31:05
To: <de...@servicemix.apache.org>
Reply-To: dev@servicemix.apache.org
Subject: Re: [DISCUSS] ServiceMix future
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 <cmoulliard@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 <se...@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 <trenaman@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<gn...@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
> >
> > joed@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
> >
> >
> >
> >
> >
> >
>
Re: [DISCUSS] ServiceMix future
Posted by Lars Heinemann <lh...@apache.org>.
Thats true. Not everyone using SMX is automatically using Camel. Speaking for myself I rarely used Camel inside
ServiceMix because it was simply not needed. SMX provided everything that was required.
Regards
Lars
Am 15.10.2010 um 10:31 schrieb Chris Custine:
> 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 <cmoulliard@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 <se...@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 <trenaman@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<gn...@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
>>>
>>> joed@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
>>>
>>>
>>>
>>>
>>>
>>>
>>
Re: [DISCUSS] ServiceMix future
Posted by Chris Custine <ch...@gmail.com>.
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 <cmoulliard@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 <se...@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 <trenaman@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<gn...@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
> >
> > joed@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
> >
> >
> >
> >
> >
> >
>
Re: [DISCUSS] ServiceMix future
Posted by Charles Moulliard <cm...@fusesource.com>.
On 15/10/10 09:53, Johan Edstrom wrote:
> The vm:// can't abstract endpoints over several installations.
>
>
> On Oct 15, 2010, at 1:50 AM, Moulliard, Charles 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<se...@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<trenaman@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<gn...@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
>>>
>>> joed@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
>
> joed@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
>
>
>
>
>
If by installations, you mean different instances / servers of SMX4,
this is also the case for NMR except if you use JMS. But in this case,
JMS is probably the most appropriate choice instead of vm:// & NMR.
Re: [DISCUSS] ServiceMix future
Posted by Johan Edstrom <se...@gmail.com>.
The vm:// can't abstract endpoints over several installations.
On Oct 15, 2010, at 1:50 AM, Moulliard, Charles 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 <se...@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 <trenaman@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<gn...@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
>>
>> joed@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
joed@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
Re: [DISCUSS] ServiceMix future
Posted by "Moulliard, Charles" <cm...@fusesource.com>.
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 <se...@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 <trenaman@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<gn...@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
>
> joed@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
>
>
>
>
>
>
Re: [DISCUSS] ServiceMix future
Posted by Johan Edstrom <se...@gmail.com>.
+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 <tr...@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<gn...@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
joed@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
Re: [DISCUSS] ServiceMix future
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Oct 14, 2010 at 20:14, Adrian Trenaman <tr...@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<gn...@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
Re: [DISCUSS] ServiceMix future
Posted by James Strachan <ja...@gmail.com>.
I agree with lots of comments here, particularly Guillaume, Adrian &
Chris's points resonate most strongly with me.
I understand that if you look at the pieces, say just Camel or Camel +
Karaf, folks might not need the full ServiceMix. Its worth stepping
back to realise that all those pieces kinda came from ServiceMix in
the first place! Rather than being one big honking project which was
app server + ESB + routing engine, we kinda decoupled pieces into
their own smaller projects with their own life. This is a good thing!
The container, integration library, NMR, JBI layers are all now
optional pieces. We shouldn't beat ourselves or ServiceMix up too much
because its done the great thing of modularising itself so folks can
use as much or as little as they like.
When I think of ServiceMix I still think of it as the box with all the
pieces; like any vendors ESB diagram does. To me ServiceMix is Karaf +
Camel + CXF + ActiveMQ + OSGi + NMR + JBI + loads of other stuff. It
doesn't really matter to me how much code lives *just* in ServiceMix
or whether the code is in Karaf or Camel or ActiveMQ or CXF or
whatever; to me ServiceMix is the ESB - the "Enterprise Service Bus"
or "Services Grid" or what have you; its the packaging, integration,
documentation and tooling of all these technologies in a single place
- where you can eat as much or as little as you like. ServiceMix has a
great brand too :)
For me personally I think ServiceMix should start to look higher up
the stack & focus more on the bigger picture of the end user consuming
all these different technologies across a number of machines. e.g.
providing consistent security, transactions, monitoring, auditing
across routes and containers. Maybe providing load balancing of non
JMS endpoints using a registry. Maybe integrating tooling like this...
http://www.slideshare.net/rguigsaad/activebam-5583589
If nothing else though, to me ServiceMix is the ESB; its the place
where we figure out how to integrate all these projects together and
create samples, documentation, recipe's and tooling. It doesn't matter
to me really how much implementation detail code lives inside CXF or
Camel or Karaf etc; ServiceMix has a clear focus on being the ESB and
preferred deployment container for all this integration stuff.
On 14 October 2010 19:14, Adrian Trenaman <tr...@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 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<gn...@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
>>>
>
--
James
-------
FuseSource
Email: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/
Open Source Integration
Re: [DISCUSS] ServiceMix future
Posted by Bengt Rodehav <be...@rodehav.com>.
Seems like we're pretty much in agreement Adrian.
How do you feel about the area that is targeted by a project like Aries?
Although useful in an integration scenario, I think the goal is more an OSGi
based "enterprise application server". When starting to use Karaf+Camel one
starts to think why I use a JEE application server for certain applications
but not for integration scenarios.
I've started exploring an OSGi based alternative to JEE. Aries is one part
in this. However, hasn't ServiceMix also been gearing in this direction? I
know ServiceMix provides OSGi bundles both for JEE specifications and
implementations thereof. Perhaps ServiceMix can provide a large enough stack
to be an alternative both in integration scenarios and "normal" enterprise
applications (instead of JEE). Not sure if this would compete with Geronimo
since OSGi is used there as well (as in the implementaion of many
application servers these days). However, using OSGi for implementing your
application server is not the same as being natively OSGi which ServiceMix
would be.
/Bengt
2010/10/14 Adrian Trenaman <tr...@progress.com>
> 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 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<gn...@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
>>>
>>>
Re: [DISCUSS] ServiceMix future
Posted by Guillaume Nodet <gn...@gmail.com>.
The clustering engine delegates to JMS, so if you're using a Camel route.
you could just add a JMS endpoint in the middle of the route and it would
work the same. That's also what a lot of people did in ServiceMix 3 by
adding a JMS endpoint provider / consumer pair in the middle of their usual
flow.
2010/10/15 Juan José Vázquez Delgado <ju...@gmail.com>
> Hi,
>
> >
> > * 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.
> >
>
> Just a point about this. AFAIK, the clustering stuff is built on top
> of the JBI layer ATM [1]. If JBI is deprecated or not promoted, what
> will happen with it?.
>
> BR,
>
> Juanjo.
>
> [1] http://servicemix.apache.org/SMX4NMR/13-clustering.html
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] ServiceMix future
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
Hi,
>
> * 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.
>
Just a point about this. AFAIK, the clustering stuff is built on top
of the JBI layer ATM [1]. If JBI is deprecated or not promoted, what
will happen with it?.
BR,
Juanjo.
[1] http://servicemix.apache.org/SMX4NMR/13-clustering.html
Re: [DISCUSS] ServiceMix future
Posted by Johan Edstrom <se...@gmail.com>.
I think what possibly is missing as well in the general context is
how much work / thought is behind servicemix-specs.... \
I've heard out on gigs "Well, it is only felix and some command line tools" to which I'll
start snickering, because getting EE / JSR services going under Osgi is no easy feat.
Karaf as a management console and deployment environment is pretty darn savvy.
Not to mention that Yes, you can use it as an EE container. But it isn't forcing you to do that :)
Things like being able to deploy webapps.
Working with some snoracle buddies - I can also say that the builds we have are pretty "stellar"....
It is a pretty magnificent deployment/cloud/maven integrated "device" as in - Nice for sysadmins
I think what really would be neat is a focus on extremely fast DOSGI - i.e wire protocol fast.
I know I want that.
In a way I think SMX4 is "hard to wrap your head around" as it can be...
OSGi, EE, JBI, WebContainer or all of the above. - You pick!
/je
On Oct 15, 2010, at 12:52 AM, Chris Custine wrote:
> Adrian's comments mirror my thoughts almost exactly. Over time, I would
> like to see increasingly tighter integration with Camel such that Camel is
> more of a first class citizen in ServiceMix alongside the NMR. This is
> already progressing nicely, but if we continue to pursue tight knit
> integration with Camel and selectively de-emphasize aging technologies like
> JBI over time, the confusion about how to use ServiceMix, Camel, and the NMR
> together will have more clarity. I think the benefits of using the runtime
> services of ServiceMix and NMR as a deployment container and router for
> Camel routes is still often overlooked.
>
> Obviously Karaf should continue to be the core container for runtime
> services and OSGi. In lieu of an integration specific standard such as JBI,
> OSGi provides a generic model to build internal services and components so
> that code is not tied 100% to the integration use case. I see this bringing
> comfort to those projects worried about writing a lot of code against a task
> specific API or vendor specific product API.
>
> In general, I am all for streamlining the project over time, so that we do
> not have 2 or more generations of the project to divide our attention. With
> the current JBI interoperability and shared components releases, I
> definitely think we can begin recommending the move to ServiceMix 4 for
> existing ServiceMix 3 users. Moving forward with new features and tools
> will be much easier if we establish a roadmap for this kind of transition
> and we can begin looking forward to these new things without worrying about
> limitations of supporting them in legacy code.
>
> My 2 cents.
>
> --
> Chris Custine
> FuseSource - Open Source Integration:: http://fusesource.com
> My Blog :: http://blog.organicelement.com
>
>
>
>
> On Thu, Oct 14, 2010 at 12:14, Adrian Trenaman <tr...@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 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<gn...@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
>>>>
>>>>
Johan Edstrom
joed@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
Re: [DISCUSS] ServiceMix future
Posted by Chris Custine <ch...@gmail.com>.
Adrian's comments mirror my thoughts almost exactly. Over time, I would
like to see increasingly tighter integration with Camel such that Camel is
more of a first class citizen in ServiceMix alongside the NMR. This is
already progressing nicely, but if we continue to pursue tight knit
integration with Camel and selectively de-emphasize aging technologies like
JBI over time, the confusion about how to use ServiceMix, Camel, and the NMR
together will have more clarity. I think the benefits of using the runtime
services of ServiceMix and NMR as a deployment container and router for
Camel routes is still often overlooked.
Obviously Karaf should continue to be the core container for runtime
services and OSGi. In lieu of an integration specific standard such as JBI,
OSGi provides a generic model to build internal services and components so
that code is not tied 100% to the integration use case. I see this bringing
comfort to those projects worried about writing a lot of code against a task
specific API or vendor specific product API.
In general, I am all for streamlining the project over time, so that we do
not have 2 or more generations of the project to divide our attention. With
the current JBI interoperability and shared components releases, I
definitely think we can begin recommending the move to ServiceMix 4 for
existing ServiceMix 3 users. Moving forward with new features and tools
will be much easier if we establish a roadmap for this kind of transition
and we can begin looking forward to these new things without worrying about
limitations of supporting them in legacy code.
My 2 cents.
--
Chris Custine
FuseSource - Open Source Integration:: http://fusesource.com
My Blog :: http://blog.organicelement.com
On Thu, Oct 14, 2010 at 12:14, Adrian Trenaman <tr...@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 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<gn...@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
>>>
>>>
Re: [DISCUSS] ServiceMix future
Posted by Adrian Trenaman <tr...@progress.com>.
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 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<gn...@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
>>
Re: [DISCUSS] ServiceMix future
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <gn...@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
>
Re: [DISCUSS] ServiceMix future
Posted by Willem Jiang <wi...@gmail.com>.
On 10/17/10 6:02 PM, Claus Ibsen wrote:
> Hi
>
> Yeah I am subscriber now. For whatever reason I was on a subscriber on
> the user list.
> Well I got the attention of this great discussion from Ade's tweet.
>
>
> On Sun, Oct 17, 2010 at 11:35 AM, Jean-Baptiste Onofré<jb...@nanthrax.net> wrote:
>> Hi Claus (and the others ;)),
>>
>> in the same way of your latest post, I begin an use case on github
>> (http://github.com/jbonofre/jbi-camel) to compare Camel and SMX components
>> in a "real" use case.
>>
>> The use case is the following:
>> - One POJO is exposed in SMX using servicemix-cxf-se component. The endpoint
>> is named cxf-se.
>> - The cxf-se endpoint is "facaded" by two endpoints: a HTTP one (using
>> servicemix-http) and a JMS one (using servicemix-jms). The first one use
>> In-Out MEP and the second one In-Only.
>>
>> Up to now, I saw some majors differences (correct me if I'm wrong :)):
>> 1/ Mediation and Procol Interchange
>> Using ServiceMix components, we can add a new endpoint in facade of an
>> existing one, just by adding the xbean of the new endpoint. In Camel,
>> changing the facade endpoint means changing the Camel route and adding a new
>> facade endpoint means adding a new Camel route. It seems that defining
>> several from() is not allowed.
>
> Yes you can, since Camel 2.0. You can have as many inputs to a route you like.
> from("xxx", "yyy", "zzz").to("bla");
>
>
>
>> 2/ Endpoint proxy
>> The servicemix-http component is able to get the WSDL of the target endpoint
>> (if there is one in the endpoint descriptor). It's not required to define
>> the WSDL in the HTTP endpoint attributes. It means that the WSDL is very
>> dynamic as it depends of the interfaces used by the POJO in cxf-se endpoint.
>> The Camel HTTP or CXF components are not able to do it. It can take at least
>> a "local" and "static" WSDL in endpoint attributes.
>
> In Camel you can proxy a service over HTTP or WS (eg using CXF), or
> whatever transport you like.
> However you will have to do this as a route, eg you need from -> to
>
> For example a little CXF example here
> https://cwiki.apache.org/confluence/display/CAMEL/CXF+Proxy+Example
>
If you are using the POJO data formate of the camel-cxf endpont, and you
don't specify the WSDL url, the WSDL will be generated from the SEI,
which is much like the CXF does.
Just one more shortcoming of the cxf-se, you need to fee the cxf-se
endpoint with the JBI message, but if you take a look at cxfbean[1]
component which is much like the cxf-se, you will find it is more easy
to be used :)
[1]http://camel.apache.org/cxf-bean-component.html
>
>> 3/ Display available services
>> The servicemix-http component is able to display a HTML page containing the
>> available HTTP services. If you click on one service, you can have the
>> endpoint WSDL (main.wsdl).
>> This logic is not present in the camel-http or camel-cxf components. The
>> users should know the Camel routes availables with the corresponding WSDL
>
> Well I would assume it could be part of the transport container. Eg
> CXF can show which web services it manages.
> Likewise a HTTP container (Jetty, Servlet) could do this as well.
>
> However in terms of Camel it has API to access information about its
> routes, consumers, endpoints etc.
> So you can make those easily avail on a html page if you like.
>
> Better management tooling may add such in the future. For example a
> Camel shell in Karaf.
>
>
CXF provides these function out of box, if you are using camel-cxf
component you can use it directly.
>
>> 4/ Async behavior
>> The servicemix-http components uses Jetty continuation to be able to process
>> HTTP request in an async way. It doesn't seem to be the case for camel-http
>> component (I have not yet check the camel-cxf one).
>
> The camel http component is based on Apache Http Client 3.1 which
> doesnt supprot async.
> You can use camel-http4 or camel-jetty for async instead.
>
> However I would like to integrate the Async Http Client project to
> Camel in the future. This project looks really cool.
> http://github.com/ning/async-http-client
Just one more note, from Camel 2.5.0 camel-cxf leverage the CXF
continucation API to consumer the request asyncly.
>
>
>> 5/ MEP
>> In Camel, the MEP is implemented by the route itself and so you need to
>> define one route per MEP that you want to manage.
>>
>
> No the MEP is part of the Exchange.
>
>
>> So, for me it's clear that ServiceMix components provide a large set of
>> features, not all cover by Camel endpoints.
>
> Large set? Sorry I fail to see the "large".
> Of course SMX != Camel and therefore they are not 100% identical.
>
> As suggested by others in this forum I agree (hardly any surprise as I
> am biased towards Camel) to work together and improve the Camel
> components rather than maintaining or working on the JBI.
> They (JBI components) should be considered in "maintenance mode".
>
> But in the end the community spoke and the momentum is on the Camel
> components, rather than the SMX counterparts.
>
>
>> The huge limitation of ServiceMix components is the fact that messages HAVE
>> TO BE in XML (XML payload). It's a huge limitation because for example it's
>> not possible to provide REST services. More over the marshaling could be
>> difficult to be (for example in servicemix-rmi, I have not yet completed the
>> marshaler :/) and performances are directly impacted (for example
>> servicemix-pdf should work in stream and avoid marshaling/unmarshaling for
>> better performance). Camel is largely better in the message using
>> TypeConverter and the possibility to work with stream, binaries, etc.
>>
>
> Another huge limitation is the fact there has hardly been any new
> development on SMX components.
> Its basically the same set of components we have had for the last 2+ years.
> Also a minor issue is the documentation. The SMX is not that well
> maintained and documented. We do seem to be better at this at Camel.
>
> Also the issue tracker of the SMX components is not having high
> attention. So if people report an issue or improvement it may go
> unattended.
>
> The community have spoken and are donating components to Camel instead
> of JBI/SMX.
>
>
>
>
>> Now, we have three options:
>> - improve and extend Camel components features to be iso between ServiceMix
>> components and Camel components
>> - stop the JBI features which "force" the usage of XML payload and provide
>> ServiceMix "NMR" components providing MEP, all features but able to manage a
>> large set of message formats (stream, bean, etc).
>> - provide a kind of servicemix-camel-bridge component that is able to use an
>> underlying Camel component but adding some extra feature such as WSDL
>> exposition in descriptor, NMR registration of the endpoint, etc.
>>
>> For now, I'm working on my local git repo, I will commit on github later
>> today.
>>
>> Any comments/thoughts are welcome, maybe especially from the Camel guys :)
>>
>> Thanks
>> Regards
>> JB
>>
>> On 10/17/2010 10:37 AM, davsclaus wrote:
>>>
>>>
>>> I agree that Camel has all components SMX has but the question is if they
>>> are as good as their
>>> smx pendants. For camel-mail<-> servicemix-mail I would say that the smx
>>> one has more functionality.
>>> So I would not blindly thre away our components without checking that
>>> first.
>>>
>>>
>>> Lars I think they are on par. The only feature I can see SMX has which
>>> Camel
>>> doesn't is the storage option.
>>> Then again Camel have some options which SMX doesn't.
>>>
>>> In any case agree on the people who voice that it would make sense to
>>> focus
>>> development on the Camel components, over the "deprecated/maintenance
>>> mode"
>>> JBI components.
>>>
>>> And someone said there was no SMPP component in Camel. In fact people from
>>> the community donated such as component
>>> http://camel.apache.org/smpp
>>>
>>> I think we got almost all SMX components covered now in Camel. For example
>>> JBoss Drools now comes with native support for Camel.
>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> ---------------------------------
>> HomePage
>> http://www.nanthrax.net
>> ---------------------------------
>> Contacts
>> jbonofre@apache.org
>> jb@nanthrax.net
>> ---------------------------------
>> OpenSource
>> BuildProcess/AutoDeploy
>> http://buildprocess.sourceforge.net
>> Apache ServiceMix
>> http://servicemix.apache.org
>> -----------------------------------
>> PGP : 17D4F086
>>
>
>
>
--
Willem
----------------------------------
Open Source Integration: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: http://twitter.com/willemjiang
RE: [DISCUSS] ServiceMix future
Posted by Łukasz Dywicki <lu...@code-house.org>.
Hi,
One thing that hurts me In JDBC Auditor is (de)serialization. GUI or other
tool have to access all classes to display audited message.
It's big deal because we create runtime dependency to services. If we'll
undeploy it we simply cannot view audited exchange.
Also in my opinion the docbook is not the best tool for documentation. The
format is pretty havy and makes impossible community to improve docs. Wiki
has lower impact but also it also have drawbacks.
Best regards,
Lukasz
-----Original Message-----
From: Jean-Baptiste Onofré [mailto:jb@nanthrax.net]
Sent: Sunday, October 17, 2010 7:44 PM
To: dev@servicemix.apache.org
Subject: Re: [DISCUSS] ServiceMix future
Hi Christian,
In ServiceMix, you can eanble the JDBCAuditor which store all JBI
messages in transit in the NMR and store it in a database. The Auditor
could started/stopped via JMX.
For the BPM, we started to discuss of that with Guillaume. Activiti,
especially if it becomes an Apache project, will be a very good candidate.
For the documentation, we are all agree with that. I started several
threads about this, including some start using DocBook in the sandbox,
etc. We really need to gear up this topic. Gert started a Scalate
documentation.
We can start a draft of the "future" ServiceMix 5 architecture, using
more Camel components, BPM, toolbox, etc.
Regards
JB
On 10/17/2010 06:50 PM, Christian Müller wrote:
> My 2 cents:
>
> In my company, we started using SMX last year. At this time, SMX4 was out
> and with the advice from Ade we are using the camel provided components
> instead of the SMX provided components for our integration solutions. It
> looks for us JBI is dead and OSGI is well established.
>
> What we would like to see in the future is:
> - Better documentation for SMX4 (or SMX5 in the future). A good
alternative
> will be the "ServiceMix in Action" book from Charles and Ade...
> - Better monitoring/auditing capabilities for troubleshooting like storing
a
> snapshot (copy) of the exchange (with Prooperties, Messages, Headers and
may
> be Attachments) in a database before/after each processing step. With an
> "excludes" and/or "includes" pattern we could define which processing
steps
> should audit or nor. With a header filter strategy (like we have in Camel)
> we could filter headers and properties which should not logged. And for
> Chrismas, I wish a nice GUI with which we can see how each exchange was
> routed and modified... - may be this is more a Camel topic.
> - Support for BPMN or BPMN2 or BPEL - may be with Activiti (
> http://activiti.org)?
> - Good support for OSGI EE
> - What is with integration of all the individual GUIs (Camel, ActiveMQ,
...)
> into one - the Karaf Web Console?
> - Use Camel as integration framework, deprecate the SMX components and use
> the free resources for the topics listed above and to improve Camel.
>
> Thank's for starting this discussion,
> Christian
>
> P.S. camel-smpp is available since Camel 2.2.
>
--
Jean-Baptiste Onofré
---------------------------------
HomePage
http://www.nanthrax.net
---------------------------------
Contacts
jbonofre@apache.org
jb@nanthrax.net
---------------------------------
OpenSource
BuildProcess/AutoDeploy
http://buildprocess.sourceforge.net
Apache ServiceMix
http://servicemix.apache.org
-----------------------------------
PGP : 17D4F086
RE: [DISCUSS] ServiceMix future
Posted by Łukasz Dywicki <lu...@code-house.org>.
Hi,
Gertv you have +1 from me too. :-)
May we change Pygments to http://alexgorbatchev.com/SyntaxHighlighter/ ?
It makes colors in runtime after page load. It causes no dependencies to
executable tools and (which is drawback) to python runtime. The minimal set
of dependencies will let people to work with documentation even if they're
not commiters/contributors.
Regards,
Lukasz
-----Original Message-----
From: Gert Vanthienen [mailto:gert.vanthienen@gmail.com]
Sent: Monday, October 18, 2010 9:13 AM
To: dev@servicemix.apache.org
Subject: Re: [DISCUSS] ServiceMix future
Hi Eric,
Before the weekend, there was very little consensus over whether or
not to go with the Scalate or DocBook based approach. I noticed that
the Scalate documentation thread has gained quite a few +1s over the
weekend so I'll git svn dcommit those changes back into Apache now. I
just wanted to be sure about the community's take on things before I
started pushing my own experiment on all of us.
Regards,
Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Mon, Oct 18, 2010 at 2:04 AM, Eric Johnson <em...@fusesource.com>
wrote:
> I'd be happy to help out beefing up the documentation. Is the Scalate
> based doc going to be the way forward or the DocBook based doc? Is the
> source in SVN so I can start submitting patches?
>
> On Sunday, October 17, 2010, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> Hi Christian,
>>
>> In ServiceMix, you can eanble the JDBCAuditor which store all JBI
messages in transit in the NMR and store it in a database. The Auditor could
started/stopped via JMX.
>>
>> For the BPM, we started to discuss of that with Guillaume. Activiti,
especially if it becomes an Apache project, will be a very good candidate.
>>
>> For the documentation, we are all agree with that. I started several
threads about this, including some start using DocBook in the sandbox, etc.
We really need to gear up this topic. Gert started a Scalate documentation.
>>
>> We can start a draft of the "future" ServiceMix 5 architecture, using
more Camel components, BPM, toolbox, etc.
>>
>> Regards
>> JB
>>
>> On 10/17/2010 06:50 PM, Christian Müller wrote:
>>
>> My 2 cents:
>>
>> In my company, we started using SMX last year. At this time, SMX4 was out
>> and with the advice from Ade we are using the camel provided components
>> instead of the SMX provided components for our integration solutions. It
>> looks for us JBI is dead and OSGI is well established.
>>
>> What we would like to see in the future is:
>> - Better documentation for SMX4 (or SMX5 in the future). A good
alternative
>> will be the "ServiceMix in Action" book from Charles and Ade...
>> - Better monitoring/auditing capabilities for troubleshooting like
storing a
>> snapshot (copy) of the exchange (with Prooperties, Messages, Headers and
may
>> be Attachments) in a database before/after each processing step. With an
>> "excludes" and/or "includes" pattern we could define which processing
steps
>> should audit or nor. With a header filter strategy (like we have in
Camel)
>> we could filter headers and properties which should not logged. And for
>> Chrismas, I wish a nice GUI with which we can see how each exchange was
>> routed and modified... - may be this is more a Camel topic.
>> - Support for BPMN or BPMN2 or BPEL - may be with Activiti (
>> http://activiti.org)?
>> - Good support for OSGI EE
>> - What is with integration of all the individual GUIs (Camel, ActiveMQ,
...)
>> into one - the Karaf Web Console?
>> - Use Camel as integration framework, deprecate the SMX components and
use
>> the free resources for the topics listed above and to improve Camel.
>>
>> Thank's for starting this discussion,
>> Christian
>>
>> P.S. camel-smpp is available since Camel 2.2.
>>
>>
>>
>> --
>> Jean-Baptiste Onofré
>> ---------------------------------
>> HomePage
>> http://www.nanthrax.net
>> ---------------------------------
>> Contacts
>> jbonofre@apache.org
>> jb@nanthrax.net
>> ---------------------------------
>> OpenSource
>> BuildProcess/AutoDeploy
>> http://buildprocess.sourceforge.net
>> Apache ServiceMix
>> http://servicemix.apache.org
>> -----------------------------------
>> PGP : 17D4F086
>>
>
> --
> Principle Technical Writer
>
> Phone (781) 280-4174
> Skype finnmccumial
> E-Mail emjohnson@fusesource.com
> Blog http://documentingit.blogspot.com/
>
Re: [DISCUSS] ServiceMix future
Posted by Gert Vanthienen <ge...@gmail.com>.
Hi Eric,
Before the weekend, there was very little consensus over whether or
not to go with the Scalate or DocBook based approach. I noticed that
the Scalate documentation thread has gained quite a few +1s over the
weekend so I'll git svn dcommit those changes back into Apache now. I
just wanted to be sure about the community's take on things before I
started pushing my own experiment on all of us.
Regards,
Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Mon, Oct 18, 2010 at 2:04 AM, Eric Johnson <em...@fusesource.com> wrote:
> I'd be happy to help out beefing up the documentation. Is the Scalate
> based doc going to be the way forward or the DocBook based doc? Is the
> source in SVN so I can start submitting patches?
>
> On Sunday, October 17, 2010, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> Hi Christian,
>>
>> In ServiceMix, you can eanble the JDBCAuditor which store all JBI messages in transit in the NMR and store it in a database. The Auditor could started/stopped via JMX.
>>
>> For the BPM, we started to discuss of that with Guillaume. Activiti, especially if it becomes an Apache project, will be a very good candidate.
>>
>> For the documentation, we are all agree with that. I started several threads about this, including some start using DocBook in the sandbox, etc. We really need to gear up this topic. Gert started a Scalate documentation.
>>
>> We can start a draft of the "future" ServiceMix 5 architecture, using more Camel components, BPM, toolbox, etc.
>>
>> Regards
>> JB
>>
>> On 10/17/2010 06:50 PM, Christian Müller wrote:
>>
>> My 2 cents:
>>
>> In my company, we started using SMX last year. At this time, SMX4 was out
>> and with the advice from Ade we are using the camel provided components
>> instead of the SMX provided components for our integration solutions. It
>> looks for us JBI is dead and OSGI is well established.
>>
>> What we would like to see in the future is:
>> - Better documentation for SMX4 (or SMX5 in the future). A good alternative
>> will be the "ServiceMix in Action" book from Charles and Ade...
>> - Better monitoring/auditing capabilities for troubleshooting like storing a
>> snapshot (copy) of the exchange (with Prooperties, Messages, Headers and may
>> be Attachments) in a database before/after each processing step. With an
>> "excludes" and/or "includes" pattern we could define which processing steps
>> should audit or nor. With a header filter strategy (like we have in Camel)
>> we could filter headers and properties which should not logged. And for
>> Chrismas, I wish a nice GUI with which we can see how each exchange was
>> routed and modified... - may be this is more a Camel topic.
>> - Support for BPMN or BPMN2 or BPEL - may be with Activiti (
>> http://activiti.org)?
>> - Good support for OSGI EE
>> - What is with integration of all the individual GUIs (Camel, ActiveMQ, ...)
>> into one - the Karaf Web Console?
>> - Use Camel as integration framework, deprecate the SMX components and use
>> the free resources for the topics listed above and to improve Camel.
>>
>> Thank's for starting this discussion,
>> Christian
>>
>> P.S. camel-smpp is available since Camel 2.2.
>>
>>
>>
>> --
>> Jean-Baptiste Onofré
>> ---------------------------------
>> HomePage
>> http://www.nanthrax.net
>> ---------------------------------
>> Contacts
>> jbonofre@apache.org
>> jb@nanthrax.net
>> ---------------------------------
>> OpenSource
>> BuildProcess/AutoDeploy
>> http://buildprocess.sourceforge.net
>> Apache ServiceMix
>> http://servicemix.apache.org
>> -----------------------------------
>> PGP : 17D4F086
>>
>
> --
> Principle Technical Writer
>
> Phone (781) 280-4174
> Skype finnmccumial
> E-Mail emjohnson@fusesource.com
> Blog http://documentingit.blogspot.com/
>
Re: [DISCUSS] ServiceMix future
Posted by Eric Johnson <em...@fusesource.com>.
I'd be happy to help out beefing up the documentation. Is the Scalate
based doc going to be the way forward or the DocBook based doc? Is the
source in SVN so I can start submitting patches?
On Sunday, October 17, 2010, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Christian,
>
> In ServiceMix, you can eanble the JDBCAuditor which store all JBI messages in transit in the NMR and store it in a database. The Auditor could started/stopped via JMX.
>
> For the BPM, we started to discuss of that with Guillaume. Activiti, especially if it becomes an Apache project, will be a very good candidate.
>
> For the documentation, we are all agree with that. I started several threads about this, including some start using DocBook in the sandbox, etc. We really need to gear up this topic. Gert started a Scalate documentation.
>
> We can start a draft of the "future" ServiceMix 5 architecture, using more Camel components, BPM, toolbox, etc.
>
> Regards
> JB
>
> On 10/17/2010 06:50 PM, Christian Müller wrote:
>
> My 2 cents:
>
> In my company, we started using SMX last year. At this time, SMX4 was out
> and with the advice from Ade we are using the camel provided components
> instead of the SMX provided components for our integration solutions. It
> looks for us JBI is dead and OSGI is well established.
>
> What we would like to see in the future is:
> - Better documentation for SMX4 (or SMX5 in the future). A good alternative
> will be the "ServiceMix in Action" book from Charles and Ade...
> - Better monitoring/auditing capabilities for troubleshooting like storing a
> snapshot (copy) of the exchange (with Prooperties, Messages, Headers and may
> be Attachments) in a database before/after each processing step. With an
> "excludes" and/or "includes" pattern we could define which processing steps
> should audit or nor. With a header filter strategy (like we have in Camel)
> we could filter headers and properties which should not logged. And for
> Chrismas, I wish a nice GUI with which we can see how each exchange was
> routed and modified... - may be this is more a Camel topic.
> - Support for BPMN or BPMN2 or BPEL - may be with Activiti (
> http://activiti.org)?
> - Good support for OSGI EE
> - What is with integration of all the individual GUIs (Camel, ActiveMQ, ...)
> into one - the Karaf Web Console?
> - Use Camel as integration framework, deprecate the SMX components and use
> the free resources for the topics listed above and to improve Camel.
>
> Thank's for starting this discussion,
> Christian
>
> P.S. camel-smpp is available since Camel 2.2.
>
>
>
> --
> Jean-Baptiste Onofré
> ---------------------------------
> HomePage
> http://www.nanthrax.net
> ---------------------------------
> Contacts
> jbonofre@apache.org
> jb@nanthrax.net
> ---------------------------------
> OpenSource
> BuildProcess/AutoDeploy
> http://buildprocess.sourceforge.net
> Apache ServiceMix
> http://servicemix.apache.org
> -----------------------------------
> PGP : 17D4F086
>
--
Principle Technical Writer
Phone (781) 280-4174
Skype finnmccumial
E-Mail emjohnson@fusesource.com
Blog http://documentingit.blogspot.com/
Re: [DISCUSS] ServiceMix future
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Christian,
In ServiceMix, you can eanble the JDBCAuditor which store all JBI
messages in transit in the NMR and store it in a database. The Auditor
could started/stopped via JMX.
For the BPM, we started to discuss of that with Guillaume. Activiti,
especially if it becomes an Apache project, will be a very good candidate.
For the documentation, we are all agree with that. I started several
threads about this, including some start using DocBook in the sandbox,
etc. We really need to gear up this topic. Gert started a Scalate
documentation.
We can start a draft of the "future" ServiceMix 5 architecture, using
more Camel components, BPM, toolbox, etc.
Regards
JB
On 10/17/2010 06:50 PM, Christian Müller wrote:
> My 2 cents:
>
> In my company, we started using SMX last year. At this time, SMX4 was out
> and with the advice from Ade we are using the camel provided components
> instead of the SMX provided components for our integration solutions. It
> looks for us JBI is dead and OSGI is well established.
>
> What we would like to see in the future is:
> - Better documentation for SMX4 (or SMX5 in the future). A good alternative
> will be the "ServiceMix in Action" book from Charles and Ade...
> - Better monitoring/auditing capabilities for troubleshooting like storing a
> snapshot (copy) of the exchange (with Prooperties, Messages, Headers and may
> be Attachments) in a database before/after each processing step. With an
> "excludes" and/or "includes" pattern we could define which processing steps
> should audit or nor. With a header filter strategy (like we have in Camel)
> we could filter headers and properties which should not logged. And for
> Chrismas, I wish a nice GUI with which we can see how each exchange was
> routed and modified... - may be this is more a Camel topic.
> - Support for BPMN or BPMN2 or BPEL - may be with Activiti (
> http://activiti.org)?
> - Good support for OSGI EE
> - What is with integration of all the individual GUIs (Camel, ActiveMQ, ...)
> into one - the Karaf Web Console?
> - Use Camel as integration framework, deprecate the SMX components and use
> the free resources for the topics listed above and to improve Camel.
>
> Thank's for starting this discussion,
> Christian
>
> P.S. camel-smpp is available since Camel 2.2.
>
--
Jean-Baptiste Onofré
---------------------------------
HomePage
http://www.nanthrax.net
---------------------------------
Contacts
jbonofre@apache.org
jb@nanthrax.net
---------------------------------
OpenSource
BuildProcess/AutoDeploy
http://buildprocess.sourceforge.net
Apache ServiceMix
http://servicemix.apache.org
-----------------------------------
PGP : 17D4F086
Re: [DISCUSS] ServiceMix future
Posted by Christian Müller <ch...@gmail.com>.
My 2 cents:
In my company, we started using SMX last year. At this time, SMX4 was out
and with the advice from Ade we are using the camel provided components
instead of the SMX provided components for our integration solutions. It
looks for us JBI is dead and OSGI is well established.
What we would like to see in the future is:
- Better documentation for SMX4 (or SMX5 in the future). A good alternative
will be the "ServiceMix in Action" book from Charles and Ade...
- Better monitoring/auditing capabilities for troubleshooting like storing a
snapshot (copy) of the exchange (with Prooperties, Messages, Headers and may
be Attachments) in a database before/after each processing step. With an
"excludes" and/or "includes" pattern we could define which processing steps
should audit or nor. With a header filter strategy (like we have in Camel)
we could filter headers and properties which should not logged. And for
Chrismas, I wish a nice GUI with which we can see how each exchange was
routed and modified... - may be this is more a Camel topic.
- Support for BPMN or BPMN2 or BPEL - may be with Activiti (
http://activiti.org)?
- Good support for OSGI EE
- What is with integration of all the individual GUIs (Camel, ActiveMQ, ...)
into one - the Karaf Web Console?
- Use Camel as integration framework, deprecate the SMX components and use
the free resources for the topics listed above and to improve Camel.
Thank's for starting this discussion,
Christian
P.S. camel-smpp is available since Camel 2.2.
Re: [DISCUSS] ServiceMix future
Posted by "Ge@@ru" <ge...@gmail.com>.
Hi,
i'm an user of smx and i think that one of the primary mission of the
project must be
documentation... currectly smx site describe many features but often
these descriptions are poor and/or relative to smx3 that is different
from smx4. Documentation is one of the first thing that permits to a
project to increase his fame because yet user with little experience can
use it and above all test it.
In fact, at least for me, isn't so easy use smx at begin and often i
read directly sources to understand how all work; and now i haven't yet
a clear about works all modules.
About camel-cxf or servicemix-cxf-* module... i think that often could
be easy use directly servicemix-cxf components for deploy but it is
only a personal opinion because i'm a new for both camel and smx.
I prefer use camel in smx because can use jbi component and expose
services fast, but yet in this case it is only an habit.
It is impossible identify a simple list of target for the future of smx
because depends where smx must used and for what.
"Only time will tell us" how smx could be increase his features. :)
But of course, the first targets must be:
- "permit to junior users to use it" (with documentation and complete
examples for all features);
- increase stability;
- help users to avoid problem with classloader problems
(classCastException, etc. when a wrong version of a library it is used
on a su, etc.).
- help users to avoid problems about memory leak (and perm gem problem)
that on production it is a lot of important;
- add documentation about share library between SA to avoid creation of
big SU/SA file with same libraries.
Good luck to SMX.
Geaaru
On Sun, 2010-10-17 at 12:02 +0200, Claus Ibsen wrote:
> Hi
>
> Yeah I am subscriber now. For whatever reason I was on a subscriber on
> the user list.
> Well I got the attention of this great discussion from Ade's tweet.
>
>
> On Sun, Oct 17, 2010 at 11:35 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> > Hi Claus (and the others ;)),
> >
> > in the same way of your latest post, I begin an use case on github
> > (http://github.com/jbonofre/jbi-camel) to compare Camel and SMX components
> > in a "real" use case.
> >
> > The use case is the following:
> > - One POJO is exposed in SMX using servicemix-cxf-se component. The endpoint
> > is named cxf-se.
> > - The cxf-se endpoint is "facaded" by two endpoints: a HTTP one (using
> > servicemix-http) and a JMS one (using servicemix-jms). The first one use
> > In-Out MEP and the second one In-Only.
> >
> > Up to now, I saw some majors differences (correct me if I'm wrong :)):
> > 1/ Mediation and Procol Interchange
> > Using ServiceMix components, we can add a new endpoint in facade of an
> > existing one, just by adding the xbean of the new endpoint. In Camel,
> > changing the facade endpoint means changing the Camel route and adding a new
> > facade endpoint means adding a new Camel route. It seems that defining
> > several from() is not allowed.
>
> Yes you can, since Camel 2.0. You can have as many inputs to a route you like.
> from("xxx", "yyy", "zzz").to("bla");
>
>
>
> > 2/ Endpoint proxy
> > The servicemix-http component is able to get the WSDL of the target endpoint
> > (if there is one in the endpoint descriptor). It's not required to define
> > the WSDL in the HTTP endpoint attributes. It means that the WSDL is very
> > dynamic as it depends of the interfaces used by the POJO in cxf-se endpoint.
> > The Camel HTTP or CXF components are not able to do it. It can take at least
> > a "local" and "static" WSDL in endpoint attributes.
>
> In Camel you can proxy a service over HTTP or WS (eg using CXF), or
> whatever transport you like.
> However you will have to do this as a route, eg you need from -> to
>
> For example a little CXF example here
> https://cwiki.apache.org/confluence/display/CAMEL/CXF+Proxy+Example
>
>
> > 3/ Display available services
> > The servicemix-http component is able to display a HTML page containing the
> > available HTTP services. If you click on one service, you can have the
> > endpoint WSDL (main.wsdl).
> > This logic is not present in the camel-http or camel-cxf components. The
> > users should know the Camel routes availables with the corresponding WSDL
>
> Well I would assume it could be part of the transport container. Eg
> CXF can show which web services it manages.
> Likewise a HTTP container (Jetty, Servlet) could do this as well.
>
> However in terms of Camel it has API to access information about its
> routes, consumers, endpoints etc.
> So you can make those easily avail on a html page if you like.
>
> Better management tooling may add such in the future. For example a
> Camel shell in Karaf.
>
>
>
> > 4/ Async behavior
> > The servicemix-http components uses Jetty continuation to be able to process
> > HTTP request in an async way. It doesn't seem to be the case for camel-http
> > component (I have not yet check the camel-cxf one).
>
> The camel http component is based on Apache Http Client 3.1 which
> doesnt supprot async.
> You can use camel-http4 or camel-jetty for async instead.
>
> However I would like to integrate the Async Http Client project to
> Camel in the future. This project looks really cool.
> http://github.com/ning/async-http-client
>
>
> > 5/ MEP
> > In Camel, the MEP is implemented by the route itself and so you need to
> > define one route per MEP that you want to manage.
> >
>
> No the MEP is part of the Exchange.
>
>
> > So, for me it's clear that ServiceMix components provide a large set of
> > features, not all cover by Camel endpoints.
>
> Large set? Sorry I fail to see the "large".
> Of course SMX != Camel and therefore they are not 100% identical.
>
> As suggested by others in this forum I agree (hardly any surprise as I
> am biased towards Camel) to work together and improve the Camel
> components rather than maintaining or working on the JBI.
> They (JBI components) should be considered in "maintenance mode".
>
> But in the end the community spoke and the momentum is on the Camel
> components, rather than the SMX counterparts.
>
>
> > The huge limitation of ServiceMix components is the fact that messages HAVE
> > TO BE in XML (XML payload). It's a huge limitation because for example it's
> > not possible to provide REST services. More over the marshaling could be
> > difficult to be (for example in servicemix-rmi, I have not yet completed the
> > marshaler :/) and performances are directly impacted (for example
> > servicemix-pdf should work in stream and avoid marshaling/unmarshaling for
> > better performance). Camel is largely better in the message using
> > TypeConverter and the possibility to work with stream, binaries, etc.
> >
>
> Another huge limitation is the fact there has hardly been any new
> development on SMX components.
> Its basically the same set of components we have had for the last 2+ years.
> Also a minor issue is the documentation. The SMX is not that well
> maintained and documented. We do seem to be better at this at Camel.
>
> Also the issue tracker of the SMX components is not having high
> attention. So if people report an issue or improvement it may go
> unattended.
>
> The community have spoken and are donating components to Camel instead
> of JBI/SMX.
>
>
>
>
> > Now, we have three options:
> > - improve and extend Camel components features to be iso between ServiceMix
> > components and Camel components
> > - stop the JBI features which "force" the usage of XML payload and provide
> > ServiceMix "NMR" components providing MEP, all features but able to manage a
> > large set of message formats (stream, bean, etc).
> > - provide a kind of servicemix-camel-bridge component that is able to use an
> > underlying Camel component but adding some extra feature such as WSDL
> > exposition in descriptor, NMR registration of the endpoint, etc.
> >
> > For now, I'm working on my local git repo, I will commit on github later
> > today.
> >
> > Any comments/thoughts are welcome, maybe especially from the Camel guys :)
> >
> > Thanks
> > Regards
> > JB
> >
> > On 10/17/2010 10:37 AM, davsclaus wrote:
> >>
> >>
> >> I agree that Camel has all components SMX has but the question is if they
> >> are as good as their
> >> smx pendants. For camel-mail<-> servicemix-mail I would say that the smx
> >> one has more functionality.
> >> So I would not blindly thre away our components without checking that
> >> first.
> >>
> >>
> >> Lars I think they are on par. The only feature I can see SMX has which
> >> Camel
> >> doesn't is the storage option.
> >> Then again Camel have some options which SMX doesn't.
> >>
> >> In any case agree on the people who voice that it would make sense to
> >> focus
> >> development on the Camel components, over the "deprecated/maintenance
> >> mode"
> >> JBI components.
> >>
> >> And someone said there was no SMPP component in Camel. In fact people from
> >> the community donated such as component
> >> http://camel.apache.org/smpp
> >>
> >> I think we got almost all SMX components covered now in Camel. For example
> >> JBoss Drools now comes with native support for Camel.
> >>
> >>
> >
> > --
> > Jean-Baptiste Onofré
> > ---------------------------------
> > HomePage
> > http://www.nanthrax.net
> > ---------------------------------
> > Contacts
> > jbonofre@apache.org
> > jb@nanthrax.net
> > ---------------------------------
> > OpenSource
> > BuildProcess/AutoDeploy
> > http://buildprocess.sourceforge.net
> > Apache ServiceMix
> > http://servicemix.apache.org
> > -----------------------------------
> > PGP : 17D4F086
> >
>
>
>
Re: [DISCUSS] ServiceMix future
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Thanks for your reply Claus.
Agree that the "huge" word is little bit heavy.
I'm resuming my use test regarding your latest comments.
Agree for the displayed services, we can add something in ServiceMix to
display HTTP service and add something by layer. Let me think more about
this and propose something to cover this feature.
For the async behavior, I'm gonna test another components to see how
it's behaving.
For the MEP, you are right, the MEP is part of the Exchange. I think
that adding ?exchangePattern=InOut for example on an URI is enough (and
great :)).
To be clear, agreed: maintaining Camel and ServiceMix is duplicate work.
Most of the Camel components are better than the ServiceMix one (for
example camel-file comparing to servicemix-file).
Regards
JB
On 10/17/2010 12:02 PM, Claus Ibsen wrote:
> Hi
>
> Yeah I am subscriber now. For whatever reason I was on a subscriber on
> the user list.
> Well I got the attention of this great discussion from Ade's tweet.
>
>
> On Sun, Oct 17, 2010 at 11:35 AM, Jean-Baptiste Onofré<jb...@nanthrax.net> wrote:
>> Hi Claus (and the others ;)),
>>
>> in the same way of your latest post, I begin an use case on github
>> (http://github.com/jbonofre/jbi-camel) to compare Camel and SMX components
>> in a "real" use case.
>>
>> The use case is the following:
>> - One POJO is exposed in SMX using servicemix-cxf-se component. The endpoint
>> is named cxf-se.
>> - The cxf-se endpoint is "facaded" by two endpoints: a HTTP one (using
>> servicemix-http) and a JMS one (using servicemix-jms). The first one use
>> In-Out MEP and the second one In-Only.
>>
>> Up to now, I saw some majors differences (correct me if I'm wrong :)):
>> 1/ Mediation and Procol Interchange
>> Using ServiceMix components, we can add a new endpoint in facade of an
>> existing one, just by adding the xbean of the new endpoint. In Camel,
>> changing the facade endpoint means changing the Camel route and adding a new
>> facade endpoint means adding a new Camel route. It seems that defining
>> several from() is not allowed.
>
> Yes you can, since Camel 2.0. You can have as many inputs to a route you like.
> from("xxx", "yyy", "zzz").to("bla");
>
>
>
>> 2/ Endpoint proxy
>> The servicemix-http component is able to get the WSDL of the target endpoint
>> (if there is one in the endpoint descriptor). It's not required to define
>> the WSDL in the HTTP endpoint attributes. It means that the WSDL is very
>> dynamic as it depends of the interfaces used by the POJO in cxf-se endpoint.
>> The Camel HTTP or CXF components are not able to do it. It can take at least
>> a "local" and "static" WSDL in endpoint attributes.
>
> In Camel you can proxy a service over HTTP or WS (eg using CXF), or
> whatever transport you like.
> However you will have to do this as a route, eg you need from -> to
>
> For example a little CXF example here
> https://cwiki.apache.org/confluence/display/CAMEL/CXF+Proxy+Example
>
>
>> 3/ Display available services
>> The servicemix-http component is able to display a HTML page containing the
>> available HTTP services. If you click on one service, you can have the
>> endpoint WSDL (main.wsdl).
>> This logic is not present in the camel-http or camel-cxf components. The
>> users should know the Camel routes availables with the corresponding WSDL
>
> Well I would assume it could be part of the transport container. Eg
> CXF can show which web services it manages.
> Likewise a HTTP container (Jetty, Servlet) could do this as well.
>
> However in terms of Camel it has API to access information about its
> routes, consumers, endpoints etc.
> So you can make those easily avail on a html page if you like.
>
> Better management tooling may add such in the future. For example a
> Camel shell in Karaf.
>
>
>
>> 4/ Async behavior
>> The servicemix-http components uses Jetty continuation to be able to process
>> HTTP request in an async way. It doesn't seem to be the case for camel-http
>> component (I have not yet check the camel-cxf one).
>
> The camel http component is based on Apache Http Client 3.1 which
> doesnt supprot async.
> You can use camel-http4 or camel-jetty for async instead.
>
> However I would like to integrate the Async Http Client project to
> Camel in the future. This project looks really cool.
> http://github.com/ning/async-http-client
>
>
>> 5/ MEP
>> In Camel, the MEP is implemented by the route itself and so you need to
>> define one route per MEP that you want to manage.
>>
>
> No the MEP is part of the Exchange.
>
>
>> So, for me it's clear that ServiceMix components provide a large set of
>> features, not all cover by Camel endpoints.
>
> Large set? Sorry I fail to see the "large".
> Of course SMX != Camel and therefore they are not 100% identical.
>
> As suggested by others in this forum I agree (hardly any surprise as I
> am biased towards Camel) to work together and improve the Camel
> components rather than maintaining or working on the JBI.
> They (JBI components) should be considered in "maintenance mode".
>
> But in the end the community spoke and the momentum is on the Camel
> components, rather than the SMX counterparts.
>
>
>> The huge limitation of ServiceMix components is the fact that messages HAVE
>> TO BE in XML (XML payload). It's a huge limitation because for example it's
>> not possible to provide REST services. More over the marshaling could be
>> difficult to be (for example in servicemix-rmi, I have not yet completed the
>> marshaler :/) and performances are directly impacted (for example
>> servicemix-pdf should work in stream and avoid marshaling/unmarshaling for
>> better performance). Camel is largely better in the message using
>> TypeConverter and the possibility to work with stream, binaries, etc.
>>
>
> Another huge limitation is the fact there has hardly been any new
> development on SMX components.
> Its basically the same set of components we have had for the last 2+ years.
> Also a minor issue is the documentation. The SMX is not that well
> maintained and documented. We do seem to be better at this at Camel.
>
> Also the issue tracker of the SMX components is not having high
> attention. So if people report an issue or improvement it may go
> unattended.
>
> The community have spoken and are donating components to Camel instead
> of JBI/SMX.
>
>
>
>
>> Now, we have three options:
>> - improve and extend Camel components features to be iso between ServiceMix
>> components and Camel components
>> - stop the JBI features which "force" the usage of XML payload and provide
>> ServiceMix "NMR" components providing MEP, all features but able to manage a
>> large set of message formats (stream, bean, etc).
>> - provide a kind of servicemix-camel-bridge component that is able to use an
>> underlying Camel component but adding some extra feature such as WSDL
>> exposition in descriptor, NMR registration of the endpoint, etc.
>>
>> For now, I'm working on my local git repo, I will commit on github later
>> today.
>>
>> Any comments/thoughts are welcome, maybe especially from the Camel guys :)
>>
>> Thanks
>> Regards
>> JB
>>
>> On 10/17/2010 10:37 AM, davsclaus wrote:
>>>
>>>
>>> I agree that Camel has all components SMX has but the question is if they
>>> are as good as their
>>> smx pendants. For camel-mail<-> servicemix-mail I would say that the smx
>>> one has more functionality.
>>> So I would not blindly thre away our components without checking that
>>> first.
>>>
>>>
>>> Lars I think they are on par. The only feature I can see SMX has which
>>> Camel
>>> doesn't is the storage option.
>>> Then again Camel have some options which SMX doesn't.
>>>
>>> In any case agree on the people who voice that it would make sense to
>>> focus
>>> development on the Camel components, over the "deprecated/maintenance
>>> mode"
>>> JBI components.
>>>
>>> And someone said there was no SMPP component in Camel. In fact people from
>>> the community donated such as component
>>> http://camel.apache.org/smpp
>>>
>>> I think we got almost all SMX components covered now in Camel. For example
>>> JBoss Drools now comes with native support for Camel.
>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> ---------------------------------
>> HomePage
>> http://www.nanthrax.net
>> ---------------------------------
>> Contacts
>> jbonofre@apache.org
>> jb@nanthrax.net
>> ---------------------------------
>> OpenSource
>> BuildProcess/AutoDeploy
>> http://buildprocess.sourceforge.net
>> Apache ServiceMix
>> http://servicemix.apache.org
>> -----------------------------------
>> PGP : 17D4F086
>>
>
>
>
--
Jean-Baptiste Onofré
---------------------------------
HomePage
http://www.nanthrax.net
---------------------------------
Contacts
jbonofre@apache.org
jb@nanthrax.net
---------------------------------
OpenSource
BuildProcess/AutoDeploy
http://buildprocess.sourceforge.net
Apache ServiceMix
http://servicemix.apache.org
-----------------------------------
PGP : 17D4F086
Re: [DISCUSS] ServiceMix future
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Yeah I am subscriber now. For whatever reason I was on a subscriber on
the user list.
Well I got the attention of this great discussion from Ade's tweet.
On Sun, Oct 17, 2010 at 11:35 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Claus (and the others ;)),
>
> in the same way of your latest post, I begin an use case on github
> (http://github.com/jbonofre/jbi-camel) to compare Camel and SMX components
> in a "real" use case.
>
> The use case is the following:
> - One POJO is exposed in SMX using servicemix-cxf-se component. The endpoint
> is named cxf-se.
> - The cxf-se endpoint is "facaded" by two endpoints: a HTTP one (using
> servicemix-http) and a JMS one (using servicemix-jms). The first one use
> In-Out MEP and the second one In-Only.
>
> Up to now, I saw some majors differences (correct me if I'm wrong :)):
> 1/ Mediation and Procol Interchange
> Using ServiceMix components, we can add a new endpoint in facade of an
> existing one, just by adding the xbean of the new endpoint. In Camel,
> changing the facade endpoint means changing the Camel route and adding a new
> facade endpoint means adding a new Camel route. It seems that defining
> several from() is not allowed.
Yes you can, since Camel 2.0. You can have as many inputs to a route you like.
from("xxx", "yyy", "zzz").to("bla");
> 2/ Endpoint proxy
> The servicemix-http component is able to get the WSDL of the target endpoint
> (if there is one in the endpoint descriptor). It's not required to define
> the WSDL in the HTTP endpoint attributes. It means that the WSDL is very
> dynamic as it depends of the interfaces used by the POJO in cxf-se endpoint.
> The Camel HTTP or CXF components are not able to do it. It can take at least
> a "local" and "static" WSDL in endpoint attributes.
In Camel you can proxy a service over HTTP or WS (eg using CXF), or
whatever transport you like.
However you will have to do this as a route, eg you need from -> to
For example a little CXF example here
https://cwiki.apache.org/confluence/display/CAMEL/CXF+Proxy+Example
> 3/ Display available services
> The servicemix-http component is able to display a HTML page containing the
> available HTTP services. If you click on one service, you can have the
> endpoint WSDL (main.wsdl).
> This logic is not present in the camel-http or camel-cxf components. The
> users should know the Camel routes availables with the corresponding WSDL
Well I would assume it could be part of the transport container. Eg
CXF can show which web services it manages.
Likewise a HTTP container (Jetty, Servlet) could do this as well.
However in terms of Camel it has API to access information about its
routes, consumers, endpoints etc.
So you can make those easily avail on a html page if you like.
Better management tooling may add such in the future. For example a
Camel shell in Karaf.
> 4/ Async behavior
> The servicemix-http components uses Jetty continuation to be able to process
> HTTP request in an async way. It doesn't seem to be the case for camel-http
> component (I have not yet check the camel-cxf one).
The camel http component is based on Apache Http Client 3.1 which
doesnt supprot async.
You can use camel-http4 or camel-jetty for async instead.
However I would like to integrate the Async Http Client project to
Camel in the future. This project looks really cool.
http://github.com/ning/async-http-client
> 5/ MEP
> In Camel, the MEP is implemented by the route itself and so you need to
> define one route per MEP that you want to manage.
>
No the MEP is part of the Exchange.
> So, for me it's clear that ServiceMix components provide a large set of
> features, not all cover by Camel endpoints.
Large set? Sorry I fail to see the "large".
Of course SMX != Camel and therefore they are not 100% identical.
As suggested by others in this forum I agree (hardly any surprise as I
am biased towards Camel) to work together and improve the Camel
components rather than maintaining or working on the JBI.
They (JBI components) should be considered in "maintenance mode".
But in the end the community spoke and the momentum is on the Camel
components, rather than the SMX counterparts.
> The huge limitation of ServiceMix components is the fact that messages HAVE
> TO BE in XML (XML payload). It's a huge limitation because for example it's
> not possible to provide REST services. More over the marshaling could be
> difficult to be (for example in servicemix-rmi, I have not yet completed the
> marshaler :/) and performances are directly impacted (for example
> servicemix-pdf should work in stream and avoid marshaling/unmarshaling for
> better performance). Camel is largely better in the message using
> TypeConverter and the possibility to work with stream, binaries, etc.
>
Another huge limitation is the fact there has hardly been any new
development on SMX components.
Its basically the same set of components we have had for the last 2+ years.
Also a minor issue is the documentation. The SMX is not that well
maintained and documented. We do seem to be better at this at Camel.
Also the issue tracker of the SMX components is not having high
attention. So if people report an issue or improvement it may go
unattended.
The community have spoken and are donating components to Camel instead
of JBI/SMX.
> Now, we have three options:
> - improve and extend Camel components features to be iso between ServiceMix
> components and Camel components
> - stop the JBI features which "force" the usage of XML payload and provide
> ServiceMix "NMR" components providing MEP, all features but able to manage a
> large set of message formats (stream, bean, etc).
> - provide a kind of servicemix-camel-bridge component that is able to use an
> underlying Camel component but adding some extra feature such as WSDL
> exposition in descriptor, NMR registration of the endpoint, etc.
>
> For now, I'm working on my local git repo, I will commit on github later
> today.
>
> Any comments/thoughts are welcome, maybe especially from the Camel guys :)
>
> Thanks
> Regards
> JB
>
> On 10/17/2010 10:37 AM, davsclaus wrote:
>>
>>
>> I agree that Camel has all components SMX has but the question is if they
>> are as good as their
>> smx pendants. For camel-mail<-> servicemix-mail I would say that the smx
>> one has more functionality.
>> So I would not blindly thre away our components without checking that
>> first.
>>
>>
>> Lars I think they are on par. The only feature I can see SMX has which
>> Camel
>> doesn't is the storage option.
>> Then again Camel have some options which SMX doesn't.
>>
>> In any case agree on the people who voice that it would make sense to
>> focus
>> development on the Camel components, over the "deprecated/maintenance
>> mode"
>> JBI components.
>>
>> And someone said there was no SMPP component in Camel. In fact people from
>> the community donated such as component
>> http://camel.apache.org/smpp
>>
>> I think we got almost all SMX components covered now in Camel. For example
>> JBoss Drools now comes with native support for Camel.
>>
>>
>
> --
> Jean-Baptiste Onofré
> ---------------------------------
> HomePage
> http://www.nanthrax.net
> ---------------------------------
> Contacts
> jbonofre@apache.org
> jb@nanthrax.net
> ---------------------------------
> OpenSource
> BuildProcess/AutoDeploy
> http://buildprocess.sourceforge.net
> Apache ServiceMix
> http://servicemix.apache.org
> -----------------------------------
> PGP : 17D4F086
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: [DISCUSS] ServiceMix future
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Claus (and the others ;)),
in the same way of your latest post, I begin an use case on github
(http://github.com/jbonofre/jbi-camel) to compare Camel and SMX
components in a "real" use case.
The use case is the following:
- One POJO is exposed in SMX using servicemix-cxf-se component. The
endpoint is named cxf-se.
- The cxf-se endpoint is "facaded" by two endpoints: a HTTP one (using
servicemix-http) and a JMS one (using servicemix-jms). The first one use
In-Out MEP and the second one In-Only.
Up to now, I saw some majors differences (correct me if I'm wrong :)):
1/ Mediation and Procol Interchange
Using ServiceMix components, we can add a new endpoint in facade of an
existing one, just by adding the xbean of the new endpoint. In Camel,
changing the facade endpoint means changing the Camel route and adding a
new facade endpoint means adding a new Camel route. It seems that
defining several from() is not allowed.
2/ Endpoint proxy
The servicemix-http component is able to get the WSDL of the target
endpoint (if there is one in the endpoint descriptor). It's not required
to define the WSDL in the HTTP endpoint attributes. It means that the
WSDL is very dynamic as it depends of the interfaces used by the POJO in
cxf-se endpoint. The Camel HTTP or CXF components are not able to do it.
It can take at least a "local" and "static" WSDL in endpoint attributes.
3/ Display available services
The servicemix-http component is able to display a HTML page containing
the available HTTP services. If you click on one service, you can have
the endpoint WSDL (main.wsdl).
This logic is not present in the camel-http or camel-cxf components. The
users should know the Camel routes availables with the corresponding WSDL
4/ Async behavior
The servicemix-http components uses Jetty continuation to be able to
process HTTP request in an async way. It doesn't seem to be the case for
camel-http component (I have not yet check the camel-cxf one).
5/ MEP
In Camel, the MEP is implemented by the route itself and so you need to
define one route per MEP that you want to manage.
So, for me it's clear that ServiceMix components provide a large set of
features, not all cover by Camel endpoints.
The huge limitation of ServiceMix components is the fact that messages
HAVE TO BE in XML (XML payload). It's a huge limitation because for
example it's not possible to provide REST services. More over the
marshaling could be difficult to be (for example in servicemix-rmi, I
have not yet completed the marshaler :/) and performances are directly
impacted (for example servicemix-pdf should work in stream and avoid
marshaling/unmarshaling for better performance). Camel is largely better
in the message using TypeConverter and the possibility to work with
stream, binaries, etc.
Now, we have three options:
- improve and extend Camel components features to be iso between
ServiceMix components and Camel components
- stop the JBI features which "force" the usage of XML payload and
provide ServiceMix "NMR" components providing MEP, all features but able
to manage a large set of message formats (stream, bean, etc).
- provide a kind of servicemix-camel-bridge component that is able to
use an underlying Camel component but adding some extra feature such as
WSDL exposition in descriptor, NMR registration of the endpoint, etc.
For now, I'm working on my local git repo, I will commit on github later
today.
Any comments/thoughts are welcome, maybe especially from the Camel guys :)
Thanks
Regards
JB
On 10/17/2010 10:37 AM, davsclaus wrote:
>
>
> I agree that Camel has all components SMX has but the question is if they
> are as good as their
> smx pendants. For camel-mail<-> servicemix-mail I would say that the smx
> one has more functionality.
> So I would not blindly thre away our components without checking that first.
>
>
> Lars I think they are on par. The only feature I can see SMX has which Camel
> doesn't is the storage option.
> Then again Camel have some options which SMX doesn't.
>
> In any case agree on the people who voice that it would make sense to focus
> development on the Camel components, over the "deprecated/maintenance mode"
> JBI components.
>
> And someone said there was no SMPP component in Camel. In fact people from
> the community donated such as component
> http://camel.apache.org/smpp
>
> I think we got almost all SMX components covered now in Camel. For example
> JBoss Drools now comes with native support for Camel.
>
>
--
Jean-Baptiste Onofré
---------------------------------
HomePage
http://www.nanthrax.net
---------------------------------
Contacts
jbonofre@apache.org
jb@nanthrax.net
---------------------------------
OpenSource
BuildProcess/AutoDeploy
http://buildprocess.sourceforge.net
Apache ServiceMix
http://servicemix.apache.org
-----------------------------------
PGP : 17D4F086
Re: [DISCUSS] ServiceMix future
Posted by davsclaus <ci...@yahoo.dk>.
I agree that Camel has all components SMX has but the question is if they
are as good as their
smx pendants. For camel-mail <-> servicemix-mail I would say that the smx
one has more functionality.
So I would not blindly thre away our components without checking that first.
Lars I think they are on par. The only feature I can see SMX has which Camel
doesn't is the storage option.
Then again Camel have some options which SMX doesn't.
In any case agree on the people who voice that it would make sense to focus
development on the Camel components, over the "deprecated/maintenance mode"
JBI components.
And someone said there was no SMPP component in Camel. In fact people from
the community donated such as component
http://camel.apache.org/smpp
I think we got almost all SMX components covered now in Camel. For example
JBoss Drools now comes with native support for Camel.
--
View this message in context: http://servicemix.396122.n5.nabble.com/DISCUSS-ServiceMix-future-tp3212177p3216036.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] ServiceMix future
Posted by Johan Edstrom <se...@gmail.com>.
Stream handling and speed would be the key ones there....
On Oct 15, 2010, at 1:40 AM, Lars Heinemann wrote:
> Yes, improving Camel components where needed is a prerequisite for deprecating the smx ones.
>
> Regards
> Lars
>
>
>
> Am 15.10.2010 um 09:38 schrieb Bengt Rodehav:
>
>> I think the general direction should still be to use Camel instead of
>> servicemix components. If possible, it's far better to improve Camel where
>> features are lacking or not good enough than providing them as a separate
>> track outside of Camel. Otherwise I think we'll just add to the confusion
>> instead of providing clear directions for ServiceMix.
>>
>> Still not entirely convinced that ServiceMix should "just" be an ESB
>> although that is of course the primary purpose. Especially when integrating
>> technology like Aries, I think the scope of ServiceMix could be extended to
>> a OSGi based platform for enterprise applications.
>>
>> /Bengt
>>
>>
>> 2010/10/15 Lars Heinemann <lh...@apache.org>
>>
>>> I think it is a good idea to move to a new major version to do all those
>>> changes. But I would then
>>> deprecate both SMX3 and SMX4 to start something really new. And I wouldn't
>>> even advertise those old
>>> versions on the new homepage but simply go only for the new one.
>>> Otherwise we will end up maintaining 3 different versions of smx in code
>>> and documentation.
>>>
>>> I agree that Camel has all components SMX has but the question is if they
>>> are as good as their
>>> smx pendants. For camel-mail <-> servicemix-mail I would say that the smx
>>> one has more functionality.
>>> So I would not blindly thre away our components without checking that
>>> first.
>>>
>>> Regards
>>> Lars
>>>
>>>
>>> Am 14.10.2010 um 16:35 schrieb Guillaume Nodet:
>>>
>>>> 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
>>>
>>>
>
Johan Edstrom
joed@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
Re: [DISCUSS] ServiceMix future
Posted by Lars Heinemann <lh...@apache.org>.
Yes, improving Camel components where needed is a prerequisite for deprecating the smx ones.
Regards
Lars
Am 15.10.2010 um 09:38 schrieb Bengt Rodehav:
> I think the general direction should still be to use Camel instead of
> servicemix components. If possible, it's far better to improve Camel where
> features are lacking or not good enough than providing them as a separate
> track outside of Camel. Otherwise I think we'll just add to the confusion
> instead of providing clear directions for ServiceMix.
>
> Still not entirely convinced that ServiceMix should "just" be an ESB
> although that is of course the primary purpose. Especially when integrating
> technology like Aries, I think the scope of ServiceMix could be extended to
> a OSGi based platform for enterprise applications.
>
> /Bengt
>
>
> 2010/10/15 Lars Heinemann <lh...@apache.org>
>
>> I think it is a good idea to move to a new major version to do all those
>> changes. But I would then
>> deprecate both SMX3 and SMX4 to start something really new. And I wouldn't
>> even advertise those old
>> versions on the new homepage but simply go only for the new one.
>> Otherwise we will end up maintaining 3 different versions of smx in code
>> and documentation.
>>
>> I agree that Camel has all components SMX has but the question is if they
>> are as good as their
>> smx pendants. For camel-mail <-> servicemix-mail I would say that the smx
>> one has more functionality.
>> So I would not blindly thre away our components without checking that
>> first.
>>
>> Regards
>> Lars
>>
>>
>> Am 14.10.2010 um 16:35 schrieb Guillaume Nodet:
>>
>>> 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
>>
>>
Re: [DISCUSS] ServiceMix future
Posted by Bengt Rodehav <be...@rodehav.com>.
Charles,
That is very much in accordance to what I have been thinking. Although
ServiceMix has been primarily an ESB, the possibilities with ServiceMix is
much greater than that if all of those projects that you list are "bundled"
with ServiceMix.
Also, look at it the other way around: If ServiceMix is not meant to target
the "enterprise applications", then something else will be used for that.
That other something could probably also be used for integration purposes.
Why then would anyone want to use ServiceMix? The value lies in combining a
comprehensive stack with some unique features. Having ServiceMix
provide/bundle other important projects (similar to your list Charles) will
help a lot since it's a lot of work to make all this work together. The
unique features of ServiceMix could then be in the area of wide scalability
and enterprise worthy, e g clustering, DOSGi, tooling, monitoring
(integration with Tivoli, Nagios etc).
/Bengt
2010/10/15 Charles Moulliard <cm...@gmail.com>
> On 15/10/10 10:09, Johan Edstrom wrote:
>
>> I'll bite that :)
>>
>> I guess you are right.
>>
>> /je
>> On Oct 15, 2010, at 2:03 AM, raulvk.soa@gmail.com wrote:
>>
>> Hmm... I actually think the description should focus on integration
>>> rather and enterprise apps.
>>>
>>> Otherwise, the purpuse becomes too generic and bland.
>>>
>>> Also, coining it as a platform for enterprise apps, doesn't it make it
>>> compete with Spring DM Server, JBossAS, etc. All of which are OSGi already,
>>> or in the process of transitioning.
>>>
>>> Just my 2 cents. Will try and describe my vision later.
>>>
>>> -----Original Message-----
>>> From: Johan Edstrom<se...@gmail.com>
>>> Date: Fri, 15 Oct 2010 01:48:53
>>> To:<de...@servicemix.apache.org>
>>> Reply-To: dev@servicemix.apache.org
>>> Subject: Re: [DISCUSS] ServiceMix future
>>>
>>> ServiceMix "The primary platform for OSGi enterprise applications"
>>>
>>> Which really is how I treat it, position it and debate it when out on
>>> jobs.
>>>
>>> /je
>>> On Oct 15, 2010, at 1:38 AM, Bengt Rodehav wrote:
>>>
>>> OSGi based platform for enterprise applications.
>>>>
>>> Johan Edstrom
>>>
>>> joed@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
>>
>> joed@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
>>
>>
>>
>>
>>
>> We have open the pandora box. With OSGI adoption in SMX4, the gravity
> center of our ESB platform has shifted from ESB to a platform supporting not
> only integration but able to be a web server, java application server ....
> So I think that we must take the time of the reflection to position
> correctly Smx 5 server for the future and the mix OSGI + OSGI EE (ARIES) +
> Camel + CXF + ActiveMQ + orchestration engine is probably the best match. As
> Aries proposes and provide JPA, JNDI, WEB, Blueprint (with better
> integration of Spring - JMS, JDBC, ....), Transactions aspects we should
> also (like now) continues to support them and open the eyes of our users
> about the perspectives proposed by that kind of platform.
>
Re: [DISCUSS] ServiceMix future
Posted by Charles Moulliard <cm...@gmail.com>.
On 15/10/10 10:09, Johan Edstrom wrote:
> I'll bite that :)
>
> I guess you are right.
>
> /je
> On Oct 15, 2010, at 2:03 AM, raulvk.soa@gmail.com wrote:
>
>> Hmm... I actually think the description should focus on integration rather and enterprise apps.
>>
>> Otherwise, the purpuse becomes too generic and bland.
>>
>> Also, coining it as a platform for enterprise apps, doesn't it make it compete with Spring DM Server, JBossAS, etc. All of which are OSGi already, or in the process of transitioning.
>>
>> Just my 2 cents. Will try and describe my vision later.
>>
>> -----Original Message-----
>> From: Johan Edstrom<se...@gmail.com>
>> Date: Fri, 15 Oct 2010 01:48:53
>> To:<de...@servicemix.apache.org>
>> Reply-To: dev@servicemix.apache.org
>> Subject: Re: [DISCUSS] ServiceMix future
>>
>> ServiceMix "The primary platform for OSGi enterprise applications"
>>
>> Which really is how I treat it, position it and debate it when out on jobs.
>>
>> /je
>> On Oct 15, 2010, at 1:38 AM, Bengt Rodehav wrote:
>>
>>> OSGi based platform for enterprise applications.
>> Johan Edstrom
>>
>> joed@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
>
> joed@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
>
>
>
>
>
We have open the pandora box. With OSGI adoption in SMX4, the gravity
center of our ESB platform has shifted from ESB to a platform supporting
not only integration but able to be a web server, java application
server .... So I think that we must take the time of the reflection to
position correctly Smx 5 server for the future and the mix OSGI + OSGI
EE (ARIES) + Camel + CXF + ActiveMQ + orchestration engine is probably
the best match. As Aries proposes and provide JPA, JNDI, WEB, Blueprint
(with better integration of Spring - JMS, JDBC, ....), Transactions
aspects we should also (like now) continues to support them and open the
eyes of our users about the perspectives proposed by that kind of platform.
Re: [DISCUSS] ServiceMix future
Posted by Johan Edstrom <se...@gmail.com>.
I'll bite that :)
I guess you are right.
/je
On Oct 15, 2010, at 2:03 AM, raulvk.soa@gmail.com wrote:
> Hmm... I actually think the description should focus on integration rather and enterprise apps.
>
> Otherwise, the purpuse becomes too generic and bland.
>
> Also, coining it as a platform for enterprise apps, doesn't it make it compete with Spring DM Server, JBossAS, etc. All of which are OSGi already, or in the process of transitioning.
>
> Just my 2 cents. Will try and describe my vision later.
>
> -----Original Message-----
> From: Johan Edstrom <se...@gmail.com>
> Date: Fri, 15 Oct 2010 01:48:53
> To: <de...@servicemix.apache.org>
> Reply-To: dev@servicemix.apache.org
> Subject: Re: [DISCUSS] ServiceMix future
>
> ServiceMix "The primary platform for OSGi enterprise applications"
>
> Which really is how I treat it, position it and debate it when out on jobs.
>
> /je
> On Oct 15, 2010, at 1:38 AM, Bengt Rodehav wrote:
>
>> OSGi based platform for enterprise applications.
>
> Johan Edstrom
>
> joed@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
joed@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
Re: [DISCUSS] ServiceMix future
Posted by ra...@gmail.com.
Hmm... I actually think the description should focus on integration rather and enterprise apps.
Otherwise, the purpuse becomes too generic and bland.
Also, coining it as a platform for enterprise apps, doesn't it make it compete with Spring DM Server, JBossAS, etc. All of which are OSGi already, or in the process of transitioning.
Just my 2 cents. Will try and describe my vision later.
-----Original Message-----
From: Johan Edstrom <se...@gmail.com>
Date: Fri, 15 Oct 2010 01:48:53
To: <de...@servicemix.apache.org>
Reply-To: dev@servicemix.apache.org
Subject: Re: [DISCUSS] ServiceMix future
ServiceMix "The primary platform for OSGi enterprise applications"
Which really is how I treat it, position it and debate it when out on jobs.
/je
On Oct 15, 2010, at 1:38 AM, Bengt Rodehav wrote:
> OSGi based platform for enterprise applications.
Johan Edstrom
joed@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
Re: [DISCUSS] ServiceMix future
Posted by Johan Edstrom <se...@gmail.com>.
ServiceMix "The primary platform for OSGi enterprise applications"
Which really is how I treat it, position it and debate it when out on jobs.
/je
On Oct 15, 2010, at 1:38 AM, Bengt Rodehav wrote:
> OSGi based platform for enterprise applications.
Johan Edstrom
joed@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
Re: [DISCUSS] ServiceMix future
Posted by Bengt Rodehav <be...@rodehav.com>.
I think the general direction should still be to use Camel instead of
servicemix components. If possible, it's far better to improve Camel where
features are lacking or not good enough than providing them as a separate
track outside of Camel. Otherwise I think we'll just add to the confusion
instead of providing clear directions for ServiceMix.
Still not entirely convinced that ServiceMix should "just" be an ESB
although that is of course the primary purpose. Especially when integrating
technology like Aries, I think the scope of ServiceMix could be extended to
a OSGi based platform for enterprise applications.
/Bengt
2010/10/15 Lars Heinemann <lh...@apache.org>
> I think it is a good idea to move to a new major version to do all those
> changes. But I would then
> deprecate both SMX3 and SMX4 to start something really new. And I wouldn't
> even advertise those old
> versions on the new homepage but simply go only for the new one.
> Otherwise we will end up maintaining 3 different versions of smx in code
> and documentation.
>
> I agree that Camel has all components SMX has but the question is if they
> are as good as their
> smx pendants. For camel-mail <-> servicemix-mail I would say that the smx
> one has more functionality.
> So I would not blindly thre away our components without checking that
> first.
>
> Regards
> Lars
>
>
> Am 14.10.2010 um 16:35 schrieb Guillaume Nodet:
>
> > 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
>
>
Re: [DISCUSS] ServiceMix future
Posted by Lars Heinemann <lh...@apache.org>.
I think it is a good idea to move to a new major version to do all those changes. But I would then
deprecate both SMX3 and SMX4 to start something really new. And I wouldn't even advertise those old
versions on the new homepage but simply go only for the new one.
Otherwise we will end up maintaining 3 different versions of smx in code and documentation.
I agree that Camel has all components SMX has but the question is if they are as good as their
smx pendants. For camel-mail <-> servicemix-mail I would say that the smx one has more functionality.
So I would not blindly thre away our components without checking that first.
Regards
Lars
Am 14.10.2010 um 16:35 schrieb Guillaume Nodet:
> 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