Your architecture potentially has no technical disadvantages compared with EJB, it's just you'll end up re-inventing the wheel an awful lot. You are essentially writing EJBs, just not running them in a container. That means anything the container does for EJBs you have to do. This effectively means you have to write your own persistence manager, transaction manager, resource manager, security manager, connection pools, mail interface, message queing, logging, management architecture, everything. Why not use services which already exist, instead of re-writing them all, potentially for every bean? Just sticking your head in the sand and saying, "I don't need it," isn't really good enough, because one day you might, and then you can either move to EJB or write it yourself. Get the picture? ;-) Tom On Tue, 30 Jan 2001, you wrote: > Hi, > > I'm terribly new to ejb/j2ee, hence to JBoss. You won't believe it, I didn't > even get it to start ! How do I start the tomcat distribution? There's no > hint about this. When I did run_with_tomcat, everthing seemed ok, but > nothing was listening at port 8080... > > BTW I'm wondering if it really pays off all this J2EE fuss. At the moment, I > am developing my first dynamic site in Java (but this is not my first > experience with Java), and I'd like to ask you how I'd do certain things > with EJB technology instead of some of the ad hoc mechanisms I devised for > my specific needs: > > First, I'd want best to avoid cookies, so I wrote a simple session manager > that works with RMI. It's a simple thread that sleeps every 15 seconds to > see if sessions' time-to-live have elapsed. It's accessed through Naming by > my servlets that use it to check if sessions already exist for a particular > HttpRequest. Another advantage to this mechanism is that it centralizes > session management: I can have any number of servers running servlets that > have access to it. Furthermore, the manager persists the session states to a > MySQL database. > > What mechanisms exist to do this with EJB/J2EE ? > > Now for the rest I didn't understand really all the complexity involved with > using ejbeans (writing 2 interfaces and 1 implementation with this obscure > distinction between Session and Entity Beans,...). As far as I have > understood (and that's definitely not far enough), what you need to cope > with the design standards that come with EJB's is: > 1) to be able to get beans with a Primary key, > 2) to have your beans managed by a naming mechanism. > > I do all that with a simple RMI server, just like for the sessions, ie I > have a sessionManager, a userManager, a billingManager,... > > What's the problem (besides the fact that it won't be "portable" to > application servers, which really isn't that an issue: all I will be ending > with is a couple of services or groups of services that will have to be > launched separately - the rmi servers, and a couple of servlets/static > pages) > > please be so kind to share your enthusiasm with me, > > regards, > > candide kemmler > > PS: you can speak french with me if you like > > > > -- > -------------------------------------------------------------- > To subscribe: [EMAIL PROTECTED] > To unsubscribe: [EMAIL PROTECTED] > List Help?: [EMAIL PROTECTED] -- -------------------------------------------------------------- To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] List Help?: [EMAIL PROTECTED]
