On 27 Nov, Rickard �berg wrote:
> 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.
No problem.
>
> 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?
It's a JMS Application Server API, defined and explained in chapter 8 of
the jms 1.0.2 specification.
The basic reason behind it is - as far as I understand - the following:
A JMS Session may not be threaded. If you want cocurrency you will have
to create one session per thread. Say you have 10 messages send per
second, but that every message takes 1 second. Then you would generally
like to have more sessions to be able to serve the messages somwhat
faster. This is what MessageDriven beans should handle. Problem is: how
is the client to know how many messages that are waiting? You could try
to figure out some slick algoritm. But there already exists an API in
JMS for this: ASF. The application server must define a ServerSession
and a ServerSessionPool. For JMS-services that support AFS it will have
the imlementation to use this via its ConnectionConsumer and Session.
If I have understod it correctly, not all JMS providers have done this.
Bea has, openjms have, but not SpyderMQ for example ( I have realy
tried to do my homework in this ;-)).
>
>> 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.
The way I have think about it is that you will have to have a special
CI for every type of MOM-system, since the setup will be done in the CI
(connection, creation of listeners ...), but when it invokes the
Interceptor chain it will do this via the standard MethodInvokation.
>
>> 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.
We will probably do some interlapping work then. I have already written
a MesageDrivenMetaData, and changed the ConfigurationMetaData and
ApplicationMetaData classes. I have not done the jboss specific stuff
yet though.
I have also rewritten the ContainerFactory, added a
MesageDrivenContainer, MesageDrivenEnterpriseContext,
MessageDrivenContainerInterceptor, MessageDrivenInstancePool (taken from
memory - the implementation is on my home computer).
Whats basically left in the ContainerInvoker - and testing ofcource
;-)
>
>> 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.
Great.
>
>> 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! :-)
Thank you. Hope it will work in the end! (I will probably also write an
MBean for openjms - but this will come later).
//Peter
>
> regards,
> Rickard
>
--
------------------------------------------------------------
Peter Antman Technology in Media, Box 34105 100 26 Stockholm
Systems Architect WWW: http://www.tim.se
Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
------------------------------------------------------------
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
