This chapter describes the Oracle Communications Services Gatekeeper Extended Web Services (EWS) WAP Push/Push Access Protocol (PAP) communication service in detail.
The EWS WAP Push/PAP communication service exposes the Oracle Extended Web Services WAP Push interface.
The communication service connects to a Push Proxy Gateway (PPG) using Push Access Protocol (PAP) 2.0. See "Push Access Protocol (PAP) 2.0" for information about this network protocol.
For the exact version of the standards that the communication service supports for the application-facing interfaces and the network protocols, see Services Gatekeeper Statement of Compliance.
Using the EWS WAP Push/PAP communication service, an application can:
Send a WAP Push message to a single or multiple (bulk) destinations.
Send a replacement WAP Push message.
Ask to be notified asynchronously of the status of WAP Push messages that have been sent. The possible values returned include:
Rejected: The message was not accepted.
Pending: The message is in process.
Delivered: The message was successfully delivered to the end-user.
Undeliverable: The message could not be delivered because of a problem.
Expired: The message reached the maximum age allowed by server policy or could not be delivered by the time specified in the push submission.
Aborted: The mobile device aborted the message.
Timeout: The delivery process timed out.
Cancelled: The message was cancelled through the cancel operation.
Unknown: The server does not know the state of the message.
Send a result notification message. This occurs only if the initial push submission was accepted for processing. One result notification message is sent per destination address.
EWS WAP Push/PAP supports a subset of the PAP 2.0 operations. These include:
push-message: Submits a message to be delivered. This operation is also used to send a replacement message.
push-response: The response to the push-message operation. This response includes a code specifying the immediate status of the message submission, of the following general types:
1xxx Success: The action was successfully received, understood, and accepted
2xxx Client Error: The request contains bad syntax or cannot be fulfilled
3xxx Server Error: The server failed to fulfil an apparently valid request
4xxx: Service Failure: The service could not be performed. The operation may be retried
resultnotification-message: Specifies the final outcome of a specific message for a specific recipient. Sent only if the initial request includes the URL to which this notification is to be delivered. Includes both textual indication of state and a status code including the following general types:
1xxx Success: The action was successfully received, understood, and accepted
2xxx Client Error: The request contains bad syntax or cannot be fulfilled
3xxx Server Error: The telecom network node failed to fulfil an apparently valid request
4xxx: Service Failure: The service could not be performed. The operation may be retried
5xxx: Mobile Device Abort: The mobile device aborted the operation.
resultnotification-response: The response to the result notification. This response includes a code specifying the status of the notification
1xxx Success: The action was successfully received, understood, and accepted
2xxx Client Error: The request contains bad syntax or cannot be fulfilled
badmessage-response: A response indicating that request is unrecognizable or is of a protocol version that is not supported. This response contains either a 3002 code (Version not supported) or a 2000 code (Bad Request). In the case of Bad Request, a fragment of the unrecognizable message is included in the response
See Services Gatekeeper Statement of Compliance for the exact version of the protocol standard Services Gatekeeper supports.
For information about the application interface for the Extended Web Services WAP Push communication service, see the discussion on Extended Web Services WAP Push in Services Gatekeeper Application Developer's Guide.
For information about the RESTful Call Notification interface, see the discussion on WAP Push in Services Gatekeeper Application Developer's Guide.
The RESTful Service Call Notification interfaces provide RESTful access to the same functionality as the SOAP-based interfaces. The internal representations are identical, and for the purposes of creating SLAs and reading CDRs, and so on, they are the same.
The EWS WAP Push/PAP communication service generates Event Data Records (EDRs), charging data records (CDRs), alarms, and statistics to assist system administrators and developers in monitoring the service
See "Events, Alarms, and Charging" for more information.
EWS WAP Push/PAP-specific CDRs are generated under the following conditions:
When the sendPushMessage response returns from the network.
When a sendResultNotificationMessage response returns from the application.
Table 26-1 lists the IDs of the EDRs created by the EWS WAP Push communication service.
Table 26-2 maps methods invoked from either the application or the network to the transaction types collected by the Services Gatekeeper statistics counters.
This section describes the properties and workflow for the EWS WAP Push/PAP plug-in instance.
Table 26-3 lists the technical specifications for the communication service.
Table 26-3 Properties for EWS WAP Push/PAP
| Property | Description |
|---|---|
|
Managed object in Administration Console |
To access the managed object, select domain_name, then OCSG, then server_name, then Communication Services, then plugin_instance_id in that order. |
|
MBean |
Domain=com.bea.wlcp.wlng Name=wlng_nt InstanceName=same as the network protocol instance_id assigned when the plug-in instance is created Type=com.bea.wlcp.wlng.plugin.pushmessage.pap.management.PushMessagePAPMBean Documentation: See the ”All Classes” section of Services Gatekeeper OAM Java API Reference |
|
Network protocol plug-in service ID |
Plugin_ews_push_message_pap |
|
Network protocol plug-in instance ID |
The ID is assigned when the plug-in instance is created. See the discussion about configuring and managing the plug-in manager in Services Gatekeeper System Administrator's Guide. |
|
Supported Address Scheme |
tel, wapuser See "WAP User Address Scheme" for information on the wapuser address scheme. |
|
Application-facing interface |
com.bea.wlcp.wlng.ews.plugin.PushMessagePlugin com.bea.wlcp.wlng.ews.callback.PushMessageNotificationCallback |
|
Service type |
PushMessage |
|
Exposes to the service communication layer a Java representation of: |
Extended Web Services WAP Push |
|
Interfaces with the network nodes using: |
Push Access Protocol (PAP), 2.0. WAP-247-PAP-20010429-a |
|
Deployment artifact: NT EAR wlng_nt_push_message_ews.ear |
ews_push_message_service.jar, Plugin_ews_push_message_pap.jar, and ews_push_message_pap.war |
|
Deployment artifact: AT EAR: Normal wlng_at_push_message_ews.ear |
ews_push_message.war, ews_push_message_callback.jar, and rest_push_message.war |
|
Deployment artifact: AT EAR: SOAP Only wlng_at_push_message_ews_soap.ear |
ews_push_message.war and ews_push_message_callback.jar |
The wapuser address scheme supports the client address formats defined in the Wireless Application Protocol Push Proxy Gateway Service Specification.
To use the wapuser address scheme, the application should set the WAPPUSH and TYPE values in the destinationAddress. For example, given the address:
WAPPUSH=+155519990730
TYPE=PLMN@ppg.carrier.com
set the destinationAddress to:
WAPPUSH=+155519990730/TYPE=PLMN@ppg.carrier.com
Given the address:
WAPPUSH=john.doe%40wapforum.org
TYPE=USER@ppg.carrier.com
set the destinationAddress to:
WAPPUSH=john.doe%40wapforum.org/ TYPE=USER@ppg.carrier.com
Following is an outline for configuring the plug-in using the Administration Console.
Create one or more instances of the plug-in service. See the discussion about configuring and managing the plug-in manager in Services Gatekeeper System Administrator's Guide. Use the plug-in service ID as listed in the "Properties for EWS WAP Push/PAP" section.
Using the Administration Console or an MBean browser, select the MBean for the plug-in instance. The MBean display name is the same as the plug-in instance ID assigned when the plug-in instance was created.
Define the characteristics of the PPG server to connect to using the PPGNotificationURL and PPGURL fields.
Specify heartbeat behavior. See the discussion on configuring heartbeats in Services Gatekeeper System Administrator's Guide.
Set up the routing rules to the plug-in instance. See the discussion about configuring and managing the plug-in manager in Services Gatekeeper System Administrator's Guide. Use the plug-in instance ID and address schemes listed in the "Properties for EWS WAP Push/PAP" section.
If required, create and load a node SLA. For details see the discussion on defining global node and service provider group node SLAs and managing SLAs in Services Gatekeeper Accounts and SLAs Guide.
Provision the service provider accounts and application accounts. For information, see Services Gatekeeper Portal Developer's Guide.
For a description of the attributes and operations of the PushMessagePAPMBean MBean, see the ”All Classes” section of Services Gatekeeper OAM Java API Reference.