Dan OConnor wrote:
> Could someone interested in this threading issue offer a specific
> example of one of the problems that require threading beans to
> solve? I think it might be helpful to consider the problem in more
> concrete terms.
>
> The "parallel workflow" example, for instance, seems very general.
> You probably wouldn't map tasks to bean threads if the tasks were
> long-running (e.g. required user interaction), because of the
> problems inherent in managing server resources.
>
One example of this type would be a service to find airline reservations
(or hotels, car rentals, etc.). The client's request specifies a set of
constraints and an objective function. For example, find reservations
for 4 passengers from Boston to Orlando, leaving on 4/22/00, returning
4/29/00, departing between 11:00 AM and 6:00 PM, with an aircraft
type that's non an MD-80. Rank the alternatives by giving 50% weight
to the lowest round trip fare, and 50% weight to the shortest scheduled
flight time.
The service may be able to use cached information (read-only or read-mostly),
such as the airlines published schedules to narrow down the field. However,
some information (such as how many seats are available at which fares) may
be too volatile to cache. In this case, the service must issue queries to each
of the vendors that has survived the initial set of filters. Response time is
reduced greatly if this set of requests can be issued asynchronously.
The client of this service wants to use a synchronous protocol (i.e. it passes in
its parameters, the service doesn't return until it has the result). If I want
to implement the service using a Stateless Session Bean, I have the problem
of figuring out how to:
a) to issue 'n' asynchronous requests,
b) waiting for them all to return, or for a timeout limit to be reached.
JMS provides a solution for part (a). However, the EJB spec precludes the
session bean from blocking on the completion of the set of async requests, or
the expiration of the timer.
As far as I can tell, in order to provide this type of service, I'd need to handle
the client's request using CORBA or straight RMI. Which, in my view is too bad,
because I think that this sort of situation is at least as prevalent as the shopping
cart pattern that motivated Stateful Session Beans. I'd much rather see the
EJB spec come up with a standard way of handling this.
Charlie Alfred
Foliage Software Systems
===========================================================================
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".
