No docs are available yet. Stay tuned ... If you look at the JMS spec
most things should be fairly obvious.
I'm glad EJB/JMS is piqueing peoples curiosity.
Tom Valesky wrote:
>
> 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".
===========================================================================
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".
