I obviously missed part of this discussion -- a negative side effect of trying to do my job while keeping up with this list. And I don't have a lot of time to respond to this fully. However, I find it necessary to disagree with the contention that JavaBeans are Session Beans, DAO classes are Entity Beans, and JMS is Message Beans. What I think you've missed by this over-simplification is the intended role of the EJB container in providing services and capabilities that you would otherwise be developing yourself: transactions, security, resource connectivity (e.g. Naming, Mail, Database), distribution, failover, caching, scaling, and declaritive configuration. Could you write these? Sure. Would use use available specifications and implementations of JDBC, JTA, JTS, JNDI, JavaMail, etc. You bet. But that is exactly what the specification is about -- ensuring a choice of robust compliant container implementations which can be used to host your application components. And while EJBs aren't necessarily the hardest thing to ever come along in application development, I wouldn't so easily dismiss them. There is a _lot_ to know if one is to make effective use of the technology.
Perhaps a re-reading of some of the J2EE docs, including the J2EE Tutorial and the Patterns section of the BluePrints, will emphasize the breadth and depth of the technology. That is, if you are interested in learning more. The question ultimately isn't "Struts vs. EJB" but whether you intend to construct using "Struts with EJB" or "Struts without EJB". Both are possible. Both are valid. Both have pros and cons. Each may be a valid (or invalid) architectural decision depending on the problem and environment. Best regards, Jim Cakalic > -----Original Message----- > From: Kousek, Theron [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 15, 2002 11:18 AM > To: 'Struts Users Mailing List' > Subject: RE: Struts vs EJB, thoughts? > > > > > As for whether EJBs is going to be required in the near > future for you > > to get a job, who's to say? > > Sadly, companies are very biased towards people who don't > have specific > product experience in many cases. Don't take this the wrong > way but EJB's > are not all that difficult. I have read a book on them and tried some > things with the reference implementation. No big deal. So > you have a home > and a remote interface. So you have session beans (our > struts Java beans > are basically the same thing), entity beans (We wrote a bunch > of db-bind > classes to be used within our struts application to perform this) and > message beans (I used JMS in cases to simulate message > beans). Ok... So > why do so many companies discredit individuals who lack a > specific product > experience even if they have decent OO skills? :-) A > friend of ours who > has done EJB for a year says EJB's are very easy. What's difficult is > understanding how they all work together. But that's OO and > not EJB. I > guess since this is an Employer's market (at least in the > Phoenix and Denver > area), they can put tight strict requirements around. Heck, > we'd love it if > our employer would buy an App Server but they won't so we're > using Struts > since it's free. But we've found out that it's very powerful > and very easy > to work with. > > thanks for your insight... > > Theron > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> >
