Tutorials : SAMS: Java's API For Mobile Services :

The SAMS Network

The important part of the SAMS network is the Service provider interface (SPI). The SPI contains the environment where programs use the SAMS API and run applications. In this case, the SAMS API acts like a client API running in the SPI environment and gets used by the various client programs.

For example, in the case of a Multimedia Messaging server (MMS), the Server communicates through a protocol, called MM7, to all client programs. So, any client program that needs to communicate with the server would have to understand the MM7 protocol and provide request messages in the same format. With the SAMS API, the client program need not worry about the underlying protocol of the server. The SAMS API provides a common interface, which can be used by the client program to communicate with the server. It is the responsibility of the server to route the request to the specific API implementation.

The SAMS API only provides interfaces for applications contained within the SPI so that they can effectively communicate with their clients. The SAMS API does not define any client-side container specifications. From the point-of-view of the SAMS API, any server in the network can be a service provider. Similarly, any application that uses the SAMS API can be seen as a consumer of the service. Usually, all mobile servers that provide specific services do so through a specific protocol, though the protocol might differ depending on the kind of service.

The SAMS API provides a protocol independent API. The service provider ensures that the SAMS API understands the protocol used it's using and also provides the supporting mechanisms for the SAMS API to work properly. The SAMS specification only provides the API outline; the responsibility of implementing them rests on the respective service providers.

The main focus of the SAMS API is to provide server-side client access to servers in the network edge domain. So programming models created using this specification will not be applicable to applications that work directly from other domains. The SAMS API provides applications access to servers in the network domain, irrespective of the network configuration they use.

The SAMS API

The SAMS API is divided into two main sections, the Common SAMS API and the Service Specific messaging APIs. The common SAMS API contains interfaces and classes that are common to all implementations of the SAMS specification. However, there is a need to have some protocol- and server-specific implementations, and their extensions are defined in the Service Specific APIs.

IN addition, the API implementation for the SAMS API contains classes and interfaces that implement the business logic for the specific protocol or service. All implementations of the SAMS specifications have to provide support for the common methods in the SAMS common API. Individual implementations extend the API further and provide server-specific API extensions.

Some common functions outlined in the common SAMS API are:

  • A factory pattern allows access to defined services.
  • A service interface that is implemented by all SAMS services.
  • A session interface provides a base implementation for all SAMS sessions.
  • A Message interface, which is the base functionality for all SAMS messages.
  • A MessageListerner interface helps applications to send and receive messages.
  • A Filter interface used to filter messages.
  • A common exception framework used by the SAMS API.
One of the objectives of the SAMS API is to provide a protocol independent interface to clients. The client does not know the underlying protocol specific implementations. The SAMS API expects support for several protocol drivers in a single environment. It also expects multiple instances of the same driver to co-exist providing different types of services. This requirement makes the SAMS API very robust but brings with it the complexity of handling requests for all these cases. The common SAMS API only provides generic interfaces to communicate with all drivers and protocols. So when requests need to be made to similar interfaces or same instances of the driver with different parameters, the API will have to support vendor specific API extensions.

SAMS API Options

Because the SAMS API is a common API, it contains all the common features supported by all underlying protocols and drivers. In some cases, drivers may provide additional functionality for a particular client or set of clients. In such cases the client applications can use the optionality defined within the SAMS API.

The SAMS API supports optionality in many ways. The first way is to define all the parameters, fields, and operations in the same general API. This marks the common and important parameters and operations required by the protocol as mandatory and marks the other specific features and operations as optional. This tells you what optional parameters you need to set for specific scenarios.

Another way of supporting options is through using the profile information, property settings, or the context information.

  • The profile information specifies the implementation specific parameters for configuring the service.
  • The property settings configure the service session dynamically. Property settings can also specify implementation-specific session or protocol options.
  • The context information dynamically configures the operations within a session.
In some cases, optionality can be done through a driver-specific configuration API where optionality can be specified at implementation time.

The SAMS Messaging Architecture

Messaging consists of different application types like MMS, SMS, instant messaging, message-oriented middleware, and many others. However, the scope of this specification is limited to SMS and MMS messages only.

The basic flow of SAMS Messaging consists of a mobile client sending an MMS or SMS message request. The SMS/MMS message is routed to the corresponding messaging server based on the type of the message. In the case of the SMS message the messaging server directly delivers the message to the recipient's device. In the case of an MMS message a notification is sent to the recipient to retrieve the MMS message. The actual MMS message is delivered to the client after the client has accepted the request.

Integration with J2EE Technologies

The SAMS APIs are designed to operate within the J2EE and J2SE platforms. The SAMS API uses two separate APIs called the SAMS service API and the SAMS resource API. The service API uses common J2EE design patterns and provides developers an easy way to program mobile applications. The SAMS resource API lies below the SAMS service API and acts as a bridge between the SAMS service API and the SPI.

The details of the implementation of the SAMS API are left to the discretion of the vendor. Some vendors may choose only to implement the SAMS service API. Meanwhile, some vendors might need to provide both the SAMS service API and a driver implementation using the SAMS resource API.

The SAMS resource API can be developed with any technology, but to reduce duplication the Java connection architecture can be leveraged. The Java Connection architecture offers resource management, transaction management, security, and result set management.

In any case, the SAMS specification does not mandate any particular implementation strategy. The SAMS APIs can be deployed on managed and non-managed environments. However, when the SAMS API integrates with other J2EE technologies, like JCE, it becomes easier to run them in a managed environment like an application server. Even so, the SAMS specification requires that SAMS applications also work in non-managed environments, hence the JCE architecture is provided as a suggestion for the SAMS resource API.

Releases

The SAMS specification was approved in June 2004 and finalized in July. It is today in maintenance release. The lead on the specification is Nokia Corporation. Other notable names on the Expert group are Apache, Cingular, BEA Systems, Sun Microsystems, and Siemens. The SAMS API will reside under the javax.mobileservices.messaging package. The SAMS API will capitalize on the work already done by the Wireless Messaging API (JSR 120). JSR 120 already defines an interface to exchange SMS messages in the J2ME environment. The JSR 205 provides the groundwork for exchanging MMS messages.

No concrete implementations of the SAMS API are found on the Internet as yet. It might take some take some time for Mobile service providers to accept the specification and start building according to it.

References:
JSR 120 Wireless Messaging API
JSR 205 Wireless Messaging API 2.0

How to Add Java Applets to Your Site

New on the Java Boutique:

New Review:

Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling API boasts simplicity, ease-of-integration, a well-rounded feature set, and it's free!

New Applet:

Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA sequences into three useful formats.

Elsewhere on internet.com:

WebDeveloper Java
Lots of Java information on webdeveloper.com

WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.

ScriptSearch Java
Hundreds of free Java code files to download.

jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.