radioAe6rt

For JXTA apps built around formal JXTA net.jxta.service.Service’s, one grows weary in the application code of looking at the various newAdvertisement() calls used to construct the modclass, modspec, and modimpl advertisements. Moreover, when the number of services begins to grow with the application, cut and paste of existing advertisement creation code becomes error prone - and looking at the proliferation of newAdvertisement() calls becomes even harder on the eyes and aesthetics.

Here are code excerpts that simplify creating new Service’s, which take XML input and produces a singleton class that returns the various formal services by string tag.

The services.xml file describes your app’s Service’s and is created lovingly by hand. Notice in the code how formal JXTA net.jxta.platform.Application’s are identified by an isApplication attribute in the service XML element. This attribute ultimately forces that same Application instance to be inserted in the “applications” hashtable associated with the subgroup and therefore to be loaded after all the formal Service’s are loaded when your application peergroup starts up.

The application utility Services singleton, and supporting code.

Unfortunately for purposes of this discussion, my utility Services singleton has a name very similar to the same unqualifed name as a formal JXTA Service. See the code for the utility fully qualified package name. Names, names.

Your app will have the usual block like this during the run-up to instantiating the subgroup, a block that relies on the code above, wherein

vices = Services.getServices(is, implAdv);

initializes the singleton. The utiltity code needs a little cleaning up, but one gets the idea.

When your app needs an instance of one of the JXTA Service’s specified in the services.xml file, do

beaconService = Services.getJXTAService(”beaconservice”, pg);

for peergroup pg.

Update: 10/15/2005: This Service helper code is now available in the JXTA Commons project .