On 6/21/05, Anto Paul <[EMAIL PROTECTED]> wrote: > On 6/21/05, David Johnson <[EMAIL PROTECTED]> wrote: > > To expand a bit on Richard's note ... > > > > On Tue, 2005-06-21 at 00:32 -0700, Richard Mixon (qwest) wrote: > > > - Remoting implies distributing your objects across the network - a > > > nice feature, but not often needed. Its talked about a lot - but for > > > most applications its just not needed. > > > > J2EE is a standard that encompasses a large number of standards > > services, most of which are considered optional. JMS, for example, is > > not implemented in any commercial server directly. Instead, you must > > purchase a messaging system such as MQ series, (generally) a JNI wrapper > > code to talk to the message service, and a JMS wrapper that goes with > > the messaging system. This all plugs into the app server as a set of > > JAR files and a couple of native libraries. > > > > JTA is an extension that, likewise, is optional and pluggable. From my > > exposure, it also appears to be largely an evolving standard, in the > > sense that some of the things you would expect to support JTA don't > > quite do so. > > > > > - Our Hibernate-based Tomcat application use Hibernate and jta.jar > > > for > > > transaction services and it works quite well. We have most of the > > > advantages of declarative transaction demarcation. > > > > Hibernate demonstrates why EJB is an optional part of the J2EE > > specification. It is fully reasonable, during product design and > > exploratory coding, to unplug one persistence model and replace it with > > another. In the case of hibernate versus EJB 1 and 2, enough people did > > this that Hibernate has effectively displaced EJB's in much of the > > industry, and Hibernate is now the core of the EJB 3 specification. > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > There is no meaning in saying that one can plug in required > services to Tomcat. My question is by design is it an application > server ?. My opinion is that Tomcat in the shipped form is not an > application server. At the minimum it should provide transaction and > persistence services, method level security is also preferred. > One can add all the above mentioned features to any servlet engine > by deploying JAR files of the required services(JNDI,JTA,persistence > and even EJB). So any servlet engine becomes an application server. Am > I right ?
I think you are getting your terms mixed up... Your arguments could be used in regards to a full J2EE container, which Tomcat isn't on it's own but an application server just needs to serve applications and Tomcat certainly does that. Regards, -- Jason Bainbridge http://kde.org - [EMAIL PROTECTED] Personal Site - http://jasonbainbridge.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
