SB = business logic, EB = data access. EB data access provides pooling and transactional services. If you have no need of these services, then the SB could access the data directly. In that case you might as well forego EJB altogether, put the JDBC in the servlet, and cache stuff in context vars. If you have one usage scenario, your choices are: 1 SB + EBs 1 fat SB or servlet, no EBs If you have n>1 usage scenarios, then your choices are: n SBs + EBs 1 fat SB + EBs n SBs with duplicated JDBC, no EBs 1 very fat SB or Servlet, no EBs The EJB choice is a functional partitioning decision. Bill Leonard wrote: > The high-level question is: If I choose to manage persistence explicitly > (instead of using CMP Entity Beans), what is the best solution using EJB? I > don't see the value-added of BMP Entity Beans versus session beans that > contain the JDBC code > > (1) My analysis, which may be faulty, is that the best alternative to BMP > entity beans is a stateful session bean (analysis is in the next section). > If someone can help me and show me where this is wrong, it would be much > appreciated. > > (2) I haven't been able to determine how I can do the following in EJB: I > want to be able to provide data caching: meaning, if 2 clients issue the > same request to the database (with the same selection criteria) then I would > like to avoid the second database hit if the first client's request is still > in the bean. > > ===> NOTE: Long detail follows <===== > > Problem Defined: > ================ > I'm trying to decide how best to integrate relational db access with EJB. > The general problem, using a specific example, is: My object model has a > DeviceProfile object which contains information for a particular device > type. The DeviceProfile data is persisted in 2 tables in a relational > database: there is a 1-many relationship between the strong and weak > entities (meaning, to retrieve the data for a device, one must perform a > join on the 2 tables and get a list of records with the strong entity's > fields being duplicated in the list). > > Clients want to be able to get a list of DeviceProfile objects by providing > a list of identifiers (or 'keys'). Further, they would like to have methods > that return this list in different formats: a) as a Collection of Java > objects b) as XML. Insertion, update and querying of this entity are all > supported. > > e.g. > String deviceProfileObjectsAsXML = > myObject.getAsXML(listOfDeviceIdentifiers); > > Here are the alternatives: > ========================== > 1. Stateless session bean (SSB) facade to BMP Entity bean w/ standard entity > bean contract followed (Enumeration of Primary Keys returned by ejbFind). > SSB accesses Entity beans and provides XML wrapping or pass-through for the > Enumeration of Entity Beans. > Analysis: > PROS: a. client update (set/get) will result > CONS: a. Database hit for each Primary Key; b. EJBObject/bean instance for > each primary key; > > 2. SSB facade to BMP Entity that uses Fat Key pattern where ejbFind returns > an Enumeration of pseudo primary keys that contain the PK plus the data for > each record. SSB provides same functionality as 1 except that the returned > collection/enumeration of deviceprofile objects are not Entity Beans; they > are Java objects. > Analysis: > PROS: a. one hit to the database > CONS: a. still have EJBObject and bean instance for each Primary Key; b. we > have to process the data in a loop in the ejbFind() method and, then, if XML > output is desired, the SSB has to process the data AGAIN; c. Data must be > copied to/from EJBObject (via container). > > 3. Same as #2 except: the Entity bean puts all the data returned from the > query into a single instance of a pseudo primary key. ejbFind() will parse > the data and put it into the pseudo primary key. The ejbLoad() method will > get the data from the EJBObject using the EntityContext. To avoid multiple > processing in the SSB and the entity bean, we can have ejbFind() methods in > the Entity Bean that return the data in the pseudo primary key formatted in > XML. Clients can issue set/get methods with key information in order to > set/get the correct db record. > Analysis: > PROS: a. one db hit (same as #2); b. one EJBOBject/bean instance (as > opposed to multiple in #2); > CONS: a. still have copying to/from EJBObject > > 4. Same as #3 except get rid of the stateless session bean and have client > access the entity bean directly. > Analysis: > PROS: a. It seems like the stateless session bean is frivolous and not > needed; otherwise, same PROS and CONS as #3. > > 5. Use a stateless session bean (and no entity bean) that performs the > querying of the database. It has methods for getting the collection in XML > format and as a collection of non-bean Java objects. > Analysis: > PROS: a. one db hit; b. one EJBObject/bean instance; c. no unnecessary > copying/caching of data in EJBObject; d. No extra call to an Entity bean > object. > CONS: a. Client will interact with the non-bean Java objects and will be > mistaken if the client thinks that by setting a value on the non-bean Java > object that the db is updated. b. set/get methods (on the stateless session > bean) with key info will result in a get from the db - no good. > > 6. Same as #5 except: use a Stateful Session Bean. Clients can then have > the option of getting the whole collection as XML or getting the data items > individually (with the stateful session bean caching the data. When client > wants a specific row (object) from the db, it gets back a non-bean Java > object that is a structure (not really an object). Client has to use > session bean to get changes to the db. > Analysis: a. Same benefits as #4; b. The CONS of #5 are removed. > > =========================================================================== > 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". -- Fred Loney Spirited Software, Inc. [EMAIL PROTECTED] =========================================================================== 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".
