Java ME and the IMS

Java is present on a plethora of devices (not just mobile phones, but set-top boxes as well), so it is ideally suited to use the IMS. JSR 281, a step in this direction, defines an API that can be used to create an IMS-ready application that can sit on any Java-enabled device that implements this API. A device that implements JSR 281 provides the IMS engine—an execution environment that an IMS-ready application can interface with. The application itself is defined with the following parameters:

■ IMS application identifier (AppId), which is a string that identifies your application (potentially from among other IMS applications on the same

device)

■ The MIDlet, which handles the application logic and—in JSR 281 lingo—is said to be the “owning Java application” .The IMS engine stores these

properties in the registry within the IMS device. This registry is used to identify the properties that define the capabilities of the IMS application.

Application developers need to define this registry by writing the capabilities within the Java Application Descriptor (JAD) or Java archive (JAR) manifest file.

This is the static method of installing an IMS application on an IMScapable

device. JSR 281 also allows developers to dynamically register their application from within the MIDlet by using the classes in the javax.microedition.ims package. As mentioned previously, the main javax.microedition.ims package is used to define, configure, and install an IMS application. The Configuration class provides methods such as setRegistry() and removeRegistry to dynamically install applications (as opposed to the static method just discussed). The ConnectionState class

is used to monitor whether the application is connected to the

IMS network and, if the network is connected, this class allows developers

to find any identities on the network. Related to this class is the ConnectionStateListener interface, implementations of which can be used to retrieve notifications about changes in the state of the connection. Finally, this package also defines the Service interface, which is the base interface for all types of IMS services, including CoreService, which is an interface

defined in the javax.microedition.ims.core package.

The second package, javax.microedition.ims.core, contains the interfaces and a single class that enable the application to create and provide the IMS services (in other words, the capabilities). At the heart of this is the

CoreService interface, which provides methods for calling remote peers over the IMS network. The CoreServiceListener implementation

of this interface is also used to listen for incoming connections.

The CoreService is what enables connections and sessions within an IMS network, but it is the ServiceMethod interface and its implemented interface

Capabilities, PageMessage, Publication, Reference, Session, and Subscription that are used to inspect and manipulate the messages that are transmitted

within each session. The messages themselves are represented using

the Message interface, but any manipulation of messages should be left for advanced IMS applications only. The MessageBodyPart interface allows an IMS application to create ad hoc body parts to attach to each message that is transmitted. Each implemented interface of the ServiceMethod interface

has a related listener interface attached. Thus, for the Capabilities interface, you can use the CapabilitiesListener; for PageMessage, you can use the

PageMessageListener; and so on. The final package, javax.micro edition.ims.core.media, is used to help with the transmission of media (BasicMedia, FramedMedia, and so on). Consequently, it provides the BasicReliableMedia,BasicUnreliableMedia, FramedMedia, and StreamMedia

interfaces. As the names suggest, BasicReliableMedia is used to transmit media over TCP, BasicUnreliableMedia is used to transmit media over UDP,

FramedMedia is used to transmit data that is delivered in packets, and StreamMedia is used for media that can be streamed in real time.