Hi, I think that we should provide a plugin strategy when registering the endpoint within the transport layer to allow to : - Register it with new NMR, JBI, JMS, Camel, ... or any other transport layer, - Define if the endpoint is available localy, remotely, - If transaction support must be use, - Idem but for audit, - Exchange format to be used, ...
example <endpoint id="uniqueRefKeyId" registerName="userRegisteringEndpointName" access="local/remote" transportLayer="EML/jms/camel" transaction="true/false" audit="true/false" format="text/object/byte"/> Regards, Charles On Thu, Mar 3, 2011 at 9:32 AM, Gert Vanthienen <[email protected]> wrote: > 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. ;-) >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >> >
