WS-Governance: a Policy Language for SOA Governance

WS-Governance: a policy language for SOA Governance? Jos´ e Antonio Parejo, Pablo Fernandez, and Antonio Ruiz-Cort´ es Universidad de Sevilla, Spain Abstract. The widespread use of Service Oriented Architectures (SOA) is beginning to create problems derived from the governance of said structures. To date there is not a single effective solution to solve all existing challenges to govern this type of infrastructure. This paper describes the problems encountered when designing a SOA governance solution in a real e-Government scenario. More specifically, we focus on problems related to specification and automated analysis of government policies. We propose a novel SOA governance specification model as a solution to these problems. We have named this model WS-Governance. In order to ease its adoption by SOA practitioners it: i) shares WS-Policy guidelines and is compatible with it, ii) has XML serialization as well as a plain-text one and iii) has a CSP based semantics that provides a precise description as well as facilitating the automation of some editing and WS-Governance related activities such as consistency checking. 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 [1,2]. According to [3] 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 policy management, including : (i) the definition of policies that encode governance rules and (ii) the establishment of appropriate conformance testing and enforcement mechanisms. Moreover, we have identified the need to incorporate the structure of the organization as essential information to take into account when the governance policies are designed. 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, boosting the possibility of specifying inconsistent policies. In this context, the capability of automatic consistency checking of policies is highly valuable, and governance tools should support it. However, the current governance tools market is vendor-driven and turbulent, where tools are based on proprietary technology and their features are guided by the specific aspects where their vendors have expertise [4,5]. 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 meta-data. This is done whilst 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 ?This work has been partially supported by the European Commission (FEDER) project SETI (TIN2009-07366), and project ISABEL P07-TIC-2533 funded by the Andalusian local Government. 2 Jos´ e Antonio Parejo, Pablo Fernandez, and Antonio Ruiz-Cort´ es 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 by creating two applications: a consistency analyzer and an on-line editor. The rest of the paper is structured as follows: In sec. 2, the case study that motivates the research presented on this paper is described. Sec. 3 depicts the limitations of WS-Policy for governance policy specification and motivates the need of a governance document. Sec. 4 presents WS-Governance, our XML-based language proposal for governance policies specification, and its plain text equivalent WS-Gov4People. Sec. 5 presents a mapping of governance documents to Constraint Satisfaction Problems that allow the automated checking of consistency. Finally, in sections 6 and 7 related work is described and conclusions are drawn. 2 A motivating use case The motivation of our approach is derived from a case-study based on a real scenario we addressed on a research project, involving a regional-wide governmental organization. This organization has a complex structure divided into 16 governmental departments and thousands of end users using a shared 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 in the organization, 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. The different services are deployed in the bus and the consumer applications ask the bus for the appropriate provider. 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. Such a framework can be created by specifying a set of Governance Policies. 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 [6,1,7,8]. 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. 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. Figure 1 shows three excerpts of different real governance documents found in our case study -conveniently modified in order to preserve privacy and meet confidentiality 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. WS-Governance: a policy language for SOA Governance 3 Fig. 1. Governance Documents 3 Using WS-Policy for SOA Governance In working for a public administration, we were concerned with developing mainstream policies that would avoid ad-hoc solutions. For this reason, we decided to use the W3C recommendation WS-Policy for defining policies [9]. As can be seen in Fig. 3 where the UML metamodel of WS-Policy is shown1, the building blocks of policies are assertions (PolicyAssertion) that are composed using and,or and xor–like compositors (All, ExactlyOne, and the top level compositor PoliciAlternative). Policy nesting is supported by meaning a logical AND operation of the assertions of the global policy and those of 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 the “VariationPoint” stereotype of PolicyExpression in Fig. 3). 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. Unfortunately, describing assertions for SOA governance policies is more complex and as far as we know there is currently no DSL to describe this kind of policies. Two mechanisms are available in WS-Policy to associate policies with the subjects to which they apply, i.e. for defining their scope. The first one associates one or more policy definitions as a part of the subject definition. For example, if we want to apply a policy to a web service described in WSDL, the policy specified in WS-Policy has to be inserted into the WSDL code. We call 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 ser1The UML class diagram in 3 represents our interpretation of the metamodel described by the XML schema specified in [9] and [10]. 4 Jos´ e Antonio Parejo, Pablo Fernandez, and Antonio Ruiz-Cort´ es Fig. 2. UML metamodel of WS-Policy vice “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 subjects at the same time is not possible and ii) changing a policy requires modifying the definition of the subject, i.e. it is an intrusive mechanism. The second mechanism associates one or more policy definitions to one or more subjects. The WS-PolicyAttachment recommendation [10] proposes the use of PolicyAttachemt and AppliesTo (shaded classes in Fig. 2). In this case, the WS-Policy is not encoded in the same file that the specification of the element, thus 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 shown in Fig. 2, WS-PolicyAttachment also leaves open the language to specify the scope, but 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 and ii) changing the policy attachment does not require modifying the definition of an element, i.e. it is non–intrusive mechanism. 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 WS-Policy defines a mechanism to test the compatibility of two policies, called policy intersection. According to the WS-Policy specification [9] “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 WS-Governance: a policy language for SOA Governance 5 in WS-Policy, thus assertions authors have to define specific mechanisms for incorporating the intended semantics of the assertions, and the specification does not provide any mechanism to integrate or define it. For instance, the first policy specified in the left column and the policy in the right column of table 1 are incompatible, since their element types <rmp:RMAssertion>and <sp:AsymmetricBinding>are different. 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 [11] and [12]. When using WS-Policy to specify the policies 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 meta-data, in order to ensure authorization for policy enactment and the integrity of the policies as enacted, thus avoiding tampering. This is the role of seals and signatures of the real documents shown in figure 1. 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 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 since WS-Policy has not been designed keeping in mind that the scope of a policy could be defined by intension; i.e. we need specify the properties of services belonging the scope, not enumerate them. If an exogenous attachment with the proposal described in the WS-Policy specification is used, then all the services references will be inserted in the AppliesTo section of the policy. Thus, if there was a change in the policy scope, like All services except S23, S45, . . . ) this would entail a re-working of all 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. Summarizing, governance policies’ scope should be defined by intension through scope predicates in most cases. 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 (fig. 1) there are properties such as “critical services” and “local/external apps & services” whose values must be obtained from different information sources. However, WS-Policy extension mechanisms allow the definition of DSL for specifying policy scope (see fig. 3), thus we propose such a DSL as part of our proposal. Inadequate consistency checking: In our use case, the most valuable property was consistency checking. The only analysis operation WS-Policy envisioned for this was the intersection of policies. 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 structural-syntactical nature policy intersection operation as defined in WS-Policy, avoiding its usage in diverse scenarios [11,12]. For example, two identical-meaning policies may prove inconsistent by using the intersection operation (see [11]). We name this drawback as Syntax/Structure Driven Semantics (SDS). This limitation can be addressed by defining a domain specific intersection processor, and consequently, our proposal for providing semantic consistency checking can be integrated in such a way. However, authors consider that defining an entirely new operation called consistency and provide an explicit semantic for the DSLs defined is a better approach. Otherwise, the intersection operation, could process some assertions based on their structure, while others will be treated semantically, leading to to incoherent results (as shown in [11]). Thus, we leave intersection as an essentially sintactically/structural operation and define a new operation named consistency that supports semantic reasoning based on CSPs. 6 Jos´ e Antonio Parejo, Pablo Fernandez, and Antonio Ruiz-Cort´ es 4 From WS-Policy to Ws-Governance WS-Governance Documents (GDs) address limitations described previosly by incorporating an extensible context to the contained policies (addresing LCD), and defining a global document structure that contains a set of policies under an umbrella governance scope (where the data sources that feed predicates for defining policies scope can be included, addressing SDL). They also describe relevant governance properties of services, applications and organizational structures, and provide mechanisms for incorporating disparate governance-relevant information sources. Moreover, LCD and SDS motivate the creation of two general purpose XML-based DSLs for specifying governance policy assertions and SOA modelling, that are described in detail below. Based on those DSLs and the authors‘ experience providing formal semantics for SLAs specified in WS-Agreement by using CSPs [13,14,15], 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. The structure of a GD in WS-Governance comprises of: •Governance Document Context: It currently defines the governing organization but its grammar is left open in order to support the expressions of authorizations to enact policies on this GD, and the data needed to ensure GD authenticity and integrity. •Governance Scope: It provides information about the SOA where policies are established. Different information sources could be used in this section, from UDDI registries to ad hoc databases, since any SOA element could be a governance policy subject; such as projects, developers, organizations, messages, XML-schemas or applications servers. •Governance Properties: It defines all properties that are relevant for governance policies. Following the philosophy of WS-Policy, its grammar is left open, allowing the use of XML-based DSLs for specifying those properties. •Governance Policies: It defines the policies that conform the governance. Those polices are fully WS-Policy compliant, where the exogenous policy attachment mechanism is mandatory. Assertion and scope definition grammar is left open, allowing the use of XML-based DSLs. It is noticeable, that neither the definition of the new concept of Governance Document, nor the use of the DSLs for Governance Policies, break WS-Policy compatibility. Although authors consider that the document-oriented treatment of policies is more natural in governance contexts (as shown in the example of fig. 1) and better supports the life-cycle of policy creation [16], from authoring by humans to deployment into servers; any governance document can be transformed into a unique policy fully compliant with WS-Policy2. Moreover, the DSLs described below ares used in WS-Policy extension mechanisms and variation points as described in fig. 3 for providing suitable languages for governance policy definition. The UML class diagram shown in Fig. 3 represents our proposal of metamodel for WS-Governance documents. Some elements of WS-Governance are intentionally left open for extension in order to allow a high degree of flexibility. This flexibility is based on the use of XML-based DSLs in some variability points, allowing the creation of a whole family of governance languages. In Fig. 3 variability points are decorated with a VariabilityPoint UML stereotype. A brief description of these variability points is provided as follows: •Context DSL: the GD metadata in the context element can be extended with any information needed by means of the nesting of new XML elements and attributes. •SOA Specification: The architecture and elements to govern must be described in order to define unambiguous policies. •Governance Property Specification: A description of the properties of the governed elements of the SOA is needed in order to define expressive policies. Those properties must be expressed using a XML-Based DSL. 2In http://labs.isa.us.es/gda/WS-Policy-transformation.xslt is available an XSLT tranformation that allows to perform this conversion automatically. WS-Governance: a policy language for SOA Governance 7 Fig. 3. UML Metamodel of WS-Governance •Policy Expression Specification: Policy scope and assertions can be expressed using any predicate-oriented DSL. In order to define effective governance documents, those DSLs must be set. In our proposal we provide two DSLs that allow the creation of service-focused governance policies, i.e. policies that specify assertions defined on service properties and their directly related elements such as consumers, providers, and governance relevant information such as organizational structure. Those DSLs are Service oriented Architecture Description Language (SADL), addressing the SOA Specificaton variation point, and Governance Assertion Language (GAL), addressing the Governance Property Specification and Policy Expression Specification variation points. The UML Class Diagrams in Figs. 4 and 5 depicts the metamodel of SADL and GAL respectively. 4.1 SOA Modeling with SADL SADL has been designed to model the SOA state and structure, making our proposal independent of the specific governance information sources available on each SOA, such as UDDI Registries, LDAP directories, ad hoc databases, etc. SADL describes both the SOA structure as elements, and its state as the corresponding governance properties values for those elements. In this paper we focus on service-related governance policies, so SADL mainly contains elements related with services; however SADL is extensible, supporting the use of any XML-based construct as sub-elements of its basic structural elements. Specifically, structural elements in SADL are described as follows: •Service Oriented Architectures are networks of participants providing and consuming services to fulfill a purpose. In SADL these participants are specified as organizations and applications. •Organizations are participants with governance relevant identity and properties, tracing an organizational boundary on their owned applications and services. Organizations are arranged hierarchically, where an organization can contain various sub-organizations (e.g. departments) and have a unique parent. •Applications represent business processes, related capabilities and software packages. They allow the arrangement of software artifacts and capabilities independently of the organizational hierarchy in a governance-meaningful way. Applications are owned by a unique organization. Applications have a set of provided and consumed services. •Services represent capabilities that participants provide and consume. Regarding SOA state description, SADL allows the specification of property values for all the aforementioned elements based on GAL. 8 Jos´ e Antonio Parejo, Pablo Fernandez, and Antonio Ruiz-Cort´ es Fig. 4. UML Metamodel of SADL Finally, SADL provides a generic element for the specification of the concrete governance data sources as references; such as UDDI registries, that should be queried to obtain the governance-relevant SOA structure and state in order to check properties and test policies adherence. By creating adapters that query those data sources and create a SADL compliant SOA model, our proposal becomes independent of those specific data-sources, thus semantics of GDs are based on explicit SADL models. 4.2 Specifying Governance properties, and policy assertions with GAL Governance Assertion Language GAL is a generic and expressive language designed to declare governance properties and assertions. Property definitions in GAL have a name and an identifier as attributes, comprising of: (i) type definition, where basic XMLSchema [17] types are supported, (ii) an optional domain definition that restricts the space of valid values of the property; where it could be described as a GAL assertion (by intension) or as a set of values (by extension); and (iii) an optional SADL governance subject declaration, that defines the type of SOA element that can present the property (service, organization, policy, all, etc.). Through GAL constraints we provide a suitable language to specify policy assertions on governance properties. Assertions can be composed using WS-Policy composition operators: All, ExactlyOne and PolicyAlternative. In order to allow consistency checking, in this paper we use a subset of WS-Governance a bit less expressive, called WS-Governance*. A WS-Governance* document must use SADL to describe the SOA to govern and GAL to define governance properties, policy scopes and policy assertions. A WS-Governance* document (ρ) comprises of: •Governance Scope defines the set of organizations O, applications Aand services Sto govern, and their relationships, namely: consumption of services by applications and organizations, provision of services by applications and organizations, ownership of applications by organizations and hierarchy of organizations. Only those elements and relationship functions are used to define policies. •Governance Vocabulary must define the set of all properties Vused in the guarantee terms. WS-Governance: a policy language for SOA Governance 9 Fig. 5. UML Metamodel of GAL •For each governance policy both scope (s) and assertion (a) must be defined as GAL assertions on the properties defined in the governance vocabulary section, and only to those applied to the sets and relationship functions defined in Governance Scope. •Policy assertions can be composed using the compositors defined in WS-Policy. XML-Schemas that model WS-Governance* documents conforming the previously described syntax are available at http://www.isa.us.es/gda/schemas. Although readable for humans, XML is not as understandable as plain text. In Table 2 the structure of a WS-Governance* document is described in a plain text language, named WS-Gov4People, that is equivalent to the WS-Governance*. The mapping of XML elements onto its corresponding WS-Gov4People sentences is shown in Table 2. A WS-Gov4People document describing the policies specified in figure 1 and a simple SOA structure is shown in the first column of table 4. 5 Automatic consistency checking through CSPs As shown in [18], the definition of the semantics of a language can be accomplished through the definition of a mapping between the language itself and another language with well-defined semantics such as Abstract State Machines, Petri Nets, rewriting logic or CSPs. These semantic mappings between semantic domains are very useful not only to provide precise semantics to DSLs, but also to be able to simulate, analyze or reason about them. In this section we define the mappings that tranform GDs* onto Constraint Satisfaction Problems (CSPs) that provide their precise semantics, allowing the usage of CSP solvers to reason about policies and complete GDs*. A CSP ψ= (V, D, C)is defined as a set of variables V, a set of domains D(one for each variable), and a set of constraints Cspecifying which combinations of variables and values are acceptable. A solution σto a CSP ψconsists of an assignment in which each variable gets a value from its corresponding domain, as long as it satisfies each constraint. The solution space of a CSP ψ, denoted as sol(ψ), is composed of all its possible solutions, if the CSP has at least one solution it is satisfiable; i.e. sat(ψ)⇔sol(ψ)6=. Mapping a GD* into CSPs. The mapping (µGD :ρ→ψ) of a WS-Governance* GD (ρ) to a CSP (ψ) is performed in two steps as follows: