Johan, Yeah, well the good thing about these use cases is that it gets us talking about what we want to achieve in a bit more detail...
For use case 2, I didn't mean to imply using STOMP, it was just about using the next version of ActiveMQ for conveying exchanges (at some point, Apollo is supposed to be supporting OpenWire again as well). I have altered the description to avoid the confusion though. I'm actually expecting us to handle use case 1 with some internal seda queues or something, similar to what we have now in the NMR. This means that when migrating a route to a remote node, something has to trigger the NMR implementation on the first node to start sending the same exchanges over the wire instead. We now have something like this for JBI, but that involves altering the route that is sending the exchange and adding a cluster registration to it. Regards, Gert Vanthienen ------------------------ FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On Thu, Mar 3, 2011 at 8:16 AM, Johan Edstrom <[email protected]> wrote: > Hey! > > I love the use-cases, I think the name actually should contain bus or esb, > since we rightfully can argue that there is no ESB nor BUS without an NMR. > UseCase1 : > > Technically it means the same JVM/Same container, we pick a streaming > scenario. > > Use case 2: > > I don't see why stomp would help here, an XML payload is a good idea. > > Use case 3 > > This has more to do with consumer setup than anything else. > > > On Mar 3, 2011, at 12:06 AM, Charles Moulliard wrote: > >> Thx. Great job. >> >> Charles >> >> On Wed, Mar 2, 2011 at 11:09 PM, Gert Vanthienen >> <[email protected]> wrote: >>> L.S., >>> >>> I created >>> https://cwiki.apache.org/confluence/display/SM/ServiceMix+5+-+NMR+Improvements >>> as an initial stab at capturing what we need from our NMR layer. The >>> requirements section list the high-level goals we want to achieve, but >>> I think the main thing to work out is the use cases section: what are >>> the things we want to be able to do with our new NMR layer >>> implementation. I've added a few obvious use cases but feel to append >>> to that list, so we can get a clearer picture of what is covered by >>> the buzzwords we listed in the requirements section. >>> >>> (By the way, I wrote these first few scenario using Camel routes as an >>> example, but those obviously cover CXF endpoints and anything else we >>> plan to integrate with the NMR as well.) >>> >>> Regards, >>> >>> Gert Vanthienen >>> ------------------------ >>> FuseSource >>> Web: http://fusesource.com >>> Blog: http://gertvanthienen.blogspot.com/ >>> >>> >>> >>> On Wed, Mar 2, 2011 at 9:38 AM, Gert Vanthienen >>> <[email protected]> wrote: >>>> L.S., >>>> >>>> How about I split out the ideas about the NMR into a separate page >>>> linked from the roadmap? It looks like we first have to get a grip on >>>> what exactly are the requirements and use cases we want to handle with >>>> our new NMR implementation... >>>> >>>> Regards, >>>> >>>> Gert Vanthienen >>>> ------------------------ >>>> FuseSource >>>> Web: http://fusesource.com >>>> Blog: http://gertvanthienen.blogspot.com/ >>>> >>>> >>>> >>>> On Wed, Mar 2, 2011 at 8:58 AM, Charles Moulliard <[email protected]> >>>> wrote: >>>>> Hi, >>>>> >>>>> Regarding to the new name of NMR, we could use another acronym --> SML >>>>> = ServiceMix Messaging Layer or EML = Endpoints Messaging Layer as the >>>>> main goal of this component will be to deliver messages to endpoints >>>>> exposed in bundles or in another SMX instances, will also handle >>>>> transaction between transactional endpoints, audit messages, provide a >>>>> registry to locate endpoints registered and least but not least >>>>> provide clustering or clouding >>>>> >>>>> Regards, >>>>> >>>>> Charles Moulliard >>>>> >>>>> Sr. Principal Solution Architect - FuseSource >>>>> Apache Committer >>>>> >>>>> Blog : http://cmoulliard.blogspot.com >>>>> Twitter : http://twitter.com/cmoulliard >>>>> Linkedin : http://www.linkedin.com/in/charlesmoulliard >>>>> Skype: cmoulliard >>>>> >>>>> >>>>> >>>>> On Wed, Mar 2, 2011 at 6:41 AM, Jean-Baptiste Onofré <[email protected]> >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> I don't want to split NMR. NMR (or the new proposed name, ServiceMix GL) >>>>>> IS >>>>>> ServiceMix 4 :). >>>>>> In fact ServiceMix 4 is a premium integration platform for other projects >>>>>> (Karaf, CXF, Camel, ActiveMQ, ODE, etc) and the NMR. >>>>>> >>>>>> So basically my answer is no, I prefer to keep NMR as the main ServiceMix >>>>>> project. >>>>>> >>>>>> Regards >>>>>> JB >>>>>> >>>>>> On 03/01/2011 09:42 PM, Michael Van wrote: >>>>>>> >>>>>>> I was a proponent of splitting NMR off of SMX and making it its very own >>>>>>> TLP. >>>>>>> But, if you guys are going to integrate it deeper into SMX, I can see >>>>>>> where >>>>>>> that wouldnt' work. ;-) >>>>>>> >>>>>> >>>>> >>>> >>> > >
