It is true that the EJB framework is all about transaction processing, and
that if you are building a more "real-time" service such as DNS... then EJB
is probably not a fit.
<vendor>
However this doesn't necessarily mean that the app servers that implement
EJB are not a fit! For example if you peel back the EJB layer from
GemStone/J, what you have is a Java 2 run-time, CORBA ORB, Persistent Cache
(OODB), JDBC connection pooling, security services, servlets/JSPs... Some of
these things are proprietary, but most are not. Many of our customers
program GemStone/J directly at the Java, PCA, CORBA layers...
</vendor>
Then again if you are smart you can build all this stuff yourself in Java.
Depends what business you are in!
-Chris.
> -----Original Message-----
> From: Yiwen Jiang [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, December 13, 1999 2:01 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Are we mad?
>
> Hi there,
>
> Thanks very much for the reply.
>
> > What's a "hard core" server vs. a business application server?
> In my own mind, "hard core" meaning DNS servers, DHCP servers, RADIUS
> servers, Network Management servers which controls and monitors LAN/WAN
> or telephone networks... it implies that the servers' performance is
> more of a concern comparing to portability. (This does not mean that
> they are not portable though, since one can write cross-platform
> application with little or none platform dependent code). But I may be
> completely wrong.
>
> Coming from writing various daemons on Unix, the EJB framework sounds
> too good to be true in my mind, and normally these approaches introduces
> performance compromises to accomodate its requirements.
>
> > It is interesting to note that about 1/2 the companies we talk to are
> folks
> > that started out building their own application server archtiecture.
> When
> > they approach the issues of scalability, fault tolerance,
> manageability...
> > they typically realize that this is a big job, and decide to buy rather
> than
> > build.
> I agree with you completely that the issues you mentioned is not a
> trivial job, but wouldn't you think that scalability and fault tolerance
> can generally be solved with a good design with or without the framework
> in place? In many occassions, these issues are different from
> application to application, and since the EJB framework offers a generic
> container class, I wouldn't suppose that the EJB framework can model the
> requirements for all applications at the system level without
> customization, if it is allowed at all (which leads to potential
> non-portability between application servers)
>
> > Note that some application servers support other models in addition to
> EJB
> > ;-)
> Yeah, but using that provides a non-"portable" framework, and tie the
> users down with a particular vendor, which is against one of the goals
> of EJB?
>
> I'm not saying that EJB is not a good framework, I'm just trying to
> figure out if there are specific types of applications that would
> benefit more out of using the EJB framework than others. I mean isn't
> there a range of applications where the benefit of using the framework
> outweighs the performance overhead for using such framework, and another
> range for the reverse?
> --
> Yiwen Jiang
> CRYPTOCard
> [EMAIL PROTECTED]
> Tel: (613) 599-2441 x245
> Fax: (613) 599-2442
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
