Of course it does support transactions ! And this doesn�t make JINI any
similar with EJB.
[]s,
Flavio.
> I'm not sure what you guys mean when you say "Jini is a non transactional
> distributed architecture..." Jini does support transactions.
>
>
http://java.sun.com/products/jini/1.1/docs/api/net/jini/core/transaction/pac
kage-summary.html
>
> -M@
>
> --
> Matt Hixson
> Aventail Corporation
> Seattle, Washington
> www.aventail.com
>
> On Thu, 23 Aug 2001, Winston Gnananayagam wrote:
>
> > <victor>
> > JINI is a non transactional distributed architecture and JDO is a non
> > distributed data model. They only seem parallel if you don't look very
> > closely.
> > </victor>
> > <response>
> > Yes, Jini is a non transactional distributed architecture, it is
meant
> > to be that way. Otherwise it will become very similar to EJB.
Transactions
> > are very costly to be maintained by the containers, moreover some
> > applications don't need transactions. Transactions can always be
implemented
> > by other means, if needed.
> > Why does anybody want to distribute their data model. Aren't they
> > already making a remote call to an RDBMS/ODBMS. Isn't it already
> > distributed??
> > Anyway, I wasn't saying EJB is not needed at all. It has its own
place
> > in any architecture. But, it definitely is not the holy grail. At some
point
> > we need to also look beyond EJB for something that works.
> > </response>
> >
> >
> > ----- Original Message -----
> > From: "Kevin Gaasch" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, August 23, 2001 4:24 PM
> > Subject: Re: [EJB-INT] Decline of the EJB civilization?
> >
> >
> > > The question is not EJB v. JDO v. JINI. These technologies are not
meant
> > to
> > > compete with each other. As many have said before, no one solution
will
> > > work in all cases. You make the decision to use EJBs, JDO, or JINI,
or
> > any
> > > other technology in the analysis phase of a project, not in the
> > > establishement phase of an IT architecture. There is no reason why
these
> > > technologies can't be used in conjunction within one IT shop. And
don't
> > > forget that EJB is not a stand-alone techology. It is a part of the
J2EE
> > > architecture. EJBs will most certainly not be the best persistance
option
> > > when used alone. But, when you use them in concert with the rest of
the
> > > J2EE APIs (JMS, JNDI, J2EE Connector, etc) and the benefits of using
the
> > > J2EE container, they can be a powerful set of tools. If all your app
> > needs
> > > is persistence, then you probably should not use EJBs. Developers
must
> > > remember, use the technology that best suits your project, don't force
a
> > > technology on a problem domain where it is not suited.
> > >
> > > Kevin E. Gaasch
> > > Java Consultant
> > > Canyon, Texas
> > > Home: (806)655-6460
> > > Work: (806)324-4100 x4215
> > > Cell: (806)674-1523
> > > email: [EMAIL PROTECTED]
> > >
> > > -----Original Message-----
> > > From: A mailing list for Enterprise JavaBeans development
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Winston Gnananayagam
> > > Sent: Thursday, August 23, 2001 3:06 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Decline of the EJB civilization?
> > >
> > >
> > > I think this discussion is going more towards whether
developing
> > > applications on Open source products is better than Commercial vendors
or
> > > not . Well, this has been an age old debate since MS Vs. Linux.
Probably
> > not
> > > a discussion for this forum.
> > > Well, to think about the core issue of the suggested article,
yeah
> > I
> > > would agree that EJB has been hyped a lot without delivering much on
its
> > > promises. Managers, Architects, Developers, all of them seem to have
> > fallen
> > > into those sales pitches(including me). If Managers made the mistake
of
> > > buying those costly products not knowing its capabilities, then
developers
> > > have fallen into the trap of making design decisions on something that
> > just
> > > does not work or has been a nightmare just to maintain it(E.g.. Entity
> > > Beans). Much had been hyped about the capability of the EJB container
and
> > > things it can do with Entity Beans. Today we see EB's as too
> > > complicated/bloated to use or to maintain it and also is a major issue
in
> > > the applications performance. I'm not saying that EJB is a useless
> > > technology, but just that its capabilities have been hyped a lot.
EJB's
> > need
> > > to be used cautiously, its not a one solution fits all(as its hyped,
to
> > milk
> > > money out of corporations).
> > > Most of the applications today seem to use Session
beans/Message
> > > Driven Beans, to make some of their critical code to be distributable.
> > Other
> > > than that its plain old Servlet/JSP/JDBC. Look at those 100s of design
> > > patterns dedicated to EJB's. Seems like we need a separate design
pattern
> > to
> > > just use those 100s of patterns. I guess today, developers are saying
> > > instead of implementing all those patterns, just make a freakin JDBC
call
> > > :-) To do just that , it doesn't make sense to pay all those money to
buy
> > a
> > > costly application server.
> > > Btw, why is Sun coming up with parallel technologies to EJB
like
> > > JINI, JDO among others??? Yeah maybe the EJB civilization is
declining.
> > But,
> > > don't worry in few years we would be discussing this same topic about
a
> > > similar technology on a different forum.
> > > Winston.
> > >
> > >
> >
===========================================================================
> > > 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".
> >
> >
===========================================================================
> > 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".
>
===========================================================================
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".