thanks guys,
I got some ideas here from your comments.
I reached the conclusion that the message consumer service, it seems
needs to maintain a queue since its underlying legacy code works as a
callback running in its own thread.
In order to have a getMessage() or take(), as interface contract, I
really do need to have a queue to take from in my consumer service.
from there on I can have a Active component take from Service A(source),
process and give to Service B(sink).
I was originally thinking of Observer/Observable for interested parties
to callback messages from mesage consumer service but that seemed very
ugly.
korosh.
On Tue, 2004-02-03 at 11:35, Leo Simons wrote:
> korosh afshar wrote:
> > Service A - is a message consumer off of a messaging infrustructure.
> >
> > Service B - is a Queue
> >
> > I have a application that needs to use Service A to read messages off of
> > the messaging bus and fill up the Queue of service B with certain types
> > of those messages.
> > Any recommendations on how to keep a clean design here implementing this?
>
> public interface Takeable
> {
> public Object take();
> }
> public interface Puttable
> {
> public void put( Object message );
> }
> public interface Processor
> {
> public Object process( Object message );
> }
> public class MyA implements Processor
> {
> // do some stuff with the message (probably translating between
> // APIs or something like that?)
> }
> public class MyB implements Puttable
> {
> // whatever
> }
> public class MySource implements Takeable
> {
> // interface to messaging infrastructure
> }
> public class MyStage implements Active
> {
> // take stuff from MySource, feed it through MyA,
> // then put it into MyB
> }
>
> IOW, decompose into sources, sinks, and processors. Use an active
> component (with worker threads for example) that moves things from
> sources through processors into sinks.
>
> You can generalize the active component if you want, or decompose it
> further.
>
> This is exactly what I'm doing with Jicarilla. Doug Lea's concurrency
> book describes all the basics. Excalibur-event is much more of the same.
>
> In terms of dependencies, the only thing that has them is the active
> component.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
