Hi Richard,
An extract from my posting to Neil
"I just had to reply to this one. You are reading my posts wrongly. I am
saying _not_ to send the icon or its _name_ over the wire but send the
_simple_ object state so that the client developer can use whatever
properties he wants in determining how to render each object and your
server-side is oblivious to this. "
Your association of "worst ejb design possible" and "Hogwash" with my design
has definately roused something in me and I am not talking about the same
feeling I get with a good interface.
William Louth
> -----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".
