Welcome!

Java IoT Authors: Pat Romanski, Elizabeth White, Liz McMillan, Yeshim Deniz, Mehdi Daoudi

Related Topics: Java IoT

Java IoT: Article

Jini Surrogate as a Platform for J2ME Games

Jini Surrogate as a Platform for J2ME Games

In Part 1 of this article (JDJ, Vol. 7, issue 3) I introduced the idea of using the surrogate architecture within Jini as a platform for J2ME games. I also showed how to start Madison, Sun's reference implementation, and how to connect to it with the provided device simulator.

This article continues the surrogate architecture tour and introduces a method through which a J2ME device can use it.

To briefly recap, the architecture allows any device, in our case a J2ME one, to connect to a Jini network through a surrogate object that represents the device in the network. The surrogate host provides a mechanism for the devices to register themselves and obtain a context that enables access to the underlying Jini infrastructure.

Another important reason for choosing the surrogate architecture is that it allows us to view the device as a single object from the network perspective. There's no single monolithic portal API or application running; instead, many different surrogate objects with unique capabilities and representing many potentially different devices are displayed in the Jini network.

How Should We Connect?
The surrogate architecture defines the term connector as a means by which a device will discover and register with a surrogate host. Possible connectors might include such protocols as Bluetooth, USB, or even traditional network ones. Madison comes with an IP interconnect, useful in many cases but it may not be the best one for our project. For several reasons I believe HTTP is the best protocol to use.

HTTP? It does have its disadvantages. Foremost of these - it's a request/response protocol. This means that either we settle for a one-way communication model where all communication with the device must come as a response to an initial request, or we have an HTTP server at both the device and the surrogate object. The second option is just not possible in J2ME, so we're stuck with the first.

The second disadvantage is that HTTP has no notion of "discovery," at least in the Jini sense. This means that our device must have knowledge, in the form of a URL, of where the surrogate host is beforehand. It would be nice to somehow find a surrogate host but we can hardly multicast the Internet looking for one.

The J2ME specification only requires support for HTTP connections, though implementations of J2ME may support other types of communication. By choosing HTTP we guarantee that any J2ME device will be able to work with our surrogate host connector. There have been many debates as to whether J2ME is powerful enough, as well as fears that using it results in the loss of powerful native functionality. Cross-platform code has its own set of disadvantages, but in our case the portability is worth the loss in functionality.

To see another advantage, let's think about our use case. Our goal is to create a games platform on mobile devices. Typically, this means many users connecting with our system simultaneously. It's not unrealistic to think of multiplayer games with thousands of players concurrently connected. In this case, HTTP scales quite well - after all, it's a proven technology already handling huge numbers of simultaneous requests. Thus our system should be able to handle more users making requests every few minutes or so rather than a group of users who are constantly connected over sockets. It may even be cheaper for the end user by minimizing the amount of airtime consumed.

Finally, even though I'm advocating HTTP as the protocol to communicate with the surrogate host, it doesn't have to be the protocol used to communicate with the surrogate object once it's instantiated. I'll continue to use HTTP in our project, but the surrogate architecture doesn't require this and other protocols could be used depending on the device's J2ME implementation.

Defining Our Protocol
In defining a surrogate HTTP protocol I'll rely heavily on what has already been defined for the IP connector. That specification is already in the review stage of the Jini Decision Process (see www.jini.org/standards/), and since HTTP is built on IP, there are some similarities. In addition, doing so is what I consider being a "good Jini citizen": cooperating and contributing to a community that gives a tremendous amount to its members. By building on the IP connector work, we respect the standards already defined, ensuring that Jini services in general will be able to communicate with each other and interoperate without difficulty.

As stated earlier we won't need the discovery protocols. We will, however, need a registration protocol that allows a device to register with the surrogate host. Examining the IP interconnect registration request protocol we can see that it will suit our needs as well for HTTP. The registration request protocol is sent by the device to the surrogate host and has the following format:

  • int protocol version
  • short length of surrogate code URL
  • byte[] surrogate code URL
  • int length of initialization data
  • byte[] initialization data
  • int length of surrogate code
  • byte[] surrogate code
We'll also need a response to this, which is something that the IP interconnect doesn't define. The main reason for defining a response is that if we use HTTP to continue communicating with the surrogate object, we must somehow let the device know how to accomplish this. Why? Once the surrogate object is instantiated, we're no longer communicating with the surrogate host. Instead, we're now communicating directly with the surrogate object. If HTTP is the only available protocol, then the device must initiate all communication. We define a response protocol in order to pass the URL for the surrogate object to the device, a different URL than for the surrogate host. Our response protocol is defined as follows:
  • int protocol version
  • short length of surrogate connect URL
  • byte[] surrogate connect URL
Finally, since I intend to continue to use HTTP as the transport for device-to-surrogate object communication, it makes sense to define some sort of message protocol. Even though the type of messages sent may be very different depending on the type of game being played, I'll define a basic message protocol. An example of basic communication is passing a message that includes some data as a payload. Of course, the device and surrogate object must both be aware of the message format, though the surrogate host need not be. The message protocol might have the following format:
  • int protocol version
  • int message type
  • int length of payload data
  • byte[] payload data
Finally Some Client Code...
Wait a minute, isn't this supposed to have something to do with J2ME? Well, there are still some missing pieces on the Jini side, but let's take a little break first and make use of the protocols introduced earlier.

Every game written using the HTTP interconnect will need to register with the surrogate host and receive a response. Therefore, it makes sense to encapsulate these two protocols in objects. Since our registration protocol is the same as the one for the IP interconnect, we may be able to reuse some of our code should we use J2ME over IP in the future.

The limited resources of a typical J2ME device now force us to make some design decisions. It's tempting to define an interface for our two protocols, something like the following:

public interface InterconnectProtocol
{
void read(java.io.InputStream in) throws java.io.IOException;
void write(java.io.OutputStream out) throws java.io.IOException;
}
This allows us a nice layer of abstraction, and by encapsulating the protocol in an object that accepts streams for reading and writing, we can use any type of connection.

What about those limited resources? By creating an interface we have one more file to add to our J2ME JAR. With some phones having an application limit of 50K, why add unnecessary bloat? It's a case of evaluating each situation. For now I'll keep the interface, as it allows flexibility in adding more protocols for different message formats. Be aware though that sometimes every little byte counts; I've worked on applications in which I removed all evidence of object-oriented design in order to bring the size of the code down.

A further reduction in code size can be obtained, in our case by combining the registration and response protocols into one object. The reason is simply that the J2ME device need only send registrations to the surrogate host; it doesn't need to read the registration protocol. Similarly it only has to read the responses and never needs to send them. Again this is a decision to make based on the situation. By combining the protocols here we lose the reusability of the registration protocol with an IP interconnect, as the response is only needed with the HTTP interconnect.

See Listings 1 and 2 for J2ME encapsulations of the registration and response protocols, respectively.

What Should an HTTP Surrogate Look Like?
Let's turn back to the Jini side of our project and think about what still needs to be defined, what an HTTP surrogate will look like, and how the surrogate host combined with the HTTP interconnect will interact with these surrogate objects.

In this section I'm assuming we'll continue to communicate with the surrogate object using HTTP. This means that either the surrogate must have an embedded HTTP server in its code, or the HTTP interconnect must provide that service for the surrogate object. The second case is not unreasonable as it simplifies the creation of surrogate objects, which is an important goal in a development platform. It also philosophically fits with the surrogate architecture: the host provides a context for the surrogate object and so does the interconnect.

This leads to the question of how a message is delivered from the interconnect-provided HTTP server to the surrogate. The embedded HTTP server provided by the interconnect and the surrogate object should have an exclusive relationship. At the very least, there should be some separation, and depending on the embedded server this might be an exclusive handler for HTTP requests destined for a specific surrogate object. To pass the message to the surrogate object we need to create an interface that it should implement:

public interface HttpSurrogate extends net.jini.surrogate.Surrogate
{
void handle(java.io.InputStream in, java.io.OutputStream out)
throws java.io.IOException;
}
Are there potential problems in defining an interface our surrogates must implement? Other HTTP interconnect implementations may have different designs and we run into a case of surrogate objects being incompatible across different surrogate hosts. However, as we are going to further define the relationship between the HTTP surrogate object and the HTTP interconnect, this seems a small issue.

The HttpSurrogate interface extends the basic surrogate interface as defined in the surrogate architecture specification (included in the Madison download). This interface is defined as follows and allows the surrogate host to provide basic life-cycle services to the surrogate:

package net.jini.surrogate;
public interface Surrogate {
void activate(HostContext hostContext, Object context)
throws Exception;
void deactivate();
}
The first object in the activate() method is the HostContext, provided by the surrogate host. The second object is the context, provided by the interconnect, and it's passed as an object; since the surrogate host calls this method on the surrogate, it doesn't need to know the nature of the context.

We'll need to define a context for the HTTP interconnect. The context defined in the IP interconnect fits our needs and keeps some consistency between the interconnects. The interface for the context is:

public interface HttpInterconnectContext extends
net.jini.surrogate.KeepAliveManagement
{
byte[] getInitializationData();
java.net.InetAddress getAddress();
}
This provides a way to retrieve both the initialization data we may include in the registration protocol and the InetAddress of the device. We may want the InetAddress in the future, as it will allow the surrogate to create connections back to the device should the J2ME implementation on that device support them.

You'll notice that the interface extends another surrogate specification interface. This allows the interconnect to assist in defining and enforcing what it means to have a live connection between a device and a surrogate.

Tell Me What You Think
So far we've covered a lot of ground and further detailed some of the ideas introduced in Part 1. We're still not there, but we're getting closer to achieving the goal of developing a game platform for J2ME devices in a Jini network.

I'm interested in hearing your opinions. Are there pieces missing, whether technical or logistical, to this puzzle? How does the Jini/J2ME platform compare to others you've used for interactive, wireless device applications? Your thoughts and suggestions are welcome.

More Stories By Bill Swaney

William Swaney, a software developer specializing in distributed computing, works for Valaran Corp., where he experiments with mobile devices and Jini networks. He divides his time between tweaking Valaran’s surrogate host implementation and kicking a soccer ball into a bucket.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


IoT & Smart Cities Stories
There are many examples of disruption in consumer space – Uber disrupting the cab industry, Airbnb disrupting the hospitality industry and so on; but have you wondered who is disrupting support and operations? AISERA helps make businesses and customers successful by offering consumer-like user experience for support and operations. We have built the world’s first AI-driven IT / HR / Cloud / Customer Support and Operations solution.
Codete accelerates their clients growth through technological expertise and experience. Codite team works with organizations to meet the challenges that digitalization presents. Their clients include digital start-ups as well as established enterprises in the IT industry. To stay competitive in a highly innovative IT industry, strong R&D departments and bold spin-off initiatives is a must. Codete Data Science and Software Architects teams help corporate clients to stay up to date with the mod...
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
Druva is the global leader in Cloud Data Protection and Management, delivering the industry's first data management-as-a-service solution that aggregates data from endpoints, servers and cloud applications and leverages the public cloud to offer a single pane of glass to enable data protection, governance and intelligence-dramatically increasing the availability and visibility of business critical information, while reducing the risk, cost and complexity of managing and protecting it. Druva's...
BMC has unmatched experience in IT management, supporting 92 of the Forbes Global 100, and earning recognition as an ITSM Gartner Magic Quadrant Leader for five years running. Our solutions offer speed, agility, and efficiency to tackle business challenges in the areas of service management, automation, operations, and the mainframe.
The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
With 10 simultaneous tracks, keynotes, general sessions and targeted breakout classes, @CloudEXPO and DXWorldEXPO are two of the most important technology events of the year. Since its launch over eight years ago, @CloudEXPO and DXWorldEXPO have presented a rock star faculty as well as showcased hundreds of sponsors and exhibitors! In this blog post, we provide 7 tips on how, as part of our world-class faculty, you can deliver one of the most popular sessions at our events. But before reading...
DSR is a supplier of project management, consultancy services and IT solutions that increase effectiveness of a company's operations in the production sector. The company combines in-depth knowledge of international companies with expert knowledge utilising IT tools that support manufacturing and distribution processes. DSR ensures optimization and integration of internal processes which is necessary for companies to grow rapidly. The rapid growth is possible thanks, to specialized services an...
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
Scala Hosting is trusted by 50 000 customers from 120 countries and hosting 700 000+ websites. The company has local presence in the United States and Europe and runs an internal R&D department which focuses on changing the status quo in the web hosting industry. Imagine every website owner running their online business on a fully managed cloud VPS platform at an affordable price that's very close to the price of shared hosting. The efforts of the R&D department in the last 3 years made that pos...