| Oracle® Communications Services Gatekeeper Communication Service Guide Release 5.0 Part Number E21362-01 |
|
|
View PDF |
| Oracle® Communications Services Gatekeeper Communication Service Guide Release 5.0 Part Number E21362-01 |
|
|
View PDF |
This chapter describes the 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 the appendix on standards and specifications in Concepts Guide.
Using the EWS WAP Push/PAP communication service, an application can:
Send a WAP Push message.
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 the appendix on standards and specifications in Concepts Guide 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 of Extended Web Services WAP Push in Application Developer's Guide.
For information about the RESTful Call Notification interface, see the discussion of WAP Push in RESTful 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
For general information, see Appendix A, "Events, Alarms, and Charging."
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 18-1 lists the IDs of the EDRs created by the EWS WAP Push communication service.
Table 18-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 18-3 lists the technical specifications for the communication service.
Table 18-3 Properties for EWS WAP Push/PAP
| Property | Description |
|---|---|
|
Managed object in Administration Console |
domain_name > OCSG > server_name > Communication Services > plugin_instance_id |
|
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 |
|
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 "Managing and Configuring the Plug-in Manager" in 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 "Managing and Configuring the Plug-in Manager" in 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:
Specify heartbeat behavior. See "Configuring Heartbeats" in System Administrator's Guide.
Set up the routing rules to the plug-in instance. See "Managing and Configuring the Plug-in Manager" in 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 "Defining Global Node and Service Provider Group Node SLAs" and "Managing SLAs" in the Accounts and SLAs Guide.
Provision the service provider accounts and application accounts. For information, see Accounts and SLAs Guide.
This section describes the attributes for configuration and maintenance:
Scope: Cluster
Unit: Not applicable
Format: Boolean
Specifies whether basic authentication is used.
Scope: Cluster
Unit: Not applicable
Format: String
Specifies the password used for basic authentication.
Scope: Cluster
Unit: Not applicable
Format: String
Specifies the user used for basic authentication.
Scope: Server
Unit: Not applicable
Format: String
Specifies the URL of the plug-in instance. Used by the Push Proxy Gateway (PPG) to send notifications of results to the plug-in instance.
Scope: Cluster
Unit: Not applicable
Format: String
Specifies the URL of the Push Proxy Gateway (PPG) the plug-in instance uses.
Scope: Cluster
Unit: Not applicable
Format: Boolean
Specifies whether delivery reports are sent to the application. Set to true if delivery reports are sent, false if they are not.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
