Hi Gabby,
You are pointing out a known problem that indeed does not have a good
solution.
As I mentioned in previous postings to this list we have complemented EJB
with added-value services (for our internal use in building telecom apps).
We need this to be both backward compatible with a legacy platform and to
support services that are needed for building large scale applications, and
are not defined in EJB. One of the services was a list service. It allows
you to specify a query and get dynamic updates for the list as it changes.
The updates are not received for the whole list, but only for pages which
the client requests as it scrolls through the list. This is key for
scalability. Another key capability for scalability is to allow for
displaying of selective attributes and not all of the object attributes. The
pages are of course bigger then the actual page displayed, to support smooth
scrolling.
This is the most complicated service we have, and there's no commercial
implementation for it. I'm sorry to tell you that if you really need such
capability, you'll have to build something like that, and it's not very
easy.
Doron
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Gabby Tal
> Sent: Monday, August 23, 1999 4:58 AM
> To: [EMAIL PROTECTED]
> Subject: Large volume data exchange
>
>
> Hi,
>
> We're designing N-tier application where the clients are desktop Java
> application.
> The issue we're about to deal with is that the client has to
> retrieve a
> large volume of data
> (lets say a few thousands of DB entries) generated by the EJB
> server as
> a response to some request.
> The questions are how is it recommended to exchange such
> volume of data
> considering the fact that the client should display this
> information in
> Swing table (enabling) high degree of data manipulation (as
> opposed to
> HTML based client).
> Should be a problem moving such large volume via RMI?
> and if so, is it reasonable to manage it in application level (for
> example saving the result in the client's associated session bean and
> then transferring it chunk by chuck to the client).
> What about using XML as a solution?
>
> Any help would be highly appreciated.
>
> Gabby
>
> ==============================================================
> =============
> 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".
