A CORBA event channel or other light weight event comm mechanism sounds more
appropriate for the client data feed here. Perhaps even simply a plain old
socket connection.
I don't get the idea of a servlet here, unless your clients are stricly
browsers, and you want to stream to them over http. Maybe this could work if
you use the Keep Alive on the http comm channel?
This sounds like the sort of thing where you want to keep the communications
overhead to a bare minimum.
-Chris.
> -----Original Message-----
> From: Chris Emery [SMTP:[EMAIL PROTECTED]]
> Sent: Sunday, August 29, 1999 8:07 AM
> To: [EMAIL PROTECTED]
> Subject: Re: EJB implementation advise needed
>
> Rickard �berg wrote:
> > Hey
>
> > I'm not sure that EJB suits your problem. I think I would rather use
> > some servlet solution.
>
>
> Thanks for the reply Rickard, I've learned a great deal from your posts
> over
> the last few months. I have to agree that servlets would be a better
> match to
> the stated problem than EJBs. Please allow me to be more precise with the
> problems requirements. My bad for not having done this in the first
> place.
> (:-/
> The Server receives the data asynchronously from other systems, there is
> the
> potential for long pauses before the server receives any data and
> conversly,
> times when data is received in high bandwidth bursts.
> All of the data provided by the various sources have the same components.
> All
> of the data is stored in a database table specific to its source. Not
> just any
> DB, but an Object DB.
> The client can choose to receive all the live data from any or all sources
> and/or provide criteria to filter the live data and/or provide criteria to
> search archived data from any source. It is preferrable to apply the
> filtering
> on the server for obvious reasons. The client can establish mulitiple
> filter
> criterias and can persist them between client connections to the server.
> The client can modify two components of the data. The modifications must
> be
> reflected in the database and to any client in posession of the modified
> data.
> I'm hard pressed to argue that Servlets would not be the best solution
> given
> these requirements. However, there is additional unrelated system
> functionality which will be provided using an EJB server, so EJBs are
> already
> part of the equation. The EJB server does not currently provide an
> asynchronous messaging service. I don't have any first hand experience
> with
> Servlets and thus cannot predict the impact utilizing them would have on
> the
> servers resources while the EJB server is running. My first inclination
> is to
> try and stay within the confines of the EJB servers resource management.
> OTH,
> I also believe in using the right tool for the job. :-)
> Any constructive input will be appreciated.
>
> Chris Emery
>
> ==========================================================================
> =
> 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".
