"What the hell were they thinking back then?" Back then - this is now -, the
idea is to offer interoperability to customers that ask for secure and
transactional cooperation between the EJB 1.x servers they use.
Today, give me the list of interoperable EJB 1.x servers, and I will use them.
I will buy licenses for both product and support and then invest my time in
developping the best EJB 1.x application I could.
When EJB 2.x becomes mature, give me the list of interoperable EJB 2.x servers,
and I will use them for new projects. However, I would most probably ask you
the list of EJB 2.x servers that are also interoperable with the currently
interoperable EJB1.x servers. The obvious reason is that, at that time, those
new EJB servers would also have to cooperate in a secure and transactional way
with my already deployed EJB 1.x applications. I'm not going to throw away all
those license fees and man-days just to get the latest toy in one part of my
architecture.
Of course, I could redeploy everything on the new EJB 2.x servers you give me,
but being careful, I would certainly prefer to migrate my EJB1.x applications
piece by piece. And if the EJB 2.x architecture is too much different from the
current EJB 1.1 architecture, I would have to consider my EJB 1.1 applications
as "legacy".
So, "What the hell were they thinking back then?"
(a) - EJB interoperability
(b) - EJB legacy integration / upward interoperability
Feel free to implement that with downloadable smoke signals and pass-by-value
embassies; I don't care. As long as you meet point (a) and (b), I am your happy
customer.
Regards,
Christophe.
Rickard �berg wrote:
> On Thu, 13 Apr 2000 12:44:49 +0200, Christophe Warland
> <[EMAIL PROTECTED]> wrote:
> ><customer>
> >I would like to point out a fact, which was surprisingly not stated
> >before:
> >(1) - with IIOP and EJB1.1, I can have interoperability today;
> >(2) - with an API-based solution, I will not have interoperability
> >before EJB2.0 is out and correctly implemented (mid 2001?).
> >From a customer perspective, I clearly choose (1) over (2).
> ></customer>
>
> I absolutely understand this. And you are free to use IIOP as a means to
> do interop. today.
>
> However, if we today choose between two alternative ways of doing this,
> and in the future we come to a point where IIOP is the limiting factor
> in that it is not capable of doing what we want, then we will most
> certainly think "what the heck were they thinking back then??".
>
> IMHO choosing an API-based solution (which will still allow IIOP to be
> used!) is more "future-compliant" than choosing a wire-protocol, which
> is "easier" but dumber.
>
> To compare with email, the basic text email (~IIOP) has worked fine for
> a long time and still does, but we would have been extremely frustrated
> if the email inventors had not designed it with "future-compliance" in
> mind and introduced MIME-based attachments that can do video and voice
> messages (for example).
>
> The same reasoning applies here: IIOP "works", but why constrain the
> possibilities for innovation in the future? (and with "the future" I
> mean "next year or so")
>
> /Rickard
>
> --
> Rickard �berg
>
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> http://www.telkel.com
> http://www.ejboss.org
> http://www.dreambean.com
>
> ===========================================================================
> 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".
