JXTA-A Messaging System for Wireless Java, Page 2
In addition to the JMS style functionality, the JXTA4J2ME-based messaging offers additional features, such as the ability to discover peers and peer groups.
In order to demonstrate how a messaging application will work using JXTA4J2ME connected to a JXTA network through a relay, let us consider the basic things that you will most likely do in any messaging application. The next section is a brief tutorial that will take you through the major steps of using JXTA4J2ME in a generic messaging application.
A Generic JXTA4J2ME-based Messaging Application
No matter what you want to accomplish in a JXTA4J2ME-based messaging application, the first step is always to instantiate the PeerNetwork class, which is part of the JXTA4J2ME implementation. This is accomplished by calling the static createInstance method of the PeerNetwork class. The createInstance method takes only one parameter, which is the name of the peer trying to connect:
PeerNetwork peerNetwork = PeerNetwork.createInstance(peerName);
In the preceding line of code, we assume that the peerName is a String type object that contains the name with which user wants to identify himself. You will perhaps have this name stored in J2ME's Record Management System (RMS) and read it from there as and when needed. (In the resources section, we have included a link to an article on how to use RMS.)
The second step is to connect to a relay:
String relayURL = getRelayURLPerhapsFromRMS(); Byte connectionState = null; connectionState = peereNetwork.connect(relayURL, connectionState);
The peerNetwork.connect method in the preceding code takes two parameters. The first string type parameter is the URL of the relay that we would like to connect to. Normally, the relay address will be stored in the J2ME RMS and some helper method (such as the getRelayURLPerhapsFromRMS method shown above) will fetch the URL from RMS. Note that the getRelayURLPerhapsFromRMS method is only shown as an example to demonstrate that the URL needs to be fetched from somewhere, perhaps from the RMS, depending on the application design. This method is neither part of JXTA4J2ME implementation nor the J2ME MIDP itself. J2ME application developers will need to implement it themselves.
The second parameter, which is a byte array, represents the state of connection to the relay. If you pass on null as the value of the state parameter, a new connection will be established.
The connect method returns the state of the connection after the method call. This value identifies the connection, so that the next time when the same peer connects to the relay, the relay will identify the peer. This way, the peer will be able to receive any messages collected while the peer was away (not connected). Therefore, you will need to store the connection state somewhere (most likely, in the RMS).
Now you are connected and ready to do some serious messaging. There are various ways you can proceed from here:
- Search for a specific resource. You can search for three types of resources using JXTA4J2ME: peers, peer groups, and pipes.
- You already know the resource, so you don't need to search. You would like to start sending in messages.
- You don't feel like sending any messages. You just want to listen to what other people are saying. So you will just poll for incoming messages.
- Any combination of the above.
Let's see how to do these tasks using JXTA4J2ME.
Searching on a JXTA network
The search method call of the PeerNetwork class will do the searching for you. This is accomplished as follows:
int requestId = peerNetwork.search (PeerNetwrok.PIPE, "hockey*");
The first parameter specifies the resource that you want to search. Possible values of this parameter are PeerNetwork.GROUP, PeerNetwork.PEER, and PeerNetwork.PIPE, which are the three static fields defined by the PeerNetwork class to specify peer groups, peers, and pipes respectively.
The second parameter is a simple search string. Therefore, the line of code shown above will search for all pipes whose names begin with "hockey" (meaning that you are trying to find communication pipes that are relevant to hockey).
The search method returns an integer type identifier, which will be used to match responses. This is necessary because of the asynchronous nature of messaging (refer to the earlier discussion on synchronous versus asynchronous messaging). You are not sure when you will receive the response to a particular message. In fact, other peers connected to the JXTA network will respond according to their own convenience (a convenience only possible with asynchronous communication).
Therefore, you can receive a variable number of responses from the JXTA network to each request. You can send any number of different search queries and expect the responses all mixed up with each other. There will be an identifier associated with each response, which will be used to match a particular request with the corresponding response.
As an example, we would like to show a typical response to the pipe search request shown above (the response has been simplified for readability):
"proxy:response" "application/octet-stream" dlen=6 "result" "proxy:requestId" "application/octet-stream" dlen=1 "1" "proxy:type" "application/octet-stream" dlen=4 "PIPE" "proxy:name" "application/octet-stream" dlen=12 "SearchPipe" "proxy:id" "application/octet-stream" dlen=80 "a unique identifier" "proxy:arg" "application/octet-stream" dlen=11 "JxtaUnicast" "jxta:EndpointDestinationAddress" "application/octet-stream" dlen=93 "destination address" "jxta:EndpointSourceAddress" "application/octet-stream" dlen=27 "source address"
This is not the actual HTTP response; it has been simplified to show the various components of a response message. We will demonstrate and explain the actual HTTP responses in the next article of this series. For the moment, just notice that the response contains several elements. Each element has been shown on a separate line in the preceding response.
Page 2 of 3