Peter,
This is an understanding issue. Bean, Home, and Object are just naming
conventions and are not part of the spec. For example, all these are
legal EJB 1.1/2.0 remote interface definitions.
public interface Customer extends javax.ejb.EJBObject {
public String myBusinessMethod() throws RemoteException;
}
public interface CustomerObject extends javax.ejb.EJBObject {
public String myBusinessMethod() throws RemoteException;
}
public interface RemoteCustomer extends javax.ejb.EJBObject {
public String myBusinessMethod() throws RemoteException;
}
public interface RemoteCustomerObject extends javax.ejb.EJBObject {
public String myBusinessMethod() throws RemoteException;
}
public interface CustomerBean extends javax.ejb.EJBObject {
public String myBusinessMethod() throws RemoteException;
}
public interface CustomerHome extends javax.ejb.EJBObject {
public String myBusinessMethod() throws RemoteException;
}
public interface LocalCustomerRemoteBeanHomeObject extends
javax.ejb.EJBObject {
public String myBusinessMethod() throws RemoteException;
}
public interface AnyNameYouWant extends javax.ejb.EJBObject {
public String myBusinessMethod() throws RemoteException;
}
The last few interface names are obviously misleading to a human, but
are legal remote interface definitions deployable on any EJB server.
Regarding CMP, BMP, generating objects, etc. Castor is fully capable of
supporting EJB 2.0 CMP, it has OQL and composite mapping facilities,
etc. We still need a 2.0 CMP container, you are welcome to contribute
one. All the containers in OpenEJB (except the first one) were made by
coping all the code from an existing container, popping the spec open,
and hacking away. You could take all the code from the 1.1 CMP
container and go from there.
-David
Peter Molettiere wrote:
>
> Thanks for the reply, David.
>
> The bit that strikes me as non-compliant (and it very well
> may not be a
> compliance issue, but more of an issue of my understanding ;)
> is this:
> all the docs and examples implement beans using Bean, Home,
> and Object
> classes rather than the Bean class and the Home and RemoteHome
> interfaces. I understand that the openejb classes implement the same
> classes which those interfaces always extend, but I thought
> it was the
> container's job to provide implementations for those
> interfaces for CMP.
> But again, I'm probably not understanding something right. This is
> totally based on my reading of Richard's book, and
> admittedly, I haven't
> had a chance to download any of the workbooks he mentions. Is
> there even
> a workbook for openejb?
>
> As far as local semantics are concerned, you seem to be supporting my
> opinion that a second set of interfaces isn't needed for local
> optimizations. I suppose the local optimizations are really
> only useful
> when a developer wants to ensure that a group of (tightly coupled)
> components run in the same container.
>
> As you may remember from some of my previous posts, I'm working on a
> development tool which allows the user to specify a database schema
> (tables, fields, relations, etc) and generate all the necessary files
> (java, deployment descriptors, etc) to implement that schema as EJBs.
> Since EJB2.0 has better support for relations, I'm thinking I'm just
> going to target 2.0 for the time being to get my code generation
> working. I have code that would let me create BMP classes,
> but it seems
> that CMP is really a better solution for new bean applications.
>
> Thanks for clarifying that point about RMI and RMI-IIOP -- I was
> refering to the EJB2.0 requirement to support RMI-IIOP -- I was
> certainly unclear.
>
> And great news about the Apple contributions! I'm looking forward to
> seeing and playing with the new build!
>
> --Peter
>
> On Thursday, August 22, 2002, at 12:24 PM, David Blevins wrote:
>
> > Hi Peter,
> >
> > EJB is certainly not trivial, you're in good hands with
> Richard's EJB
> > book. Yes, Richard I wrote OpenEJB together, though he is now off
> > writing full-time. I am also writing a J2EE book for
> Addison-Wesley
> > in fact. I also teach an excellent EJB course, so if you have a
> > budget for training, make sure you let me know.
> >
> > OpenEJB doesn't support the 2.0 specification. We will actually go
> > straight to EJB 2.1, which is backwards compatible with EJB 2.0.
> > Richard's book has EJB 1.1 as well as EJB 2.0 examples in his book,
> > the 1.1 examples will work with OpenEJB.
> >
> > The IntraVM server is compliant with EJB 1.1. Out of
> curiosity, what
> > strikes you as not compliant? We don't have the ability to
> deploy EJB
> > 2.0 Local interfaces yet, though we already have the ability to run
> > them. What I mean by that is that OpenEJB can be
> configured to either
> > enforce the remote semantics on calls inside the container
> system or
> > to just pass local references. We don't need a Local
> interface to do
> > it, needless to say, we were a bit disappointed when they
> added Local
> > interfaces to the EJB 2.0 spec. That is functionality
> we've had since
> > day one and doesn't require to implement two sets of
> interfaces just
> > to get it either. Not sure who in the EJB expert group
> proposed the
> > idea.
> >
> > The spec doesn't require the server to support the RMI protocol, it
> > requires you to use RMI safe objects in your remote
> interface method
> > parameters and return values. This is distinctly
> different. Vendors
> > are free to use any protocol they want. In the EJB 2.0 spec they
> > added the requirement that vendors must also support the RMI-IIOP
> > protocol for vendor-to-vendor interoperability purposes and
> for CORBA
> > client access, servers are not required to use it otherwise. We
> > actually had that functionality already as well, only it
> never worked
> > so well. Our man at Apple, Stefan Reich, has just
> rewritten the thing
> > entirely and will be checking that in soon. Apple uses the
> RMI-IIOP
> > protocol to get interoperability between WebObjects
> applications and
> > beans in OpenEJB. We're the only open source project to have
> > commercially tested and frequently used RMI-IIOP interoperability.
> > The code should be checked in soon, hopefully it won't be that long
> > after that before we can get some supporting documentation together
> > for it.
> >
> > David
> >
> >> -----Original Message-----
> >> From: Peter Molettiere [mailto:[EMAIL PROTECTED]]
> >> Sent: Friday, August 16, 2002 7:09 PM
> >> To: David Blevins
> >> Subject: Re: [OpenEJB-user] castor, cmp, and open-ejb
> >>
> >>
> >>
> >> Hey David,
> >>
> >> Thanks for the thoughtful response.
> >>
> >> The EJB thing is a slightly steeper learning curve than I had
> >> anticipated! Woohoo! So I went and bought the O'Reilly _Enterprise
> >> Java Beans_ book, third edition, which I would recommend to anyone
> >> looking for a thorough EJB lesson. Isn't Richard Monson-Haefel (the
> >> author) one
> >> of the OpenEJB developers?
> >>
> >> Reading the book has brought up some more questions though. Does
> >> OpenEJB support the EJB 2.0 specification? My guess is no, but it
> >> never hurts to
> >> ask.
> >>
> >> Also, with the IntraVM Server, it seems that the mechanism for
> >> looking up and using local beans isn't compliant to any standards,
> >> either EJB1.X
> >> or 2.0 -- the 2.0 standard has a provision for local
> access to beans,
> >> but requires a couple local interfaces be implemented.
> >>
> >> In reading the book, I'm a little confused as to why the
> >> specification even provides a separate set of interfaces
> to use for
> >> local (same VM) access to beans rather than simply requiring the
> >> container implementations to optimize out the expensive RMI calls
> >> when a bean happens to be deployed on the same server. The way the
> >> spec is written
> >> seems to require beans to know about their deployment, and the
> >> deployment of the beans they use, which puts constraints on system
> >> administration, etc. Am I missing something?
> >>
> >> As far as I can tell from the bits I've read in the book, the EJB
> >> spec requires native java RMI, but allows CORBA or SOAP or
> whatever
> >> to be used as well.
> >>
> >> --Peter
> >>
> >> On Friday, August 16, 2002, at 10:03 AM, David Blevins wrote:
> >>
> >>> Hi Peter,
> >>>
> >>> There aren't any docs for configuring CMP beans on
> >> OpenEJB's site yet.
> >>> As you noticed, we are using castor in our CMP container, all cmp
> >>> config files are all castor controlled files. You should
> >> be able to
> >>> get information on Castor's mapping files on their website
> >>> (www.castor.org). There is no difference between
> >> configuring an entity
> >>> bean than with any other java object, so anything you learn about
> >>> Castor's config files will be applicable. I would hop onto their
> >>> mailing list if you have trouble with the syntax of the
> >> Castor config
> >>> files.
> >>>
> >>> On the topic of Stubs and Ties, we have a server (an
> >> adapter really)
> >>> that can make beans accessible over a CORBA ORB. If you
> >> use that, you
> >>> do need stubs and ties (a tie is like a skeleton). We
> >> don't support
> >>> it or test on it at the moment as it is being completely
> >> re-written.
> >>> I say it's more of an adapter because it just consists of
> a little
> >>> glue to allow you to embed OpenEJB inside OpenORB. OpenORB
> >> is really
> >>> the "server", not our glue. Again, it's being re-written.
> >>>
> >>> OpenEJB is a container system that can be plugged or adapted into
> >>> other products or server. We have three server
> >> implementations of our
> >>> own so far.
> >>>
> >>> Local Server (aka IntraVM) -- Allows clients in the same VM
> >> to access
> >>> the container system directly. This is a mandatory
> server as it is
> >>> what we use when one bean accesses other beans. It also supports
> >>> non-bean access, so you can use it in your applications
> >> when you want
> >>> to run OpenEJB in the same container system. This
> "server" is over
> >>> two years old.
> >>>
> >>> Remote Server -- Allows people to run OpenEJB as a
> >> standalone server
> >>> and access beans remotely over a network. When you use the
> >> "openejb
> >>> start" command, you are starting the Remote Server. This
> >> server uses
> >>> dynamically generated proxies, so no stubs or ties are
> >> required on the
> >>> server or client sides.
> >>>
> >>> CORBA Adapter -- Exports remote and home interfaces as
> >> Stubs and Ties
> >>> into a CORBA ORB implementation. Currently only supports
> >> OpenORB, but
> >>> the whole thing is being re-written to perform better and
> >> be capable
> >>> of using any valid ORB implementation. It does require
> >> stub and tie
> >>> classes on the server and client sides. It uses the
> >> RMI-IIOP protocol
> >>> to communicate over the network.
> >>>
> >>> An interesting note, when you use the deploy command, it
> >> deploys the
> >>> bean into the container system itself. You can then access
> >> the bean
> >>> through the any of the servers above.
> >>>
> >>> David
> >>>
> >>>> -----Original Message-----
> >>>> From: [EMAIL PROTECTED]
> >>>> [mailto:[EMAIL PROTECTED]] On
> >> Behalf Of Peter
> >>>> Molettiere
> >>>> Sent: Tuesday, August 13, 2002 4:17 AM
> >>>> To: [EMAIL PROTECTED]
> >>>> Subject: [OpenEJB-user] castor, cmp, and open-ejb
> >>>>
> >>>>
> >>>>
> >>>> So, I'm getting deeper into open-ejb, and finding that it
> >> seems to be
> >>>> very tightly coupled with castor. In fact, it seems that the cmp
> >>>> implementation is actually part of castor. As it turns
> >> out, there's a
> >>>> note in the castor documentation saying "Enterprise
> >> JavaBeans CMP --
> >>>> TBD". Are there docs explaining the interface between
> open-ejb and
> >>>> castor? Hopefully something a little higher level than the
> >> javadocs?
> >>>>
> >>>> From what I can gather, in order to implement CMP beans,
> >> you need to
> >>>> do the following:
> >>>>
> >>>> * setup the castor database config file for the
> >> database connection
> >>>> * write the castor mapping.xml file to map tables to beans
> >>>> * write your *Bean, *Home, and *Object classes and interfaces
> >>>> * write the ejb-jar.xml file
> >>>> * package the bean classes and ejb-jar.xml file into
> a bean.jar
> >>>> file
> >>>> * deploy the bean.jar file into the open-ejb server
> >>>> * write/compile/execute your client code.
> >>>>
> >>>> Does this seem correct? Am I missing anything? How about
> >> generating
> >>>> the RMI stubs and skeletons for distributed access?
> >>>>
> >>>> Any help appreciated.
> >>>>
> >>>> I'm trying to wrap this whole process in an application
> >> which takes
> >>>> an xml file describing the database config and schema, and
> >> generates
> >>>> appropriate open-ejb config files, bean .java sources, and ant
> >>>> build.xml file to implement cmp entity beans for the whole db
> >>>> schema. Yes my mother always told me to keep my mouth
> closed while
> >>>> chewing. :)
> >>>>
> >>>> --Peter
> >>>>
> >>>>
> >>>>
> >>>> -------------------------------------------------------
> >>>> This sf.net email is sponsored by: Dice - The leading online job
> >>>> board for high-tech professionals. Search and apply for
> tech jobs
> >>>> today! http://seeker.dice.com/seeker.epl?rel_code=31
> >>>> _______________________________________________
> >>>> http://OpenEJB.sf.net
> >>>> OpenEJB-user mailing list [EMAIL PROTECTED]
> >>>> https://lists.sourceforge.net/lists/listinfo/openejb-user
> >>>>
> >>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone? Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> http://OpenEJB.sf.net
> OpenEJB-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/openejb-user
>
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
http://OpenEJB.sf.net
OpenEJB-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openejb-user
