Hello Tom, I start at the end. It is quite possible that those requirements & restrictions can have influence on the design. One example for this is the case of D, which is eventually a database service. I imagine it as one having a service interface called by other client-like entities (Jini term) and its implementation having no "internal life" (not interacting with space autonomously). Revealing some more details: 'A' is a service which has no public interface, its "implementation" waits for entries to appear in space, communicates with devices based on info in entries and handles answers (results of communication, data flux can be high). I want it to free from duties other than its main one as much as it is possible. Processing of answers almost invariably includes storing them into database, signaling progress, making calculations for certain subsets and possibly many others no one can foresee right now. Looking back all these I see the relevant points as: - let 'A' do its communication duties well - let 'A' "get rid of" arriving data ASAP (directly to D or via some fast intermediary?) - let 'A' initiate other processings (via JS?) - plan for relative easy addition of processing to the system (I do not expect introduction of new processing as a requirement that implies dynamic flexibility.)
Hmm, JS seems to be a good way to organize this flow (except of 2nd point), doesn't it? Zsolt On Wed, Feb 16, 2011 at 12:11 PM, Tom Hobbs <[email protected]> wrote: > 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 >
