An Interview with Shai Gotlib

As the capabilities of mobile devices have increased, so has the need to track runtime aspects of a mobile application or a mobile device. Application usage patterns, response times, and quality of service-related information are examples of the types of events network and service providers must collect and analyze. The new Event Tracking API for J2ME, JSR 190, currently in public review, standardizes mobile event management. In this interview with Artima, JSR 190 spec lead Shai Gotlib discusses the need for mobile events, how the infrastructure defined in JSR 190 simplifies event management in a mobile network, and also talks about privacy and security aspects of mobile event collection. This interview was conducted via email, with some comments provided by Tal Givoly, Amdocs' Chief Scientist.

Shai Gotlib: The need for monitoring and tracking of Java ME applications has recently increased because of the dramatic evolution in areas such as mobile games. Newly-developed monitoring and control systems for mobile networks also intensify this need.

Examples of such monitoring and event tracking include being notified when a user launches a mobile game. Such an event notification can help determine, for instance, what games are most popular, and can help a network or service provider learn about market behavior.

As well, a set-top box can enable a user to react to specific events in a show, using a remote control to send feedback, and those events can also help the network provider learn about viewer preferences and improve service. Similarly, by tracking a user's activities on a mobile terminal, such as a cell phone, a network provider or a game vendor can monitor the success of a new game promotion, for instance.

Event monitoring can also help track physical behavior, as in GPS- or GPRS-based vehicle tracking systems. Another example of physical environment monitoring with events are sensors in a greenhouse sending humidity and temperature information to a monitoring and control server.

Up to now, each business had to invent its own reporting and event collection framework, resulting in fragmented and costly product development. The JSR 190 Event Tracking API provides a standard framework for the developer to send and receive events, as well as to configure the environment and the underlying protocol.

JSR 190 defines an optional Java ME package that standardizes the tracking of application events on a mobile device—an exporter—and the submission of those event records to an event-tracking server—a collector—via a standard protocol. It also defines the underlying protocol between the Java ME devices and the collection system. It also specifies event templates [Editor's note: Templates are record structures corresponding to events], and allows the developer to specify custom templates as well.

Frank Sommers: How does JSR 190 event notification relate to a traditional publish-subscribe event system, such as those used in conjunction with JMS, CORBA, Jini, or TIBCO's event bus?

Shai Gotlib: Java ME applications must take into consideration CPU limitations, as well as bandwidth and storage limitations. Those requirements dictated the characteristics of the underlying protocol between the Java ME device and the collection system. Accordingly, the protocol had to be reliable and consume minimum CPU, bandwidth, and storage resources. We also thought that it would be a huge advantage to find a protocol that the industry already adopted.

The Internet Protocol Detail Record Streaming Protocol (IPDR/SP) was found to be such a protocol, suitable for the JSR 190 needs. The IPDR/SP specification provides an advanced streaming protocol for [network usage] accounting information exchange. It is specifically designed for reliable export of usage data from a network element. Real-time operation, high reliability at low bandwidth and processing costs, and minimal CPU and storage demands are key factors in this protocol.

IPDR/SP enables the negotiation of a data event template at the beginning of a communication session, and then sends stream data only, encoded as XDR, with no meta-data, such as field names or types. This approach allows IPDR/SP to demand very little bandwidth. In the context of JSR 190, IPDR/SP gives the Java ME exporter the possibility to send the minimal information required by the collection system.

In contrast to some of the other messaging systems, JMS is more about XML-based asynchronous messaging, while IPDR/SP uses binary encoded messages. CORBA's events service is about providing a flexible callback model. While IPDR/SP enables this mechanism, IPDR/SP is dedicated to exposing tracking events from the Java ME device to the [event] collection system.

IPDR/SP has built-in reliability and availability in the application layer that does not exist either in JMS nor in CORBA. It also has a built-in template negotiation mechanism that enables decreasing bandwidth demand, which also does not exist in CORBA or JMS.

IPDR/SP is also well-adopted by the industry, as is evidenced by its approval in the Alliance for Telecommunication Industry Solutions' (ATIS) Requirements and Architecture. As well, IPDR/SP is in process of being submitted to International Telecommunications Union (ITU) as part of ITU's Next Generation Network (NGN) standardization. Finally, IPDR/SP was submitted as a full American National Standard.

Frank Sommers: In what way does JSR 190 facilitate the development of loosely coupled systems? Could this API be used as a general message subscription and event notification framework in a mobile application?

Shai Gotlib: We believe that the JSR 190 Event Tracking API is the best framework for exposing tracking events in a reliable, real-time, low cost—in terms of CPU and bandwidth—way. It enables the developer to easily expose events, while collection systems can collect and analyze the exposed events following a standard. But the JSR 190 API does not attempt to replace the publish/subscribe notification mechanism provided by the JMS framework. Events broadcasting is also not part of JSR 190.

Frank Sommers: To what extent does this API take into account the dynamic nature of networks? For instance, as new event collectors come online, or existing ones become unavailable, how does JSR 190 address those runtime changes?

Shai Gotlib: The JSR 190 API has two mechanisms to handle dynamic networks. The more common case is where a set of potential available collectors exists, but not all of those collectors are available all the time.

The JSR 190 configuration mechanism enables you to configure many collectors to be available for each Java ME exporter. Each collector has a priority, and the exporter exposes events only to the collector with the highest priority, while other collectors are on standby.

Whenever problems appear with exposing events to the current highest-priority collector, the exporter switches to another collector that has the next highest priority. If a new collector comes online with an even higher priority, the exporter switches automatically to expose events to that new collector.

Less often, the set of collectors may not be stable and must be changed frequently. That issue can be handled by implementing the Java API for defining the available collectors in such a way as to obtain the set of available collectors from somewhere on the network dynamically, whenever the ETA is initialized.

Frank Sommers: Do specific kinds of event monitoring and event relay have to be designed and built into the application from the start, or can such monitoring be added later, as an aspect? For instance, a network operator may want to monitor and collect events about an application that the application developer didn't think about. Can the network operator add such capabilities to an existing application?

Shai Gotlib: In the simplest and most common use-case of the JSR 190 API, the application developer is responsible for defining the event templates, and for populating and sending the tracking events in the proper locations inside the application. The application distributor is responsible for defining the available collectors and their priorities.

The available event templates are considered to be part of the configuration that can be modified dynamically. The developer can implement the Java API for defining the available event templates configuration in such a way that it takes the available templates from somewhere on the network. The application developer, in that case, has to know how to dynamically change the events that he exposes inside the application according to those templates.

Frank Sommers: The spec says that it is the underlying protocol's responsibility to submit events to the network. But mobile devices typically operate in an unreliable environment. How are event submission and transmission errors handled, and how does an application know if events are not sent correctly? How does the event collector decide between failure of the application versus not getting any messages from the application due to network failure?

Shai Gotlib: The underlying protocol behaviors—errors, specific states transitions, and so on—can be monitored by registering a listener object on the JSR 190 implementation. For example, a listener can be notified about an error to the effect that a template to be used is not known, or about the fact that no connection with any collector exists. At that point, the application has to decide how to handle those errors.

The connection between the exporter and the collection system is a "hot" connection, a mechanism inherited from IPDR/SP. Both sides know whether they are connected or not by using a keep-alive mechanism. As the exporter identifies problems with the connection to the active event collector—the one with the highest priority—fail-over will be performed automatically by the JSR 190 implementation, and another collector will become the active collector. The "hot" connection is the reason that connection problems due to network failure will be identified immediately by the JSR 190 implementation.

Frank Sommers: Could you please describe the privacy aspects of the spec? Can access to events be controlled in a fine-grained manner? For instance, can I, as a user of a JSR 190-compatible app, allow only specific events, such as those related to, say, performance monitoring, but not events related to personal info, such as my game scores? Or would I simply have to either allow or disallow all events from the device?

Shai Gotlib: The JSR 190 API provides a tool for application developers and service providers. The intent of the JSR is not to compromise user privacy, but as with any tool, it is not always possible to predict or restrict how it will be applied.

The JSR 190 API adopts the permission framework of MIDP 2.0, and introduces a special permission: javax.microedition.events. That permission specifies that if access to the JSR 190 API is denied by either the user or the security policy of the device, the JSR 190 implementation must throw a SecurityException. Thus, the user currently has the ability to either allow or disallow all events from the device.

If it was up to end users to pick and choose which event types to allow, they would enable events only if they saw value doing that, and when they felt secure doing so. The owner of the event collector will probably need to provide such value and assurances to the end user.

For instance, enterprise users can leverage performance data from the device to determine whether a service-level agreement was adhered to. It is in their best interest to ensure that such data is collected and processed to determine the perceived quality of service versus the guarantee or commitment made by the service provider.

On the other hand, sending data over some kind of media may lead to additional costs for the end-user. That is the primary reason we wanted the user to be able to control whether to allow

Resources

JSR 190, Event Tracking API for J2ME
http://www.jcp.org/en/jsr/detail?id=190

Open Mobile Alliance
http://www.openmobilealliance.org

JSR 242, Digital Set Top Box Profile - On Ramp to OCAP
http://www.jcp.org/en/jsr/detail?id=242

IPDR/SP Protocol Specifications
http://www.ipdr.org/download-docs/specification.html

Talk back!

Have an opinion? Be the first to post a comment about this article.

About the author

Frank Sommers is an Artima senior editor.