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]
