Mark Mynsted wrote:
> > EJB is like XML...a big fat buzzword that people try to throw at any
> > solution without really analyzing *why*. I wonder how many people have
> > purchased an EJB server from one of the big companies and then figured out
> > that not only was it to much trouble to use, but also was the wrong solution
> > to the problem. I bet you that it is quite a lot.
>
> Oh I do not know... A CTM (Component Transaction Monitor) sounds like the natural
>solution to address the weaknesses in ORBs, i.e. transactions, security, persistence,
>and resource management. It seems quite possible to me that many companies have
>created a fair infrastructure on top of CORBA implementations then need to come up
>with home grown solutions for security, persistence, etc. as they expand..
I did read some stuff from IBM concerning how they use CORBA months ago. As I
understand it CORBA is a solution to a different problem to EJBs. CORBA is used by
IBM consultants as a legacy connectivy technology. They sort of advocate CORBA as a
method by which old legacy codebases and servers can continue to be used in tandem
with more modern langauges.
I wouldn't say that this (original?) use of CORBA is really replaced by EJBs.
I don't claim to be an expert but I have a theory about EJBs... please feel free to
disagree..
Transactions are a technology that is absolutely neccessary for order processing
systems. These are used in call centres which are created by companies with loads of
cash. In the nineties there seemed to be a lot of competition about transaction
throughput in the database market - and tons of cash from call centres et al. to pay
for RDBMS development. I sort of think that there is a lot of investment now
in creating web-based apps with that kind of archetecture. Kind of 'deep'.
It's sort of natural to want to keep your transactional components close to the
database. So, you start running them in the database (stored procedures). You can only
efficienly go on adding complexity for a while before the volume becomes too great for
the server, plus the rules become too complex for the languages you code this stuff
in. So, you start coding middle-tier objects that are transactional
but can be placed on servers that are close to the database. I believe Oracle have
stuff like cartridges (?) and MS have stuff like MTS (now) to do this type of thing.
It took people a while to work out good ways of doing this, and once they did,
suddenly everybody's doing distributed middle-tiers - even when there is no great
design justification.
So, in order to take advantage of java (which has certain advantages in this kind of
situation) in this context (and so sell even more high-powered solaris servers) sun
has developed EJBs. And they are right. They allow you to start with a small server
farm running on cheap OSs and then as your order processing system gets ever more
complex and the demands ever greater, it *should* be much easier to scale
up.
I sort of suspect that for most other types of application the bother of actually
using distributed transaction isn't worth the cost of implementation. I sort of think
of these application are 'wide' in their data access structure rather than deep.
(There are probably applications which are wide and deep but they are so big that
they'll never get finished ;-)
Having said all that, I do agree to a certain extent re:EJB being better than
home-grown archetectures. In certain kinds of application, there comes a time when you
need technologies like EJB. (That's exactly the experience that my brother's company
had.)
robert
>
> Am I misunderstanding who is buying EJB servers, or what an EBJ server is?
>
> But I agree with you. It seems to me that companies frequently buy great solutions
>to the wrong problem.
>
> >>> Jon Stevens <[EMAIL PROTECTED]> 10/10/2000 5:10:47 PM >>>
> on 10/10/2000 3:01 PM, "Robert Burrell Donkin"
> <[EMAIL PROTECTED]> wrote:
>
> > That is the question...
> >
> > I'm sort of interested in the general achetecture. It seems to me that EJB
> > might be a technology which could be leveraged to
> > implement but I have a feeling that EJB archetectures lend themselves to
> > 'deeper' middle-tiers rather than flatter ones.
> > (Still, I don't claim to be an EJB expert, so hopefully if I'am wrong some one
> > will correct me.) You need a declarative
> > system - one where you can concisely specify the tables-structure you'll be
> > running against. The table-structure (at least
> > for the types of application I'm talking about) should to certain extend
> > specify the structure of the data to be posted.
> >
> > I had the intention of looking into some more concrete stuff about this but
> > (due to circumstances I don't want to go into) I
> > don't think I'll have the time to do so anytime soon.
> >
> > I am still interested in archetecture questions but I can't claim to have any
> > concreate answers...just questions...
> >
> > robert
>
> EJB is like XML...a big fat buzzword that people try to throw at any
> solution without really analyzing *why*. I wonder how many people have
> purchased an EJB server from one of the big companies and then figured out
> that not only was it to much trouble to use, but also was the wrong solution
> to the problem. I bet you that it is quite a lot.
>
> :-(
>
> -jon
>
> --
> http://scarab.tigris.org/ | http://noodle.tigris.org/
> http://java.apache.org/ | http://java.apache.org/turbine/
> http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
> http://www.collab.net/ | http://www.sourcexchange.com/
>
> --
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://java.apache.org/main/mail.html>
> Problems?: [EMAIL PROTECTED]
>
> --
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://java.apache.org/main/mail.html>
> Problems?: [EMAIL PROTECTED]
--
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
