October 22, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Overview of JXTA

  • August 21, 2002
  • By Sams Publishing
  • Send Email »
  • More Articles »

Module Class Advertisement

A Module Class advertisement defines behavior. Peer groups, peer, and other advertisements reference a module class ID that is defined by the module class advertisement. The advertisement has the following parameters:

  • Module class ID (MCID)—Unique identifier used to reference the module class.

  • Name—Name of the module. Used for searching and identification. Not guaranteed to be unique.

  • Description (Desc)—Description used for searching and identification.

The following is a sample advertisement. This is the module class advertisement for the EX1 advertisement:

<?xml version="1.0"?>

<!DOCTYPE jxta:MCA>

<jxta:MCA xmlns:jxta="http://jxta.org">
  <MCID>
   urn:jxta:uuid-2584FEB44D3B40E9A16A8419C9ABE09F05
  </MCID>
  <Name>
   JXTAMOD:JXTA-EX1
  </Name>
  <Desc>
   Tutorial example to use JXTA module advertisement Framework
  </Desc>
</jxta:MCA> 

Module Specification Advertisement (Module)

A Module Specification Advertisement is the specification of a module. The advertisement contains information about the implementation referred to by a module specification ID. Because the code for a module is usually part of the peer application, there is no need to publish the advertisement for each ID, but it is a good practice to document the module via the advertisement. Each module has the following tags:

  • Module spec ID (MSID)—An ID that specifically defines this module.

  • Compatibility statement—An XML specification used to define the compatibility of the code to a language and version.

  • Name—Name of the specification.

  • Description(Desc)—Description of the specification used for searching and identification.

  • Creator (Crtr)—Creator of the specification.

  • Specificaton URI document (SURI)—URI of a specification document.

  • Version (Vers)—Version of this specification.

  • Parameters (Parm)—List of parameters to be used by the implementation.

  • Proxy—ModuleSpecID of a proxy module if one exists.

  • Authenticator (Auth)—ModuleSpecID of an authenticator module if required.

The following is an example of the XML for the module specification for the EX1 example. Note that in addition to its standard tags, there is a pipe advertisement used to communicate to the module. This is done as a convenience, so that the user of the code does not need to look for an extra pipe advertisement:

<?xml version="1.0"?>
<!DOCTYPE jxta:MSA>
<jxta:MSA xmlns:jxta="http://jxta.org">
  <MSID>
   urn:jxta:uuid-88A7B34E2B354A75A181B34E6058D3DA0F
          230D7557A24F159F80ABA479BC0C3B06
  </MSID>
  <Name>
   JXTASPEC:JXTA-EX1
  </Name>
  <Crtr>
   sun.com
  </Crtr>
  <SURI>
   http://www.jxta.org/Ex1
  </SURI>
  <Vers>
   Version 1.0
  </Vers>
  <jxta:PipeAdvertisement>
   <Id>
     urn:jxta:uuid-9CCCDF5AD8154D3D87A391210404E59
          BE4B888209A2241A4A162A10916074A9504
   </Id>
   <Type>
     JxtaUnicast
   </Type>
   <Name>
     JXTA-EX1
   </Name>
  </jxta:PipeAdvertisement>
</jxta:MSA> 

Module Implementation Advertisement

The Module Implementation advertisement is the final link in the chain to define a module. The advertisement defines specific references to a specific language representation on a peer. This advertisement is used to launch the code.

  • Name—Optional name associated with the module.

  • Description (Desc)—Optional string used to describe and allow for searching of key words to locate a module.

  • ModuleSpecID (MSID)—ID that uniquely identifies the specification being implemented.

  • Compatibility (Comp)—An element that describes the execution environment. For Java this would be the JVM version.

  • Package URI (PURI)—Optional URI used to download the code of this implementation (not implemented in version 1.0).

  • Code—Contains a reference used to load and execute the code of this implementation. For a Java module, this is a fully-qualified classname.

  • Parameter (Parm)—Arbitrary parameters to be interpreted by the implementation's code.

  • Provider (Prov)—Provider of the implementation.

The following is the module implementation for the standard peer group. Note that this implementation contains further implementation advertisements in the param tag. Also note that the last entry is the shell application. The shell is defined this way as the default application of the peer group. If the peer group is started after it is initialized, the code in the application tag is executed:

<?xml version="1.0"?>

<!DOCTYPE jxta:MIA>

<jxta:MIA xmlns:jxta="http://jxta.org">
 <MSID> urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE000000010306 </MSID>
 <Comp> <Efmt> JDK1.4 </Efmt> <Bind> V1.0 Ref Impl </Bind> </Comp>
 <Code> net.jxta.impl.peergroup.StdPeerGroup </Code>
 <PURI> http://www.jxta.org/download/jxta.jar </PURI>
 <Prov> sun.com </Prov>
 <Desc> General Purpose Peer Group Implementation </Desc>
 <Parm>
  <Svc>
   <jxta:MIA>
    <MSID> urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE000000060106</MSID>
    <Comp> <Efmt> JDK1.4 </Efmt> <Bind> V1.0 Ref Impl </Bind> </Comp>
    <Code> net.jxta.impl.rendezvous.RendezVousServiceImpl </Code>
    <PURI> http://www.jxta.org/download/jxta.jar </PURI>
    <Prov> sun.com </Prov>
    <Desc> Reference Implementation of the Rendezvous service </Desc>
   </jxta:MIA>
  </Svc>
  <Svc>
   <jxta:MIA>
    <MSID> urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE000000030106 </MSID>
    <Comp> <Efmt> JDK1.4 </Efmt> <Bind> V1.0 Ref Impl </Bind> </Comp>
    <Code> net.jxta.impl.discovery.DiscoveryServiceImpl </Code>
    <PURI> http://www.jxta.org/download/jxta.jar </PURI>
    <Prov> sun.com </Prov>
    <Desc> 
     Reference Implementation of the DiscoveryService service 
    </Desc>
   </jxta:MIA>
  </Svc>
  <Svc>
   <jxta:MIA>
    <MSID>
     urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE000000050106
    </MSID>
     <Comp> <Efmt> JDK1.4 </Efmt> <Bind> V1.0 Ref Impl </Bind> </Comp>
    <Code> net.jxta.impl.membership.NullMembershipService </Code>
    <PURI> http://www.jxta.org/download/jxta.jar </PURI>
    <Prov> sun.com </Prov>
    <Desc> 
     Reference Implementation of the MembershipService service 
    </Desc>
   </jxta:MIA>
  </Svc>
  <Svc>
   <jxta:MIA>
    <MSID>
     urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE000000070106
    </MSID>
     <Comp> <Efmt> JDK1.4 </Efmt> <Bind> V1.0 Ref Impl </Bind> </Comp>
    <Code> net.jxta.impl.peer.PeerInfoServiceImpl </Code>
    <PURI> http://www.jxta.org/download/jxta.jar </PURI>
    <Prov> sun.com </Prov>
    <Desc> Reference Implementation of the Peerinfo service </Desc>
   </jxta:MIA>
  </Svc>
  <Svc>
   <jxta:MIA>
    <MSID> urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE000000020106 </MSID>
    <Comp> <Efmt> JDK1.4 </Efmt> <Bind> V1.0 Ref Impl </Bind> </Comp>
    <Code> net.jxta.impl.resolver.ResolverServiceImpl </Code>
    <PURI> http://www.jxta.org/download/jxta.jar </PURI>
    <Prov> sun.com </Prov>
    <Desc> 
      Reference Implementation of the ResolverService service 
    </Desc>
   </jxta:MIA>
  </Svc>
  <Svc>
   <jxta:MIA>
    <MSID> urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE000000040106 </MSID>
    <Comp> <Efmt> JDK1.4 </Efmt> <Bind> V1.0 Ref Impl </Bind> </Comp>
    <Code> net.jxta.impl.pipe.PipeServiceImpl </Code>
    <PURI> http://www.jxta.org/download/jxta.jar </PURI>
    <Prov> sun.com </Prov>
    <Desc> Reference Implementation of the PipeService service </Desc>
   </jxta:MIA>
  </Svc>
  <App>
   <jxta:MIA>
    <MSID> urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE0000000C0206 </MSID>
    <Comp> <Efmt> JDK1.4 </Efmt> <Bind> V1.0 Ref Impl </Bind> </Comp>
    <Code> net.jxta.impl.shell.bin.Shell.Shell </Code>
    <PURI> http://www.jxta.org/download/jxta.jar </PURI>
    <Prov> sun.com </Prov>
    <Desc> JXTA Shell reference implementation </Desc>
   </jxta:MIA>
  </App>
 </Parm>
</jxta:MIA>

Pipe Advertisements

Pipe advertisements describe the type of pipe. Pipe advertisements are rather simplistic. They only have a name, ID, and type. As we have discussed, there are several different types of pipe. The specific pipe type is listed in the Type tag.

Pipes contain the following tags:

  • Name—Name of the pipe.

  • Id—The ID of the pipe.

  • Type—The type of the pipe. Type is related to a protocol and therefore to endpoints on a peer. Types are UnicastType, UnicastSecureType, and PropagateType.

The following is an example of an XML pipe advertisement. This pipe is a unicast pipe:

<?xml version="1.0"?>
<!DOCTYPE jxta:PipeAdvertisement>
<jxta:PipeAdvertisement xmlns:jxta="http://jxta.org">
 <Id>
  urn:jxta:uuid-59616261646162614E50472050325033A10C
          F46E7B7041B48C3EBF32A5DA2A4404
 </Id>
 <Type>
  JxtaUnicast
 </Type>
 <Name>
  frodo.replyTo
 </Name>
</jxta:PipeAdvertisement>

Endpoint Router Messages

The router protocol uses query and response messages to discover routes. The query message supplies the peer ID of the destination. The ID of the origin is assumed that of the source. This message is sent from a peer to a peer, which implements the peer endpoint protocol. The XML endpoint router query message schema is as follows:

<xs:element name="EndpointRouterQuery" type="jxta:EndpointRouterQuery"/>
<xs:complexType name="EndpointRouterQuery">
  <xs:element name="Credential" type="xs:anyType" minOccurs="0"/>
  <xs:element name="Dest" type="xs:anyURI"/>
  <xs:element name="cached" type="xs:string"/>
</xs:complexType>

The router answer message contains the information about the route that was located by the router or a router it collaborated with to create the answer.

The actual route is a list of peers that are all gateways, except the final destination that is not required to be a gateway:

<xs:element name="EndpointRouterAnswer" type="jxta:EndpointRouterAnswer"/>
<xs:complexType name="EndpointRouterAnswer">
  <xs:element name="Credential" type="xs:anyType" minOccurs="0"/>
  <xs:element name="Dest" type="xs:anyURI"/>
  <xs:element name="RoutingPeer" type="xs:anyURI"/>
  <xs:element name="RoutingPeerAdv" type="xs:string"/>
  <xs:element name="Gateway" type="xs:complexType"/>
</xs:complexType>

Messages

Message advertisements are used for the various messaging protocols, as well as for user defined messages. There are two different types of messages—XML and binary.

XML Messages

XML messages are used for transport mechanisms that only support text or as a general way to send a message. Because messages are seen as the most used type of data that is transported between peers, the binary message is offered in most cases because it is much more efficient.

The XML message format consists of a message tag that encapsulate the data of the message. Each element has a name, a mime type, and an optional encoding parameter. By changing the mime type and the encoding, you can place any supported data type between the enclosing element tags that is valid XML. For data that is not XML, the < character is replaced with the string &lt;, and & symbols are replaced with &amp; as equivalent. The following is an example of an XML message:

  <!DOCTYPE Message>
  <Message version="0">
  <Element name="jxta:SourceAddress" 
  mime_type="text/plain">
  tcp://123.456.205.212
  </Element>
  <Element name="stuff" 
  encoding="base64" mime_type="
  application/octet-stream">
  AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygp
  KissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUV
  JTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eH
  l6e3x9fn+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6Choq
  OkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsc=
  </Element>
  </Message>

Binary Messages

Binary messages are compact packets used to send information with as compact a data stream as possible. Two-byte lengths are sent with the high-order byte first. All strings start with a two-byte length, followed by the UTF8 string value. The message format is specified by using ABNF (see IETF RFC 2234 at http://ietf.org/rfc/rfc2234.txt). The format of the binary message is defined by Tables 2.1 and 2.2.

Table 2.1 Binary Message Format

Section

Description

"jxmg"

Start of the message.

Version

One byte. Must be 0 for the 1.0 binary format.

Namespaces

See Namespaces.

element_count

Two bytes designating the number of elements to follow.

Table 2.2 Message Element

Section

Description

"jxel"

Element signature.

namespaceid

One byte that designates the name space.

Flags

Indicates which parts follow 0x00 if type is not present and 0x01 if type is present.

simple_name

Name of this element. If the namespace ID is 0, the simple name is the name. Otherwise concatenate the namespace name designated by the ID with a colon (:) and the simple name. The next byte is the flags byte.

[type]

Present if the flags byte has the least significant bit set (0x01).

len4

Four byte length of content.

 





Page 5 of 6



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel