Hi Richard
I am currently reading your post but I must immediately correct you on one
point. I have never advocated sending of an object graph as shown here:
public class EmployeeDetail {
private int id;
private String lname;
private String fname;
private Address [] addresses;
private DepartmentDetail department;
private EmployeeDetail manager;
private [] JobTitle;
private double salary;
private HealthInsurance hInsruance;
private LifeInsurance lInsurance;
private Person spouse;
private Person [] children;
}
what I would have sent to the client would have been serializable
_relatively_simple_ fields that are not collections or arrays of objects. I
advocate sending simple fields the exploration of objects of interest
contained with the object can be obtained through another remote call - a
trade off which I thought I had stated previosuly.
Maybe my article in JavaReport will unlock some of this. I do regard myself
as smart in this area and have battled this type of design many times and
most of the time won (and will continue to do so) and it gets better and
better as I move from project to project but I will admit its not for the
faint hearted. On one project in Belgium the project manager had reached the
stage where he was questioning what I was doing and my ability to deliver
with the other teams members. Just before he confronted me about this I
delivered both the client and server ends and everbody on the team was
amazed by what I had created. I believe I was inspired hence my company's
name. To this date my friend who worked on the same project still talks
about the expressions on the face of both the users and project manager when
I turned around and ran the beta version from my workstation - "from nothing
came something big and powerful". I love my users. I always say to my
developers when they deliver a part of the user interface to me "if it
doesn't give me a horn then it aint going in" - apologies for the coarse
language no offence intended.
More too come. I just get a kick out of this list.
kind regards,
William Louth
Inspired Consultancy
> -----Original Message-----
> From: Richard Monson-Haefel [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, April 27, 2000 4:12 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Cached Rowsets-do we need to use them
>
> Hi William,
>
> Having worked extensively on both ends of the front (GUI and ServerSide) I
> have
> to follow practical lessons I have learned and respectively reject your
> approach
> to the problem.
>
> What follows is an embarrassingly long e-mail that I found myself
> compelled to
> write. I don't suspect that I'll change your mind, William, because you
> seem
> rather stubborn about it. So I have written this for the hundreds of
> other EJB
> developers that subscribe to this e-mail list. I beseech you to read this
> thoroughly before deciding to adopt William's ideas. William's hart is in
> the
> right place, but his way simply doesn't work. I've seen his design
> implemented
> many times in the past by some pretty smart people, but I have never seen
> it
> succeed. I have seen my own strategy succeed in various forms in some
> pretty
> big projects, and so I know it works. You will have to decide for
> yourself.
>
> I probably will not follow up with this discussion because I feel that I
> have
> been as concise and detailed as possible. In addition, it simply is too
> time
> consuming to continue on this thread. But I'll be listening and if
> anything
> compelling is said I promise to respond.
>
>
> -------------
>
> Its more appropriate to provide data to the client that is as close to its
> final
> user's representation as possible. Requiring the client to navigate the
> relationships of a complex object graph (as you propose) requires a few
> assumptions about the client: A) Its a fat client that can afford memory
> and
> processing cycles to deal with the navigation of complex object graphs.
> B) A
> great deal of the business logic is to be housed in the client. These are
> the
> assumptions that prospered under the two-tier architectures of the late
> 80's and
> early 90's. Since that time, however, we have been introduced to World
> Wide Web
> and discovered that a client applications can have many forms including
> GUI
> clients, HTML (via Servlets), hand-held devices, etc. My experience has
> been
> that an application that services a large community will eventually
> require at
> least two different kinds of client (frequently GUI and HTML). Only the
> fat
> client application can afford the resources to house the business logic.
> Placing the business logic in the client, means you have to duplicate that
> logic
> in other clients. These are the primary motivates for a three tier
> architecture
> and thin clients.
>
> If I want to provide my client(s) with a list of all the employees and
> their
> salaries I could go about this in two ways: 1) I could provide my clients
> with
> a graph of employee objects (William's solution). OR (2) I could provide
> them
> with a serializable ResultSet (my solution).
> *******************************
> Strategy 1 (William's strategy):
>
> The EmployeeDetail Object might be defined as follows:
>
> public class EmployeeDetail {
> private int id;
> private String lname;
> private String fname;
> private Address [] addresses;
> private DepartmentDetail department;
> private EmployeeDetail manager;
> private [] JobTitle;
> private double salary;
> private HealthInsurance hInsruance;
> private LifeInsurance lInsurance;
> private Person spouse;
> private Person [] children;
> }
>
> In order to obtain this information I might use a session object as
> follows:
>
> public class PayRollBean implements javax.ejb.SessionBean [
>
> public Enumeration getEmployeeSalaries( ){
> Vector vect = new Vector( );
> InitialContext cntx = new InitialContext( );
> Object ref = cntx.lookup("java:comp/env/ejb/employee");
> EmployeeHome empH = (EmployeeHome)PortableRemoteObject.narrow(ref,
> EmployeeHome.class);
> Enumeration enum = empH.findAllEmployees( );
> while( enum.hasMoreElements( )){
> Employee emp =
> (Employee)PortableRemoteObject.narrow(enum.nextElement(),Employee.class);
> EmployeeDetail detail = emp.getDetialObject();
> vect.add(detail);
> }
> return vect.elements();
> }
> ...
> }
>
> The EmployeeDetail object would be constructed by each EmployeeBean as
> follows:
>
> public class EmployeeBean implements javax.ejb.EntityBean {
>
> public int id;
> public String lname;
> public String fname;
> public Address [] addresses;
> public DepartmentDetail department;
> public EmployeeDetail manager;
> public [] JobTitle titles;
> public double salary;
> public HealthInsurance hInsruance;
> public LifeInsurance lInsurance;
> public Person spouse;
> public Person [] children;
>
> public EmployeeDetail getDetailObject( ){
> EmployeeDetail detail = new EmployeeDetail( );
> detail.id = id;
> detail.lnam = lname;
> detail.fname = fname;
> detail.address = address;
> detail.department = department;
> detail.manager = manager;
> detail.titles = titles;
> detail.salary = salary;
> detail.hInsurance = hInsurance;
> detail.lInsurance = lInsuracne;
> detail.spouse = spouse;
> detail.children = children;
> return detail;
> }
> ..
> }
>
> The client application would use all this as follows:
>
> public class MyClient {
>
> public static void main(String [] args){
>
> InitialContext cntx = new InitialContext();
> PayRollHome home =
> (PayRollHome)PortableRemoteObject.narrow(cntx.lookup("java:comp/env/ejb/pa
> yroll"),
> PayRollHome.class);
> PayRoll payRoll = home.create( );
> Enumeration enum = payRoll.getEmployeeSalaries( );
> while(enum.hasMoreElements()){
> EmployeeDetail detail = (EmployeeDetail)enum.nextElement();
> System.out.println(detail.lname+", "+detail.fname+"
> "+detail.salary);
> }
> }
> }
>
>
> Looks pretty good, doesn't it? but its anything but efficient.
>
> First, in order to get the data we have to use an ejbFinder method to get
> a
> remote reference to an entity bean for every employee in the enterprise.
> This
> alone would cause so much latency as to be prohibitive, but that's
> William's
> strategy since he has advocated keeping everything in an object like
> representation. Anyway, after we finish loading every single employee
> record in
> the data base into hundreds (possibly hundreds of thousands) of Employee
> beans
> we then proceed to create thousands of EmployeeDetial beans to send back
> to the
> client. Once the client gets the EmployeeDetail objects from the PayRoll
> bean,
> it will extract the data it needs and produce the output (in this case a
> System.out but it could be a GUI table if you like).
>
> Notice that only a portion of the data in the EmpolyeeDetail bean is
> needed?
> Yet we create and serialize the entire graph including complex
> relationships
> with the employee's manager, insurance benefit information, address, etc.
>
> This is an example of the worst EJB design possible, yet people persist in
> taking this rout to preserve the "OO" design of the system. Hogwash! All
> you
> have done is created a system that will not run fast enough to service
> your
> client population and will require an enormous amount of resources (many
> clustered servers, huge platforms, lot and lots of memory).
>
> **********************************
> Strategy 2: Here is my strategy to the problem:
>
>
> public class PayRollBean implements javax.ejb.SessionBean [
>
> public EJBResultSet getEmployeeSalaries( ){
>
> DataSource dataSource =
> (DataSource)cntx.lookup("java:comp/env/jdbc/db");
> Connection con = dataSource.getConnection( );
> Statement stmt = con.createStatement( );
> ResultSet set = stmt.executeQuery("select LNAME, FNAME, SALARY
> from
> EMPLOYEE");
>
> CustomResultSet customSet = new CustomResultSet(set);
> return (EJBResultSet)customSet;
>
> }
> ...
> }
>
> The EJBResultSet return type for the method is an interface that can have
> many
> different implementation. One implementation might be a wrapper to a
> CachedRowSet, while another might be a custom ResultSet that is a
> lightweight
> serializable object containing only the data needed. I have personally
> created
> the custom implementation which is used today in production in a very
> large
> CORBA banking system.
>
> The implementation for CachedRowSet would make sense when using a JDBC 2.0
> driver that supported that type. The nice part about EJBResultSet is that
> all
> implementations use the EJBResultSet interface so the client is unaware of
> the
> different implementations. (Encapsulation & Polymorphism). The result set
> is
> read only because we don't want the client attempting to update the
> database
> directly. The EJBResultSet should contain cached data and be immutable.
> (This
> can be done with a CachedRowSet also be setting the properties to be
> read-only.)
>
> Below is a partial definition of the EJBResultSet (limited for brevity).
>
>
> public interface EJBResultSet extends Serializable {
>
> public boolean next( ) throws QueryException;
> public Properties getMetaData( ) throws QueryException;
> public int getRowCount() throws QueryException;
> public boolean getBoolean(int columnIndex) throws QueryException;
> public boolean getBoolean(String columnName) throws QueryException;
> public byte getByte(int columnIndex) throws QueryException;
> public byte getByte(String columnName) throws QueryException;
> public java.util.Date getDate(int columnIndex) throws QueryException;
> public java.util.Date getDate(String columnName) throws
> QueryException;
> public double getDouble(int columnIndex) throws QueryException;
> public double getDouble(String columnName) throws QueryException;
> public float getFloat(int columnIndex) throws QueryException;
> public float getFloat(String columnName) throws QueryException;
> public int getInt(int columnIndex) throws QueryException;
> public int getInt(String columnName) throws QueryException;
> public long getLong(int columnIndex) throws QueryException;
> public long getLong(String columnName) throws QueryException;
> public Number getNumber(int columnIndex) throws QueryException;
> public Number getNumber(String columnName) throws QueryException;
> public Object getObject(int columnIndex) throws QueryException;
> public Object getObject(String columnName) throws QueryException;
> public short getShort(int columnIndex) throws QueryException;
> public short getShort(String columnName) throws QueryException;
> public String getString(int columnIndex) throws QueryException;
> public String getString(String columnName) throws QueryException;
> }
>
> [Note: An alternative is to use the RowSet interface which is certainly
> more
> standard then EJBResultSet or possibly the java.sql.ResultSet interface
> itself.
> I use the EJBResultSet to limit my API to the read only methods and simply
> the
> API for the developer]
>
> The client application would use the EJBResultSet just like a JDBC
> ResultSet.
> The advantage to using this design is that the underling data can change
> (e.g.
> add the person's department) but the client code stays the same. This
> means
> that a change in my requirements has very little impact on my client or
> server.
> The EJBResultSet is lightweight with out the business object baggage which
> is
> not necessary for listing behavior. As a result it can be easily used in
> a
> variety of client types form heavy GUI to Servlets, to smaller devices.
>
> In addition, the EJBResultSet is standard across all quires and provides
> meta-data so that it can be used by tools and builders without developer
> intervention. This is not possible with the object graph approach that
> William
> proposes because the type of objects and their graphs change for each kind
> of
> query. In the case of the EJBResultSet it can be used to peruse Employee
> salaries as easily as it can be used to peruse Hotel Reservation data.
> The
> programming interface is familiar to developers (pretty much the same as
> java.sql.ResultSet) and its an API that used consistently across all
> listing
> operations. Developer's learn how to use it once. The interface never
> changes,
> just the data.
>
>
> Below is an example of how the EJBResultSet interface is used:
>
> public class MyClient {
>
> public static void main(String [] args){
>
> InitialContext cntx = new InitialContext();
> PayRollHome home =
> (PayRollHome)PortableRemoteObject.narrow(cntx.lookup("java:comp/env/ejb/pa
> yroll"),
> PayRollHome.class);
> PayRoll payRoll = home.create( );
> EJBResultSet set = payRoll.getEmployeeSalaries( );
> while(set.next()){
> System.out.println(set.getString("lname")+",
> "+set.getString("fname")+" "+set.getDouble("salary"));
> }
> }
> }
>
> The EJBResultSet solution I use grew out of my CORBA experience before the
> days
> of EJB. Admittedly, we didn't have serialization back then but we managed
> to
> fake it. Anyway its a proven technique that works and was popular with
> server
> side and gui developers because its simple, consistent, and lightweight.
>
> This strategy has also been independently recognized by the folks at Sun
> Microsystems. In fact that need for this type of functionality was the
> motivation behind the CachedRowSet and RowSet types introduced in JDBC
> 2.0.
>
> *******************
>
> This discussion has focused on listing behavior and is specific to only
> that
> topic. The fact that I use JDBC directly is not a condemnation of entity
> beans.
> I'm a big advocate of Entity beans because they are extremely vital part
> of the
> EJB model. They are used extensively when updating entities and leveraging
> their
> behavior to accomplish tasks.
>
> Listing behavior is only a subset of the scenarios we have to deal with
> when
> designing EJB solutions, but its one area where we can can model the data
> as its
> used, in Tabular format. In my case I like the EJBResultSet design but I
> have
> also used multidimensional String arrays and arrays of structures. See
> this EJB
> design Tip for mote detail (http://www.ejbnow.com/ejbtips/ejbtip_4.html).
>
>
> Thanks,
>
> Richard
> --
> Richard Monson-Haefel
> Author of Enterprise JavaBeans, 2nd Edition
> Published by O'Reilly & Associates
> http://www.EjbNow.com
>
>
>
>
> "Louth, William (Exchange)" wrote:
>
> > To Richard and Chris,
> >
> > I do recognize your concerns regarding bandwidth especially when sending
> > alot of extra data not required. But please consider that the client
> (UI)
> > designer might not be the same guy designing the session bean interface.
> The
> > client designer might decide that to better help the user he will add
> icons
> > to the list to aid selection visually. The determination of the icon for
> > each cell item will require the client (or some framework) to inspect
> other
> > properties of the object in question. This inspection could possibly
> change
> > throughout the products development as the UI designer strives to
> increase
> > the usuability of the client. With this in mind you can see why it is
> not
> > ideal that we send strings as representations of the user's conceptual
> model
> > to the client.
> >
> > I do recognize Strings are fully feldged objects but lets be honest we
> are
> > diluting the OO model - thus my concern. I want to build clients that
> are
> > powerful, of high usuability and at the same time thin. To achieve this
> > requires the client to treat every object as an user object which has
> > certain charcateristics. Using this construct we can build a interface
> (i.e.
> > browser, list component) which can interact with many different types of
> > objects as render them in a consistent manner throughout the interface.
> > Using the String solution leads to duplication of repetitive code
> through
> > the client which could possibly be inconsistent - their goes the
> usuability
> > and most likely the project/product.
> >
> > "If a systems one-on-one [user-computer] interaction with its human is
> not
> > pleasant and facile, the resulting deficiency will poison the
> performance of
> > the entire system, however fine that system might be in its other
> aspects."
> > - Jef Raskin , The Humane Interface (Great Book - I highly recommend it)
> >
> > [richard] In the case of listing behavior it makes sense to present
> lists of
> > data as lists and not graphs of domain objects.
> > [chris] However the problem is that without a "value holder" approach
> you
> > end up serializing a lot of extra stuff to the client.
> > [william] The Detail object normally does not send the whole object
> graph. I
> > try to just package the simple fields and leave collections to other
> > operations. This is a trade-off which we both recognize has to made be
> when
> > building distributed systems.
> >
> > [richard] Send over an array of detail objects or a serializable
> > implementation of a ResultSet.
> > [william] I think we are agreeing some what here apart from I do like
> the
> > ResultSet concept since its origins stem from relational database
> > technology. There is others ways to interact with user objects instead
> of
> > through some table like interface - you are flatening the structure.
> >
> > [richard] This is far easier for the client to work with then a complex
> > graph of Employee objects with lots of superfluous information
> (information
> > not specific to my current needs).
> > [william] This is the point that I am attempting to raise above. I hate
> to
> > say this but change is constant.
> >
> > [richard] Objects do not always represent business concepts, in fact
> objects
> > usally represent more utilitarian concepts like String, Socket, and
> > TextArea.
> > [william] I think you know what I meant. If we do flatten the structure
> and
> > send it over the wire this then requires the client to to build around
> this
> > structure a more user aligned object. This results in more work and a
> fatter
> > client. I thould point out that normally I try to get my session beans
> to
> > call getDetails() or something like this on my entity beans so to me
> making
> > a resultset is flattening.
> >
> > [richard] OO representations of Lists are OO at its finest because these
> > constructs make it easier for programmers to work with the data.
> > [william] The Java Collections is a nice OO framework but my point is
> not to
> > de-objectfy (if there is such a word) my data and behavior constructs.
> An
> > example would be converting a List interface to a plain array. We lose
> > something here...agree?
> >
> > [richard] Another point was made that its wasteful to convert
> information
> > from objects to lists. This seems like an odd point since the data is
> > accessed (in most cases involving lists) directly from the database
> which is
> > usually relational.
> > [william] I think the point was made with regard to converting the
> > properties of an object into an array of strings.
> >
> > [richard] This idea that good OO requires all business data to be housed
> in
> > business objects at every tier is misguided.
> > [william] Its strange that we move from the database to entity
> bean/session
> > bean (more OO like) and then to table of strings. To me it would seem
> that
> > the closer the data gets to the user the more OO like it would appear.
> Maybe
> > this is because of the constraints placed on us by GUI frameworks.
> >
> > [richard] The point is, you give the client what it wants - nothing more
> and
> > nothing less. Don't force the client applications to deal with graphs
> of
> > domain objects simply because it ideologically more conformable.
> > [william] "I want more of this and less of that" - agreed. Its the
> > determination of the more and less thats so tricky and requires proper
> task
> > analysis which is sometimes ignored in favour of just wrapping around
> some
> > database. I believe we can give more and achieve the less at the same
> time.
> >
> > [richard] Enterprise JavaBeans provides an objectified view of the an
> > enterprise system.
> > [william] Then why de-objectify? I think our apparent differences stem
> from
> > what we consider what the client framework should be like. I try to
> build an
> > underlying OO framework directly beneath the client UI components to
> achieve
> > my goal of creating a great OOUI. This can be achived through your
> methods
> > but I have found this to be more work and more open to interface bugs.
> This
> > is my experience maybe others have found all this part quite difficult
> and
> > approached it differently.
> >
> > I will admit that my method does require more design upfront but then
> again
> > I try to attempt to spend my time designing and less building. Also what
> I
> > propose is geared towards the user interfaces I build others building
> more
> > primitive interfaces would mostly benefit more from your solution. This
> all
> > comes down what type of system your building for now and then and that
> where
> > us architects come in and perform are magic (designing with trade-off).
> > "There is no progress without struggle" - Fredrick Douglas
> >
> > [richard] Lets use good OO practices where appreciate but not at the
> expense
> > of performance and simplicity.
> > [chris] Good OO" has to be balanced with pragmatism when the distributed
> > nature of these environments is taken into consideration.
> > [william] Yes, I am always battling with these issues constantly. What I
> try
> > to do is start with the ideal solution solution and then perform devils
> > advocate on it with regard to these constraints. I am a logical designer
> who
> > is a reluctant physical designer.
> >
> > [chris] When the "network really Is the computer" this may change. But
> we
> > ain't there yet! Are the bandwidth guys listening? ;-)
> > [william] I await.
> >
> > I think this is my email qouta for today...bye.
> >
> > William Louth
> >
> > "Nothing is more impossible that to write a book that wins every readers
> > approval" - Miguel de Cervantes
> >
> > > -----Original Message-----
> > > From: Richard Monson-Haefel [SMTP:[EMAIL PROTECTED]]
> > > Sent: Wednesday, April 26, 2000 11:31 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Cached Rowsets-do we need to use them
> > >
> > > William,
> > >
> > > I would like to address the circumstances under which the client
> requires
> > > a list
> > > of data; data that is conceptually organized in a table format. This
> is
> > > not
> > > intended to be take personally, it simply a response to your post.
> > >
> > > In the case of listing behavior it makes sense to present lists of
> data as
> > > lists
> > > and not graphs of domain objects. The reason is quite simple, you
> > > eliminate all
> > > the overhead associated with accessing complex object graphs on the
> > > client. If,
> > > for example, a client wants a list of all the employees and their
> current
> > > salaries then that is exactly what should be delivered to the client.
> > > Send over
> > > an array of detail objects or a serializable implementation of a
> > > ResultSet.
> > > This is far easier for the client to work with then a complex graph of
> > > Employee
> > > objects with lots of superfluous information (information not specific
> to
> > > my
> > > current needs). Personally I like the use of serializable ResultSet
> > > object
> > > because the the object manages the data and the list itself.
> > >
> > > To say that a list of data, whether its an array of detail objects or
> a
> > > serializable ResultSet, is not OO certainly seems indicative of a
> > > misunderstanding of objects. Objects do not always represent business
> > > concepts,
> > > in fact objects usally represent more utilitarian concepts like
> String,
> > > Socket,
> > > and TextArea. The idea behind OO is two fold: (1) It provides simple
> > > unified
> > > interface to data and behavior; (2) It provides more flexibility and
> > > extensibility to systems. The first point is particularly important
> in
> > > this
> > > case. OO representations of Lists are OO at its finest because these
> > > constructs
> > > make it easier for programmers to work with the data.
> > >
> > > Another point was made that its wasteful to convert information from
> > > objects to
> > > lists. This seems like an odd point since the data is accessed (in
> most
> > > cases
> > > involving lists) directly from the database which is usually
> relational.
> > > I
> > > would say that its more wasteful to covert relational data into domain
> > > objects
> > > just so that it can be presented in a tabular format on the client.
> This
> > > idea
> > > that good OO requires all business data to be housed in business
> objects
> > > at
> > > every tier is misguided. Data is data and If I want my data in a list
> > > then
> > > that's how I should get it. If I need more complex behavior or
> > > relationships
> > > then I'll model it as business objects with a complex graph. The
> point
> > > is, you
> > > give the client what it wants - nothing more and nothing less. Don't
> > > force the
> > > client applications to deal with graphs of domain objects simply
> because
> > > it
> > > ideologically more conformable.
> > >
> > > Enterprise JavaBeans provides an objectified view of the an enterprise
> > > system.
> > > It allows us to model business concepts and provide a component model
> that
> > > can
> > > assembled, reused, and re-assembled into new solutions while maintain
> > > transaction and security control. In short it makes it simpler to
> > > assemble
> > > solutions from existing components. While EJB, like MTS and CORBA is
> > > objectified these are certainly not your father's objects. They are
> > > distributed
> > > server side components and the paradigm that they live in is different
> > > from
> > > traditional OO. Lets use good OO practices where appreciate but not
> at
> > > the
> > > expense of performance and simplicity.
> > >
> > > Richard
> > >
> > > "Louth, William (Exchange)" wrote:
> > >
> > > > Hi Sesh,
> > > >
> > > > Personally I do not believe in database-like view of the world that
> is
> > > > constantly being advocated in list and tabular server operations.
> What
> > > you
> > > > typically see is an collection of objects on the server side being
> > > > transformed into an array x array of strings before transmitting to
> > > client.
> > > > What happen to OO? I prefer to send my domain objects (State or
> Details
> > > > objects, whatever you call them) to the client and rely on an good
> OOUI
> > > to
> > > > solve the problem of mapping each object into what component it
> needs to
> > > be
> > > > displayed in. I have an article coming up in JavaReport detailing
> how to
> > > > better solve this great divide titled "Bridging the gap between Java
> > > Clients
> > > > and Enterprise Java Beans using XML". To me OO concepts should be
> > > brought
> > > > more and more into the design of client interfaces - please do not
> reply
> > > > regarding widgets.
> > > >
> > > > kind regards
> > > >
> > > > William Louth
> > > >
> > > > > -----Original Message-----
> > > > > From: Sesh Kumar Jalagam [SMTP:[EMAIL PROTECTED]]
> > > > > Sent: Wednesday, April 26, 2000 6:28 PM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: Cached Rowsets-do we need to use them
> > > > >
> > > > > Hai how is every one listing the data from the entitybeans. Does
> any
> > > one
> > > > > use Cachedrowsets. I tried to use them but I was only able to use
> them
> > > > > with BMP's . I couldn't find any way to convert an Enumeration to
> > > > > CachedRowset.
> > > > >
> > > > > The method i am following to list the data to the users is by
> > > collection
> > > > > of immutable objects (JavaBeans. with only getter fields).Are
> there
> > > any
> > > > > other better ways to do this (
> > > > > <http://www.ejbnow.com/ejbtips/ejbtip_4.html)>
> > > > >
> > > > > I want to know how others are doing this
> > > > > Thank you
> > > > > Sesh
> > > >
> > > >
> ***********************************************************************
> > > > Bear Stearns is not responsible for any recommendation,
> solicitation,
> > > > offer or agreement or any information about any transaction,
> customer
> > > > account or account activity contained in this communication.
> > > >
> ***********************************************************************
> > > >
> > > >
> > >
> ==========================================================================
> > > =
> > > > 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".
> > >
> > > --
> > > Richard Monson-Haefel
> > > Author of Enterprise JavaBeans, 2nd Edition
> > > Published by O'Reilly & Associates
> > > http://www.EjbNow.com
> > >
> > >
> ==========================================================================
> > > =
> > > 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".
> >
> > ***********************************************************************
> > Bear Stearns is not responsible for any recommendation, solicitation,
> > offer or agreement or any information about any transaction, customer
> > account or account activity contained in this communication.
> > ***********************************************************************
> >
> >
> ==========================================================================
> =
> > 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".
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
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".
