Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Integrating ACPL based Policy with BPEL based workflow on Oracle: A Case Study Master’s Project by Imran Padshah for Computer Science Dept. Old Dominion University Advisor: Dr. M Zubair Introduction Institutions that have received federal funding for research projects must be in compliance to OMG circular A-21 and are responsible for maintaining an effort reporting system that documents all the work done for such grants. Failing to have such a system could result in the loss of federal grants and/or legal implications. In this project, we realize a Simple Electronic Effort reporting System (eERS) using Oracle BPEL engine and integrate it with a policy specified in ACPL that capture business policies for the effort reporting system. The proposed system provides employees working on federal projects with effort reports that can be viewed and signed electronically. eERS will be responsible for gathering all the information and apply business rules to create such reports. The eERS will eliminate the need for paper documentation thereby improving confidentiality and ease of distribution. It will also make the certification and feedback process easier. Since eERS will gather, distribute and manage data from disparate sources it is a classic example for Service Oriented Architecture (SOA). Business Processing Execution Language (BPEL) emerges as a natural choice to implement this process, as it is emerging as a clear standard for composing multiple synchronous and asynchronous services into collaborative transactional flows. BPEL is an XML standard that enables task sharing across web services. In this project we use a simple eERS transactional flow to demonstrate how we can build different web services and integrate them using BPEL. The eERS system has some business policies that have to be applied. We choose an XML based language ACPL to implement these business rules and integrated it with the different web services through the BPEL process to have a unified transactional flow. Design Researchers (or employees) can work on one or more projects. A researcher's time is committed between projects and school activities. The employee has to sign in with his secure login and certify on the data after completion of a project cycle. For example an employee's time may be distributed as follows: Project 1: 30% Project 2: 40% Project 3: 25% Adminstrative: 5%
  2. 2. Then the data is stored in the database as follows: Empid | Projid | Committed Effort | 12391 Proj1 30 12391 Proj2 40 12391 Proj3 25 Note: The administrative data need not be certified. Employees need to login securely and certify their effort (actual effort) on each project they worked on. An employee’s actual effort might differ from the committed effort for that project. If the value entered by the employee falls within a certain policy range (policies are set by ACPL) then the value is accepted and stored in a database for reporting purposes otherwise the employee is notified about the conflict and it has to be resolved with the project manager. Creating web services for this process: The eERS process can be divided into distinct functional modules. These distinct functional modules are developed as separate web services and then later integrated using BPEL. The final integrated process is also a web service by itself and can be invoked by and front-end UI. We used JSP to call this integrated web service. We created two types of web services:  Synchronous: - clients invoke a request on a service and then suspend their processing while they wait for a response  Asynchronous: - clients initiate a request to a service and then resume their processing without waiting for a response The following web services were created: Get Committed Effort Web Service: When the employee logs in, we need to get all the products the employee works in along with the committed effort for that employee in each project. To facilitate this we create a web service that takes in as input the employeeid and the projectid and returns back the committed effort for the employee/project.
  3. 3.  Input: Employeeid, Projectid  Process: Query Database  Output: Return committed effort.  Type: Synchronous Empid Projid Query Database Return Committed Effort GetDataWS Database Get Response ACPL Policy Validation Web Service: This web service checks to see if the actual effort entered by the employee falls with in the acceptable policy range set by the XML policy file. This web service gets the actual effort and committed effort and does to numeric calculations and checks to see if the data entered conforms to the norms set by the policy. If it does then it returns Accept else it returns Conflict. This policy is defined in Autonomic Computing Policy Language and implemented using IBM’s Policy Management for Autonomic Computing.  Input: Actual Effort, Committed Effort  Process:  Read the policy file implemented in ACPL  Apply the input to see if it falls within the accepted range.  Send result.  Output: Accept/Conflict Note: Refer to Appendix for detailed instructions on how the ACPL policy was implemented.
  4. 4. Store Data Web Service: When the actual effort falls within the acceptable limits then this data has to be stored for future use for generating reports etc. We create another web service that does this.  Input: Empid,Projid,Comm_Eff,Act_Eff  Process: Store in Database  Type: Asynchronous
  5. 5. Send Email of conflict data Web Service: If the actual effort data that is entered does not comply with the policy then the conflict is notified to the employee so he/she can correct the data accordingly.  Input: Empid, Projid, Act_Eff, Comm_eff, Policy  Process: Send email  Type: Asynchronous BPEL Orchestration: After creating all the above mentioned web services we need to combine them into one unified transaction flow. We use Oracle’s BPEL Process Manager to integrate all these web services into one unified transactional flow. The following diagram shows the flow in our business process.
  6. 6. We implement the above flow in Oracle BPEL Process Manager. The figure below shows a diagrammatic view of whole process.
  7. 7. Internally the whole process is integrated in XML. The following is excerpt of the XML file that represents the process integration in BPEL.
  8. 8. Instructions on how to run the project: Download the Oracle BPEL Process Manager from the Oracle website provided in the reference link. Download IBM’s PMAC from the IBM website also provided in the reference link. Install the above software by following the readme files that come along with the installs. These are required to run this project. Look in the appendix section to see how you can launch policies in ACPL. Get the files for the project which are submitted along with this report. Deploy these web services that are submitted with this project. The front-end JSP and HTML also need to be put in the directory in the server. The database schema also will be available. Run the schema to create all the necessary tables required for this project. To access the front-end for this project go to the following link http://machinename:9700/InvokingProcessesUI/Login.html Enter a valid login and password and now you can use the system to enter actual effort for an employee who logged in. The process flow for the data entered can be monitored using the BPELConsole. Future Work: The objective of this project was a proof of concept of using BPEL to integrate different web services and integrate it with ACPL. The proposed eERS system needs a lot of improvements to be fully functional and useful.
  9. 9. Conclusion: The objective of this project was the integration of ACPL based Policy with BPEL based workflow on Oracle’s BPEL Process Manager. This objective was successfully achieved. References: The following links were used for downloading software and for referring examples which helped in the implementation of technologies used in this project. Oracle’s BPEL Process Manager: IBM’s Policy Management Tool for Autonomic Computing
  10. 10. Appendix Difficulties faced: - Hardware: I started to develop this project in a laptop computer to make it easily portable for demos. The technologies used in this project should typically be implemented in server grade machines. I had used different machine configurations but RAM was the most important criteria for this project. I had unsuccessfully used laptops with 256MB and 512MB RAM and had to redo the project in a 1GB RAM laptop where finally everything worked fine. - References: At the time of implementation of this project the BPEL and ACPL technologies were fairly new. I could not find proper books or examples to implement the project. The best sources of information were Oracle and IBM web pages listed in the references section above. Details on ACPL implementation: Please refer to the files submitted with the project for complete source code. Download and install: You can download and install the IBM’s PMAC from the webpage given in the references section. Setup: Follow the README that comes with the install in order to run PMAC. Define Policy: ACPL is an XML policy standard in which policies are defined. The following is a sample policy. The policy defined in this ACPL file returns true if the actual effort entered, falls within plus or minus 10% of the committed effort. Pseudo code for this policy can be represented as follows: if((actual_effort<committed_effort+10% of committed_effort)&& (actual_effort>committed_effort-10% of committed_effort)) then return true; This policy is represented in ACPL as follows:
  11. 11. Launching Policy: After saving the policy you can launch the policy using the deploy command of PMAC. Follow the read me that comes with PMAC to see the exact use of this command. Java code used to access this policy: The following is the excerpt of the java code that accesses the policy through the PMAC interface: DecisionInput di = new DecisionInput( "ToleranceScope", "ExpenseApproval"); di.putInt( "acc_eff", acc_eff);
  12. 12. di.putInt( "comm_eff", comm_eff); Decision d = Decider.getDecider().requestGuidance( di); if ( d.noGuidance()) { System.out.println("Conflict"); } else { boolean approval = d.booleanValue( "approved", false); if (approval) { System.out.println("Accepted"); } else { System.out.println("Conflict"); } where: ToleranceScope - is the name of the policy file name ExpenseApproval – is the decision name within the policy acc_eff – is the actual effort that is passed as input to the policy comm_eff – is the committed effort that is passed as input to the ACPL policy. Integrating with BPEL: The policy can be accessed through the command line using PMAC. In this project we choose to integrate ACPL with BPEL by using java embedding. A java embedding call from BPEL calls the ACPL policy though PMAC by passing the required parameters (in this case actual effort and committed effort).