COMPAS: Compliance-driven Models, Languages, and Architectures for Services

1. COMPAS: Compliance-driven Models, Languages, and Architectures for Services

2. Overview • COMPAS: Overview • Central problems addressed by COMPAS • COMPAS assumptions and approach • Case Study: Advanced Telecom Services • Runtime compliance governance in COMPAS Credits: slides used from presentations of Schahram Dustdar, UweZdun, MarekTluczek, and other members of the COMPAS project

3. About COMPAS • Funding: European Commission, 7th Framework Programme, Specific Targeted Research Project (STREP) • Duration: February 2008 till January 2011 • Budget: 3.920.000 € • Partners: 6 research and 3 industrial partners from Austria, France, Germany, the Netherlands, Italy, Poland • More athttp://www.compas-ict.eu

4. COMPAS: Overview • COMPAS addresses a major shortcoming in today’s approach to design SOAs: Throughout the architecture various compliance concerns must be considered • Examples: • Service composition policies, Service deployment policies, • Information sharing/exchange policies, Security policies, QoS policies, • Business policies, jurisdictional policies, preference rules, intellectual property and licenses • So far, the SOA approach does not provide any clear technological strategy or concept of how to realize, enforce, or validate them

5. Problem in Detail • A number of approaches, such as business rules or composition concepts for services, have been proposed • None of these approaches offers a unified approach with which all kinds of compliance rules can be tackled • Compliance rules are often scattered throughout the SOA • They must be considered in all components of the SOA • They must be considered at different development phases, including analysis, design, and runtime

6. Current Practice vs. COMPAS Approach • Current practice: • per case basis • no generic strategy • ad hoc, hand-crafted solutions • COMPAS: • unified framework • agile • extensible, tailor-able • domain-orientation • automation • etc.

7. COMPAS Approach: Auditor’s View • Goals: • Support the automated controls better • Provide more automated controls 7

8. COMPAS Assumptions • Types of compliance concerns tackled: • We concentrate on the service & process world • We concentrate on automated controls • Compliance expert selects and interprets laws and regulations • We deal with two scenarios of introducing compliance (and variations of them): • Greenfield • Existing processes

9. COMPAS Assumptions • COMPAS provides an architecture and approach for dealing with compliance • Some compliance examples from the case studies are used to exemplify and validate that architecture and approach • Existing languages (e.g., BPMN, BPEL, UML Activity Diagrams), technologies (e.g., ESBs, Process Engines), etc., are used wherever possible • New software components are realized for specific compliance related solutions (see D1.1 and DA.1)

10. COMPAS Assumptions • We distinguish: • High-level processes (e.g., BPMN), non-technical and “blurry” • Low-level processes (e.g., BPEL), technical and detailed

11. Compliance Solution: Overview & Roles

12. Case study: Advanced Telecom Services (WatchMe) 12

13. Compliance in WatchMe • Domains: Internal policies, QoS and Licensing

14. Business process execution 14

15. User Interface - Login

16. Business process execution 16

17. User Interface - Search

18. Business process execution 18

19. User Interface – Choose

20. Business process execution 20

21. Business process execution 21

22. User Interface – Choose 22

23. Runtime compliance governance in COMPAS

24. Quality of Service DSL Quality-of-Service Compliance Concerns: Specified in Service-Level-Agreements (SLA), e.g., Availability > 99% • Support for stakeholders with different expertise: • Domain experts • Technical experts Runtime measuring of QoS values Monitoring of QoS events

25. Licensing DSL A high-level language for specifying license constraints in service-oriented business environments that is targeted at domain experts Runtime integration similar to the QoS DSL

26. Process Engine andExtensions • Extension of event model: • Extended Apache ODE version 1.1.1 • Provisioning of information required for compliance monitoring and mining Extension for enabling traceability: Integrate Universally Unique Identifiers (UUIDs) in BPEL and Events to identify models from which the processes are generated

27. Complex Event Processing andEsper Rules Complex Event Processing to aggregate compliance events Compliance violation detection on high-level (aggregated, business) events

28. Business protocol-basedmonitoring Checking of temporal properties specification during execution of a system Continuously observe and check the correct behavior of a system during run-time

29. Event Log and Datawarehouse Provide a general schema that can accommodate process and compliance requirements without need to change for each new process or requirement Store and provide access to all events (low and high level) Separate the operative part (running processes) of COMPAS from the assessment part (data warehouse analysis and reporting)

30. Compliance Governance Dashboard Report on compliance, to create an awareness of possible problems or violations, and to facilitate the identification of root-causes for non-compliant situations • Targeted at several classes of users: • chief officers of a company, • line of business managers, • internal auditors, and • external auditors (certification agencies)

31. Questions? Thanks for your attention! http://www.compas-ict.eu