Hi!
Peter Antman wrote:
> OK, I have started to dig into jboss to do a first experimental
> implementation of Message Driven Beans.
>
> I wrote a private mail to Richard to get some design guidlines, but he
> never replied.
Sorry about that. This was a big decision so I wanted to wait a bit
before replying, and then it just got lost in the midst of things.
Anyway, here we go.
> Here are my design decissions:
>
> 1. Message Driven Beans are verry much like Stateless Session beans, but
> without a remote interface and a home. From the Container and down,
> code will be reused or stolen from the Stateless Session stuff. (most
> are already done here)
Correct!
> 2. From the container perspective, the only "client" it has is the
> ContainerInvoker. I will therefore implement a specific
> JMSContainerInvoker. The responsibility of this invoker is to set up
> the subsciption against the JMS queue or topic, and when messages
> arive invoke the Interceptor chain.
Correct again.
> 3. The interaction with JMS will go through the JMS Application Sever
> Facility. This is designed to handle JMS messages cuncurrently, so
> its seems to be the natural choice.
What is ASF? Is this a public API?
> 4. Message Driven beans should be able to interact with other
> MOM-systems, such as XmlBlaster. Ideally jboss will be agnostic about
> this from the container and down (using configuration and reflection)
> but I am not shure about this yet. At the ContainerInvoker level its
> pretty straight forward, but I have not verified Transaction handling
> yet).
It should work by simply changing ContainerInvoker depending on incoming
message source. The CI then chooses what method to invoke down below
("onMessage" in case of JMS, or perhaps "sendMessage" for a JavaMail
Transport handler), and the call travels down through the container and
into the instance. The JBoss container infrastructure is perfect for
abstracting things as much as is needed to allow different message API's
to be used.
> Problems:
>
> 1. Some core classes in jboss have to be extended, for example
> ConatinerFactory, ConfigurationMetaData, ApplicationMetaData and
> probably more.
Yup. I am working on a metadata rewrite, and am currently looking at EJB
2.0 extensions.
> 3. Some of jboss optimizations will probably be a problem. If I
> understand it correctly jboss will compare remote interfaces to see
> if an invokation is local. Since Message Driven beans don't have a
> remote interface this will crach if it invokes another bean (I have
> not verified this yet).
This should not be a problem. The interface of the called bean is
tested, not that of the caller.
> Well, more will probably pop up. Give me a week or to and we will see (I
> only have time to spend one hour or two each evening when my kids have
> gone to sleep).
If you have any further questions, let me know. Eventually you will have
access to the proper metadata from the XML, but for now just use some
hardcoded values or similar.
And good luck! :-)
regards,
Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
