I view the entity-bean with cmp as a standardized or-mapping framework. It also separates system-services such as load-balancing, caching, failover etc. from the or-services. Many commercial or-mapping products have these services built-in. Now these are provided by the ejb-container instead. Almost every major or-mapping product is integrated with the major ejb-containers nowadays so the it is becoming somewhat of a de facto standard. So, ehm, to answer: they do, why not, and ehm...no(?)... :-) --- Arkin <[EMAIL PROTECTED]> skrev: > Actually, if the services fulfill coarse-grained > operations using > fine-grained method calls, why don't they use O/R > mapping? Why use > entity beans to begin with? > > If you want to be close to the data, get as close as > you possible can > (O/R mapping). If you want to be far from the data, > select a > far-reaching architecture (EJB entity beans). > > arkin > > "Jon Tirsén" wrote: > > > > 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 > === 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".
