WS-Governance A language for SOA Governance Policies definition - Technical Report

WS-Governance A language for SOA Governance Policies definition Josè Antonio Parejo Maestre, Pablo Fernandez and Antonio Ruiz Cortés Computer Science and Engineering School Department of Computing Languages and Systems University of Seville {japarejo,pablofm,aruiz}@us.es Applied Software Engineering Research Group http://www.isa.us.es University of Sevilla http://www.us.es This work is partially supported by: Ministerio de Ciencia e Innovación Consejería Innovación, Ciencia y Empresa, Junta de Andalucía January 28, 2011 Contents 2 Contents 1 Introduction 3 2 Preliminaries 4 2.1 Compatibility amongst policies . . . . . . . . . . . . . . . . . . . . . . 5 3 A motivating use case 6 3.1 WS-Policydrawbacks........................... 8 4 From WS-Policy to Ws-Governance 9 4.1 DSLs in WS-Governance . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2 SOA Modeling with SAML . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3 Specifying Governance properties, and policy assertions with GAL . . . 12 5 Property checking through CSPs 15 5.1 CSPsinanutshell............................. 15 5.2 Semantics of GDs* based on CSPs . . . . . . . . . . . . . . . . . . . . 15 5.3 Checking for Consistency . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.4 Prototype implementation . . . . . . . . . . . . . . . . . . . . . . . . . 19 6 Related Work 19 7 Conclusions and Future Work 20 8 Acnowledgements* 21 J. A. Parejo, P. Fernandez and A. Ruiz ISA Group 1 Introduction 3 1 Introduction SOA adoption brings an increase on the number of elements of the IT architecture, where proper management and control become capital issues. In this context, SOA Governance is defined as the management process aimed at delivering the SOA promise of reuse, business goals support and responsiveness [11, 15]. Both industry and academia have identified SOA Governance as a promising area [15, 7]. According to [21] SOA Governance Lifecycle can be divided into six stages, from more abstract business levels to more concrete operational levels: Create a SOA strategy, Align Organization, Manage Service Portfolio, Control Service Lifecycle, Policy Definition and Enforcement and Service Level Management. In this paper we focus on the policy definition as the key stage that requires a deeper analysis in order to support an agile governance. Effective governance requires a formalization of the governance policy management, including : (i) the definition of policies that encode governance rules and (ii) the establishment of appropriate conformance testing and enforcement mechanisms for defined policies. Moreover, we have identified the need to incorporate the structure of the organization as an essential information to take into account when the governance policies are designed. Our case study shows an important number of elements where governance policies can be specified (such as services, applications or departments) This high variability represents an important drawback in terms of management since it boosts the possibility of specifying inconsistent policies; specifically, in our case study, the structure, size and departmental autonomy of the organization implies that multiple administrators could specify policies in a distributed and independent way. In this context, the scenario represents a Cooperative Information Systems reality with highly distributed inter-organizational interaction that should be coordinated. Therefore, the capability of automatic consistency checking of policies is highly valuable. The current governance tools market is vendor-driven and turbulent, where tools are based on proprietary technology and its features are guided by the specific aspects where its vendors have expertise [7, 8]. Furthermore, most current governance platforms assume that policy definitions are error-free, but policies can be inconsistent [10]. The contribution of this paper is twofold: (i) First, a language for governance policies definition is presented. This language defines governance documents; which make policies unambiguous by providing a rich context for governance policies and their metadata, while maintaining their definition independently of the SOA elements to govern, their internal organization and the underlying infrastructure. (ii) Secondly, a formal definition of governance document is proposed, describing the elements to govern, their properties and the policies that govern them. This formal definition allows the automation of policies consistency checking. To the best of our knowledge, this proposal provides a novel approach, paving the way for building more powerful and automated governance tools. This proposal has been developed and tested on a proof of concept prototype. The rest of the paper is structured as follows: In the next section preliminary concepts are provided. In section 3, the case study that motivates the research presented on this paper is described, drawbacks of WS-Policy for governance policy specification are depicted and the need of a governance document is motivated. Section 4 presents J. A. Parejo, P. Fernandez and A. Ruiz ISA Group 2 Preliminaries 4 Figure 1: UML metamodel of WS-Policy WS-Governance, our proposal of XML-based language for governance policies specification, and its plain text equivalent WS-Gov4People. Section 5, presents a mapping of governance documents to Constraint Satisfaction Problems that allow the automated checking of properties. Finally, in sections 6 and 7 related work is described and conclusions are drawn. 2 Preliminaries A Governance Policy represents a capability, requirement or behavior that allows the SOA to achieve its goals, and whose meeting is quantifiable and monitorable through time [2, 11, 4, 16]. Governance policies are as heterogeneous as the said governed elements, addressing the distributed, flexible, and heterogeneous nature of current SOAs. Moreover, governance policies originate from disparate sources, from legal regulations and their derived compliance issues to strictly technical details. WS-Policy is a W3C recommendation that provides a framework for defining policies [25] which takes into account this very complex situation. As can be seen in Fig. 2 where the UML metamodel of WS-Policy is shown1, the building blocks of policies are assertions (PolicyAssertion) that are composed using operators: All equivalent to logical AND,ExactlyOne equivalent to logical XOR, and the top level compositor PoliciAlternative equivalent to logical OR. Policy nesting is supported by meaning a logical AND operation of the global policy and the nested one. Assertions represent domain-specific capabilities, constraints or requirements, where their grammar is left open by WS-Policy, thus allowing the use of XML-based Domain Specific Languages (DSLs) for that purpose (see “VariationPoint” stereotyped PolicyExpression in figure 2) . This is a common strategy also followed by recommendations such as WS–Agreement to meet the open–closed design principle: recommendation should be open for extension but closed for modification. WS-Policy has been mainly focused on the definition of policies related to specific service capabilities such as security, reliability, etc. In fact, there are a number of DSLs for those purposes. 1The UML class diagram in 2 represents our interpretation of the metamodel described by the XML schema specified in [25] and [24]. J. A. Parejo, P. Fernandez and A. Ruiz ISA Group 2 Preliminaries 5 Unfortunately, describing assertions for SOA governance policies is a bit more complicated (see later) and as far as we know there is currently no single DSL to describe this kind of policies. Two mechanisms are available in WS–Policy to associate policies with the elements to which they apply, i.e., their scope. The first mechanism aims to associate one or more policy definitions as a part of the element definition. For example, if we want to apply a policy to a single web service described in WSDL, the policy specified in WSPolicy has to be inserted into the WSDL code. We called this mechanism endogenous attachment, since the definition of the policy is internal to the element one. Left column in table 1 shows an example of this kind of attachment. In this case, two polices on the web service “StockQuote” are defined: one to ensure a reliable message and another to specify security mechanisms on web service binding. Notice that with endogenous attachment: i) attaching a set of policies to a set of elements at the same time is not possible (one–element specification) and ii) changing a policy requires modifying the definition of an element, in other words, it is an intrusive mechanism. The second mechanism aims to associate one or more policy definitions to one or more elements, and more specifically to the references of these elements. To this end, WS-PolicyAttachment recommendation [24] proposes the use of PolicyAttachemt and AppliesTo (shaded classes in figure 2). In this case, the WS-Policy is not encoded in the same file that the specification of the element. We call this mechanism exogenous attachment. Right column in table 1 shows an example of this kind of attachment. In this case, secure binding mechanisms are asserted on the “StockQuote” and “MortgageRisk” services using its endpoint reference address. As it can be seen in figure 2, WS-PolicyAttachment also leaves open the language to specify the scope, in fact, it is the domain expression variation point, domain expression to specify policy subjects. Domain expressions grammar is left open by WS-Policy, thus allowing the use of XML-based DSLs, but WS-Policy provides a basic language to specify it based on URIs. Note that with exogenous attachment: i) it is possible to attach a policy to a set of elements at the same time (multi–element specification) and ii) changing the policy attachment does not require modifying the definition of an element, in other words, it is anon–intrusive mechanism. 2.1 Compatibility amongst policies WS-Policy defines a mechanism to test the compatibility of two policies, called policy intersection. According to the WS-Policy specification [25] “policy intersection is optional but a useful tool when two or more parties express policies and want to limit the policy alternatives to those that are mutually compatible”. The intersection consists of two parts: a domain-independent policy intersection and domain-specific processing. The former takes into account the assertion type equality, i.e. the XML element type equality and its nested elements, but not its parameters. The latter is not defined in WS-Policy, thus assertions authors have to define specific mechanism for incorporating the intended semantics of the assertions (and the specification does not provide a standard mechanism to integrate it). For instance, the first policy specified in the left column and the policy in the right column are incompatible, since their element types J. A. Parejo, P. Fernandez and A. Ruiz ISA Group 3 A motivating use case 6 WS-Policy 1 WS-Policy 2 <wsdl:definitions name=’StockQuote’ Element <wsp:PolicyAttachment> xmlns:wsp=’...’ ...>attached <wsp:AppliesTo>\ <wsp:Policy wsu:Id=’RmPolicy’ >\<wsa:EndpointReference>|Policy <rmp:RMAssertion>|<wsa:Address>.../MortageRisk.wsdl</...>|Scope <wsp:Policy/>|<wsa:Address>.../StockQuote.wsld</...>|Scope </rmp:RMAssertion>|</wsa:EndpointReference>|def. </wsp:Policy>|</wsp:AppliesTo>/ <wsp:Policy wsu:Id=’X509Policy’ |Policy <wsp:Policy wsu:Id=’X509Policy’ \ <sp:AsymmetricBinding>|assertions <sp:AsymmetricBinding>| ... |... |Policy </sp:AsymmetricBinding>|</sp:AsymmetricBinding>|assertions </wsp:Policy>/</wsp:Policy>/ ... </wsp:PolicyAttachment> </wsdl:definitions> Table 1: Endogeous vs Exogeous Attachment Figure 2: Case study architecture < rmp :RMAssertion > and < sp :AsymmetricBinding > are different. The second policy in the left column could be compatible depending on the nested subelements, where each policy should contain a matching nested subelement, and those elements should be of the same type. The notion of policy intersection is thus basically syntactical and structural, and it is not valid for complex domain-specific processing or semantic reasoning about policies, as shown in [6] and [1]. 3 A motivating use case The motivation of our approach is derived from a case-study based on a real scenario involving a regional-wide governmental organization. This organization has a complex structure divided into 16 governmental departments with around 5,000 end users using a shared IT infrastructure. thousands of end users (civil servants using the IT infrastructure). This infrastructure is distributed in the different departments both logically and physically and is usually managed autonomously in each location. In recent years there has been a shift toward SOA and currently there is an important number of core services replicated in the infrastructure with different QoS capabilities. From an architectural point of view, the infrastructure is designed as a federated bus of services; in this context, each department represents a node with two main elements: an Enterprise Service Bus and a Management System that provide different horizontal functionalities (such as monitoring, transactions or security). All the different nodes are integrated conforming the global infrastructure. J. A. Parejo, P. Fernandez and A. Ruiz ISA Group 3 A motivating use case 7 Figure 3: Governance Documents, from top to down: (i) Policies for Critical Services enacted by root authority A; (ii) Policies on service usage between Dept. 1 and Dept. 2; (iii) Policies on service provision internal to Dept. 1 The different services are deployed in the bus and the consumer applications ask the bus for the appropriate provider. In figure 2 an architectural conceptualization is shown: each of the nodes correspond with a department; the nodes are composed of applications for end-users with the bus providing core common services. As depicted, the bus can provide access to external services from other nodes. Due to the structure of the organization, each department has developed a high autonomy in its IT infrastructure management. Consequently, the integration of applications and services amongst different departments has raised an important issue: the need to specify a consistent normative framework on the whole organization for meeting business needs without breaching autonomy. In this motivating scenario, a SLA Management Infrastructure (SLAMI) in charge of creating, storing, locating and enforcing SLAs for transactions has been deployed in each node. Based on the analysis of the common organization operations and the usage of the current SLAMI component, we have identified some examples in this scenario where SOA governance is applied. In the following cases, the infrastructure should cual? adapt to provide an appropriate behavior depending on different parameters: •Depending on the application. Some applications have a higher priority than others or require different security restrictions and QoS levels. •Depending on the application’s department (i.e. node). Since applications can access services of external departments, the nodes could establish different rights for external (from other nodes) or local (the same node) applications. Figure 3 shows three excerpts of different real governance documents found in our case study -conveniently modified in order to preserve privacy and meet confidentiality J. A. Parejo, P. Fernandez and A. Ruiz ISA Group 3 A motivating use case 8 clauses-. Currently, these fragments correspond to human-oriented policies that should be enforced by administrators by means of configurations of the IT-infrastructure. Each document is enacted by a different organization: the first document by the main authority so it should be enforced by all sub-organizations (departments); the second document represents an integration agreement amongst two departments (1 and 2) and finally, the last document is an internal governance document of department 1. There is a real and urgent need of a language to define governance policies unambiguously with precise semantics; as a first step toward governance policy definition, enforcement and automatic consistency checking. 3.1 WS-Policy drawbacks In working for a Public Administration, we were concerned with developing mainstream policies that would avoid ad-hoc solutions. We therefore tried to use WS-Policy; however, when applying it to the previously described documents we encountered the following limitations: Lack of Context and meta-data (LCD) Governance policies need a rich context to ensure their validity, specifying who enacts the policies and providing additional metadata in order to ensure authorization for policy enactment and the integrity of the policies as enacted, thus avoiding tampering. In using WS-Policy , there is not a single point where we can insert the required information that assures the validity of the policy, such as official seals, a declaration of validity by the enacting authority or a GD’s preamble. We call this problem Lack of Context Data (LCD) Scope Definition Limitations (SDL) Defining a policy P1 as simple as ”All services provide an Availability greater than 99%” may become a nightmare for SOA practioners since WS–Policy has not been designed keeping in mind that the scope of a policy could be defined by intension. For example, if an endogenous attachment is used then all the services descriptions will need to be changed to incorporate the policy. This intrusive action used to be forbiden in large organizations since it is time–consuming and error prone. In turn, if an exogenous attachment is used, then all the services references will need to be computed and inserted in the AppliesTo section of the policy. It may seem that this kind of policy is well supported by exogenous attachment, but it is not true in our case study. For example, if there was a change in a political decision All services except S23, S45, . . . ) this would entail a re-working of over a hundred services as well as modifying the content of the scope section. This is not an adequate solution when dealing with a SOA comprising of hundreds of applications and services; where policies are often, even if slightly, changed. Summarizing, these circumstances make it very appealing to have the possibility to define the policies’ scope by intension and not only by extension; which was the only used mechanism to date, without the creation of a DSL language to support this. The expression of these scope predicates require a rich predicate DSL and the specification of the elements and data sources needed to feed the predicate, in order to effectively evaluate policy scope. This problem is particularly acute for governance policies, since governance relevant information is stored in disparate sources, such as UDDI registries, LDAP directories, ad hoc databases, etc. For instance, in our sample GDs there J. A. Parejo, P. Fernandez and A. Ruiz ISA Group 4 From WS-Policy to Ws-Governance 9 are properties such as “critical services” and “local/external apps & services” whose values must be obtained from different information sources. Isolation of Policies (IoP): WS-Policy only defines Policy, and PolicyAttachment as top level elements, were no logical grouping of cohesive interrelated policies is provided except for the logical compositors. A GD should, however, contain a set of cohesive policies that govern concrete aspects of the architecture; following specific management or business goals in order to perform a proper management of the own governance policies set. For instance, in our sample Gov. Doc. (i), the set of policies that manage critical services are grouped in a unique cohesive document. WS-Governance Documents address drawbacks described above by incorporating an extensible context to the contained policies (addresing LCD), thus defining a global document structure that contains a set of policies under an umbrella governance scope (addressing IoP). It also describes relevant governance properties and provides mechanisms for incorporating disparate governance-relevant information sources (addressing SDL and some LCM issues). GDs are described in detail in the next section. Inadequate consistency cheking Due to the specific nature of the governmental authority, a fundamental need in our case-study was to check the consistency of the government policies. The only analysis operation WS-Policy envisioned for this was the intersection of policies. In our case, this analysis was not appropriate due to the syntactical or structural nature of this operation. For example, two identical-meaning policies may prove inconsistent by using the intersection operation. Consequently, a semantical consistency notion is needed. One of the most valuable features of any language is to dispose of a tool support able to debug programs written in that language as well as to provide some interesting properties. In our user case, one of the most valuable properties was to check the consistency. It is said that a policy is consistent if it has no internal contradictions. If the automatic management and enforcement of policies is the aim, a formal semantics of governance policies is needed. The open and flexible nature of WS-Policy makes it difficult to provide homogeneous semantics to policies, since each domain specific DSL would have its own semantics. This problem motivates the merely structuralsyntactical nature policy intersection operation as defined in WS-Policy, avoiding its usage in diverse scenarios [6, 1], we name this drawback as Syntax/Structure Driven Semantics (SDS). LCD and SDS drawbacks motivate the creation of two general purpose XML-based DSLs for governance policy assertions and SOA modelling described in detail in the next section. Based on those DSLs and the authors‘ experience providing formal semantics for SLAs specified in WS-Agreement by using CSPs [19, 13, 12], a CSP based semantics for WS-Governance documents using those DSLs is proposed in Sec. 5 addressing SDS. Based on those semantics a consistency property for policies and governance documents is defined. 4 From WS-Policy to Ws-Governance A WS-Governance Document (GD) provides policies definitions along with contextual metadata, sources-of-governance relevant information, and the specification of properties on which policies definitions is based. In so doing, WS-Governance addresses J. A. Parejo, P. Fernandez and A. Ruiz ISA Group 5 Property checking through CSPs 16 this section we define the mappings that tranform GDs* onto CSPs that provide their precise semantics, allowing the usage of CSP solvers to reason about policies and complete GDs*. Mapping a GD* into CSPs. The mapping (µGD :ρ→ψ) of a WS-Governance* GD (ρ) to a CSP (ψ) is performed in two steps as follows: 1. For each policy pi= (s, a)in the GD*, piis mapped for the concrete governance scope (SOA model in terms of services, applications, organizations and its relationships) into a constraint pC ithat contains only variables and literals composed using logical and algebraic operators. This constraint is constructed so that it tells exactly when the policy holds in the given governance scope. This transformation is performed by the explicit enumeration of the sets and relationships (ownership, provision, consumption, and organizational hierarchy) on the governance scope for each quantifier, combining the resulting constraints using logical AND (∧) operators for universal quantifiers and logical OR (∨) operators for existential quantifiers. 2. The set of constraints pC={pC i}n i=1 and original GD* ρare mapped into a CSP ψ={V, D, C}by creating: •a variable vx si|oi|aiin Vfor each property xand corresponding element in the SOA (service, organization and application). •variables vsupOrg oi,vprov si,vcons siand vown aiin Vfor the relation functions supOrg (hierarchical relationship among organizations), provider and consumer (relationship among services and applications) and owner. Additionally, their domain of organizations, applications, and services are created. •constraints {vsupOrg oi=oj},{vprov si=ak},{vcons si=ak}, and {vown ai=ol}in Cfor each variable created in the previous step specifying the values of the relationshipssupOrg,provider,consumer and owner. Those constraints and variables express the SAML SOA structural model of the governance scope. •a constraint {vx si|oi|ai={Value Expr?}} in Cfor each property valuation specified in the state section of the governance scope in ρ. Finally, for each constraint in pCproperty invocation functions X(si|oj|aj)are exchanged by their corresponding variables vx si|oi|ai, and the resulting constraint is added to C. The mapping of different elements of a GD* is shown in Table 3. In order to exemplify the use of GD*, in the left column of table 4 we can see the expression of the policies contained in the governance documents found in the case study (Figure 3). In the table we can see the four different parts of a GD* document: Context, SOA Model, Vocabulary and Policies. In this context, the SOA Model part has been enriched with the structure information of a subset in the organization: on the one hand, Department 1 has one A1 application that provides s1 service and on the other hand, Department 2 has two applications (Zeus and A3). The former consumes s1 and s2 and provides s3 service; the latter only provides s2. It is important to highlight that J. A. Parejo, P. Fernandez and A. Ruiz ISA Group 5 Property checking through CSPs 17 WS-Governance* Element CSP Mapping Governance Document -Name (Id) GD Name, Id and Governor Org. Governor: Org. Name?(Org. Id?) are not mapped to CSP SOA Governance Model: For each organization oia variable vsuporg oiis created STRUCTURE: denoting the parent org. of oiand a domain {Organization: Org. Name? (Org. Id?)dsuporg i={o1,...n}is added to D SubOrganizations: Org. Id1?,. . . ,Org. IdN? a constraint {Cprov oi=oj}is created encoding the orgs. hierarchy Applications: For each application aja variable vown ajis created Provides: denoting the owner org. of aj, a domain {Service: Serv. Name? (Serv. Id?)}* down j={o1,...n}is added to D Consumes: and a constraint {Cown ai=oj}is created encoding the app. ownership {Service: Serv. Name? (Serv. Id?)}* For each service ska variable vprov skis created }* , a domain dprov k={a1,...,am}is added to D }+ and a constraint {vprov sk=al}is created encoding the provisioning STATE: {Property val. Expr?}* Add Constraint: vx si|oi|ai[Proverty val. Expr.?] Vocabulary: Add variables & domains: Property: Xfor Services for each property xwe create a variable for {Servs|Orgs|Apps}vx si|oi|aifor each element in Type: boolean its corresponding set S|O|A Domain: Domain Expr.? Add Constraint: vx si|oi|ai[Domain Expr.?] Policies: Add contraint: Policy P1 {forall yVS|O|A vsi|oi|ai (Scope expr)[y/vy si|oi|ai] in (Servs|Orgs|Apps)}+ ⇒(Assertion expr)[y/vy si|oi|ai] {exists yWS|O|A vsi|oi|ai ((Scope expr)[y/vy si|oi|ai] in (Servs|Orgs|Apps)}+ ⇒(Assertion expr)[y/vy si|oi|ai] Scope:Scope expr? , For each constraint c∈Cdo: Assertion:Assertion expr |(c)[vy si|oi|ai/vx si|oi|ai] where E[x/y] means: ’ the expression E, but with occurrences of x replaced by y’ Table 3: Mapping of WS-Governance* elements onto CSPs the policy found in the second document fragment of the example is not translated into a policy in the GD* document but it represents structural information expressed in the SOA Model section. Following the mapping described in this section, in the right side of Table 3 the CSP transformation of the GD* is presented. 5.3 Checking for Consistency Checking a GD ρwritten in WS-Governance* for consistency lets us know whether it has internal contradictions or not. The root of the inconsistencies can be: (i) that a policy in ρis intrinsically inconsistent; (ii) that the set of policies in ρare inconsistent; or (iii) even when the set of policies in ρ,Pρ={ρ1, . . . , ρn}, are initially consistent, then ρcan be inconsistent due to the additional information added by the SAML SOA state and structure specified in it. For instance, the GD* shown in the first column of table 4 is inconsistent. The cause of the inconsistency is that policies ρ2=’Critical services availability should be “’24x7’ ’ and ρ3=’Service s1availability is “window” if it is consumed by external applications’ are inconsistent, since s1is both consumed by application a2 J. A. Parejo, P. Fernandez and A. Ruiz ISA Group 5 Property checking through CSPs 18 Sample SGDL4People Document Corresponding CSP Governance Document -Critial Services Management (GD1)φ={V, D, C}where C={CD∪CSOA ∪Cρ} Governor: (ox)V={VP rop ∪VW∪Vρ}, D ={DP rop ∪DSOA} Scope: VSOA={Vprov ∪Vcons ∪Vown ∪VsupOrg} STRUCTURE: Vprov ={vprov s1, vprov s2, vprov s3, vprvO s1, vprvO s2, vprvO s3} Organization: E-gov. Org. X (ox)Suborganizations: o1,o2Vcons ={vcons s1, vcons s2, vcons s3, vcnsO s1, vcnsO s2, vcnsO s3} Organization: Department 1 (o1)Vown ={vown a1, vown a2, vown a3} Applications: Vsuporg ={vsuporg o1, vsuporg o2} Application:A1 App (a1)DSOA ={Dprov ∪Dcons ∪Down ∪Dsuporg } Provides: s1 (s1) , A={a1, a2, a3},O={o1, o2} Organization: Department 2 (o2)Csoa ={CStruct ∪CStat} Applications: CStruct ={{vprov s1=a1},{vprov s2=a3},{vprvO s1=o1},{vprov s3=a2},{vprvO s2=o3}} Application:Zeus (a2){vprov s3=a2},{vprvO s3=o2},{vcons s1=a2},{vcons s2=a2},{vcnsO s1=o2}, Consumes: s1 (s1)s2 (s2) Provides: s3 (s3){{vcnsO s2=o2}, vcons s3=},{vown a1=o1},{vown a2=o2}, Application:A3 App (a3){vown a3=o2},{vsupOrg o1=ox},{vsupOrg o2=ox}} Provides: s2 (s2)CStat ={{vCrit s1=true}} STATE: Down ={O, O, O}, DsupOrg ={O, O} Critical(s1)=true Dprov =Dcons ={A, A, A, O, O, O} Vocabulary: VP rop ={vCrit s1, vCrit s2, vCrit s3vAvail s1, vAvail s2, vAvail s3} Property: Critical for Services Type: boolean DP rop ={{true, false},{true, false},{true, false}, Property: Availability for Services Type: enum {024x70,0office0},{024x70,0office0},{024x70,0office0}} Domain: ’24x7’,’office’CD=∅since there is no domain constraints Policies:Cρ={Cρ1, Cρ2, Cρ3} Policy P1 (ρ1)forall sin Services Cρ1={∧3 i=1((vcrit si=true)⇒(vprvO si=vconsO si))}={((vcrit s1=true)⇒(vprvO s1=vcnsO s1))∧ Scope:Critical(s)=true Assertion:ProviderO(s)=ConsumerO(s) ((vcrit s2=true)⇒(vprvO s2=vcnsO s2)) ∧((vcrit s3=true)⇒(vprvO s3=vcnsO s3))} Policy P2 (ρ2)forall sin Services Cρ2={∧3 i=1((vcrit si=true)⇒(vAvail si=024x70))}={((vcrit s1=true)⇒(vAvail s1=024x70))∧ Scope:Critical(s)=true Assertion:Availability(s)=024x70((vcrit s2=true)⇒(vAvail s2=024x70)) ∧((vcrit s2=true)⇒(vAvail s2=024x70))} Policy P3 (ρ3)forall ain Applications Cρ3={∧3 i=1((scons s1=ai∧vprov s16=vown ai)⇒(vAvail s1=0office0))}= Scope:a∈Consumer(s1)∧Owner(a)6=Owner(Provider(s1)) = {((scons s1=ai∧vprov s16=vown a1)⇒(vAvail s1=0office0)) ∧((scons s1=a2∧vprov s16=vown a2)⇒ Assertion:Availability(s1)=’office’ ⇒(vAvail s1=0office0)) ∧((scons s1=a3∧vprov s16=vown a3)⇒(vAvail s1=0office0))} Table 4: Sample WS-Governance4People onto CSP mapping J. A. Parejo, P. Fernandez and A. Ruiz ISA Group 6 Related Work 19 ’Zeus’ of department 2 and critical. This information, service consumption and criticality of services are specified by the SOA Structure and State section of the GDs*, thus the corresponding constraint Availability(s1) =024x70∧Availability(s1) =0window0 is obviously unsatisfiable due to the SOA state and structure, not because of an incosistency of policies per se, and consequently ρ2and ρ3are inconsistent in ρ. Definition Internal Consistency A GD* ρis said to be consistent iff its corresponding equivalent CSP is satisfiable. consistent(ρ)⇔sat(ψρ) Definition Consistency. A non empty set of GDs in WS-Governance* P={ρ1, . . . , ρn} is said to be consistent iff its corresponding equivalent CSPs are simultaneously satisfiable. consistent(P)⇔sat( n ^ i=1 ψρi) As an example, our approach found an additional inconsistence: in the mapping of the GD* shown in Table 4, the corresponding CSP ψcontains among others the following constraints: {vcrit s1=true ⇒vprovO s1=vconsO s1},{vcrit s2=true},{vconsO s1=o2}, and {vprovO s1=o1}. This set of constraints in unsatisfiable, since vprov s1=o2and vprov s2=o1 are unsatisfiable, and consequently the GD* is inconsistent. 5.4 Prototype implementation We have developed an implementation of our approach using the Choco constraint solver [9]. This prototype receives two XML documents as input: a WS-Governcance* document ρD, and a SAML document that provides governance relevant information ΓD, simulating a UDDI registry enriched with metadata to support governance policies reasoning. After mapping the ρDand ΓDto the equivalent CSP, our proof-of-concept prototype processes the CSP and returns a report showing the results of the following checks: intrinsic consistency of each isolated policy of ρD, consistency of the whole set of policies of ρDand the general consistency of ρDon ΓD. Our propotype implementation is available for download at http://www.isa.us.es/GDA. 6 Related Work Concerning policy definition, Ponder is the pioneer and probably most widely used language. Ponder [3] is a declarative, object oriented language for the specification of management polices in distributed object systems. Additionally, Ponder provides structuring techniques for policy administration in large scenarios and systems. WSGovernance incorporates similar concepts by the explicit declaration of governor and document context, and uses SAML and GAL assertions to model scope. The usage of J. A. Parejo, P. Fernandez and A. Ruiz ISA Group 7 Conclusions and Future Work 20 WS-Policy as the base policy expression construct, and explicit declaration of governance relevant information sources, makes WS-Governance better suited for SOA governance policies declaration. However, an interesting capability supported by Ponder that we plan to add to WS-Governance in the future is the declaration of policy types as templates. Rei and KAoS [22], both based on semantic web concepts are proposals oriented to the definition of policies for expressing web services capabilities policies. However, is WS-Policy the proposal that has more successful in industrial scenarios, thus we have chosen it for extension in order to define SOA governance policies. Our proposal provides a richer consistency notion allowing the detection of semantical inconsistences in policies with complex interaction as shown in this paper. General policy conflict analysis is not a novel problem [10], but its application in the context of SOA governance policies in this paper is original. Several approaches have been proposed for policy expression and conflict analysis in the context of network management [20], and security [5], but they are based on Binary Decision Diagrams (BDD), forcing the reasoning with less expressive policies than our CSP based proposal. 7 Conclusions and Future Work In this paper, based on the specific needs of our case study, a novel XML-based language called WS-Governance has been proposed. WS-Governance takes WS-Policy as a starting point and extends it with two new languages (GAL and SAML), maintaining the compatibility with this standard. The main benefit of WS-Governance is to contextualize policies and integrate governance data sources, enabling effective governance since it provides a formal semantics that supports automated consistency checking. This paper represents a significant improvement in the context of SOA Governance, since a vendor-independent governance language with precise semantics is proposed, allowing the specification of expressive Governance Documents independently of the underlying infrastructure. Furthermore, the GD semantics and consistency operation paves the way for the building of a new generation of governance tools. In this scenario governance policies are created in a distributed, independent but collaborative way, maintaining global consistency. This collaborative process helps governance boards on the creation of the essential normative framework needed for the achievement of the SOA promise. There are some challenges we have to face in the near feature, namely: i) define extensions of the GD context variability point in order to effectively ensure authentication and authorization of the enacting organization for defining policies and avoid tampering (currently this extension is supported by the language through the variability point but those mechanisms are not specified); (ii) extend WS-Governance to support the definition of policy templates improving reuse and usability; (iii) developing an appropriate tooling for GDs edition; iv) improve WS-Governance and the mapping onto CSP in order to support advanced temporal concerns such as described in [14]; v) carry out a performance analysis of our implementation in order to study the influences of the SOA model, type of governance properties and number and complexity of governance policies. J. A. Parejo, P. Fernandez and A. Ruiz ISA Group 8 Acnowledgements* 21 8 Acnowledgements* This work was partially supported by the European Commission (FEDER) and Spanish Government under Web-Factories (TIN2006-00472) and SETI (TIN 2009-07366) projects, and by the Andalusian Government under project ISABEL (TIC-2533) and THEOS (TIC-5906). http://www.micinn.es/ http://www.juntadeandalucia.es/organismos/economiainnovacionyciencia.html References [1] Anne H. Anderson. Domain-independent, composable web services policy assertions. In POLICY, pages 149–152, 2006. [2] Jan Bernhardt and Detlef Seese. A conceptual framework for the governance of service-oriented architectures. In Service-Oriented Computing, ICSOC 2008 Workshops, pages 327–338. Springer, 2009. [3] Nicodemos Damianou, Naranker Dulay, Emil Lupu, and Morris Sloman. The ponder policy specification language. In POLICY ’01: International Workshop on Policies for Distributed Systems and Networks, pages 18–38. Springer, 2001. [4] Patricia Derler and Rainer Weinreich. Models and tools for soa governance. In Trends in Enterprise Application Architecture, pages 112–126. Springer, 2007. [5] Hazem H. Hamed, Ehab S. Al-Shaer, and Will Marrero. Modeling and verification of ipsec and vpn security policies. In ICNP, pages 259–278, 2005. [6] Bernhard Hollunder. Domain-specific processing of policies or: Ws-policy intersection revisited. In ICWS, pages 246–253, 2009. [7] L. Frank Kenney and Daryl C. Plummer. Magic quadrant for integrated soa governance technology sets. Technical report, Gartner RAS Core Research, March 2009. Available at http://mediaproducts.gartner.com/reprints/oracle/article65/article65.html. J. A. Parejo, P. Fernandez and A. Ruiz ISA Group References 22 [8] Kostas Kontogiannis, Grace A. Lewis, and Dennis B. Smith. A research agenda for service-oriented architecture. In SDSOA ’08: Proceedings of the 2nd international workshop on Systems development in SOA environments, pages 1–6, New York, NY, USA, 2008. ACM. [9] Francois Laburthe, Narendra Jussien, Guillaume Rochart, Hadrien Cambazard, Charles Prud’homme, Arnaud Malapert, and Julien Menana. Choco, java library for constraint satisfaction problems (csp), constraint programming (cp) and explanation-based constraint solving (e-cp). One Source Software (BSD license) available online. [10] Emil Lupu and Morris Sloman. Conflicts in policy-based distributed systems management. IEEE Trans. Software Eng., 25(6):852–869, 1999. [11] Eric A. Marks. Service-Oriented Architecture Governance for the Services Driven Enterprise. John Wiley & Sons, 2008. [12] Carlos Müller, Manuel Resinas, and Antonio Ruiz-Cortés. Explaining the noncompliance between templates and agreement offers in ws-agreement*. In Proc. of the 7th International Conference on Service Oriented Computing (ICSOC), volume 5900, pages 237–252, Sweden, Stockholm, Nov 2009. Springer Verlag. [13] Carlos Müller, Antonio Ruiz-Cortés, and Manuel Resinas. An initial approach to explaining sla inconsistencies. In 6th. Int. Conf. on Service-Oriented Computing (ICSOC), volume 5364 of LNCS, pages 394–406, Sidney, Australia, Dec 2008. Springer Verlag. [14] Carlos Müller, Octavio Martín-Díaz, Antonio Ruiz Cortés, Manuel Resinas, and Pablo Fernandez. Improving temporal-awareness of ws-agreement. In ICSOC, pages 193–206, 2007. [15] M. P. Papazoglou, P. Traverso, S. Dustdar, and F. Leymann. Service-oriented computing: State of the art and research challenges. IEEE Computer, 40(11):38–45, November 2007. [16] J. A. Parejo, Pablo Fernández, and Antonio Ruiz-Cortés. Towards automated slabased governance policy enforcement. In International Joint Conference on Service Oriented Computing (ICSOC), 2009. [17] José Antonio Parejo, Pablo Fernandez, and Antonio Ruiz-Cortés. Soa governance languages schemas. including schemas for soa governance description language (sgdl), soa modelling languange (saml), and governance assertions language (gal). Online XML Schemas, 06 2010. [18] David Peterson, Shudi (Sandy) Gao, Ashok Malhotra, C. M. Sperberg-McQuee, and Henry S. Thompson. W3c xml schema definition language (xsd) 1.1 part 2: Datatypes. W3C Working Draft, 12 2009. J. A. Parejo, P. Fernandez and A. Ruiz ISA Group References 23 [19] Antonio Ruiz-Cortés, Octavio Martín-Díaz, Amador Durán, and Miguel Toro. Improving the automatic procurement of web services using constraint programming. International Journal of Cooperative Information Systems, 14(4):439–467, Dec 2005. [20] Taghrid Samak, Ehab Al-Shaer, and Hong Li. Qos policy modeling and conflict analysis. In POLICY, pages 19–26, 2008. [21] T. G. J. Schepers, M. E. Iacob, and P. A. T. Van Eck. A lifecycle approach to soa governance. In SAC ’08: Proceedings of the 2008 ACM symposium on Applied computing, pages 1055–1061, New York, NY, USA, 2008. ACM. [22] A. Uszok, J.M. Bradshaw, M. Johnson, R. Jeffers, A. Tate, J. Dalton, and S. Aitken. Kaos policy management for semantic web services. Intelligent Systems, IEEE, 19(4):32–41, Jul-Aug 2004. [23] Antonio Vallecillo. A journey through the secret life of models. Schloss Dagstuhl - Leibniz-Zentrum fÃ1 4r Informatik, 2008. [24] Asir S Vedamuthu, David Orchard, Frederick Hirsch, Maryann Hondo, Prasad Yendluri, Toufic Boubez, and Ümit Yalçinalp. Web services policy 1.5 - attachment. W3C Recommendation, 09 2007. [25] Asir S Vedamuthu, David Orchard, Frederick Hirsch, Maryann Hondo, Prasad Yendluri, Toufic Boubez, and Ümit Yalçinalp. Web services policy 1.5 framework. W3C Recommendation, September 2007. J. A. Parejo, P. Fernandez and A. Ruiz ISA Group