I think you really hit the nail right on the head. Currently the whole
system of EJB specs is architectured around the C2B e-commerce model. EJB is
perfectly suitable to the internet-pet-shop kind of data processing, where
thin clients (served by servlets and JSPs) make transactions in short-lived
sessions over a synchronous chain of light-weight software modules -- those
temporary chains being built-up only for the duration of typically three or
four transactions at most. This architecture is relatively simple to
implement but has serious limitations which make it unsuitable for many
complex intra-enterprise tasks.
Recently on this list, someone raised the legitimate requirement of having
an interface for EJBeans to take scheduled actions. To safely provide such
an interface a whole lot of far-reaching problems have to be solved by
designers (standardizing ways of propagating contexts crossing from one
execution thread to another or ways for the containers to somehow retain
part of the control over thread-manipulation -- to mention only the most
obvious items) as well as by implementors. I am currently working on a
telephone subscriber provisioning system and I have been thinking about ways
of rearchitecting the product around EJB, but right at the outset I ran into
the problem of creating timers. And I can hardly imagine a telecom software
without timers. Connectors seem to provide a work-around, but then again I
am essentially outside the EJB space and have only a standardized way to
connect to it.
But the fact that EJB currently encourages/supports only short-lived
software pipes has other consequences. I am not an expert in implementing
security functionality (either :)), but I feel that this property currently
makes EJB unwieldy to use in environments, where a large number of
transactions needs to be processed in a short time with message protection.
(Take a bank for example.) For various reasons (one of which is providing
interoperability and interoperability seems to be one of the long-term
violons d'Ingre of the EJB/Java-architects), message protection is mostly
implemented by using some protocol between the source and destination to
negotiate a mechanism, protection level and most importantly a key. With
this kind of setup the longer the link persists the better the overhead
(related to the negotiation phase) is spread across the whole communication.
With short-lived software pipes it may be very discouraging to use message
protection and --consequently--, where message protection is absolutely
needed, EJB may be at a disadvantage. In the internet-pet-shop model a
standardized message protection may be implemented between the thin client
and (outside the EJB-container) the WEB-server. In this case, part of the
cost linked to message protection is exported outside the enterprise system
(to the browser of bunny-mom or kitty-pa), and part of it is outside the
EJB-container itself in the WEB-server. The whole app server itself
(including the EJB-container) will fit on one suitably large host, so
message protection inside the enterprise system is not really an issue. So
it is likely not to an issue for a pet-shop. But what about large
distributed company-wide systems with clusters of EJB-containers spanning a
whole headquarter and eventually several (specialized) branches? Is not the
performance cost of message protection with EJB systems prohibitivly high in
this kind of environments?
Peter
-----Original Message-----
From: Ian McCallion [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 06, 2001 2:46 PM
To: [EMAIL PROTECTED]
Subject: Re: Message Driven Beans]
Cedric Beust wrote:
>
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Ian McCallion
>
> > 2. An EJB is either an MDB or it isn't; it's either driven by messages
> > or by RMI. It would be really useful for an MDB, SFSB, or even an
> > Entity Bean to be able to fire off a JMS message and be woken up
> > when the reply arrived.
>
> Aren't these two sentences contradictory?
No.
> It looks like you want your SFSB
> to behave synchronously (it sleeps until it gets a reply), so why
publishing
> the message on a JMS Destination instead of making an RMI call?
Messaging systems such as IBM MQSeries support a request/reply paradigm. The
advantage of using messaging over synchronous calls comes when the timescale
involved in the request/reply increases. With messaging (because messages
can
be hardened) the reply could reliably come back and be processed correctly a
week later, even after the server had been shut down and restarted. But this
is
something that is quite impractical using synchronous mechanisms such as
RMI.
One of the reasons why message brokers and workflow products are different
beasts from application servers is that one deals with asynchronous
messaging
(with request/reply handled badly) and the other deals with synchronous
calls
(with asynchronous messaging handled badly).
By supporting what I proposed, a workflow script could be interpreted by an
EJB,
allowing application servers to take an even broader role in enterprise
applications.
========================================
Ian McCallion
Alexis Systems Limited
Romsey, UK
========================================
===========================================================================
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".
