Monday, April 25, 2005

 

Sharing my experience in working with the PSEMembership

Introduction

This posting is an ad hoc set of personal comments about the experience I've had so far in using the PSE Membership. It refers to the previous posting as for the goals and steps that I am trying to follow.

All right, let's start, readers, please don't be too upset by what below. I'm not an expert SW engineer, so It may be inappropriate for me to post these comment, but I just hope it helps ...

Comment 0.0:
It may have changed, but the building of the JXTA platform is a little funky. There is no way to compile the platform with Eclipse for instance as some java files (for monitoring if I recall) are generated by the JXTA build.xml ant file. The only way to build the platform is to use the JXTA ant file. So I need to use the jxta.jar library when developing my application. That is fine until I need to look into the JXTA platform source code. I can't do it from eclipse, I need to use another editor for editing the platform source code.

Comment 0.1
Again, it may have changed, but on the www.jxta.org web site front page there is no link to download.jxta.org which was confusing when I first tried to get the binaries of the latest stable release. If you want the latest platform "you've got" (again not really, but a link to "download.jxta.org" is hard to find) to get it through CVS which could discourage some users.

My Experience with PSE

Generating and signing certificates.


Step 1 through Step 2.2 were no problem. Creating a Self signed Certificate Authority, certificate Signing Request, and actually signing them, checking signatures is actually fun !
I used JXTA FileKeyStoreManager, and PSEUtils classes to manage my CA as well as my "Super Peer" keys and certificate chain. I got a big help by looking at the pse.* command of the JXTA Shell. It really helped. Thanks to the JXTA community for suggesting it.

Comment 1:

I would just regret that JXTA does not follow any standard as to the use on the X509 Distinguish Name. At least JXTA should document its use of the Certificate fields such as its use of JXTA ID within the DN, or the forced appending of "-CA" .

Generating and the SAXTA Peer Group and Peer group Advertisement.

I actually under evaluated the time I would spend on that task. Since I had experience with "custom" peer groups and ModuleImplementation, I though I had an advantage. I'll have the following comment on my experience in doing so:

Comment 2:

My vision of the JXTA platform is that it provides some JAVA Abstraction to the JXTA XML protocols. Specifically, the platform is a layered application which upper layer provides fully object oriented and abstracted view of the JXTA concepts. I actually would consider the JAVA platform to have about 4 different abstraction layers (From higher to lower):
Each layer is "self contained" and provide a specific representation of the JXTA protocols. The higher the level, the most abstraction and ease of use. The lower level, the most thing that is left to be managed, but also the more flexibility. Naturally there are some junction points between 2 consecutive layers. For instance, you can switch from Peer Group and Peer Group Advertisement there is peerGroup.getPeerGroupAdvertisement() and a newGroup (peerGroupAdvertisement). I understand that JXTA would not consider a good practice to the mix of layer such as newGroup (peerGroupStructuredDocument).

However I have not been able to do otherwise while assembling a MembershipModuleImplAdvertisement. I have not seen a work around to the following syntax:

certificateMembershipModuleImplAdv.setParam((Element) certificateGroupParamAdv.getDocument(MimeMediaType.XMLUTF8));

Comment 3:

I personally am not found of having a "null" value being a valid in a method. For instance, I am not found of the following type of syntax: peerGroupDiscoSvc.getRemoteAdvertisements(null,DiscoveryService.GROUP,null,null,1000);
or
peerGroupDiscoSvc.getLocalAdvertisements(DiscoveryService.GROUP,null,null);
For the least it forces the user to look into the javadoc to try to figure out what are these parameters to learn that a null value is acceptable as default. More often that not, it also makes the user look into the source code itself to try to get an answer.
Comments:
Re: Comment 0.0:

Indeed it is unfortunate that it's not possible to build JXTA "out of the box" without running the Ant build.xml or Makefile at least once. We've thought about adding a default configuration for the metering files, but worried that this might be confusing when someone wanted to change the configuration. (Mostly that they would should up as CVS modified files).

Comment 1:

Regarding the use of -CA. This is intended to reflect that the key is self signed. I've seen it used in other cases but I've never been sure where it's recccommended as a standard.

One thing to keep in mind is that the PSE is designed to be used with certificates from ANY source, not just the ones created by default. I've wondered about how best to document what JXTA does when it's not the same as what JXTA requires.
 
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?