Cool. When do you expect for this to make its way into the EJB spec? How
far off is this? A month? 6 months? A year? Two years? More? Also, how
will containers differentiate "plain old" EJBs from JMS-enabled EJBs? At the
deployment
descriptor level? Or will there be new JMS-oriented interfaces that the
machines will
have to implement? (From your comments below, it would seem that
message-oriented
EJBs will be quite different from RPC-oriented EJBs -- I'm just trying to
figure out how different
they'll be. If there's a document that addresses these issues, please point
me there (the application
server chapter of the JMS spec didn't really address EJBs specifically.)).
===========================================================================
Tom Valesky -- [EMAIL PROTECTED]
http://www.patriot.net/users/tvalesky
-----Original Message-----
From: Mark Hapner <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Saturday, May 22, 1999 12:18 AM
Subject: Re: Parallel processing in session bean
>No it does not. See the application server chapter of the JMS spec for
details.
>The short answer is the EJB is written as a JMS MessageListener and the
>container and JMS provider conspire to transparently deliver each message
to a
>stateless session bean instance for processing. The EJB uses the JMS
Message API
>to access its header and content. The EJB deployment descriptor specifies
the
>source of the messages for a bean and the container takes care of managing
the
>JMS connections required.
>
>This is not async EJB RPC. Messaging is a first class distributed computing
>paradigm of equal weight and importance as RPC. It is fundamentally wrong
to
>relegate it to second class service as an async RPC transport.
>
>Tom Valesky wrote:
>
>> Mark,
>>
>> I can see how an EJBean can send a JMS message, but how does it handle
>> receiving
>> JMS messages? Does the container completely insulate the bean from the
fact
>> that
>> the invocation came from JMS instead of a connection-oriented invocation?
>>
>> Thanks,
>>
>> Tom
>>
>>
===========================================================================
>> Tom Valesky -- [EMAIL PROTECTED]
>> http://www.patriot.net/users/tvalesky
>>
>> -----Original Message-----
>> From: Mark Hapner <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>> Date: Friday, May 21, 1999 10:29 PM
>> Subject: Re: Parallel processing in session bean
>>
>> >Any Java program or component can be a JMS client and receive messages
from
>> >EJBs or send messages to EJBs (assuming the EJB containers are
integrated
>> with
>> >the JMS provider used by the program).
>> >
>> >Chamberlain Steve wrote:
>> >
>> >> This example relates to inter-bean communications. Can you comment on
>> >> whether JMS is also the approved means of passing event notification
to
>> >> non-bean clients? I am surprised that the EJB spec does not prescribe
>> here
>> >> (I have not read 1.1 yet). I have seen statements to the effect that
>> >> enterprise beans (unlike non-enterprise beans) do not generally send
or
>> >> receive events; but that is manifestly not true: you only need think
of
>> >> online trading etc.
>> >>
>> >> Certainly, attempting to implement the standard Java event model on
EJBs
>> >> does not work too well. Some EJB server providers (e.g. Weblogic)
provide
>> >> their own event services, but presumably not portably. If not JMS,
then
>> >> what?
>> >>
>> >> Thanks
>> >>
>> >> Steve Chamberlain
>> >> Schneider Electric
>> >>
>> >>
>>
===========================================================================
>> >> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
>> body
>> >> of the message "signoff EJB-INTEREST". For general help, send email
to
>> >> [EMAIL PROTECTED] and include in the body of the message "help".
>> >
>>
>===========================================================================
>> >To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
>> >of the message "signoff EJB-INTEREST". For general help, send email to
>> >[EMAIL PROTECTED] and include in the body of the message "help".
>>
>>
===========================================================================
>> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
>> of the message "signoff EJB-INTEREST". For general help, send email to
>> [EMAIL PROTECTED] and include in the body of the message "help".
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".