Jerome,
Various folks have spent a lot of time looking at the container portability
issue.
What I concluded is that we do not yet have enough experience with EJB
servers
to tackle the container portability problem without seriously compromising
the
functional capabilities of EJB servers. I think it is a good objective, but
let's
revisit it in about 3 years. Meantime, there is a lot of work yet to be
done in
fleshing out entity bean persistence, singleton EJBs, persistenct
associations,
and deployment.
Jim
Jim Rhyne, STSM, Legacy Modernization Architect
[EMAIL PROTECTED], 408 463 3013 TL 543, Fax. 408 463 2425 TL 543
IBM Corp. M80/E246, 555 Bailey Ave, San Jose CA 95141 USA
J�r�me Beau <[EMAIL PROTECTED]>@JAVA.SUN.COM> on 01/07/2000 04:13:54
AM
Please respond to [EMAIL PROTECTED]
Sent by: A mailing list for Enterprise JavaBeans development
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: State of the EJB Vision?
Basically, the goal of EJB is to view the business as EJB components and
the
technical stuff as standardized services provided by EJB containers where
such
components live (today this could not be always true, but this is the EJB
target).
So all your code - the code to be portable - is in such components, not in
the
container.
What you want to move transparently between servers is your business, not
the
technical services. So what you want is EJB component portability, not EJB
container
portability.
However it is true that container portability could provide additional
advantages
such as EJB technical services pluggability, i.e. plugging some third-party
EJB
technical service implementation (persistence for example) on any EJB
server.
"Kenneth D. Litwak" wrote:
> When I first took a course on EJBs I was told that the 2.0 spec for
EJBs
> would resolve the ambiguity between a container and aserver, so that you
could
> assemble an application in a container and sellthe whole thing, container
and
> all, or at least move it transparently between EJB severs. This was a
major
> part of teh EJB vision, a core piee of what makes EJBs a better
alternative than
> just using an app server.
>
> I know others proably knew about his alrady, but I recently
learned that
> SUn has dropped this idea altogether becuase the EJB vendors won't play
ball.
> They refuse to allow a standard definition of a container or serer, thus
making
> container portability virtually impossible. This seems to me to be sucha
major
> loss to the EJB vision that I am wondering if what is left is sufficient
by
> itself. If I can't have a portable container, I'm not very far from
app-server
> specific code. So, thanks to the vendors, what's the compelling reason
to use
> EJBs now, if I can never sell you an EJB application that is ready to go,
> because it must be installed one piece at a time in a vendor-specific
container
> now?
>
> Ken
>
>
===========================================================================
> 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".
