Nesting

General Intent

Very early on it appeared that it would be usefull to have groups support a hierarchical organization. The primary reason I saw for that was the following:

Now, how this nesting can be played out in the real world is not all that clear, because each group may define different boundary rules for various kinds of object. For example, discovery, rendezvous, and resolver services define the boudaries (and possibly the horizon) of publications, while pipes and resolver defines the boundaries of communications. On top of that, Membership and encryption may apply more restrictions or not, etc.

One may well imagine, for example, a group A that is being instanciated inside a group B, but does not depend upon B for anything other than inheriting its transport bindings. Then, is it realy a sub-group ? With the endpoint code as it is today, an instance of group A within group B can probably open pipes with an instance group A within a group C. It probably is not an issue for group A, but it could be an issue for group B or C, since their membership policies can be betrayed by such a bootleg gateway. On the other end no-one can stop a group member from betraying the group, be it by running an implementation of JXTA (not approved by the group) which permits such betrayal, or by making a Polaroid of one's own screen showing group-confidential information :-).

Another aspect of nesting that's not quite satisfactory: nesting as a way to provide special services. Imagine that someone comes-up with a nice propagation service that depends on the cooperation of many peers (say a distributed calculation framework). Every group that whishes to leverage it may grab the code and incorporate that service, but only the members of each group will be participants in the calculations for that group. If a group A wanted to take advantage of very large community of volunteers calculators, that group would have to be a subgroup of a larger group composed of these volunteers. Let's say it exists and that's group B. Then, what happens if some-other great community-based service is created as a different large group, say group C ? If group A wanted to leverage both communities, group A would have to be both a subgroup of B and a subgroup of C. With a pure hierarchy this is not possible.

The only way to solve that is to generalize the is-a-subgroup-of relation to a depends-upon relation. I think it would remove a not-too-effective security feature but add a very effective cooperation feature. Besides, the code currently does not enforce the strict hierarchy for many other practical reasons. So, it seems that we just need to think of how applications and groups can best take advantage of using multiple groups and weither some hooks are needed to allow placing restrictions on it, if needed. I believe that both modes are valid: pure subgroup, which can have no existence outside of its surrounding group, and "client" group, that uses one or many other groups but exists as a separate entity, but I'd have to check if there's enough in JXTA right now to let group creators chose which way they want to go and have some control over it.

Transport

One of the consequences of the choice of encapsulating the whole API in the group is that transport bindings are, at leat in theory, a per-group feature. However, since it would be rather impractical to have each group use its own version of, say, a TCP binding with its own port number etc, we came up with the following trick: The endpoint object of a group (which contains these bindings) may be shared by descendent groups, thus giving it direct access the the transport bindings of the underlying group. The other side of that coin is that each group may define its own transport bindings, which do not exist in the underlying group. To enable that, a group just needs to create its own transport object rather than using its parent group's one and add this new transport to it. The transport bindings of the parent group will be available as well.

The intent here was to make it possible to define such things as a grapevine kind of transport, which would route messages from peer-to-peer by making use of the existing pipes and transports in the underlying group. As it happens routing was too badly needed to wait for such a thing to be developed and so, Eric wrote a router and put it straight in the generic endpoint code. On the other-end alternate methods for moving messages around can also (and sometimes better) be defined as new services such as JXTA-wire does, so, may be disguising this kind of thing as a transport might not be very usefull.

The reason I brought that up, is that it has some impact on the issue of running multiple sessions on one host. Because transports are a group feature, it is not easy to re-organize the code so that transport bindings can be local servers shared by multiple instances of JXTA assuming that's something we have to support; see the other issues.



Jean-Christophe Hugly