Re: [Embedlets-dev] Global Light Blinker Project (approach JINI community too)

[Gregg G. W. <gr...@sk...>]

>One only needs a well known initial rendezvous address to bootstrap a
>PeerGroup.  After a PeerGroup is bootstraped the PeerGroup's rendezvous can
>dynamically scale up and down in number and move around.  If all of the
>rendezvous in a PeerGroup would somehow drop offline, the Peers themselves are
>designed to fire up their own Rendezvous services in order to keep the
>PeerGroup online.  Beyond this, Rendezvous can even be situated behind
>firewalls and NATs.

There are of course scenarios where all the relay and proxy mechanisms can 
breakdown and create failure.  This is what you have to recognize about 
distributed systems.  This is why Jini uses leasing.  When partitioning 
occurs, you have to be ready to deal with it.

>The main server infrastructure that is absolutely needed on the open internet
>are JXTA Relays so that devices behind firewalls and NATs can participate in a
>PeerGroup.

But, this is not the be-all/end-all solution for participation.  There is not 
solution that provides 100% connectivity, that is just life!

>Anyway, I think that remotely controlling devices is unlike illegal file
>sharing where one is in danger of having one's servers shut down.  The cost 
for
>server hosting of Rendezvous and Relays is very reasonable and so I do not 
view
>this issue as being a major problem.

See the above two points.

>Agreed.  And the JXTA reference implementation already comes with the proper
>tools for creating world-community class UUIDs and so I am not too concerned
>about this issue either.  If this issue eventually does become a problem I
>think that the JXTA developers can be relied upon to come up with a solution.

Jini (and RMI underneath) and CORBA and many others have such concepts to aid 
in discovery and group isolation as well as participation.  It is a 'good' 
thing when everyone follows the rules.

It is interesting to note that MAC address allocation has never been free 
assignment, and one form of security in wireless networks is to specify 
allowed MAC addresses.  And you can specify your mac address using the 
advanced dialog of most network cards (wired or wireless).  In the end, UUID 
is a mechanism, but not a solution.  Certificates are a better step, but like 
anything that involves mathematical generation (the signature), they can be 
eventually compromised by the determined.  This we all know...

>> This is where you have to be careful.  JXTA provides protocols between JXTA 
>> clients that allow a proxy (of sorts) to interconnect them.  This is a well 
>> known architecture.  I have a proxy at my work location that an X-10 server
>> at my house (whose network is NAT'd) connects to.  My J2ME phone connects 
>>to the proxy which then provides the connecting pipe between the two 
'worlds'.
>
>Is the connection between your phone and your in-home proxy secure at the
>transport level (including over multi-hop networks) and also as the
>authentication level?  Can anyone who has the appropriate credentials securely
>log into your in-home domain from anywhere on the internet using any class of
>device?  JXTA 2.0 includes the technologies which are needed to do these 
things
>which is one of the main reasons that I am excited about it.

It is quite insecure, because I did not want to spend time on that issue 
without underlying support.  I could change the phone to use https and provide 
a password instead, and then make the proxy demand SSL and a password from the 
home machine to connect.  Now that Jini 2.0 has these things built into the 
RMI infrastructure, I can easily secure the link to the home.  The J2ME 
environments https is the easiest way to secure the phone to the proxy link.

>> There are many competing technologies working in the world of distributed 
>> computing.  JXTA is very interesting.  I'm on the Jini wagon because it 
>> provides the solutions that I need for the same types of problems. [...], 
and
>> in the end, the first technology to deploy the next killer application, 
>> may end up with the momentum to carry the lead...
>
>As people like Bruce Boyes can tell you, at JavaOne this year I expended a ton
>of energy trying to determine whether to go with JINI or JXTA.  After sitting
>in on most of the JINI and JXTA sessions, and asking developers in both
>communities where these technologies excelled and where they overlapped, I
>still did not have a good answer by the last day of the show.  I did discover,
>however, that the JINI and JXTA communities do not talk very much and this
>surprised me.

The reason is that they are not compatible technologies at the same levels.  
JXTA does not use RMI and is not designed to capitalize on Java's security 
model.  Jini is very much slanted in the direction of using solutions that 
have already be designed and implemented so that it can pivot on those 
technologies rather than spend time recreating them for no apparent technical 
gain.  There are always licensing, political and personal reasons that drive 
people to recreate technologies.

Does it strike you as strange that Bill Joy was involved in both Jini and JXTA 
development and introduction to the world community?  Read below...

>Thankfully, the last session of the last day of the show was about using JINI
>and JXTA together and during this session it all fell into place for me.  The
>presenter showed how JINI was operating at a higher level of abstraction than
>JXTA was and that a very reasonable thing to do was to use JINI on top of JXTA
>and to not worry too much about the levels where they overlap.

This is key.  They overlap in that they implemen many of the same technical 
concepts.  I believe that they deploy these technologies for the use of 
different audiences.  Jini is about exploiting mobile code with well 
advertized interfaces.  Jini pivots off of the RPC mechanism first defined by 
RMI.  Jini 2.0 greatly improves the RMI model with a new wire transport 
protocol that includes Authentication, Authorization, code verification, and 
pre-unmarshalling security checks to make sure that you only unmarshall 
objects from codebases that you expect.

JXTA is about exchanging information.  If you want to build services, you have 
a lot more work to do to create the services' programming model and to manage 
all kinds of issues.

One example for Jini/RMI vs JXTA might be an information search service (like 
google).  If I provide an implementation of a information search facility that 
is defined in a Java interface, I can decide in my implementation what the 
most efficient and effective transport, caching and security implementation 
is, and when you get the 'proxy', you don't have to know about that 
implementation.

In JXTA there is no code mobility. You have to implement these policies 
everywhere, or have a central server that implements some of these policies 
(local caching always has to be implemented locally), and then the 
applications have to know which version of the service to use to get the 
special services, and if the interface to those services changes, your 
specialized service breaks.

So, the Jini/RMI model brings the abstraction/compatibility level up to the 
code interface level, instead of at the wire protocol compatibility level 
where JXTA is positioned.

>I very much admire both of these amazing technologies and after attending this
>session I felt relieved about there being a good chance that they will
>cooperate in the future.

There is a JXTA protocol JERI connector implementation that has been discussed 
on the Jini-users list.  So, there are people thinking about how these two 
things work together.  What this would allow is for an RPC call to propagate 
through the JXTA network, utilizing its transport features.  This is an 
interesting concept, and could be interesting for a number of types of 
applications where NAT isolated systems need RPC calls to occur between them.

>Bringing the Embedded Java and 'Computer Science' Java worlds closer together
>is one of the Embedlet Projects stated goals and so including the JINI
>community in this project seems like a great way support this goal.

Well, I would return your question with a some counter questions. What do you 
want to enable the most with JAPL and Embedlets?  Do you want to enable all 
the devices to talk to each other?  Do you want to make it possible for 
non-java environments to participate at all levels and on all fronts?

Jini requires a slightly different mindset for the type of problem you talk 
about with the global light blinking business.  With JXTA, and no mobile code, 
people can easily open up all kinds of rendevous and they don't need to worry 
about security related to code.  With Jini, security has to be your first 
consideration in the design of your system because mobile code demands that.  
With JXTA, security doesn't become a concern until you get worried about the 
content of your messages, or if your messages are driving service actions.  
So, people have to do more work up front to make sure they have the security 
model that makes sense for mobile code, and then for user access...

This upfront work is usually what most people complain the most about when 
using Jini.  It requires thought and dedication to details.  This frustrates 
many people and the perils that result from the range of decisions that can be 
botched do make many belive that Jini is flawed or unproven.  You have to know 
what you're doing.  The Jini2.0 contributed implementation from Sun includes 
many examples of various types of security.  Reading is required and this also 
presents a barrier.  My startnow.jini.org project is a place where I have 
tried to start providing some abstrations and convenience classes that reduce 
what you have to learn.  I haven't directly attacked the security issues.  The 
sun provided examples provide some good starting points, as I said...

Now I am rambling...

-----
gr...@cy...  (Cyte Technologies Inc)