On Wed, 12 Jul 2000, Dan Christopherson wrote:
> One caveat that I should have made: Don't take my opinions as an
official
> position of the jboss team, since I have been at most tangentially
> involved (that will change if I can ever get out from under, but my
> opinions will never be official positions of the jboss organization).
>
Ok, point is taken. But I was also interested in a theoretical
discussion about the status of the PersitanceManager (PM) in EJB 2.0.
> Now, more opinions! 8^})
>
> The first point I'd like to make is that (as far as I know) the EJB spec
> does not specify APIs between the container and the persistence manager.
> It specifies the responsibilities of each, but not specific
interactions.
> This is typical in this sort of spec: the API for users is 'fully'
> specified, but there is enough slack in the spec to allow implementors
> room to make different trade offs that differentiate themselves.
You are correct there. Since the say that Pluggable Persistance
Managers will be part of the next EJB spec version, one may conclude
that the PM of EJB 2.0 is not. I would however like to say that the
interesting part of a spec is the news things, and not the things that
have not changed. The container governing the persistance is not new; the
idea of it being possible to have an extarnal losly coupled PM to do
the persistance is new, and therefore interesting. My feeling when I
read the spec is that the PM thing surfaced late and that we will
probably see some more details about this in the final version.
I therefore agree with you when it commes to an implementers freedom
to create a tightly knit container and PM; but I at the same time
thinks that the spec is pointing in another direction - and
think it is verry interesting to ponder the consequenses of such a
strategy.
They do also have a couple of Object Interaction Diagrams (9.12)
which point in the direction I have made my interpretation, although
said to be "illstrative".
>
> Looking closer at the spec, I better understand your interpretation of
the
> Persistence Manager's role (generate a BMP). However, I would still
point
> out that if _all_ the persistence manager does is generate a BMP bean,
> that could be done now.
No, not from a standard description of a bean. It is correct that CocoBase
may generate such a beast, and that any body could do that. But you
could not take that bean and move it to another generation tool
(meaning perhaps another data source under the hood) without having to
rewrite/redo large part.
"The advantage of using container-managed
persistence is that the enity bean can be logically independent of the
data source in wich the entity is stored."(9.3)
>From my perspective the advantage of CMP for EJB 2.0 is that there are
a standard how to:
1. Write Coarse Grained Bean.
2. Define relationships.
3. Howto deletage to the PM (abstract methods)
Even if this in the end will be implemented as an BMP it is not a BMP
since the bean provider have not written a single line of data access
code. An only by using another PM it may work againts different
persistant storage (and without containg one bit of proprietary
mapping code).
>The advantages of the new CMP lie in persistence
> managers that do things that are more difficult to do (if not
impossible)
> in BMP (caching, optimized updates, etc.)
I have never implemented a CMP container so I did not see that
imediately. What you mean I guess is that the architecture allows for
a PM to get controll over access to the container managed fields and
relationships and thereby being able to use better caching strategies?
Would it not be possible for an external PM to do that to?
>Some of these things do require
> something beyond the BMP implementation - some service running in the
> container. This is really what I'm trying to point out. Again, do NOT
take
> this as an official statement from the jboss organization - wait and see
> if mark, rickard, or one of the other people who have contributed
> significant code to the effort.
>
> Dan Christopherson (danch)
> STR Technical Architect (www.str.com)
>
>
Here are some more comments on what the spec says about the PM:
1. Pro PM as a concrete Entity bean:
In 9.3 the spec says that typically the PM takes a jar file, produces
a concrete implementation of the bean and produces a new jar
file. "The modified ejb-jar file then serves as the input to the
Container Provider's tool."
In 9.5.2 it is stated that: "The persistence manager provider tools are
responsible for providig the concete entity bean class".
As I understand it there are a form of contract between the Container
and the PM when it commes to synchronization. (9.5.2.1 and 9.6).
The PM managers view of the concete entity bean looks like ... an
entity bean. (9.6.3)
In 9.8 it is said that the section "describes the responsibilites of
the Persistence Manager Provider's tools to ensure that an entity bean
with container managed persitence can be deployed in any EJB Container"!!
The demand that the PM also is given access to the transaction manager
and a transactionless connection resource, points in this direction
to.
2. Open ended
The PM can basically be interpreted as a generated concrete bean which
governs the persistance; or it could be interpreted that the PM has to
generate a concrete implementation of the bean; but at the same time
the synchronization protocoll and the relation to the Conatiner is
open for server specific implementations. One such place is 9.6.3
which basically states that a PM may implement all the entity bean
methods, but it only HAVE to implement a subset.
>From this perspective it is a question of wich strategy one prefere.
3. Hard to solve issues.
There are still some hard to solve issous. One of them beeing the
container caching strategy. Typically one may read in 9.6.9 about
different commit time options. When writing about them, the spec only
uses the container as an example. Take for example option A in wich
"The Container ensures that the instance has exclusive access to the
state of the object in the persistent storage". (This is when the
Container caches a bean in ready state - don't give it back to the
pool - between transactions and don't use ejbLoad) The first
interpretation is that this means that the PM and the Container must
be the same thing since in all what has hierto been explained in the
spec, it is the PM that has access to the data storage and knows wich
tables to lock.
It is however not only a possibly deprecated paragraph, but points to
something prolematic. It is the container that knows how it will
handle and cache its bean instances, and some of the possible
strategys will make it necesarry for it to have some kind of controll
of how a specific resource is locked ( as in Opion A in the spec).
Interestingly the spec tries to give an independent PM view even of
option A (see 9.11.1). But even if the aproach described there would
work, that would imply that either the container somehow have to know
that the PM uses Opion A and adopt to that, or the PM must know that
it executes in a Option A container and adopt to that.
/Peter
> On Tue, 11 Jul 2000, Peter Antman wrote:
>
> > Hi,
> > thanks for your answer. From it I deduce three conclusions:
> >
> > 1. Here at Jboss something is pluggable if the API is openly documented.
> > This is offcource a correct view, but it also bears al the classical
> > portabillity quetsions with it. This might be ok for a commercial vendor
> > (top link is a $12 000 deal, and it will probably never support open
> > source alternatives) but for open source tools (and servers) the way to go
> > is almost always to follow standards as close as possible. There are
> > exceptions to this, if you have almost total market penetration (as
> > apache) you may get away with having your own API to make things work. But
> > for opens source EJB servers I think you rally should make everything
> > protable between EJB vendors (and support that strategy); then you may
> > make available internal API for people who are really shure they only want
> > to use Jboss.
> >
> > 2. The Jboss view is that a sepparation of container and PM (i.e a PM
> > ithout container specific knowledge) will become a verry inefficient way
> > to handle CMP beans. This might be so. Currently I personally don't know.
> >
> > 3. Jboss will knit the Container and the PM through a proprietary
> > (although open source) API, and will not make it possible to use an
> > external PM that does not have any knowlage about any Jboss specific API
> > but only use the Container-PM contract specifyed in the spec.
> >
> > /Peter
> >
> >
> > On Tue, 11 Jul 2000, danch wrote:
> >
> > > My basic comment is that just because the EJB 2.0 spec would appear to
> > > allow the container to implement CMP by generating BMP classes doesn't
> > > mean that that's how containers will (or should) implement EJB 2.0
> > > entities. More below.
> > >
> > > Peter Antman wrote:
> > > >
> > > > Hi,
> > > Hi!
> > >
> > > <snip!>
> > > >
> > > > 3. What is the strategy concerning CMP?
> > > >
> > > > In 1.0 and 1.1 CMP persistence was delegated to container; visable in JAWS
> > > > for example. This is not so in 2.0 (at least accordning to my
> > > > interpretation). Instead the persistence should be governed by a
> > > > PersistenceManager (PM). If you read the spec caerfully one may note that
> > > > the contract between the Container and the PM is basicly the same contract
> > > > as between the Container and the Bean in BMP.
> > > This looks to me (that is, my interpretation is) that this really just
> > > specifies more of the architecture of the container. No harm here, since
> > > this is where a lot of containers have headed anyway (Inprise,
> > > Bluestone, I believe WebLogic, and jboss (where _everything_ is
> > > pluggable) all have ways of plugging in Persistence Managers, under one
> > > name or another)
> > >
> > > >
> > > > In 2.0 a CMP bean will have to be an abstract class; the dependant object
> > > > classes should also be abtract. I is then upp to the persistence manager
> > > > to create subclasses that implements the persistence. These subclasses are
> > > > EJB Entity beans (possibly with some extensions to handle transaction
> > > > synchronization).
> > > Notes:
> > > the CMP bean provided by the bean developer is an EJB entity bean, what
> > > the container does with it is what the container does with it. The
> > > reason all of this happened (I'm assuming, anyway) is so that the
> > > container can have more knowledge of exactly what changed, and can
> > > therefore provide better tuned database accesses. This also helps
> > > containers support CMP with dependent objects (of two flavors!) as an
> > > added bonus.
> > >
> > > >
> > > > Accoring to my interpretation this means that at CMP container is basicly
> > > > a BMP container which makes the TransactionManager available in the PM
> > > > namespace (JNDI) to the bean.
> > > >
> > > > Seen from this perspectiv CMP in 2.0 is basiclly a specification of how to
> > > > design (the bean provider) and autogenerate (the PM provider) BMP beans.
> > > > When done accorning to the spec, these are called CMP beans. It also means
> > > > that external generation tools may be used to implement CMP in 2.0 without
> > > > any knowlage of the CMP container of a specific EJB server.
> > > Just because the container is going to implement a subclass doesn't mean
> > > that that subclass will be a BMP bean. it just allows the container to
> > > place hooks inbetween your code and the data it accesses to better
> > > monitor and optimize database accesses. I think it's unlikely that many
> > > server vendors will actually implement something that I'd consider BMP
> > > (with an ejbLoad that naively grabs all of the data through a JDBC
> > > connection every time?!?!? please no!). There is still a very very very
> > > big disctinction between CMP and BMP: in BMP the bean developer (J2EE
> > > role) worries about persistence; in CMP the container does. Note that
> > > there has never been a restriction against a container implementing CMP
> > > via inheritence - fer goddess' sake, you had to make CMP fields public!
> > >
> > > There are _now_ tools (CoCoBase) that generate BMP beans without
> > > neccessarily knowing what server it will be deployed to. If you're very
> > > carefull, you can now 'generate' CMP beans that will run on a variety of
> > > servers .
> > >
> > > >
> > > > How will Jboss solve this? Will you build a container that is dependant of
> > > > an external PersistenceManager? Will you create a PersistenceManager? Will
> > > > you integrate the PercistenceManager in the Container, i.e JAWS? Will is
> > > > be possible to deploy PM generated impl beans?
> > > JAWS really is a persistence manager. I'd imagine that it should conform
> > > to the contracts specified by the 2.0 spec. jboss handles everything as
> > > plugins already, and its internal architecture is open, so you can write
> > > a 'co-peting' persistence manager right now, if you want.
> > >
> > > >
> > > > Without really making any promisses (or threats ;-)) I am contemplating
> > > > the idea of making Percolator a PersistenceManager for EJB 2.0 since it
> > > > already have a lot of the code generation logic in place. But if all EJB
> > > > server will chose to make their own proprietary PM (as Weblogic) and not
> > > > making a CMP container where you may use an external PM this would be of
> > > > little use.
> > > As I said before, a lot of the container vendors have opened enough of
> > > the interface between their container and their PM so that a third party
> > > can write a pluggable PM. I thought that Weblogic 5.1 was one of those,
> > > but I may be wrong - I dropped WL 5.1 in disgust when development turned
> > > out to be a remarkable PITA.
> > >
> > > >
> > > > There are a lot of open issues, I know - its is not shure how you should
> > > > treat Uniquing of dependant objects, manage Caches at the container level
> > > > or even how you get the container to deploy the generated Beans in the
> > > > container. I still think the approach of making the PM external to the
> > > > container is interesting. Put together with Connectors and JDO the PM
> > > > begins to look like a universal switching system to connect diverse
> > > > backends together in a portable way.
> > > I'll take Rickard's line and say that all that is a Small Matter of
> > > Implementation 8^}) Seriously, yes that's a lot of stuff, but there's a
> > > lot of talent reading this.
> > >
> > > >
> > > > In what direction is Jboss heading?
> > > >
> > > > Greetings
> > > > Peter
> > > >
> > > > -----------------------------------------------------------
> > > > Peter Antman Technology in Media, Box 34105 100 26 Stockholm
> > > > Systems Architect WWW: http://www.tim.se
> > > > Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
> > > > Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
> > > > ------------------------------------------------------------
> > > >
> > > > --
> > > > --------------------------------------------------------------
> > > > To subscribe: [EMAIL PROTECTED]
> > > > To unsubscribe: [EMAIL PROTECTED]
> > > > Problems?: [EMAIL PROTECTED]
> > >
> > >
> > > --
> > > --------------------------------------------------------------
> > > To subscribe: [EMAIL PROTECTED]
> > > To unsubscribe: [EMAIL PROTECTED]
> > > Problems?: [EMAIL PROTECTED]
> > >
> >
> > ------------------------------------------------------------
> > Peter Antman Technology in Media, Box 34105 100 26 Stockholm
> > Systems Architect WWW: http://www.tim.se
> > Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
> > Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
> > ------------------------------------------------------------
> >
> >
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Problems?: [EMAIL PROTECTED]
> >
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
------------------------------------------------------------
Peter Antman Technology in Media, Box 34105 100 26 Stockholm
Systems Architect WWW: http://www.tim.se
Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
------------------------------------------------------------
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
