Skip Headers

Oracle9iAS Wireless Developer's Guide
Release 2 (9.0.2)
Part Number A90485-02
Go To Documentation Library
Home		 Go To Product List
Solution Area		 Go To Table Of Contents
Contents		 Go To Index
Index

Go to previous page Go to next page

13
Push Service and SMS

This document describes Push and SMS Services architecture, and explains how to use these Services to create and deploy mobile applications. Each section of this document presents a different topic. These sections include:

Figure 13-1 Push Service and SMS

Text description of feature3.gif follows.

Text description of the illustration feature3.gif

13.1 Push Service and SMS Overview

Push services are a key component that enhance your mobile application features by supporting alerts to your mobile users. Oracle9iAS Wireless Push services provide a highly scalable mechanism to deliver messages to all mobile devices. The messages are delivered to the mobile devices in a protocol that is native to the device, for example via SMS to a mobile phone, as an email to a 2-way pager, as an audio message to regular phone or as a fax to a fax machine.

Push Services in Oracle9iAS Wireless are implemented as a Web Service (WSDL) and use SOAP over HTTP. The SOAP service allows applications to invoke remote object methods over HTTP protocol. This enables applications to invoke push service from anywhere on the Internet and using any programming model. Oracle9iAS Wireless Push services allow applications to specify both the message and the recipient(s) of the message. The application communicates to the Push service in Oracle9iAS Wireless using SOAP and HTTP. Oracle9iAS Wireless receives the message and delivers the messages to mobile devices using appropriate protocols such as SMS, Email, Voice, and others.

Figure 13-2 Push Services

Text description of push1.gif follows.

Text description of the illustration push1.gif

Push Services in Oracle9iAS Wireless is a scalable platform that can handle large volumes of messages to many devices. The Push Service is based on extensible architecture and design that can be extended to support a variety of devices and push protocols. Push SOAP messages are handled by a Messaging subsystem on the Oracle9iAS Wireless server. The Messaging subsystem supports a driver-based architecture. The drivers are components in the wireless messaging system that handle all device-specific or communication protocol specific routines. The Messaging subsystem, based on the device address and transport type (SMS, Voice, Email), dispatches the message to the appropriate transport/protocol driver implementation. The driver interface delivers the message to the device in the native device protocol. The Messaging subsystem can support multiple drivers in a single instance and can support multiple drivers.

Message drivers in Oracle9iAS Wireless are plugable modules that implement device-specific or communication protocol-specific handling routines. The Oracle9iAS Wireless server ships with pre-built drivers that support communication protocols such as SMS (SMPP and UCP), Voice, Email and Fax.

Figure 13-3 Message Drivers

Text description of push2.gif follows.

Text description of the illustration push2.gif

Oracle9iAS Wireless server ships with a special driver implementation that allows your wireless instance (or install) to act as a client to another Oracle9iAS Wireless installation or any service that respects the Web Service Interface defined by Oracle9iAS Wireless. This special driver uses the SOAP interface (as the PUSH APIs) to send the messages. In the product by default, this driver is configured to act as Push Client to an Oracle9iAS Wireless instance hosted, on the Internet, by Oracle. Instance administrators can change this default setting to point to any server that respects the PUSH WSDL interface defined by Oracle9iAS Wireless.

13.2 Push Services API

Oracle9iAS Wireless Push service is deployed as a web (WSDL) service using SOAP with HTTP as the transport layer. WSDL (Web Services Definition language) is a standard XML interface that defines a Web Service application. With clearly defined WSDL, developers can build applications in any programming language such as Java and VB, and communicates with the Oracle9iAS Wireless messaging interface over the Internet. Developer can use any WSDL toolkit to quickly implement a Push application and send messages to mobile devices using any Oracle9iAS Wireless instance on the Internet.

Oracle9iAS Wireless supports a simple Push API, in Java, that abstracts any protocol-specific (SOAP) implementation from the application Java code. The Java Push API is an interface in the Java programming language. It is the preferred API for application developers who need a clear and simple interface to deliver messages. The Java Push API uses SOAP over HTTP to communicate to the Oracle9iAS Wireless server instance.

Note:

If you run your application, (hence the Java Push API) within the Oracle9iAS Wireless server Java VM, the Java Push API will not use SOAP, and instead will use in process communication to handle message delivery.

The Push API supports a uniform interface for the delivery of messages to any kind of devices such as SMS, Voice, Email, and Fax. The API allows applications to specify multiple recipients for a single message using only one delivery request. Further, the message destination addresses can have devices using different communications channels, for example, a single message delivery request application can send messages to Email as well as fax machines. Applications can make one delivery request and send the messages to a list of users with SMS devices, Email clients and Voice devices

Oracle9iAS Wireless supports different types of contents for delivery. A message can simply consist of only text characters, or can be as complex as a multipart message. Message types are identified based on the MIME, hence delivering documents such as Microsoft Word or Adobe PDF is possible if the target device supports the message MIME type.

13.2.1 Building a Push Application

Oracle9iAS Wireless can support Push content of different MIME Types such as Microsoft Word documents or Ringtones. A message can consist of text only or can be a complex multipart message. Oracle9iAS Wireless identifies the message types based on the MIME, hence delivering document such as MS-Word or PDF is possible if the target device supports the message MIME type. Oracle9iAS Wireless provides Java Push API that support a text only message (PushLite) and an advanced Push API that supports messages of any MIME type (Push).

Following are the two interfaces to send a Push Message:

13.2.1.1 PushLite

oracle.panama.messaging.push.PushLite

PushLite provides text messaging abilities. It is lightweight and very easy to use. 

public String[] send(String[] senders, String[] recipients, String message)

Sends out a text message (without subject) to multiple recipients of multiple transport types. Encoding of the message is "text/plain". This method provides the easiest way to send out text messages. Other overloaded send() methods can be used to set subject, reply to, content type encoding (MIME type) and associated key parameters.

senders - an array of senders' addresses. A sender's address has a transport type and address, separated by a colon (:). One sender per transport type. Latest sender of the same transport type will override earlier senders of the same transport type in the array. 

Example 1: "Email:myemail@company.com"
Example 2: "SMS:16505551234"

Valid transport types are defined in 

oracle.panama.messaging.common.TransportType

recipients - recipients' addresses (Oracle9iAS Wireless email address or phone number)

Format of recipient addresses: 

<transport>:<recipient address 1>[,recipient address 2 ...]
Example: SMS:1-650-5551234,1-408-3456789

Recipients of the same transport may be separated into multiple lines, But, these lines may not be separated by recipients of other transport type lines. An exception will be thrown if it has been detected. 

Example 1 -- OK: 
"Email:john@company.com,mary@company.com" 
"Email:bob@company.com" 
"SMS:1-123-45678" 

Example 2 -- ERROR: second email recipients line (bob@company.com) is cut 
off by SMS recipients
"Email:john@company.com,mary@company.com" 
"SMS:1-123-45678" 
"Email:bob@company.com"

message - body of message. 

public String[] send(String[] senders,    String[] replyTOs,  String[] 
recipients,  String[] associatedKeys,


String subject,  String message,  String encoding)

sends out a text message with subject, reply to addresses, associated keys and content type encoding.

senders - senders' addresses (same as described above).

replyTOs - an array of alternate reply to addresses or phone numbers (optional). Use null if no reply to address. The format is the same as senders

recipients'' addresses (Same as above)

associatedKeys - an array of text strings that may be used by client applications to do message tracking. One key per recipient. The length of each key could be up to 64 bytes. The order of the keys are the same as the order of recipients. This field is optional, if no associated key is used, use null.

subject - subject of message (optional).

message - body of message.

encoding - MIME type with optional charset encoding of message. For example: "text/plain", "text/plain; charset=us-ascii" and "text/html" 

public String getStatus(String messageID)

Get current status of one message ID.

Returns: a text status string 

public String[] getStatus(String[] messageIDs)

Get current status of a set of message IDs.

Returns: an array of text status strings.

13.2.1.2 Push

oracle.panama.messaging.push.Push
public WorkOrder[] send(Packet pkt)

Send out a message packet.

pkt - The message packet to be delivered. Packet class will be discussed shortly.

Returns: a set of WorkOrders will be returned after the Push server accepts the request. One WorkOrder for each instance of recipient's address. 

public Status getStatus(WorkOrder workOrder)

Get current status of a work order. One work order has one address and the message ID of that address. 

public Status[] getStatus(WorkOrder[] workOrders)

Get current status of a set of work orders. 

oracle.panama.messaging.push.Packet

Packet class represents a generic message in the real world. (For example: email) It may have a subject, one body or a set of message bodies (multipart). The same message may be delivered to multiple recipients of multiple transport types (delivery types).

For example: the same message can be delivered to 2 email recipients, 3 SMS recipients and 4 fax machines in the same packet.

Every transport type may have a sender, an alternate reply to address and a group of recipients. The packet could have a set of optional delivery instructions, such as priority, registered, etc.

To accomplish this, first construct an empty Packet instance. Then set message, message info, sender, reply to and recipients of the packet. Please see sample code below for more details.

The Push API provides methods to set the properties of a message and dispatch to the Oracle9iAS Wireless instance. For a detailed description of the API interfaces, refer to the Oracle9iAS Wireless Push Javadoc (oracle.panama.messaging.push). To send a push message you will need to provide the following:

To compile and run the Java Push API you will need JDK 1.3 for your platform and Oracle9iAS Wireless Push Java libraries.

13.2.1.3 Example: Send a message to multiple recipients

Use PushLite to send out message to two email recipients and 1 SMS phone. 

     // 2 email and 1 SMS recipients
 String recipients[] = new String[2];
 recipients[0] = new String(TransportType.EMAIL + ":" 
+"john@company.com,mary@company.com");
 recipients[1] = new String(TransportType.SMS + ":" +"1-333-5551234");
  // one email sender and one SMS sender
 String senders[] = new String[2];
 senders[0] = TransportType.EMAIL + ":" + "sender@company.com";
 senders[1] = TransportType.SMS + ":" + "1-222-1234567";
 String messageString = "Hello World!";   // message body
// set the gateway URL to null to use local Push Server. 
// Local Push server is running in the same JVM of Push client. No SOAP is used.  
String gatewayURL = "http://messenger.oracle.com/push/webservices";
 // create a PushLite client instance
 PushLite pushLite = null;
 try{
// In fact, Oracle's hosted Push Server does not require an account
// if you have not signed up, you can use "" as both username and password
pushLite = new PushLite(gatewayURL,"user name","password");
}
 catch(PushException e)
  { e.printStackTrace();   }

// Set proxy if Push client machine is inside firewall and Push Web Services is 
outside firewall.
// Let's assume the proxy server is: www-proxy.company.com:80
 pushLite.setProxy("www-proxy.company.com", 80);

// get supported transport types on Push Web Services
String supportedTransportTypes[] = pushLite.getSupportedTransports( );

// send out a text message
  String wo[] = null;
  try
  {
    wo = pushLite.send( senders, recipients, messageString);
  }
  catch(PushException e)
  {
    System.out.println("**** PushException caught ");
    e.printStackTrace();
  }
  if(wo != null)
  {
    for(int i=0;i< wo.length;i++)
      System.out.println(wo[i]);
  }
// query delivery statuses 
  String status [] = null;
  try{
    pushLite.getStatus(wo);
  } catch(PushException e) { e.printStackTrace(); }
  if(status != null)
  {
    for(int i=0;i< status.length;i++)
      System.out.println("[" + status + "]");
  }

13.2.1.4 Example: Sending an Oracle9iAS Wireless XML Message using PushLite

// In order to send out a Oracle9iAS Wireless XML message, we need to specify 
oracle.panama.messaging.ContentTypes.MOBILE_XML as encoding type when calling 
send( )

// String subject = "message subject";

// send out an Oracle9iAS Wireless XML text message
  String wo[] = null;
  try
  {
	// no reply to addresses, no associated keys in this example
    wo = pushLite.send( senders, null, recipients, null, subject,  
xmlMessageString, oracle.panama.messaging.ContentTypes.MOBILE_XML);

  }
  catch(PushException e) {  ...}

13.2.1.5 Example: OTA: Sending a Ringtone to two cell phones

import oracle.panama.messaging.common.*;
import oracle.panama.messaging.push.*;

        // SMS recipients
        AddressData smsRecipients[] = new AddressData[2];
        smsRecipients[0] = new PhoneAddressData("1-333-5551234");
        smsRecipients[1] = new PhoneAddressData("1-444-5551234");
        // Packet object
        Packet pkt = new Packet();

       AddressData smsSender = new PhoneAddressData("1-222-1234567");

        pkt.setFrom(TransportType.SMS, smsSender);

        pkt.addRecipients(TransportType.SMS, smsRecipients);

        Message msg = new Message();

      // Ring tone message.
       msg.setContentType(RingTone.MIME);
       msg.setSubject("ring tone");
       RingTone ringtone = new RingTone();
       ringtone.setRingToneEncoding(RingTone.RINGTONE_ENC_OTA_ASCII);
       ringtone.setPhoneModel("Nokia 6210");
       
ringtone.setRingTone("024A3A51D195CDD008001B205505906105605585505485408208499000
");
       msg.setContent(ringtone);

       pkt.setMessage(msg);

        String gatewayURL = "http://messenger.oracle.com/push/webservices";

     // create a push client instance
        Push push = null;
        try{
          push = new Push(gatewayURL,"user name","password");
        }
        catch(PushException e) { e.printStackTrace();}

        WorkOrder wo[] = null;
        try
        {
      // send message packet to the server
                wo = push.send(pkt);
        }
        catch(PushException e)
        {
                System.out.println("**** PushException caught ");
                e.printStackTrace();
        }

        if(wo != null)
        {
                for(int i=0;i< wo.length;i++)
                System.out.println(wo[i]);

        // get sending statuses
                Status status[] = null;
                try {
                  status = push.getStatus(wo);
                } catch(PushException e) { e.printStackTrace(); }

                if(status != null)
                {
                for(int i=0;i< status.length;i++)
                                System.out.println(status[i]);
                }
        }

13.2.1.6 Using Push API - WSDL

The Push Service is deployed as a Web Service on the Oracle9iAS Wireless server. The Web service uses SOAP over HTTP. To enable development of push applications on non Java environments, Oracle9iAS Wireless provides a WSDL (Web Services Definition Language) file. The WSDL can be used with any Web services development toolkit that supports your application programming environment and Model. We also ship a standalone package to facilitate development using the Push server; this package is named push_client.zip and is available on the product CD. The WSDL file is provided in the wsdl directory of push_client.zip. Before your development, please verify the Push Web Services location at the end of the wsdl file: 

<service name= "PushServer">
  <port ...>
    <soap:address location= "push web services URL" />
  </port>
</service>

13.3 Oracle9iAS Wireless Messaging System

Oracle9iAS Wireless contains a Messaging subsystem that handles sending and receiving messages to and from devices, and all message routing functions. The driver, a component of this subsystem, implement the actual communication protocol stack while the Messaging system supports Transport API that provides the abstraction for applications to communicate with the Messaging subsystem. The Transport API (just as in the Push API) allows applications to send messages to mobile devices. In addition to sending messages the Transport API allows applications to receive messages from the client devices and also allows the applications to change message routing at runtime.

The Transport API application must be running on the same Java VM as the Oracle9iAS Wireless instance in order to use the Transport API (unlike the Push API which does not have this requirement). Oracle9iAS Wireless internal applications, such as the Async server and alert Engine, use the Transport API to deliver messages to the mobile devices.

Figure 13-4, "Messaging System Architecture" shows the Messaging subsystem architecture. To receive messages from the device, applications must implement a listener interface and register the listener instance with Messaging subsystem.

Figure 13-4 Messaging System Architecture

Text description of push3.gif follows.

Text description of the illustration push3.gif

Transport APIs are independent of the underlying network protocols required to communicate with mobile devices. The underlying network protocols are implemented by the driver. The drivers implement device-specific and wireless communication specific messaging stacks. To deliver messages, the Messaging system uses the appropriate driver to deliver messages to the device. The Transport API supports operations that allow applications to send and receive messages from devices.

The Transport API provides Push applications with the necessary abstraction from the underlying wireless protocols and allows the Push application to be device/network agnostic. The Transport API allows applications, if required, to control message routing with the available drivers.

The Messaging system supports multiple drivers for different wireless protocols and also allows multiple drivers that support a given network protocol. The Messaging system handles all message routing functions, techniques to boost performance, fault tolerance, and supports a highly scalable environment. The API allows developers to customize various functions of the transport system.

The drivers are plugable components in the Messaging system; they handle all network/protocol specific requirements. The Messaging system defines a Driver Interface that provides the necessary decoupling to achieve the required abstraction. The Driver API provides an extensible interface for network and protocol-specific drivers to be plugged into the Oracle9iAS Wireless Messaging system. A driver implementation wraps required network protocol routines for example, an Email driver can implement an IMAP/SMTP interface or use a MAPI interface. Drivers must implement the interface defined by the Messaging system.

13.3.1 Transport Runtime Processes

13.3.1.1 Push SOAP Web Service

The Push Web Service is a Servlet running as part of the VM for Oracle9iAS Wireless runtime, no special or independent process is started for it.

13.3.1.2 Messaging Servers

Messaging server processes are runtime containers for protocol drivers and provide the necessary environment for the drivers. The messaging server runs the driver instances and manages the life cycle of the driver instances. Oracle9iAS Wireless can run multiple messaging servers on different machines.

13.3.1.3 Driver and Driver Instance

Driver is the software that implements Oracle9iAS Wireless Transport Driver interface. A Driver instance is a runtime instantiation of a Driver that runs in a process.

Each driver identifies the type of protocol it handles such as Email or Fax. A single driver can handle more than one protocol. The protocol a driver handles, the implementation class and the drivers configuration parameter are specified using the Oracle9iAS Wireless Webtool.

The drivers are configured as a site level property for an Oracle9iAS Wireless installation and can be registered with one or more messaging servers. Such a configuration allows administrators to load balance and manage hardware resources based on the usage of individual drivers.

13.3.2 Configuration

13.3.2.1 Messaging Server

Using the Oracle9iAS Wireless Webtool a messaging server can be configured in the same way one adds, edits or deletes a server process. Also the Webtool enables you to configure performance parameters and the configuration of driver instances associated with the messaging server. See Oracle9iAS Wireless Getting Started and System Guide for more details.

13.3.2.2 Driver

The Oracle9iAS Wireless Webtool allows you to add, edit or delete a driver. Drivers are site-level properties in the Oracle9iAS Wireless installation. The configuration page allows you to provide details of a driver name, the implementation class and other driver-specific properties.

13.3.2.3 Driver Instances

Once a driver is made available on the site level, instances of the driver can be created and associated with individual messaging servers. You can have multiple instances of a driver running on different messaging servers, and these different instances can have distinct driver parameter settings. For example you could have one Email driver and create instances of the driver that point to different SMTP servers. The same is true for other protocols, such as multiple instances of the SMPP driver with different values for the various Telcos to which your server connects.

13.3.3 Transport API

This section details the Transport API, explaining the major constructs and functionality available to customize the Transport System.

Transport API is the client side messaging interface. Transport API is a rich set of APIs which can be used for both sending and receiving. In terms of sending, transport API provides some extra valued features, such as messaging routing and status tracking.

To receive messages, the application must register listening end points and a message callback listener to the transport system. An endpoint essentially is in the form of an address such as a phone number. It identifies to the transport system how message should be dispatched. When a message is received for a targeted address, it is dispatched to the listener associated with an endpoint with a matching address.

When a message delivery request is submitted, the transport system performs analysis of the recipients and routes the message to the appropriate protocol drivers for delivery.

13.3.3.1 Destination Analysis

A single message can be delivered to multiple recipients of different communication protocols. For example, one can send a meeting reminder to a few people using SMS, and some other people to their email addresses. So before routing messages to drivers, the transport must analyze and group recipients by their delivery category. Typically, the transport system starts its internal processing by analyzing all destinations and groups them accordingly.

13.3.3.2 Message Routing

To send a message, the transport system has to find a proper driver to do so. The process of finding a proper driver is called message routing. The transport system at a particular time may have many messaging servers and protocol drivers configured. Different driver instances may handle different categories of messages. For example, a driver may be able to send SMS messages only. Another one may be able to send email and fax messages only. Therefore, the transport system has to use a driver with SMS capability to send SMS messages, a driver with email capability to send email messages. Sometimes, there may be more than one driver that can handle the same category of messages. For example, there could be more than two SMS drivers. One talks to ATT's SMSC, the other talks to Cingular's SMSC. The transport system must use ATT's SMS driver to send SMS messages to ATT's devices, and use Cingular's SMS driver to send SMS messages to Cingular's devices. All these decisions are made by the transport based on two sets of information. The first set is the sending criteria specified by the application, such as delivery type, speed, cost, encoding and so on. Of these, the delivery type is required and can be specified in the class destination. The other set of information is provided by the set of available drivers. The properties of the drivers are configured by the administrator, such as driver speed, driver cost, encoding and delivery category. As mentioned earlier, routing finds the best matching driver. Some properties must match, for example, the delivery category; some of them just find the closest match, for example, cost and speed.

The transport uses the following info to do the routing:

Attribute encoding is not used in routing this release.

The transport will route a message to a driver with best match:

  1. The delivery category, such as SMS or EMAIL.

  2. The protocol, such as UCP or SMPP.

  3. The carrier, such as Cingular or Telia.

  4. If (speed_requested >= 0 and cost_requested >= 0), the minimum (driver_speed -speed_requested)**2 + (driver_cost - cost_requested)**2

    or

    if cost_requested < 0 the minimum abs(driver_speed - speed_requested)

    or

    if speed_requested < 0, the minimum abs(driver_cost - cost_requested)

    If more than one driver meet the above criteria, the transport chooses randomly one of them.

13.3.3.3 Providing hints to facilitate transport internal processing

Applications can provide hints that help speed up routing and destination analysis. For example, if you specify "Email" as the delivery category of all recipients, the transport will not have to look into each of the recipients to determine what they are.

In principal, the required parameter to deliver a message (the Messenger.send() methods) is Destination and Message. All others (SenderInfo, MessageInfo and DeviceInfo) are optional. When they are specified, they will be interpreted as hints that describe properties common to all recipients. For example, if a DeviceInfo is specified and the getDeliveryType() of this DeviceInfo instance returns DeliveryType.EMAIL.getName() then the transport will take it as a hint that all recipients are email addresses and no destination analysis will be performed.

13.3.3.4 Key interfaces/classes

The key interface is oracle.panama.messaging.transport.Messenger.

An instance of this interface will be returned via get method of oracle.panama.messaging.transport.MessengerController which in turn can be obtained through the TransportLocator class. This gives you access into the rest of the package to build your messaging applications.

Please refer to the javadoc for a complete reference of the APIs.

13.3.3.5 Hooks

Applications can install hooks that will be invoked during message sending and receiving depending on the type of the hook. All hooks are optional. Typically the hooks are passed all of the information the application specifies and can do what ever is appropriate. Hooks are useful in providing routing information, and perform other custom logic in some cases.

There are two main categories of hooks:

No default hook is provided for the product.

13.3.3.5.1 Named Hooks

DriverFinder--(interface oracle.panama.messaging.transport.DriverFinder). The expected semantics of this hook is to fill in the driver name for a delivery request.

CarrierFinder--(interface oracle.panama.messaging.transport.CarrierFinder). This hook is a named hook that can be configured through webtool. The expected semantics of this hook is to locate a carrier for a given device address. The carrier information is then used by the DriverFinder or the transport system to perform routing. It is generally called once per message. There can be only one hook of this kind.

GSMSmartMsgEncoder--(interface oracle.panama.messaging.transport.GSMSmartMsgEncoder). This hook is used to encode GSM smart messages.

FailOverHook--(interface oracle.panama.messaging.transport.FailOverHook). This hook is for future use.

13.3.3.5.2 General Hooks

PreSendingHook--(interface oracle.panama.messaging.transport.GeneralHook). This hook is called before sending any message.

PostSendingHook--(interface oracle.panama.messaging.transport.GeneralHook). This hook is called after sending any message.

PreReceivingHook--(interface oracle.panama.messaging.transport.GeneralHook). This hook is called before passing any received message to the listener.

PostReceivingHook--(interface oracle.panama.messaging.transport.GeneralHook). This hook is called after passing any received message to the listener.

13.3.4 OTA

Oracle Corporation has provided convenience classes to support Ringtone, Graphics and WAP Provisioning. To support other types of OTA such as calendar, see the documentation on the driver that provides such capability.

13.3.5 Sample programs

 A sample program for sending.
 
 /**
  * A simple transport client.
  *
  * @author jxiang
  */
 public class SimpleClient {
 
   public static void main(String[] args) throws Exception {
 
     TransportLocator locator = TransportLocator.getInstance();
     MessagingController controller = locator.getMessagingController();
     Messenger messenger = controller.getMessenger();
     messenger.start();
     Destination dest = new Destination();
     dest.setAddress("1234");
     DeviceInfo di = new DeviceInfo();
     di.setDeliveryType(DeliveryType.SMS.getName());
     dest.setDeviceInfo(di);
     dest.SetDriver("SMSDriver");  // we know we are going to use SMSDriver. You 
can also leave it blank.
     MessageInfo mi = new MessageInfo();
     dest.setMessageInfo(mi);
     SenderInfo si = new SenderInfo();
     Message msg = new Message();
     msg.setContentType("text/plain");
     msg.setSubject("subject");
     msg.setContent("body");
     String id = messenger.send(dest, si, msg, null);
     // try to get the sending status based on the message id.
     // general, you should query the status after some time,
     // allowing the transport to process.
     Status status = messenger.getStatus(id);
     messenger.stop();
   }
 }
A sample program for receiving.
 
 /**
  * Copyright (c) 2001 Oracle Corporation all rights reserved
  */
 
 package oracle.panama.messaging.transport.test;
 
 import java.io.BufferedReader;
 import java.io.InputStreamReader;
 
 import oracle.panama.messaging.common.*;
 import oracle.panama.messaging.transport.*;
 import oracle.panama.model.DeliveryType;
 
 /**
  * A simple transport client.
  *
  * @author jxiang
  */
 public class SimpleClient {
 
   public static void main(String[] args) throws Exception {
 
     TransportLocator locator = TransportLocator.getInstance();
     MessagingController controller = locator.getMessagingController();
     Messenger messenger = controller.getMessenger();
     messenger.start();
     EndPoint point = new EndPoint("a@b.c", DeliveryType.EMAIL.getName());
     messenger.addEndPoint(point);
     point = new EndPoint("1-650-5061234", DeliveryType.SMS.getName());
     messenger.addEndPoint(point);
     messenger.setMessageListener(new ReceivingListener());
     messenger.start();
     System.out.print("Enter quit to quit: ");
     BufferedReader br = new BufferedReader(
       new InputStreamReader(System.in));
     while (true) {
       String buf = br.readLine();
       if (buf != null && buf.equals("quit")); {
         messenger.stop();
         break;
       }
     }
     System.exit(0);
   }
 }
 
 
 class ReceivingListener implements MessageListener {
 
   public int onMessage(String address, DeviceInfo info,
     String destination, Message message) {
     // process received message.
     String contentType = message.getContentType();
     if (contnetType.equals(Ringtone.MIME)) {
        // received a ring tone.
        // printed the attributes.
        Ringtone ringtone = (Ringtone)message.getContent();
        String enc = (String)ringtone.get(Ringtone.RINGTONE_ENCODING);
        // .............	
     }
     return Listener.SUCCEED;
   }
 
 }

13.3.6 Driver Interface APIs

The driver interfaces are intended for the implementation of drivers for particular protocols. As explained above, drivers can be plugged into the transport system rather easily, extending network protocol support to the base product. A driver is expected to be a very thin layer and handles only the protocol specific details. It should not deal with much of life cycle, load balancing or scalability issues. The transport system handles these issues.

The transport system initializes and destroys driver instances by respectively calling the init() and destroy() methods as specified in the Interface Driver. The transport system also handles load balancing and concurrence. A driver should just focus on interpreting the semantics of a particular protocol, leaving all others to the transport system.

Figure 13-5 Driver Lifecycle

Text description of push4.gif follows.

Text description of the illustration push4.gif

A driver can be capable of only "sending", or "receiving", or both. To implement the "sending" semantics, a driver would just implement the send() methods as specified in the interface Driver. Receiving is a bit more complex in that the action to receive is driven by the transport. To implement receiving, a driver fills in the logic to receive in the receive() method specified by the Driver interface. The transport will continuously invoke the receive() method through out the life cycle of the driver instance.

However, the drivers should make every effort to be instance thread safe, or the usage must be clearly conveyed to system administrators so that proper configurations can be set to not thread the driver instance.

This following highlights the key classes and interfaces required for developing the SMS driver interface to work with the Oracle9iAS Wireless Platform.

Note:

All classes mentioned below assumes the package of oracle.panama.messaging.transport unless otherwise specified.

13.3.6.1 Class oracle.panama.messaging.transport.TransportLocator

The class TransportLocator defines interfaces that provides initial access to both the messaging interface and the driver interface. Two key methods defined for this class are:

13.3.6.2 Interface oracle.panama.messaging.transport.Driver

This is the main interface for you to develop drivers for a particular protocol. You develop a driver by implementing the Driver interface. Your component is a qualified Oracle9iAS Wireless driver if it implements this interface.

13.3.6.2.1 The init() and destroy() methods

These are the methods controlling the life cycle of the driver instance. The initialization properties passed to the init method are those specified through the Webtool configuration framework.

The init() method should return an initialization status, which can be one of: 

Driver.FAILED, Driver.SEND, Driver.RECEIVE
Driver.SEND_RECEIVE.

Ensure the status returned is consistent with those configured through the webtool UI. If different, then the status returned here takes precedence.

13.3.6.2.2 The send() method

Drivers implement this method to perform whatever is appropriate for their particular protocols to send out messages. The content to delivery is stored in the Message object passed onto the send() method, while the address parameter specifies one or more recipients to deliver the message to.

Further, the driver is expected to return a unique id for each message, or IDs one for each of the recipients. These ids will be used by the transport to query status of the delivery when necessary.

The driver must return a null message ID to make the transport retry. Exceptions thrown out of the send method are ignored, except for exceptions of type DriverException. If the send () method throws an exception of the type DriverException, the transport will not retry. If the code of the exception is marked fatal, the sending capability of this driver instance is revoked. If the exception is not marked fatal, the driver will still be used to send other messages.

13.3.6.2.3 The receive() method

Drivers implement this method to perform whatever is appropriate for their particular protocols to receive messages. As mentioned above, the transport would drive the operation. Normally, the driver is expected to return from this method once a message is received. This way controlled is yielded back to the transport regularly so that the transport and decide the best step to take next.

The receive() method is called continuously by the transport. Hence it is preferable the receive() method blocks if it does not receive any messages. However it should not block indefinitely otherwise it will be considered a runaway operation and the thread that calls the receive will be terminated. The time elapse for runaway threads can be configured by setting "Maximum Execution Time per Request" under runtime configuration (default is 120 second). When a message is received, it should call the onMessage method of the Message Listener to submit the message (or, the onStatus callback on Status Listener if the message was a status report). The method can throw an exception of type DriverException and mark it fatal to ask the transport to stop calling the receive () method. The reason for this design is to simplify the logic and thread control of the driver.

13.3.6.2.4 The getStatus() method

The transport calls this method in an attempt to retrieve delivery status for a particular message.

13.3.6.2.5 The queryTracking() and queryNotifying() methods

With some protocols, an active poll to the external service must be performed to check status of messages previously sent. These methods are called by the Transport to determine whether a getStatus() must be issued to retrieve status, or the driver would pass status back to Transport without such call (in this case, typically the driver calls onStatus() inside receive() ).

13.3.6.3 Interface oracle.panama.messaging.transport.DriverManager

This provides entry point into other driver related utilities and interfaces such as Message Listener. You can get an instance of the DriverController by calling the getDriverController() method of the Locator.

Figure 13-6 Flow of Message and Status

Text description of push5.gif follows.

Text description of the illustration push5.gif

13.3.6.3.1 The getMessageListener() and getStatusListener() methods

These methods return the Transport callback instances for the receiving messages or status. You typically call the onMessage() or onStatus() methods within your implementation of the receive() method in the Driver interface to pass on messages and status to the Transport system respectively.

13.3.6.4 Interface oracle.panama.messaging.transport.GSMSmartMSGEncoder

If your implementation needs to handle UCP style smart message delivery, such as OTA WAP provisioning, ring-tone, graphics, you may find this interface useful.

We ship a default implementation of this interface, which can be located by getting the value for a property named "wireless.messaging.gsmsms.encoder.class". The default implementation handles OTA WAP provisioning, ringtone, and graphics for Nokia and Ericsson handsets.

If you would like to extend the base capability you can do so by developing your own implementation by extending this interface. Once done, you should then configure the transport property "wireless.messaging.gsmsms.encoder.class" to have the value of the class of your implementation.

13.3.6.4.1 The encode() method

This is the only method needed for the interface. The parameters indicate the type (ringtone, graphics), model (Nokia, Ericsson) and all the attributes relevant to the requested type.

You process the information and eventually return the encoded message in a form of GSMSmartMsg, which is essentially the fragments for the message and some specific smart message info.

It might happen that either the type, or model or other are of something your implementation does not support. In this case, you have two choices:

13.3.6.5 Interface oracle.panama.messaging.transport.MessageListener and StatusListener

You obtain instance of these interfaces by calling the appropriate methods in the DriverManager interface.

You use them typically within your implementation of the receive() method in the Driver interface to inform the availability of messages or status to the Transport system.

13.3.6.6 Class oracle.panama.messaging.common.Message

The message class is used to capture the content to be delivered or received. It is pretty comprehensive and has similar expressive power as email. It supports multi-part messages and allows mime types to be associated with the content. However, how to deal with the particular parts or MIME types is left for the implementation of the drivers.

13.3.6.7 Class oracle.panama.messaging.common.ContentTypes

This class is not a class only for drivers. It specifies a few content types (MIME types) in addition to the standard MIME types. As driver implementers, you might encounter these MIME types. How to deal with these MIME types is left to the individual driver, but it is critical that you are aware of them rather than failing when presented.

13.3.6.8 Properties of the driver

While adding a driver to the Oracle9iAS Wireless through webtool, a set of properties must be specified, as listed in the table below.

Table 13-1 Driver properties

Name Description

Name

A discretionary name for the driver. This is a required property.

Class

The class that implements the driver. This is a required property.

Delivery Category

The supported categories of transport it supports, such as SMS, Email. This is a required properties.

Protocol

The particular protocol the driver transmits, such as SMPP or UCP. This is optional. Default is "*", meaning all of the possibilities.

Carrier

The carrier the driver can support, such as Cingular, Telia. This makes sense particularly in the SMS area and is optional. Default is "*", meaning all the possible carriers.

Speed

Speed of the driver. This can be used to better load balancing. This is optional, with possible value ranging from 0-10. Default is 0 (slowest).

Cost

Cost to use this driver. This can be used to improve load balancing. This is optional, with possible value ranging from 0-10. Default is 0 (most inexpensive).

Capabilities

Whether the driver can send, receive or both. This is optional defaulted to "send only".

Number of Message queues

This must be 1 (one) for this release.

Encoding, locale

Not used in this release.

13.3.6.9 Custom properties for a driver

When installing a driver, custom properties can be specified for the driver to function. For example, for an email driver to work, it might need to have a property for the imap hostname. The driver can be coded to expect a property of, say, name imap.hostname. When adding a driver through webtool, one can specify any number of property names. When creating the driver instances, the specific values of such a property can be provided. For example, out of the same driver code, one can install two email driver instances, each provided with imap hostnames to two distinct IMAP servers.

These set of custom properties will be passed into the driver instance when init() is called. In addition to the set of custom properties, some Oracle9iAS Wireless site-level properties are also passed implicitly, they are: 

 "wireless.log.directory";
 "wireless.firewall.http.use.proxy";
 "wireless.firewall.http.proxy.host";
 "wireless.firewall.http.proxy.port";
 "wireless.firewall.http.non.proxy.hosts";
 "wireless.firewall.ftp.use.proxy";
 "wireless.firewall.ftp.proxy.host";
 "wireless.firewall.ftp.proxy.port";
 "wireless.firewall.authentication.set";
 "wireless.firewall.authentication.username";
 "wireless.firewall.authentication.password";

13.3.6.10 Example: A Sample Driver

  // Copyright (c) 2001 Oracle Corporation. All rights reserved.
 package oracle.panama.messaging.transport.driver.sample;
 
 /**
  * A SimpleDriver class.
  * <P>
 * @author Oracle Corporation
  */
 
 import java.util.Properties;
 import java.net.ServerSocket;
 import java.net.Socket;
 import java.io.BufferedReader;
 
 import java.io.PrintStream;
 import java.io.InputStreamReader;
 import java.io.IOException;
 import java.io.PrintWriter;
 import java.io.FileOutputStream;
 import java.text.SimpleDateFormat;
 
 import oracle.panama.messaging.transport.*;
 import oracle.panama.messaging.common.*;
 import oracle.panama.model.DeliveryType;
 import oracle.panama.util.MessageCatalog;
 import oracle.panama.core.admin.L;
 
 /**
  * A Simple driver
  *
  * @author ashah
  */
 public class SimpleDriver implements Driver {
 
   private String mCompanyName;
   private String mDeliveryType;
   private String mVersion;
   private PrintWriter log = null;
 
   /**
    * Initialize the driver.
    *
    * @param properties the driver's properties.
    * @return the initialization status.
    */
   public int init(Properties properties) {
 
     // get the locator instance and various listeners
     TransportLocator locator = TransportLocator.getInstance();
     DriverController manager = locator.getDriverController();
     mMessageListener = manager.getMessageListener();
     mStatusListener = manager.getStatusListener();
 
     // read properties
     mCompanyName = properties.getProperty("company-name");
 
     // delivery type is needed. Use SMS
     mDeliveryType = DeliveryType.SMS.getName();
     mVersion = "1.0";
 
 
     int status = Driver.FAILED;
 
     try {
       String logName = properties.getProperty("logfile");
       if (logName == null)
         logName = new String("SimpleDriver.log");
       log = new PrintWriter(new FileOutputStream(logName, true ) );
       } catch(Exception e) {
         e.printStackTrace();
       return status;
     }
 
     log ("initialized: " + new java.util.Date());
     mPort = Integer.parseInt(properties.getProperty("port"));
     mCounter = System.currentTimeMillis();
     mPrefix = "unknown::";
     mDelay = 20000;  // 20 seconds
     mMessage = new Message();
     mSemaphore = new Object();
     status = Driver.SEND_RECEIVE; // TODO - verify the return code
 
     mStatus = new Status();
 
     log ("init complete");
     return status;
   }
 
   /**
    * Destroy the driver.
    */
   public void destroy() {
     try {
       log ("destroy");
       mServerSocket.close();
       mReader.close();
       mWriter.close();
       log ("destroy complete");
     }
     catch (Exception e) {
     }
   }
 
   /**
    * Get the version of the driver.
    *
    * @return the version of the driver.
    */
   public String getVersion() {
     return mVersion;
   }
 
   /**
    * Get additional information of the listener.
    *
    * @return the information of the listener.
    */
   public String getInfo() {
     return "Simple Driver";
   }
 
   /**
    * Send a message to a single address with this driver.
    *
    * @param address the address to send to.
    * @param encoding the encoding of the device.
    * @param tracking the tracking level.
    * @param expiration the expiration time.
    * @param reliability the reliability level.
    * @param fromAddr the from-address.
    * @param replyToAddr the reply-to-address.
    * @param message the message to send.
    * @return a unique message id, null if failed.
    */
   public String send(String dtype, String address, int mode, String encoding,
     int tracking, int expiration, int reliability, String fromAddr,
     String replyToAddr, Message message) {
 
     log ("send: " + address + " => " + message.getContent());
     String id = null;
     try {
       id = mPrefix + getNextId();
       mWriter.println(id);
       mWriter.println(message.getContent());
       mWriter.flush();
     }
     catch (Exception e) {
       // not synchronized, it works for this toy.
       mWriter = null;
       mReader = null;
       id = null;
     }
     log ("sent id: " + id );
     return id;
   }
 
   /**
    * Send a message to a list of addresses with this driver.
    *
    * @param addresses the addresses to send to.
    * @param encoding the encoding of the device.
    * @param tracking the tracking level.
    * @param expiration the expiration time.
    * @param reliability the reliability level.
    * @param fromAddr the from-address.
    * @param replyToAddr the reply-to-address.
    * @param message the message to send.
    * @return a list of unique message ids, null if failed.
    */
   public String[] send(String dtype, String[] addresses, int[] modes, String 
encoding,
     int tracking, int expiration, int reliability, String fromAddr,
     String replyToAddr, Message message) {
     String[] ids = null;
     log ("send: multiple => " + message.getContent());
     try {
       int count = addresses.length;
       ids = new String[count];
       String id = mPrefix + getNextId();
       ids[0] = id;
       mWriter.print(id);
       for (int i=1; i<count; i++) {
         id = mPrefix + getNextId();
         ids[i] = id;
         mWriter.print(',' + id);
       }
       mWriter.println();
       mWriter.println(message.getContent());
       mWriter.flush();
     }
     catch (Exception e) {
       // not synchronized, it works for this toy.
       mWriter = null;
       mReader = null;
       ids = null;
     }
     log ("sent multiple");
     return ids;
   }
 
   /**
    * Send a message to a list of addresses with this driver.
    *
    * @param dtypes the delivery types for all destinations
    * @param addresses the addresses to send to.
    * @param modes the delivery modes
    * @param encoding the encoding of the device.
    * @param tracking the tracking level.
    * @param expiration the expiration time.
    * @param reliability the reliability level.
    * @param fromAddr the from-address.
    * @param replyToAddr the reply-to-address.
    * @param message the message to send.
    * @return a list of unique message ids, null if failed.
    */
   public String[] send(String[] dtypes, String[] addresses, int[] modes, String 
encoding,
     int tracking, int expiration, int reliability, String fromAddr,
     String replyToAddr, Message message) throws DriverException  {
     String[] ids = null;
 
     int count = addresses.length;
     log ("send: " + count + " recipients : " + message.getContent());
     ids = new String[count];
 
     for (int i=0; i<count; i++) {
       ids[i] = send(dtypes[i], addresses[i], modes[i], encoding, tracking, 
expiration, reliability, fromAddr,
                     replyToAddr, message);
     }
     return ids;
   }
 
 
   /**
    * Get the sending status of a message.  The
    * status got by this call should be reported
    * the transport system via the driver listener
    * onStatus callback.
    *
    * @param mid the id of the message.
    */
   public void getStatus(String mid) {
   }
 
   /**
    * Get the sending statuses of a list of messages.
    * The statuses got by this call should be reported
    * the transport system via the driver listener
    * onStatus callback.
    *
    * @param mids the ids of these messages.
    */
   public void getStatus(String[] mids) {
   }
 
   /**
    * Check if query is required to get the notification.
    *
    * @return true if required, false otherwise.
    */
   public boolean queryNotifying() {
     return false;
   }
 
   /**
    * Check if query is required to track the
    * sending status.
    *
    * @return true if required, false otherwise.
    */
   public boolean queryTracking() {
     return false;
   }
 
   /**
    * Receive a message/status.  If any message/status
    * is received, the driver should use the onMessage/
    * onStatus callbacks of the driver listener (got
    * via the controller) to report it to the transport
    * system.  This method should do something if the
    * initization status has the RECEIVE ability.
    */
   public void receive() {
     log ("receive started");
     synchronized (mSemaphore) {
       try {
         if (mServerSocket == null) {
           try {
             mServerSocket = new ServerSocket(mPort);
             mServerSocket.setSoTimeout(mDelay);
           }
           catch (IOException ioe) {
             mServerSocket = null;
             mSocket = null;
             throw ioe;
           }
         }
         if (mSocket == null) {
           try {
             mSocket = mServerSocket.accept();
             mSocket.setSoTimeout(mDelay);
           }
           catch (IOException ioe) {
             mSocket = null;
             throw ioe;
           }
         }
         if (mReader == null) {
           mReader = new BufferedReader(
             new InputStreamReader(mSocket.getInputStream()));
           mWriter = new PrintStream(mSocket.getOutputStream());
         }
         String buf = mReader.readLine();
         log ("receive read: " + buf);
         if (buf.charAt(0) == '*') {
           String address = buf.substring(1);
           mMessage.setContent(mReader.readLine());
           DeviceInfo info = new DeviceInfo();
           info.setDeliveryType(mDeliveryType);
           info.setEncoding("7b");
           String from = "FROM-ME-TODO";
           mMessageListener.onMessage(from, info, address, mMessage);
           log ("message sent to message listener");
         }
         else {
           mStatus.setContent("received");
           mStatusListener.onStatus(buf.substring(1), mStatus);
           log ("status sent to status listener");
         }
       }
       catch (IOException ioe) {
         mReader = null;
         mWriter = null;
       }
     }
   }
 
   private synchronized long getNextId() {
     if (++mCounter < 1) mCounter = 1;
     return mCounter;
   }
 
 
     /**
    * write to message log
    *
    * @param message string
    */
   void log(String message) {
     if( log != null ) {
       synchronized( log ) {
         String currentTime = new SimpleDateFormat( "yyyy-MM-dd 
HH:mm:ss").format( new java.util.Date() );
         log.println(currentTime + " " + message);
         log.flush();
       }
     }
   }
   
   private Socket mSocket;
   private Object mSemaphore;
   private ServerSocket mServerSocket;
   private MessageListener mMessageListener;
   private StatusListener mStatusListener;
   private BufferedReader mReader;
   private PrintStream mWriter;
   private Message mMessage;
   private Status mStatus;
   private String mPrefix;
   private long mCounter;
   private int mDelay;
   private int mPort;
 
 }

13.4 Oracle9iAS Wireless Pre-built Drivers

As explained before, drivers are plug-in components to Oracle9iAS Wireless that extends protocol-specific support of the system. Oracle9iAS Wireless ships with a few pre-built drivers that support major protocols that have been accepted as industry standards.

The pre-built drivers handle communication protocols such as SMS (SMPP and UCP), Email, Voice, Fax. The following section provides a brief overview of these pre-built drivers and the configuration properties required for these drivers. The pre-built drivers implement only a subset of the communication protocols specification that are sufficient to construct and deliver and receive a message. The pre-built Oracle9iAS Wireless drivers typically do not implement the complete specification of the communication protocols.

13.4.1 PushClient Driver

This driver uses a Hosted Push service and by default uses the service hosted by Oracle Corporation. This driver essentially acts like a Push client to an Oracle9iAS Wireless server hosted on the Internet and can be configured to point to any service that supports the Oracle9iAS Wireless Push Web Service. The PushClient driver uses a special protocol, SOAP over HTTP (the Oracle9iAS Wireless Push Web Service). As a matter of fact, the Oracle hosted push server does not require any account for access. If you have not signed up, you can use "" as both username and password. The URL for it is: http://messenger.us.oracle.com/push/webservices

13.4.1.1 Class name

 oracle.panama.messaging.transport.driver.push.PushDriver

13.4.1.2 Configuration

This driver handles sending only. It supports as many transport types as the Hosted Push Service. The actual types supported are dependent on which Hosted (Oracle9iAS Wireless Instance) service is running. The Oracle9iAS Wireless Service supports an API that describes the exact transports supported by an Instance.

13.4.2 Email Driver

13.4.2.1 Classname

oracle.panama.messaging.transport.driver.email.EmailDriver

The email driver supports SMTP in delivering messages, and either IMAP or POP3 in receiving messages. This driver can handle sending and receiving messages. Both IMAP or POP3 protocols are supported for receiving messages.

13.4.2.2 Configuration

13.4.3 Voice Driver

The voice driver supports the Out Bound Call protocol supported by VoiceGenie. Currently, it has been tested only to work with a VoiceGenie gateway. This driver handles sending messages only. Although the driver can send messages only, it should be configured to have both sending and receiving capabilities for the driver to work.

This driver can handle content type text

For other content types, the driver will throw a non-fatal driver exception.

13.4.3.1 Classname

oracle.panama.messaging.transport.driver.voice.VoiceGenieDriver

13.4.3.2 Configuration

13.4.4 UCP Driver

UCP (Universal Communication Protocol) is one of the most popular GSM SMS protocols. The Oracle9iAS Wireless Server product ships with a pre-built implementation of the UCP driver as a driver that is capable of both sending and receiving.

This driver can handle content type text

For other content types, the driver will throw a non-fatal driver exception.

13.4.4.1 Classname

oracle.panama.messaging.transport.driver.sms.UCPDriver

13.4.4.2 Configuration

This is the maximum size for each chunk in byte. The default is 150.

Notes:

1) If you have a direct TCP connection to the SMSC, the driver uses Command 60 to start a session with the SMSC. This allows the driver and the SMSC to communicate with one socket connection for sending, receiving and status. In this case the sms.server.url is not used.

2) If the connection you have to a SMSC is HTTP based then you should provide the value for sms.server.url and this is the URL the driver instance uses to send messages. Also sms.receiver.listener.port should be provided so that the driver instance opens binds to this port for incoming messages. In the HTTP connection case, sms.server.host and sms.server.port are not used.

3) sms.message.chunksize controls the size of each message in case the message total size is bigger than one SMS message. sms.message.maxchunks controls the maximum number of chunks allowed for each message. Those beyond that will be discarded.

13.4.5 SMPP Driver

SMPP (Short Message Peer to Peer) is one of the most popular GSM SMS protocols. Oracle9iAS Wireless Server product ships with a pre-built implementation the SMPP driver as a driver that's capable of both sending and receiving. The driver opens TCP connection to the SMSC as a transceiver, hence only one connection (initiated by the driver) is needed for all communication between the driver and the SMSC.

This driver can handle content type text ContentTypes.URL (only if the content type of the related resource is text). For other content types, the driver will throw a non-fatal driver exception.

13.4.5.1 Classname

 oracle.panama.messaging.transport.driver.sms.SMPPDriver

13.4.5.2 Configuration

13.4.6 Fax Driver (RightFax)

This a Driver that support Fax message and supports RightFax (by Captaris) FAX protocol. The driver depends on the RightFax software package and the availability of a RightFax Fax server to deliver fax messages. This driver is capable of only sending messages.

This driver can handle any content type. It particularly recognize the following MIME types:

In the case of the ContentTypes.URL, the driver will retrieve the content from the specified URL. The content and MIME type returned by this operation will become content and MIME type sent to the fax server.

13.4.6.1 Classname

 oracle.panama.messaging.transport.driver.fax.RightFAXDriver

13.4.6.2 Configuration

Go to previous page Go to next page
Oracle
Copyright © 2002 Oracle Corporation.
All Rights Reserved.
Go To Documentation Library
Home		 Go To Product List
Solution Area		 Go To Table Of Contents
Contents		 Go To Index
Index