Objects that play together should stay together. William PS: It is not always possible or advisable; treat it as a guideline. > -----Original Message----- > From: Jon Tirs�n [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, April 12, 2000 12:48 PM > To: [EMAIL PROTECTED] > Subject: Re: Use of application servers inside the database (Was: RE: > 'local' entity beans vs dependent objects) > > The major problem of putting entities separated from > the session beans is that entities typically are more > object-oriented and communicate using fine-grained > method-calls, while sessions are service-oriented > using coarse-grained method-calls. The services > fullfill their coarse-grained operations using several > fine-grained method calls on the entities. > This makes it necessary (for performance/scaleability) > to put the entities and sessions in the same > address-space (ie. using local calls). > > So the irony here is: For performance the entity > should be close to the data and the session should be > close to the entity. > > --- "Ananiev, Alexander" > <[EMAIL PROTECTED]> skrev: > > I like the idea of getting database as much to do as > > possible in terms of > > persistence. And I have a question in that regard. > > I'm currently in the > > process of evaluating Oracle JServer which is EJB > > 1.0 application server > > embedded in 8i database. The idea is to put entity > > beans (even though in > > fact current version of JServer doesn't support > > them) or some O/R layer into > > Jserver which would get the persistence logic as > > close as it can get to the > > data. On the other hand, I can still have my session > > beans with the business > > logic running outside of the database in some other > > application server which > > is supposedly more scalable. So, has anybody on the > > board happened to > > implement similar architecture? What do experts here > > think about the > > usability of "embedded" as I call them application > > servers (I know that > > other vendors are also putting JVMs inside their > > databases) ? And the last > > question: would there be a problem to propagate > > transaction context between > > containers from different vendors? > > > > Alexander "Sasha" Ananiev > > PricewaterhouseCoopers > > > > > > -----Original Message----- > > From: Louth, William (Exchange) > > [SMTP:[EMAIL PROTECTED]] > > Sent: Monday, April 10, 2000 3:56 PM > > To: [EMAIL PROTECTED] > > Subject: Re: 'local' entity beans vs > > dependent objects > > > > Hi all, > > > > Are we advocating that the business > > interface, that is used for > > local > > objects, have RemoteExceptions listed for > > all methods. It will have > > to if it > > is also to be used for the RemoteInterface. > > This seems strange > > considering > > that we are now dealing with local > > state/details objects are > > implying that > > they are remote. This really is going to > > cause confusion for the > > client side > > developer. Maybe I am reading this wrong. > > Maybe what people are > > really > > saying is that the bean and state objects > > are implementing the > > common > > business interface. > > > > One thing to consider before moving totally > > away from entity beans > > and to > > session beans with OO databases. Entity > > beans should not be just > > data > > holders they should do some useful work on > > their internal state and > > help > > reduce the amount of the data sent across > > the network. This comes > > back to a > > previous post I made on the inprise > > newsgroup about this area: > > > > > > > ====================================================== > > Subject: Re: Design questions > > Date: Fri, 4 Feb 2000 10:52:25 +0100 > > From: "William Louth" > > <[EMAIL PROTECTED]> > > Newsgroups: inprise.public.appserver > > > > My last post was not so clear so let me try > > again. > > > > A good starting point is the following > > pyramid: > > > > / User \ > > / GUI \ > > / Session Beans \ > > / Entity Beans \ > > / Database \ > > ==================== > > > > What the above diagram is showing is a > > layered architecture. I use > > this > > diagram with new recruits to help them > > understand how to allocate > > processing > > over components. In terms of designing most > > business systems we > > should try > > to do as much work (processing) at each of > > the lower layers. The > > larger the > > layer the more data held. The following is > > also based on the > > Locality > > Principle which means moving processing > > closer to the data or > > objects that > > play together should stay together. So with > > this we see that we > > should get > > the database to do as much as possible since > > it has most of the > > data, > > actually all of the persistent data. What > > this mean, well getting > > the > > database to do the filtering (selection), > > sorting, computation > > (computed > > fields) .etc of the data before moving it up > > to the entity bean > > layer. The > > more work this layer does the less the > > entity beans have to do since > > less > > data is possibly passed. > > > > Note: I am not advocating building alot of > > business logic into the > > DB layer > > in fact this is something I am not in favour > > of. > > > > At the entity bean layer we should then > > provide some methods in our > > interface which provide bulk processing of > > our internal data for > > clients > > (session beans). For example the premium > > calculations of some > > insurance > > policy object, our state returned in one > > method call, etc.. In terms > > of good > > OO design this is better. What we are trying > > to do is reduce the > > amount of > > data we pass up the pyramid i.e. to our > > clients, by processing more > > of it. > > At the session bean level we should try to > > do as much as possible to > > the > > entity data we have extracted before > > returning to the client. This > > in our > > case manifests itself in returning objects > > which represent customs > > views of > > our entity data, in most cases these views > > do not include all the > > objects > > processed and their properties. > > > > At the user interface layer we should do > > better tasks analysis to > > refine the > > information that is displayed to the user, > > looking at what objects > > are > > involved, what information on these objects > > needs to be displayed > > and at > > what point in the task is it best to provide > > the information. In > > many > > interface designs too much data is usually > > given to the user which > > requires > > them to do more processing (mind) before > > they can get the > > information they > > need to peform their task efficiently. > > .... > > > > With distributed computing we should be > > logical designers who are > > reluctant > > physical designers. > > > === message truncated === > > __________________________________________________ > Do You Yahoo!? > Send online invitations with Yahoo! Invites. > http://invites.yahoo.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".
