Some servers, like Weblogic, support the startup of named RMI servers as
part of the App Server Startup. Where the RMI server itself controls the
threading and long lived processes. Perhaps something like this, but part
of a standard would be useful for what you are looking for.
Tim Gonda
----- Original Message -----
From: "Kov�cs P�ter" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 06, 2001 12:29 PM
Subject: Re: Message Driven Beans]
> 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".
>
>
>
===========================================================================
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".
