Hello Dimitri,
With the new RH invocation invokers mechanism, you will be able to build a
JMS invoker that is able to route calls to the appropriate bean (for any
deployed bean). The call details that are part of the message are forwared
to the JMX but which then consider it as a standard call: it doesn't care it
comes from JMS or RMI or SMTP or xxx.
Cheers,
Sacha
> -----Message d'origine-----
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de Dmitri
> Colebatch
> Envoye : lundi, 22 octobre 2001 04:00
> A : [EMAIL PROTECTED]
> Objet : [JBoss-user] MDB dispatcher pattern - opinions
>
>
> I'm playing catch up with designing MOM style systems, and looking at
> approaches for using MDB. What I'm thinking is having a "dispatcher
> mdb" that receives the JMS message, and passes them on to the appropriate
> SLSB that implements the logic.
>
> So here's a framework I imagine.
>
> All messages should be object messages, and the contained object must
> implement the MethodInvocation interface, which has the following
> methods:
>
> // the next thing on the list
> public String nextTask();
>
> // where should this go when finished
> public Destination finalDestination();
>
> // if something else needs to be done next
> public void insertTask(String target);
>
> // a mechanism to stop the rest of the chain
> public void error();
>
> public Object getAttribute(String name);
> public void setAttribute(String name, Object value);
>
> This object represents the invocation that needs to be done.
>
> The "task" represents a method that needs to be invoked. The context is
> provided by the set/get attribute (like servlet chaining). A config file
> maps the tasks to the class that provides the "message
> handler" interface. This interface has two methods:
>
> public void init(HomeInterfaceProvider p);
> public void handle(MethodInvocation mi);
>
> the first method provides a way for the handler to access a home interface
> it needs. This is simply a cache of home interfaces looked up by the MDB
> and the MDB itself implements this interface.
>
> The second method is where the handler extracts the contents of the
> message, and calls the appropriate SLSB. At this point, not all the
> required information might be available int he invocation, a target can be
> inserted to gather than information, and another to retry with the
> information present. For instance, in a typical e-commerce purchase, we
> would need to:
> - check the stock
> - check the user's credit
> - debit the user's credit card and place the order
>
> The servlet (or struts/webwork action class) sends a JMS message somewhere
> containing the request to place the order. The invocation object contains
> the list of goods that need to be ordered, and is simply a request to
> "place the order". The mapper knows what needs to be done, and inserts the
> tasks that need to be done (check stock/credit).
>
> This example probably doesn't do it justice, as its very simple, but I'm
> thinking that something like this might be worthwhile. If you disagree, or
> there's something out there that does the same thing anyway, let me know -
> constructively please (o:
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
