JXME Platform Configuration

Today I am tackling platform configuration. I decided that to address configuration early on and avoid the pain later on, when JXME/CDC is ready prime time. To give a little background on PlatformConfig :
PlatformConfig is JXTA Advertisement (XML Document) which identifies, and describes how a platform instance is configured. A PlatfromConfig is read in at runtime by the platform and services, and transports are configured according to the defined service parameters. PlatformConfig defines the following:
  • PeerID
  • Meta-data about the peer (name, description)
  • Core Services and associated configuration (which also happen to be Advertisements as well)
  • PSEConfig advertisement contains peer certs
  • Service Elements which define a service ID, along with a advertisement defining the service parameter
  • TransportAdvertisement representing TCP, HTTP, etc. which defines transport parameters
  • Core services (Rendezvous, Relay, Proxy, etc.)
So here's my line of thinking, the platform provides a built in lite XML parser, and better yet it also provides bindings to the aforementioned advertisements, I don't see a reason to use an XML parser directly, nor the need to define another XML configuration representation. A simple configurator factory can leverage those bindings to generate a PlatformConfig, as well as provide static methods to retrieve/update platform service objects.

Posted on: May 04, 2005

Posted by: hamada

Category: jxta

Tags: none

Permanent link to this entry

Comments:

Even though JXTA J2SE and JXTA-C both use PlatformConfig and both use it in a similar way I don't believe there's a requirement that it be used for every JXTA implementation. <p/>Since JXME is likely to support a much more limited set of configuration parameters than used by the other JXTAs. (PSEConfig in particular being unnecessary--JXME should use only the certs in the SIM if available). It's not that a JXME implementation is less capable than the others, but it will have probably have less need for configuration. This is a good thing. The more that JXME can figure out on it's own without needing intervention the more successful as an API JXME will be. <p/>So what does this mean? Maybe an XML configuration file isn't needed. It could be that configuration for JXME could be done through a handful of system properties. It would be great to have a list of the individual configuration parameters and then think about the best way to encapsulate them.

Posted by Mike Duigou on May 04, 2005 at 02:24 PM PDT #

I agree I don't expect that we need to add support for all of the services (PSE being one as point out). Configuration still needs to be persisted in support of restart, etc. This data of course can be represented in some other form, however I tend to shy away from creating yet another way to represent a platform configuration, I would rather maintain consistency.

Posted by Mohamed AbdelAziz on May 04, 2005 at 02:35 PM PDT #

Post a Comment:
Comments are closed for this entry.

This blog copyright 2009 by hamada