Rickard �berg wrote:
>
> Ok, now I am beginning to understand what you're trying to say. You're
> describing what's on the two endpoints. I believe you have missed an
> important point. To begin with, you should read the Jini article which
> explains how the sending point gets the wire-protocol implementation
> from the receiver. Once you have done that it should be clear what I am
> proposing.
The article Ricard refers to is titled "End of Protocols" and was written
by Jim Waldo, the Lead Architect for Sun's JINI project. A copy can be
found at the following URL:
http://developer.java.sun.com/developer/technicalArticles/jini/protocols.html
>
> You're doing the same mistake as Inprise: not seeing the forest for all
> the trees. There's no need for a wire-protocol. You only need an API to
> get the information.
>
Strong agreement here. As long as the client and the service agree on the semantics
of their API, the protocol they use to communicate is an implementation detail.
IMO, JINI's notion of a Lookup Service is a very useful one. The general idea
is that a service definition consists of an API (Java Interface) and a set of
properties that describe properties of the implementation. BTW, one of these
properties *might* be used to identify the protocol, for cases where efficiency,
security, or reliability considerations might make one protocol a better choice
than another for a particular API.
JINI Servers register their services with the Lookup Service (in a similar way
that EJB Servers register EJB Home and Remote interfaces with JNDI). When
a client needs to locate a service, it sends a request to the Lookup Service,
specifying the API it needs and the property value constraints it needs (some
subset of the available ones, null is interpreted as don't care). The JINI Lookup
Service finds the set of registered servers that support the API, and uses the
client-specified Property constraints to determine the subset that qualify.
Personally, I think this model is a major step forward over the namespace-oriented
JNDI model, and I, for one, would love to see the EJB spec find someway to
support the JINI service model.
Charlie Alfred
===========================================================================
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".
