Building Billing Processes with BPEL for Telecom Web Services

  This is the last prototype project I did before I left Oracle. The goal is to explore a general approach for building flexible business processes to control Telecom Service Delivery by integrating Oracle BPEL PM with Oracle Web Services Manager (OWSM). So, Oracle BPEL Process Manager and Oracle Web Services Manager (OWSM) can be used as foundation platform to build Telecom Service Gateway.

  The sample Telecom Service we used is a Parlay X Send SMS Web Service built on top of Oracle Application Server Wireless Messaging. The whole Service Delivery Platform environment I set up is shown in the following diagram:
  For this project, one key thinking is that, in the governed SOA world, exposed Web Services or Business Services should be protected by certain Control Policies and we can orchestrate at least some type of Control Policy, such as Orchestrate Pre-Paid Billing Policy, Using BPEL.

  In general, we can see at least two types of control policies in the real world: declarative policy and process-driven policy. “Only the users with manager role can access Approving-PO Web Service” is a typical example of declarative policy. Process-driven policy usually involves a list of process steps to enforce the policy before and after service invocation. “Billing Policy” used in Telecom Industry, especially “Pre-Paid Billing Policy” is a typical example of process-driven policy.

  To use a service enforced by Pre-Paid Billing Policy, the service consumer will usually pay certain a mount of money as credit before he can start to use the service. Later, every time he/she uses the service his/her credit will be deducted based on the usage. Once the credit is used up, he/she will not allowed to use the service anymore unless he/she put new money in. Actually, it can be described as a list of processing steps as the following:

1. A Service Request come in and the User has been authenticated
2. User will be authorized if his account has enough credit for the service involved
3. An adequate fund has been reserved from user account
4. If the Service Request has been fulfilled successfully, the reserved fund will be transferred to service provider. If the service request failed due to network or server or other issues, the reserved fund should be returned to user's account as credit available

  Since Process-Driven Policy often invoke a list of pre-processing and/or post-processing steps, some of them might also be long-standing steps, BPEL actually is an ideal language/tool to describe and enforce it. The Pre-Paid Billing Policy described above can be easily implemented by orchestrated BPEL Processes.

  Assuming there is a BPEL Engine like Oracle BPEL PM running all the Pre-Paid Billing Policy Processes which integrated with existing external Billing System through exposed Web Service Interfaces, and there is a Service Execution and Enforcing Environment, such as Oracle Web Service Manager which will notify Billing Policy Process at different execution phases. The Pre-Paid Billing Policy can easily be orchestrated by multiple BPEL Processes as the following diagram shown:

  When the service request is received in the Service Execution Environment, the associated Policy Enforcement Point (PEP) will invoke the "Rating And Fund Reservation Billing Process" with collected Service Detail Record (SDR), which will check the user's credit at real time, reserve the fund if there is enough fund available and start "QoS And Charging Billing Process".

  "QoS And Charging Billing Process" will in turn start "Service Notification Process" waiting for the Asynchronous Service Notification.

  Then the Policy Enforcement Point (PEP) will notify "Service Notification Process" whether the Service Request is fulfilled, which will in turn notify the "QoS And Charging Billing Process", which will cancel the reserved fund if the request is failed to fulfill, otherwise, it will start "Post-Pay Confirmation Process" waiting for the final status notification once the final fulfillment is confirmed, which will finally let the "QoS And Charging Billing Process" deduct/transfer the reserved fund.

  In addition, "Service Notification Process" is also responsible to notify the "QoS And Charging Billing Process" in case that the Service Invocation is crushed without a chance to send out the notification.

  The Pre-Paid Billing Policy logic are mainly implemented in two orchestrated BPEL Processes:

1. Rating and Fund Reservation Billing Process, its business process logic is straightforward as the following diagram shown, when the process receives the service invocation request containing the Service Detail Record (SDR), it will invoke the external "Authorize Pay Web Service" to check whether the user has enough fund for the service request, if it is true, it then will reserve the fund through external "Reserve Fund Web Service" and start "QoS and Charging Process" and return the status of “Success”, otherwise the status of "Failed" will be returned
   
   


2. QoS And Charging Billing Process, as the following diagram shown, when it get started, it will immediately start "Service Notification Process" waiting for the Service Notification, if the "service fulfilled" status is received, the "Post-Pay Confirmation Process" will be started waiting for the final delivery status to invoke the external "Transfer Fund Web Service" and finish the whole Pre-Paid Billing Policy Processing. In case of failure, "QoS And Charging Billing Process" will invoke the external "Cancel Reserved Fund Web Service" to return the fund back to the customer's account.
   
   

  As demostrated, using BPEL to build process-driven policies make these policies not only naturally executable but also easily integrated with both internal and external enterprise software systems