Hi Zsolt, Is there anything to stop you subclasses A and/or having many instances of it running?
I'm thinking of something like the following; Definitely have this; Client ---(public interface)--> A --> JS And also have one of these two options; 1. SubA --> JS (and then writes results back into a (possibly the same) JS) and also D --> JS (thus the workflow chain has been broken) 2. SubA --> JS --> D I guess it depends on what exactly are your requirements and restrictions. Any good? Cheers, Tom On Tue, Feb 15, 2011 at 3:09 PM, Zsolt Kúti <[email protected]> wrote: > 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 >> > >> >
