Hello Dan, Sure, just did not want to clutter the larger picture at first. Service 'A' (at the end of its operation) may produce large number of small datasets (max. a few KB/set), which are parts of larger ones (additions to ever-growing series). Some on-the fly mathematical analysis is to be made on either this additional parts, or some larger chunks including the additions (but only on a filtered set of data forming in A). The system already accomplishes request/response like operations too, but this is different. The result of analysis may give rise to notification of interested parties, if any.
Thanks! Zsolt On Tue, Feb 15, 2011 at 3:36 PM, Dan Creswell <[email protected]>wrote: > Can you provide some examples of the kinds of processing steps you're > thinking about? > > This feels like it might be a classic workflow problem equally it might be > more request/response, difficult to tell from the below... > > On 15 February 2011 14:25, Zsolt Kúti <[email protected]> wrote: > > > So... > > > > Consider service S that has two modes of operation. > > 1. Clients can access its functionality as usual and gets back the > > result. > > 2. It takes part in a process as follows: > > - takes appropriate entries from a space > > - calls its own public method as in 1. > > - calls another service (D) with the result > > > > I guess it tries to accomplish too much, so steps in 2 should be a > > separate "coordinating" service's (CS) job. > > > > This was my idea at first version: service A calls S, then with the > > results calls D. However A has already enough duty (can be quite > > engaged with them) and as other processing needs may arise in the > > future, I do not want to keep them within A. Hence the plan is A > > places info into JavaSpace for further processing by either S > > or CS. > > So instead of A-S-D(from A) now I have either A-JS-S-D, or > A-JS-CS-S-D(from > > CS) chain of > > process. > > Pros: CS can really be a coordinator among many processing steps by > > ordering them and knowing when to finish, cleaner responsibilities > > Cons: more complex, more places for possible errors > > > > I would like to know how you think about the above scenarios. > > Thanks! > > > > Zsolt > > >
