You seem to be misinterpreting Rickards posts, so I thought I'd give
clearing the situation up a shot. You're not alone though, there seems to be
a lot of confusion in this thread (I hope I dont add to it), so here goes:
The proposal here (by Rickard, one which we at Orion as a vendor fully back)
is an API-based solution instead of a protocol one. This is where the
confusion seems to begin: What is an API and what is a protocol? How do they
differ?
First lets look at a protocol:
A protocol is not tied to code, it does not define methods, classes and
other code-related stuff. Instead it focuses on how two entities interact
over a serialized (usually) wire. An example of a protocol is HTTP.
Then there's an API:
Lets take a look at java.sql - everyone discussing this topic is probably
more thant vaguely familiar with this API. java.sql does not define *how* a
client talks to a database - rather it mandates how clients (being a client
does not imply not being a server too though mind you) interract with the
resourse/server via an API - methods, classes and so on. JDBC could have
been a protocol, if so it would have defined the way the client and the
server talks to the database "over the wire". So why isnt it? Why would that
be a bad thing? Well, lets go back to HTTP again (the protocol). Since both
endpoints have to agree upon the protocol it is hard to change it
(evolution). You cannot optimize HTTP to do something better (unless you're
MS - embrace and extend - but lets keep those aspects out of it for
simplicity ;). But with an API based solution the vendor (db vendor when
talking java.sql) can implement their protocol as they wish - it doesnt
matter and is completely transparent to the client endpoint. This way you
get an "as good as possible" protocol when talking to the server and
evolution is simpler.
So? What about EJB? Well, we for one are in the API camp. EJB is so far API
based and should remain so as much as possible. We believe that the
"complexness" of having to install an EJB driver on your client (client
could be another EJB server - a client to the service) is a small point
compared to the benefits in failover, performance and other areas. You get a
decoupled architecture where all the pieces can evolve seperately. That said
we also want IIOP standardized - there are places where a protocol makes
sense (like non-java clients for instance) and for IIOP to be useful it has
to be more standardized in the EJB-context than it currently is. That said
we dont think it should be *required*. The current J2EE (of which EJB is a
part of) describes possible J2EE server impls as ranging from the extremes
of everything being distributed to running everything (including client,
http etc) in one VM. The latter case doesnt even *need* a wire protocol at
all and that should remain the case it's up to us.
So, to sum up:
Define a clear API for EJB interraction (the Connector arch, JNDI API and
JAAS API should provide a good base for this).
Standardize IIOP for exotic clients/legacy systems (important, going for an
API based solution for server interop does not make this less important, it
still has a use
for client connectivity from non-java/3rd party clients).
Do not make IIOP a required item (and no, this is not a personal interest
opinion - we are in the group that will support IIOP as a protocol - but it
still shouldnt be required, no distribution whatsoever should be (besides
VM-local distribution which is automatic)).
Comments are welcome.
/Magnus Stenman, the Orion team
http://www.orionserver.com/
PS. There also seems to be some confusion regarding RMI in general, so:
RMI is an API.
JRMP is a protocol.
IIOP is a protocol.
T3 (weblogic) is a protocol.
ORMI (Orion) is a protocol.
(RMI needs a protocol to operate, chose any of the above or another one -
which one you chose is not specified by RMI though)
----- Original Message -----
From: "Arkin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 22, 2000 5:42 AM
Subject: Re: Does IIOP Matter !!! READ THIS !!!!!!!!!!!
> What Rickard is promoting is a way to not do propagation. Instead the
> EJB server sends a stub to the client and the stub takes care of that.
> This is a nifty cool RMI trick, but IMHO an implementation detail.
>
> The way IIOP deals with it (as well as SOAP, DCOM and other protocols)
> is through the wire. Whether your stubs do that, or someone else
> generate and use their own stub and pass it on the wire is an
> implementation detail.
>
> arkin
>
> > > The difference between my suggestion and yours is that with mine there
> > > is nothing to agree upon. I propagate it my way, and everyone else
uses
> > > their own way. I really don't care how others do it.
> >
> > Can you clarify how others could interpret your contexts if you use your
> > way of putting them onto the wire and everyone else uses theirs? i.e.
> > how would another server know how to examine your contexts?
> >
> > cheers,
> >
> > j.
> >
> >
===========================================================================
> > 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".
>
> --
> ----------------------------------------------------------------------
> Assaf Arkin www.exoffice.com
> CTO, Exoffice Technologies, Inc. www.exolab.org
>
>
===========================================================================
> 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".
