Governance Document Analyser (GDA)

WS-Governance

WS-Governance is a novel XML-Based language that allows the definition of Governance Documents. WS-Governance is based on WS-Policy but extends it, following its philosophy of open syntax and extensibility. A WS-Governance Document (GD) provides governance policies definitions (based on WS-Policy elements) 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 the drawbacks of WS-Policy for governance policies definitions. 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 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 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 Policies: It defines the policies that conform the governance. Those polices are 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.

The following UML class diagram represents our proposal of metamodel for WS-Governance documents.

DSLs in WS-Governance

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 the previous figure XML-based DSL 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.
• 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 Modelling Language (SAML), addressing the SOA Specificaton variation point, and Govenance Assertion Language (GAL), addressing the Governance Property Specification and Policy Expression Specification variation points.

The UML Class Diagrams shown below depicts the metamodel of SAML and GAL respectively.

SOA Modeling with SAML

AML 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, \adhoc databases, etc. SAML describes both the SOA structure as elements, and its state as the corresponding governance properties value to those elements. In this paper we focus on service-related governance policies, so SAML mainly contains elements related with services; however SAML is extensible, supporting the use of any XML-based construct as sub-elements of its basic structural elements. Specifically, structural elements in SAML are described as follows:

• Service Oriented Architectures are networks of participants providing and consuming services to

fulfill a purpose. In SAML 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 (\eg 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, SOAML allows the specification of property values for all the aforementioned elements based on GAL.

Finally, SAML 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 SOAML compliant SOA model, our proposal becomes independent of those specific data-sources, thus semantics of GDs are based on explicit SOAML models.

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 XML-Schema 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 SAML 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.

XML Schemas

XML-Schemas that model WS-Governance* documents conforming the previously described syntax are available at:

• WS-Governance
• SAML
• GAL

Download

Our propotype implementation is available for download at GDA.

User Manual

Our current prototype is a java jar file. You can invoke the analisys of a governance document with the following syntax:

java -jar GDA.jar GovernanceDocument [SOADefinition]

where GovernanceDocument is the path of a valid WS-Governance document, and SOAdefinition is an optinal prameter cotaining the path to a SAML SOA definition. If the SOAdefinition is specified, the SOA model included in GovernanceDocument is ignored. In the download pack we provide valid policies files and soa models.

(You need a proper jre installe in order to run GDA, for more information in this issue go to JRE Installation instructions)

Test Suite

We have developed a test suite that allows testing that the tool works properly. This suite is composed of a set of governance documents with well known documented inconsistences. In the following we provde links to each document and explain briefly why each document is inconsistent. The test suite is divided in three groups of files:

• Files that contain only one policy. Files in this group only can be inconsistent because of intrinsecal policy inconsistence or inconsistence between the policy an the soa description specified using SAML. This group comprises of:
  • SampleIntrinsicallyInconsistentPolicy.xml: This file contains a unique intrinsically inconsistent policy P1. Specifically, P1 states that For All services two clauses that conform a contradiction must hold: “Availability >= 95 AND Availability < 90“. The results obtained using the prototype on this policy should be:

Consistence Level	Result	Explaining
Intrinsic	False	Policy P1 is instrinsically inconsistent since “Availability >= 95 AND Availability < 90” is a contradiction
Policy Set	False	Policy P1 is instrinsically inconsistent
Document	False	Policy P1 is instrinsically inconsistent

• Files that contain multiple policies. This group comprises of:
  • SampleMutuallyInconsistentPolicies.xml: This file contains two policies P1 and P2 that are intrinsically consistent but inconsistent as a set, i.e. P1 contradicts P2. Specifically, P1 states that “For All services Availability >= 95“, and P2 states that “For All services Availability < 90“. Both policies can´t hold simultaneously, and consequently, the policy set of this document is inconsistent, independently of the SOA specified in the preamble of the document. The results obtained using the prototype on this policy should be:

Consistence Level	Result	Explaining
Intrinsic	True	Policies P1 and P2 are instrinsically consistent
Policy Set	False	Policy P1 contradicts P2.Thus, the policy set of this GD is inconsistent
Document	False	The policy set is inconsistent, consequently the document is inconsistent

• SampleTripleInconsistentPolicies.xml: This file contains three policies P1, P2 and P3 that are intrinsically consistent, consistent in pairs, i.e. policies sets {P1, P2},{P1, P3} and {P2, P3} are consistent, but inconsistent as a whole set, i.e. {P1, P2,P3} is inconsistent. Specifically, P1 states that “ For all services with Version = 1, Availability >= 95“, P2 states that “ For all critial services Version = 1“, and P3 states that “ All services are critical and either Version =\= 1 or Availability < 90 “. The results obtained using the prototype on this policy should be:

Consistence Level	Result	Explaining
Intrinsic	True	Policies P1,P2 and P3 are instrinsically consistent
Policy Set	False	Policy set {P1,P2,P3} is inconsistent
Document	False	The policy set is inconsistent

• Files modeling sample Governance Documents provided in papers submitted to journals and conferences. This group comprises of:
  • Files modeling the example of the paper submitted to e’10 e-passing 2010 by J. A. Parejo et al:
    • e-passing2010GovernanceDocument.xml: This file specifies the example described in the paper. A graphical representation of the SOA and policies specified in this file is shown in the next figure:

. This document contains three policies, P1, P2 and P3. P1 states that “All critical services are consumed locally“, i.e. consumers of critical services pertain the same organization of its providers. P2 states that “All critical services have 24×7 availability“, note that this availability value is modelled in the file as an ingeter value equal to 1. P3 states that “ all applications that consume s1 and do not pertain the organization that provides s1 will have and availability for s1 of ‘window’“, note that Availability equal to window is expressed in the file as Availability=0. Thus, the policy set of this document is consistent, but in the concrete SOA specified in SAML in this document, inconsistences arise. Specifically, the SOA model states that, “ s2 is Critical “, “ s2 is provided by organization o2 ” and “ s2 is consumed application ‘Zeus’ owned by organization o1“, ““. In this context two inconsistences arise: on the one hand the statements specified above contradict P1, since o2 is different of o1 and an application of o1 is consuming a critical service of o2 (s2); on the other hand, the statements specified above conform a contradiction between P2 and P3, since it is both critical and consumed by a external application, making that constraints on availability of each policy become a contradiction. The results obtained using the prototype on this policy should be:

Consistence Level	Result	Explaining
Intrinsic	True	Policies P1,P2 and P3 are instrinsically consistent
Policy Set	True	Policy set {P1,P2,P3} is consistent
Document	False	There are inconsistences between the policy set and SOA specification

In order to test that our tool finds both inconsistences, two additional files have been created cotaining the elements that lead to each inconsistence:

• e-passing2010Part1.xml This file contains the elements that lead to the first inconsistence.
• e-passing2010Part2.xml This file contains the elements that lead to the second inconsistence.

Governance Document Editor (GDE)

Governance Document Editor is a web application to edit government documents in an assisted way. The editor window is divided in three areas as shown in the new figure.

On the top section, there are different options to open, save and analyse GDs. On the left side of the main area, every section in the GD is organized in a tree view. Every node on the tree is attributed on the right-hand side. The main tree has separate sections for each subsection in GD, that is:

• SOA Governance Organization
• Domain vocabulary, that is, their properties.
• Governance policies

Language syntax elements are automatically generated from the tree model, so edition focuses on the relevant government contents, avoiding syntax errors. The editor is available on-line at http://labs.isa.us.es/apps/gde/.