On Dec 20, 2008, at 8:12 PM, Niclas Hedhman wrote:
On Sun, Dec 21, 2008 at 12:33 AM, Michael McGrady
<mmcgr...@topiatechnology.com> wrote:
The same is true of the architecture of the Web. Note that the
Internet is defined solely by documents of various protocols: TCP/
IP, HTTP,
etc. Lookup is not included.
Go read RFC-2165 and all the related ones. Then come back and say that
IETF is not concerned with Service Lookup. It is a different topic
whether Jini should now use SLP or not, but AFAIU SLP wasn't around
when the Jini team started out...
I wasn't thinking of LAN protocols or the IETF, but ......
(A) What the IETF is concerned with and (B) what I talked about, viz.,
the Internet architecture, are two different things. In fact the
Internet architecture is what makes IETF possible. So, to try and be
clear, I
will
spend
a little more time on this than most of you probably will like or
need. I just want to be clear so we can work together to close off
some of these things hopefully in happy accord.
The Internet's distributed nature of routing information and
memoryless forwarding is critical to its operating without central
control or direction. A decentralized development structure matches
this decentralized architecture. No body has the power to issue or to
enforce standards on the Internet.
The IETF is not like any other standards body I know about. The IETF
allows for collaborative development because the Internet is a
collaborative architecture.
Internet Levels
5. Web application, Others
4. FTP, SMTP, HTTP, Others
3. TCP, UDP,Others
2. IP
1. Ethernet, X.25, HDLC, Others
The IETF, fundamentally, uses this Internet collaborative structure to
adopt standards that have already been developed and deployed on the
Internet. IP-Phone, for example, was developed and deployed without
any cooperation from TCP/IP developers or ISPs. We are free to use
this standard or to do what we like. Whatever we do, collaboration is
required to make it work.
I think this is correct and, if not, stand ready to learn. But, if
so, I think what I said about the Internet was true. (See The Art of
Systems Architecting, Maier and Rechtin, on collaborative
architectures.)
I think that you are confused over the terminology used here.
JavaSpaces' take() operation has nothing to do with lookup.
Not sure why you thought or seem to think that I thought take() had
something to do with lookup.
JavaSpaces API-wise has dependency on;
- Entry Specification
- Transaction Specification
- Lease Specification
(maybe something else I forgot)
And I agree with Dan, Gregg and others that this is architecturally
sound. Even Structure-101 agrees to a large extent (there are some
smaller mistake but nothing major).
I don't see any problem with JavaSpaces having a dependency on these
and believe it does.
And I think that your argument is that the above are Jini specific
specifications. They are developed by the Jini group, but most people
here would define Jini as "Discovery, Lookup and Join", and the 3
above ones are 3 pre-requisites that doesn't/didn't exist. So, the
argument at that level would be that these and other specs are much
more generic than Jini itself.
I agree with this. In fact this is pretty much what i have been saying.
Then the fact that JavaSpaces implementation here uses Jini under the
hood is not much stranger than 99.something% of all TCP
implementations uses IP under the hood.
In JINI, Entry is not used by JavaSpaces "under the hood", it and
other aspects are in the buyer's JavaSpaces API brochure.. It is in
the API, along with the following:
public interface JavaSpace {
Lease write(Entry entry, Transaction txn, long lease)
throws TransactionException, RemoteException;
long NO_WAIT = 0;
Entry read(Entry tmpl, Transaction txn, long timeout)
throws UnusableEntryException, TransactionException,
InterruptedException, RemoteException;
Entry readIfExists(Entry tmpl, Transaction txn, long timeout)
throws UnusableEntryException, TransactionException,
InterruptedException, RemoteException;
Entry take(Entry tmpl, Transaction txn, long timeout)
throws UnusableEntryException, TransactionException,
InterruptedException, RemoteException;
Entry takeIfExists(Entry tmpl, Transaction txn, long timeout)
throws UnusableEntryException, TransactionException,
InterruptedException, RemoteException;
EventRegistration
notify(Entry tmpl, Transaction txn, RemoteEventListener listener,
long lease, MarshalledObject handback)
throws TransactionException, RemoteException;
Entry snapshot(Entry e) throws RemoteException;
}
All these interfaces, I think, except MarshalledObject and
RemoteException (I know), should be part of a JavaSpaces package that
is separate from and independent of JINI. I will develop more
detailed arguments on why later, if at least we can agree this is what
I think.
So, architecturally speaking, I think you are on really thin ice,
and
that you are outright wrong about your assertions.
I think that my remarks on the Internet (which I was talking about)
and the IETF (which is a very different matter) might serve to bring
us into agreement. If not, at least maybe you now think I am not so
wooden headed.
Mike
