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. ;-) >>>>>> >>>>> >>>> >>> >>
