100 likes | 216 Views
COMPAS: Compliance-driven Models, Languages, and Architectures for Services. Overview. Central problems addressed by COMPAS COMPAS assumptions and approach Contribution to NEXOF. COMPAS: Overview.
E N D
COMPAS: Compliance-driven Models, Languages, and Architectures for Services
Overview • Central problems addressed by COMPAS • COMPAS assumptions and approach • Contribution to NEXOF
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
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
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.
COMPAS Approach: Auditor’s View • Goals: • Support the automated controls better • Provide more automated controls 6
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 • We distinguish: • High-level processes (e.g., BPMN), non-technical and “blurry” • Low-level processes (e.g., BPEL), technical and detailed
Contribution to NEXOF • Conceptual model contribution: • Conceptual model and terminology shared with NEXOF-RA, contributing to the Conceptual Reference Model (including Glossary) where compliance concerns could be acquired, modeled, realized, enforced and validated. • Architecture & Pattern contribution: • COMPAS contributed its overall architecture to NEXOF-RA to identify functional elements and derive architectural choices if not patterns to be proposed; • Design of a channel-based coordination pattern for design-time service composition within NEXOF-RA. • Participation & contribution to NEXOF-RA events • Open Call for Contribution, Investigation teams • 2 publications: • Collaborative web service discovery with the Implicit Culture Framework, NESSI Open Framework - Reference Architecture (NEXOF-RA), 2008 ; • Design Time Service Composition with Reo Coordination Tools, NESSI Open Framework - Reference Architecture (NEXOF-RA), 2008.
Questions? Thanks for your attention! http://www.compas-ict.eu