hi, IN a loosely coupled system like this why wouldn't you make all the services stateless and put the state into a context object in the event?
What leads you to use events rather than simply having A call a method on B? There are some really good reasons to use an event driven architecture (e.g. SEDA), but it is a bit unusual. Combining event-driven and per-request state stored in a component strikes me as definitely odd. thanks david jencks On Aug 13, 2014, at 5:47 AM, Milan Tomic <[email protected]> wrote: > Hello JB > > By the state I mean one object (a variable) that should be saved somewhere in > service A and merged with result from service B. Which is recommended way in > OSGi to store some key/value pairs? > > I am not using ServiceTracker so far, but I am using events: > > Event e = new Event(Constants.QUEUE_NAME, properties); > eventAdmin.postEvent(e); > > to do a service communication: A -> B -> A > > TIA, > Milan > > > > On Wednesday, August 13, 2014 10:21 AM, Jean-Baptiste Onofré > <[email protected]> wrote: > > > Hi Milan, > > by state, you mean the current status of the service or the response > from the service ? > > Do you use ServiceTracker ? > > Regards > JB > > On 08/13/2014 10:10 AM, Milan Tomic wrote: > > > > I have a request where I call one service and need to get result back. > > Which is the best way to achive this? > > > > So, I have: > > > > A -> B -> A > > > > I would also have to keep a state in service A and to merge it with > > response from B. Where should I store my state? > > > > Thank you in advance, > > Milan > > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
