63.236.73.167/java/other/article.php/1450221

Back to Article

Overview of JXTA August 21, 2002 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.

Search:

WebMediaBrands Corporate Info

Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs

Solutions

Whitepapers and eBooks

Adobe Article: Adobe Helps PHP Developers Create Rich Internet Applications Adobe Article: Java Developers Finding a Home at Adobe Flex IBM Articles: A Smarter Business Needs Smarter Technology Intel Xeon Processor Increases Server Efficiency and Capabilities Intel Tech Brief: Automated Energy Efficiency for the Intelligent Enterprise Oracle Whitepaper: Using Oracle In-Memory Database Cache to Accelerate the Oracle Database Oracle Whitepapers - Innovation for IT Leaders Avaya Article: Communication-Enabled Mashups--Empowering Both Business Owners and IT

Internet.com eBook: IT Manager's Guide to Social Networking Internet.com eBook: Get Ready for Windows 7 Microsoft Article: Expression Web 3--New Features for PHP Developers Whitepapers: Manage Your Business Infrastracture with IBM Whitepaper: Maximize Your Storage Investment with HP Internet.com eBook: Becoming a Better Project Manager Microsoft Article: Stress Free and Efficient Designer/Developer Collaboration MORE WHITEPAPERS, EBOOKS, AND ARTICLES

Webcasts

Webcast: Connecting PHP to Microsoft Technologies Video: Microsoft Partner Program Benefits Video: Windows Azure Debugging Tips SAP BusinessObjects Webcast: Unlock the Power of Reporting with Crystal Reports

IBM Webcast: Speed Business Innovation with Reduced Cost and Risk Video: Deploy Applications on Windows Azure MORE WEBCASTS, PODCASTS, AND VIDEOS

Downloads and eKits

Downloads & Free Trials: Microsoft's New Efficiency Resource Center Get the Windows 7 SDK Free Trial: Red Gate SQL Backup Pro 6

Iron Speed Designer Application Generator MORE DOWNLOADS, EKITS, AND FREE TRIALS

Tutorials and Demos

Virtual Lab: Migrating PHP Applications Enabling Web Slices and Accelerators with a PHP Site Internet.com Hot List: Get the Inside Scoop on the Hottest IT and Developer Products

All About Botnets MORE TUTORIALS, DEMOS AND STEP-BY-STEP GUIDES