Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. 11 Introduction..............................................................................................................................................2 22 Architectural Goals and Principles...........................................................................................................2 33 Service Ecosystem View..........................................................................................................................2 44 Realizing Service Oriented Architectures View........................................................................................2 55 Owning Service Oriented Architectures View..........................................................................................2 6 5.1 Policies and Contracts Model...........................................................................................................2 7 5.1.1 Policy and Contract Principles...................................................................................................4 8 5.1.2 Policy Metrics............................................................................................................................7 9 5.2 SOA Governance and Management Model......................................................................................7 10 5.2.1 Understanding Governance.......................................................................................................7 11 5.2.2 A Generic Model for Governance..............................................................................................8 12 5.2.3 Management and Governance................................................................................................10 13 5.2.4 SOA Governance....................................................................................................................11 14 5.2.5 Management of Services ........................................................................................................16 15 5.3 SOA Testing Model.........................................................................................................................21 16 5.3.1 Traditional Software Testing as Basis for SOA Testing...........................................................22 17 5.3.2 Testing and the SOA Ecosystem.............................................................................................23 18 5.3.3 Elements of SOA Testing........................................................................................................24 19 5.3.4 Testing SOA Services.............................................................................................................28 20 5.3.5 Architectural Implications for SOA Testing..............................................................................31 21 5.4 Security Model................................................................................................................................31 22 5.4.1 Security Concepts...................................................................................................................32 23 5.4.2 Where SOA Security is Different.............................................................................................33 24 5.4.3 Trust .......................................................................................................................................33 25 5.4.4 Security Layers........................................................................................................................36 26 5.4.5 Security Threats......................................................................................................................38 27 5.4.6 Security Responses................................................................................................................39 28 5.4.7 Architectural Implications of SOA Security..............................................................................40 29
  2. 2. 30 1 Introduction 31 2 Architectural Goals and Principles 32 3 Service Ecosystem View 33 4 Realizing Service Oriented Architectures View 34 5 Owning Service Oriented Architectures View 35 Governments are instituted among Men, 36 deriving their just power from the consent of the governed 37 American Declaration of Independence 38 39The Owning Service Oriented Architectures View focuses on the issues, requirements, and 40responsibilities involved in owning a SOA-based system. Owning a SOA-based system raises 41significantly different challenges to owning other complex systems -- such as Enterprise suites -- because 42there are strong limits on the control and authority of any one party when a system spans multiple 43ownership domains. 44Even when a SOA-based system is deployed internally within an organization, there are multiple internal 45stakeholders involved and there may not be a simple hierarchy of control and management. Thus, an 46early consideration of how multiple boundaries affect SOA-based systems will provide a firm foundation 47for dealing with them in whatever form they are found rather than debating whether the boundaries should 48exist. 49This view focuses on the role of policies and contracts in controlling, Governance and Management 50challenges, and on the security challenges involved in running a SOA-based system. 51 52 Figure 1 Model Elements Described in the Owning Service Oriented Architectures View 53The following subsections present models of these functions. 545.1 Policies and Contracts Model 55The owners and leadership of an organization use governance to decide on policies that reduce intra- 56organizational conflict (or process friction) and to help ensure thatare intended to align all participants in 57the organization work together to achieve the organization’s goal. In an ecosystem SOA, there are 58organizations with overlapping goals and conflicting policies, but which may want to team to achievethose
  3. 3. 59organizations agree to policies that reflect their overlapping goals. The participating organizations enter 60into a contractpurpose of the policies is to help ensure that all teaming partners work together by reducing 61inter-organizational conflict, increasing the effectiveness of the team. Section 5.1 will define and discuss 62the concepts of policies and contracts as applied to SOA. Section 5.2 will discuss how the organization 63governs and manages policies and contracts related to SOA. 64Policy 65 A policy represents some constraint or condition on the use, deployment, or description of a 66 resource as defined by a participant or, more generally, a stakeholder. 67A policy is the formal characterization of the conditions and constraints that governance deems as 68necessary to realize the goals which it is attempting to satisfy. Policy may identify required conditions or 69actions or may prescribe limitations or other constraints on permitted conditions or actions. For example, 70a policy may prescribe that safeguards must be in place to prevent unauthorized access to sensitive 71material. It may also prohibit use of computers for activities unrelated to the specified work assignment. 72Policy is made operational through the promulgating and implementing of Rules and Regulations (as 73defined in section XXX). 74As discussed in the Reference Model, a policy that cannot be enforced is better described as a wish. In 75the context of SOA, it should be clear how compliance can be assessed for policies and derived rules and 76regulations, who is to assess compliance, and when, e.g. at a single milestone or on a recurring basis, the 77compliance is assessed. Compliance is discussed further in section 5.2. 78"Although provision of management capabilities enables a service to become manageable, the extent and 79degree of permissible management are defined in management policies that are associated with the 80services. Management policies are used to define the obligations for, and permissions to, managing the 81service." [WSA] On the other hand, a policy without any means of enforcing it is vacuous; merely an 82admonishment to virtue. In the case of management policy, we rely on a management infrastructure to 83realize and enforce management policy. 84Contract 85 A contract represents an agreement by two or more participants to constrain their behavior and 86 state. 87Contracts are legally binding agreements between two or more parties. A contract is formed when there is 88an offer that is duly made and the offer is accepted and there is evidence that indicates there was a 89tangible exchange of value between the two parties. While this Reference Architecture is inclusive of 90legally binding contracts for a SOA, contracts do not always have to be legally binding agreements. 91A contract may include references to policies and other contracts while a policy may include references to 92contracts and other policies. For example, a contract may reference a set of policies and a policy may 93prioritize certain contracts over others. 94As noted in section 4.4.2, policy may be asserted by any participant or on behalf of the participant by its 95organization. Part of the purpose of governance is to arbitrate among diverse goals of participants by 96deciding on policies articulated to realize those goals. The intent is to form a consistent whole that allows 97governance to minimize ambiguity about its purpose. While resolving all ambiguity would be an ideal, it is 98unlikely that all inconsistencies will be identified and resolved before governance becomes operational. 99For governance to have effective jurisdiction over participants, the participants must be in some degree of 100agreement that it will abide by the governance mandates. A minimal degree of agreement often presages 101participants who “slow-roll” if not actively reject complying with Policies that express the specifics of 102governance. 103As described in the Reference Model, a policy is an enforceable constraint or condition on the use, 104deployment, or description of an owned entity as defined by any participant. A contract is a constraint 105that has the agreement of the constrained participants. 106This Reference Architecture reflects a common separation between mechanism and policy. In many 107situations it is often simpler to build mechanisms that address a more general problem than the one at 108hand, and then to use that general mechanism to solve the particular problem. In the case of a SOA 109ecosystem, the mechanisms focus on the ability to match participants’ needs with service capabilities. 110However, each particular combination of need and capability is very likely to be distinct; resulting in a 111large number of circumstances. The leadership can use policies as a framework or structure for managing 112this combinatorial explosion.
  4. 4. 113Policies and contracts have wide applicability within the Reference Architecture. They are used to express 114security policies, service policies, relationships, and constraints within the social structures that 115encapsulate service participants, management of services, and many other instances. The enforcement 116of a policy or contract may be a part of the SOA-based computing environment or it may be handled 117outside of the SOA-based computing environmentdone in an automated fashion as part of a service 118interaction or it may be handled in separate, external processes. 1195.1.1 Policy and Contract Principles 120In the realization of policies and contracts for a SOA, there are common policy principles that will be 121encountered in many of the standards and/or technology choices used for the realization. Six of these 122common principles are covered in this section. 1235.1.1.1 Principle 1: Goals of Policies and Contracts 124Policies SHOULD reflect the goals of governance or management processes; see Section 5.2 125Governance of Service Oriented Architectures and section 5.3 Services as Managed Entities Model. The 126governance and management processes SHOULD use formal and standardized policy languages to 127enable the widest possible understanding and use of stated policies and contracts, and architecture 128components SHOULD be available to enable compliance. 1295.1.1.2 Principle 2: Policy and Contract Specification 130The governance and management processes SHOULD use formal and standardized policy languages to 131enable the widest possible understanding and use of stated policies and contracts, and architecture 132components SHOULD be available to enable compliance. The language used to describe policies and 133contracts inevitably constrains the forms and types of policies and contracts expressible in the 134description. FHowever, formal policy language definitions are outside the scope of this specification. For 135formal policy languages, standard specifications such as XACML and WS-Policy may be referenced. 136Policy/Contract descriptions may be associated with a service through the Service Description as defined 137in Section 4.1 Service Description Model. 138Regardless of the language used to describe policies and contracts, there are certain aspects to capture 139in any system for representing policies and contracts including: 140 • the description of atomic policy constraints 141 • the methods for nesting of policy constraints; allowing for abstractions and refinements of a policy 142 constraint 143 • the methods for the referencing policy constraints allowing for the reuse of a policy constraint 144 • the methods for defining alternative policy constraints for the selection of compatible policy 145 constraints between the consumer and provider 146 • policy versioning 147 • policy modules 148Policy/Contract descriptions may be associated with a service through the Service Description as defined 149in Section 4.1 Service Description Model. 1505.1.1.3 Principle 3: Policy Constraints Specification 151Policies are often characterized in terms of permissions or aboutand obligations. An overriding meta- 152constraint is that policy constraints (likewise contract constraints) MUST be enforceable – a constraint 153that is not enforceable is not a legitimate element of a system of policies and contracts in the SOA 154ecosystem.
  5. 5. 155 156 Figure 2 Policies and Contracts 157Policy Constraint 158 A policy constraint is a measurable proposition that characterizes the intent of the policy. 159Permission 160 A permission constraint governsstates the ability of a participant or other actor to perform an 161 action or enter some specified state. 162Permissions may apply to any action that any actor may be able to perform. Note that permissions are 163distinct from ability and from authority. Authority refers to the legitimate nature of an action, whereas 164permission refers to the right to perform the action. 165Obligation 166 An obligation constraint governsstates the requirement that a participant or other actor should 167 perform an action or maintain some specified state. 168For example, once the service consumer and provider have entered into an agreement to provide and 169consume a service, both participants incur obligations: the consumer is obligated to pay for the service 170and the provider is obligated to provide the service. 171Obligations to maintain state may range from a requirement to maintain a minimum balance on an 172account through a requirement that a service provider ‘remember’ that a particular service consumer is 173logged in. 174A permission-style constraint is about the right to access some resource or perform some action; an 175obligation-style constraint is about the requirement to perform some action or maintain the state of a 176resource. 177Obligations and Permissions have a positive form and a negative form. A positive permission refers to 178something that you may do, a negative permission refers to something you should not do. Similarly, a 179negative obligation states something a participant is obliged not to do. 180These are combinable, in the sense that you may have a positive permission constraint (for example, you 181may use encryption in your messages), whereas a negative permission constraint indicates that there is 182something you may not do. Similarly, a positive obligation may be something like you must keep the 183balance of your account positive; whereas an example of a negative obligation may be that the bank will 184not cover a check for more than the balance in your account. 185Permission-style constraints are often checkable a-priori: before the intended action or access is 186completed, the current permission constraints may be applied to deny the access if necessary. However, 187obligation-style constraints can normally only be verified post-priori. 188Policies and contracts can contain a mix of permissions and obligations, and, in sufficiently rich policy 189management frameworks, can be combined in interesting ways: for example, you may be obliged to give 190permission to certain actions; or you may be permitted to enter into obligations (this is the core of the right 191to enter into contracts). 192In a business context, contracts are legally binding agreements between two or more parties. A contract 193is formed when there is an offer that is duly made and the offer is accepted and there is evidence that 194indicates there was a tangible exchange of value between the two parties. While this Reference
  6. 6. 195Architecture is inclusive of legally binding contracts for a SOA, contracts do not always have to be legally 196binding agreements. 197A contract may include references to policies and other contracts while a policy may include references to 198contracts and other policies. For example, a contract may reference a set of policies and a policy may 199prioritize certain contracts over others. 2005.1.1.4 Principle 4: Policy Composition 201Multiple policies may be defined for one or more services in one or more ownership domains. The 202application of policies and contracts over distributed services requires the ability to compose one or more 203policies into an overarching policy. The composition of policies may be implemented as a hierarchy or 204nesting and/or it can be implemented as intersections and unions of sets. 2055.1.1.5 Principle 5: Conflict Resolution 206The analysis of policy rules may result in conflicts between or among the policy rules. There can be many 207causes for policy conflicts such as conflicting policy rules between ownership domains and policy 208language specifications that do not convert to first order predicate logic for IT policy mechanisms. This 209can cause policy decision results to be indeterminate. Policy administration mechanisms may provide 210conflict resolution capabilities prior to the storage/distribution of policies. At run time, conflicts may 211propagate to higher authorities inside or outside the SOA-based IT mechanisms.The prospective 212participants in a service interaction may each have differing policies, and the establishing of the execution 213context requires resolution of policy conflicts before interaction can proceed. The enterprise or the more 214general SOA ecosystem MUST include internal or parallel external mechanisms to resolve such conflicts. 2155.1.1.6 Principle 56: Delegation of Policy 216Policy authorization may be delegated to agents acting on behalf of a client to enable decentralized policy 217administration and/or policy enforcement. This allows policies to be administered and/or enforced in a 218hierarchical fashion. Policies may also be transferred to an agent or resource to effectively allow that 219agent or resource to separate from an ownership domain. The agent or resource may join another 220ownership domain or rejoin the same ownership domain later.As discussed below, management is 221delegated the responsibility to implement policy through rules and regulations. In a hierarchical 222organization, a management level may express derived policies that are appropriate for its subordinate 223levels, and those levels may institute rules and regulations or further derived policies as needed to 224establish sufficient guidance and details for assessing compliance. The delegation may also be to peer 225levels that have specialized skill in the implementation of the policy; an example would be a peer 226delegated to define the details of security. 227Multiple governance chains are discussed in section
  7. 7. 2285.1.2 Policy Metrics 229 230 Figure 50 Policy Metrics 231Metrics often express measurement of service performance compliance and regulatory compliance. 232Service Level Agreements (SLAs) are one commonly used category of contractual compliance. There 233are two types of SLAs according to the ITIL Standard: Operational Level Agreements, e.g., response 234time, server uptime, etc., and Business Service Level Agreements, e.g., the procurement system will be 235up from 8 AM EST to 8 PM PST, five days a week. The metrics that comprise a SLA often consists of 236(Service Level) constraints such as <service level SLA stuff> or <business level constraints> such as 237<business level SLA stuff>. 238Within a single ownership domain such as an enterprise, generally there is a hierarchy of governance 239structures. Some of the more common enterprise governance structures include corporate governance, 240technology governance, IT governance, and architecture governance [TOGAF v8.1]. These governance 241structures can exist at multiple levels (global, regional, and local) within the overall enterprise. 2425.2 SOA Governance and Management Model 243The SOA-RM defines Service Oriented Architecture as an architectural paradigm for organizing and 244utilizing distributed capabilities that may be under the control of different ownership domains [SOA-RM]. 245Consequently, it is important that organizations that plan to engage in service interactions adopt 246governance policies and procedures sufficient to ensure that there is standardization across both internal 247and external organizational boundaries to promote the effective creation and use of SOA-based services. 2485.2.1 Understanding Governance 249Winston Churchill said “To govern is to decide.” The question is “decide about what?” There are several 250recommendations for the organization, IT, and SOA. Governance is about making decisions that are 251aligned with the overall organizational strategy and culture of the enterprise. [Gartner] It specifies the 252decision rights and accountability framework to encourage desirable behaviors [Weill/Ross-MIT Sloan 253School] towards realizing the strategy and defines incentives (positive or negative) towards that end. It is 254less about overt control and strict adherence to rules, and more about guidance and effective and 255equitable usage of resources to ensure sustainability of an organization’s strategic objectives. [Open 256Group]. Succinctly put, the purpose (or reason for being) of Governance is to decide on policies that will 257minimize process friction within and among ownership domains, thereby increasing the level of trust and 258interaction within and among ownership domains. 259To accomplish this, governance requires organizational structure and processes and must identify who 260has authority to define and carry out its mandates. It must address the following questions: 1) what
  8. 8. 261decisions must be made to ensure effective management and use?, 2) who should make these 262decisions?, and 3) how will these decisions be made and monitored?, and (4) how will these decisions be 263communicated? The intent is to achieve goals, add value, and reduce risk. 2645.2.2 A Generic Model for Governance 265In general, within any one organization the concepts of governance would fit into the following 266governance and management model. Figure X1 shows a generic model of governance represented by 267segmented models that begin with motivation and proceed through measuring compliance. It is not 268meant to be an all-encompassing treatise on governance but a focused subset that captures the aspects 269necessary to describe governance for SOA. It is not meant to imply that practical application of 270governance is a single, isolated instance of these models; in fact, there are likely hierarchical chains of 271governance that apply and possibly parallel chains that govern different aspects or focus on different 272goals. This is discussed further in section XXX. The defined models are simultaneously applicable to each 273of the overlapping instances. 274 275 Figure X1—The High-level Governance and Management Model 276In addition to the definitions of policies and contracts defined in Section 5.1, the objects of the model in 277Figure X1 are defined as: 278Governance 279 Governance decides which conditions and constraints are necessary for the organization or 280 among organization to enable it to satisfy common goals and the structures and processes 281 needed to define and respond to actions taken towards realizing those goals. 282Governance Framework 283 The Governance Framework is a set of organizational structures that enable governance to be 284 consistently defined, clarified, and as needed, modified to respond to changes in its domain of 285 concern.
  9. 9. 286Governance Processes 287 Governance Processes are the defined set of activities that are performed within the Governance 288 Framework that enable the consistent definition, application, and as needed, modification of 289 Rules that organize and regulate the activities of Participants for the fulfillment of expressed 290 policies. (See section XXX for elaboration on the relationship of Governance Processes and 291 Rules.) 292Leadership 293 Leadership is the entity who has the responsibility and authority to generate consistent policies 294 through the use of the governance processes and framework to define and champion the 295 structures and processes through which the goals of governance are realized. 296Policy 297 A policy is the formal characterization of the conditions and constraints that governance deems 298 as necessary to realize the goals which it is attempting to satisfy. Policy may identify required 299 conditions or actions or may prescribe limitations or other constraints on permitted conditions or 300 actions. For example, a policy may prescribe that safeguards must be in place to prevent 301 unauthorized access to sensitive material. It may also prohibit use of computers for activities 302 unrelated to the specified work assignment. Policy is made operational through the promulgating 303 and implementing of Rules and Regulations (as defined in section XXX). 304Policy 305 A policy represents some constraint or condition on the use, deployment, or description of a 306 resource as defined by a participant or, more generally, a stakeholder. 307 "Although provision of management capabilities enables a service to become manageable, the 308 extent and degree of permissible management are defined in management policies that are 309 associated with the services. Management policies are used to define the obligations for, and 310 permissions to, managing the service." [WSA] 311 On the other hand, a policy without any means of enforcing it is vacuous. In the case of 312 management policy, we rely on a management infrastructure to realize and enforce management 313 policy. 314 315Contract 316 A contract represents an agreement by two or more participants to constrain their behavior and 317 state. 318Management 319 Management is the control of the use, configuration, and availability of resources in accordance 320 with the policies of the stakeholders involved. Management is the entity responsible to enact, 321 enforce, and mediate the policies defined by the Leadership through the Governance Process. 322Rule 323 A Rule is a prescribed guide for carrying out activities and processes leading to desired results, 324 e.g. the operational realization of policies. 325Regulation 326 A Regulation is a mandated process or the specific details that derive from the interpretation of 327 Rules and lead to measureable quantities against which compliance can be measured. 328Metric 329 A metric is a policy constraint used to measure compliance. 330Governance requires an appropriate organizational structure and the identification of who has authority to 331make governance decisions. In the above figure, the entity with governance authority is designated the 332Leadership. This is someone, possibly one or more of the Participants, which the Participants recognize 333as having authority for a given purpose or over a given set of issues or concerns. 334The Leadership is responsible for prescribing or delegating a working group to prescribe the Governance 335Framework that forms the structure for Governance Processes, which define how governance is to be
  10. 10. 336carried out. Normally this group is management. The Governance Process does not itself define the 337specifics of how governance is to be applied, but it does provide an unambiguous set of procedures that 338should ensure consistent actions, which Participants agree, are fair and account for sufficient input on the 339subjects to which governance will be applied. 340The Participants may be part of the working group that codifies the Governance Framework and 341Processes. When complete, the Participants must acknowledge and agree to abide by the products 342generated through application of this structure. 343The Governance Framework and Processes are often documented in the charter of a body created or 344designated to oversee governance. This is discussed further in the next section. Note that the 345Governance Processes should also include those necessary to modify the Governance Framework itself. 346An important function of Leadership is not only to initiate but also be the consistent champion of 347Governance. Those responsible for carrying out governance mandates must have Leadership who 348makes it clear to Participants that expressed Policies are seen as a means to realizing established goals 349and that compliance with governance is required. 350A given enterprise may already have portions of these models in place. To a large extent, the models 351shown here are not specific to SOA; discussions on direct applicability begin in Section XXX. 3525.2.2.1 Motivating Governance 353 354 Figure 3 Motivating governance model 355An organizational domain such as an enterprise is made up of Participants who may be individuals or 356groups of individuals forming smaller organizational units within the enterprise. The overall business 357strategy should be consistent with the Goals of the participants; otherwise, the business strategy would 358not provide value to the participants and governance towards those ends becomes difficult if not 359impossible. This is not to say that an instance of governance will simultaneously satisfy all the goals of all 360the participants; rather, the goals of any governance instance must sufficient to enable the participants to 361satisfy a useful subset of each participant's goals so as to provide value and ensure the cooperation of all 362the participants. 363Governance does this through policies. Policies provide guidance as to acceptable or unacceptable 364interactions among the participants. Policies are often characterized in terms of permissions or about 365obligations. An overriding meta-constraint is that policy constraints (likewise contract constraints) MUST 366be enforceable – a constraint that is not enforceable is not a legitimate element of a system of policies 367and contracts in the SOA ecosystem. 3685.2.3 Management and Governance 369The primary role of governance is to decide or set the key policies that govern the running of the system. 370Recall that in an ecosystems perspective for SOA, the goal is less about having complete fine-grained 371control of the Service Components, but more about enabling the individual participants to work together. 372Policies that are set at the governance of a SOA will tend to focus on the rules of engagement between 373participants – what kind of interacts are permissible, how to resolve disputes, and so on. 374While governance may be primarily focused on setting policies, management is more focused on 375enactment, enforcement, and mediation of policies.
  11. 11. 3765.2.4 SOA Governance 377This section will apply the model of Governance, as shown in Figure X1 in Section XXX within the SOA 378ecosystem execution context. 3795.2.4.1 The Importance of SOA Governance 380One of the hallmarks of SOA that distinguishes it from other architectural paradigms for distributed 381computing is its ability to provide a uniform means to offer, discover, interact with, and use capabilities, as 382well the ability to compose new capabilities (assemble services) from existing ones in response to the 383organization’s environment, (i.e., agility) that transcends ownership domains. Consequently, ownership, 384and issues surrounding it, such as obtaining acceptable terms and conditions (T&Cs) in a contract, is one 385of the primary topics for SOA governance. Generally, IT governance does not include T&Cs, for example, 386as a condition of use as its primary concern. Instead, organizations consider T&Cs the purview of the 387“business”, not IT. 388Just as other architectural paradigms, technologies, and approaches to IT are subject to change and 389evolution, so too is SOA. Setting policies that allow change management and evolution, establishing 390strategies for change, resolving disputes that arise, and ensuring that SOA-based systems continue to 391fulfill the goals of the business are all reasons why governance is important to SOA. 392As noted in Section XXX, the participants in a service interaction include the service provider, the service 393consumer, and other interested or unintentional third parties. Depending on the circumstances, it may 394also include the owners of the underlying capabilities that the SOA services access. Governance must 395establish the policies and rules under which duties, responsibilities, and obligations are defined and which 396ground the expectations of the participants. These expectations include transparency in aspects where 397transparency is mandated; trust in the impartial and consistent application of governance, and assurance 398of reliable and robust behavior throughout the SOA ecosystem. 3995.2.4.2 Characteristics of SOA Governance 400It is often asserted that SOA governance is a special form of IT governance as there is a natural hierarchy 401of these types of governance structures; however, the focus of SOA governance is less on decisions to 402ensure effective management and use of IT as it is to ensure effective management and use of SOA- 403based systems. Certainly, SOA governance must still answer the basic questions also associated with IT 404governance, i.e., who should make the decisions, and how these decisions will be made and monitored. 405An expected benefit of employing SOA principles is the ability to bring resources to bear quickly to deal 406with unexpected and evolving situations. This requires a great deal of confidence in the underlying 407capabilities that can be accessed and in the services that enable the access. It also requires 408considerable flexibility in the ways these resources can be employed. Thus, SOA governance requires 409establishing confidence and trust while instituting a solid framework that enables flexibility, indicating a 410combination of strict control over a limited set of foundational aspects but minimum constraints beyond 411those bounds. 412Governance, in the context of SOA, includes; the organization of services that promotes their visibility, 413facilitates interaction among service participants, and directs that the results of service interactions are 414those real world effects as described within the service description and constrained by policies and 415contracts as assembled in the execution context. SOA governance must specifically coordinate policy 416among ownership domains, i.e. all the participants may not be under the jurisdiction of a single 417governance authority. For governance to be effective, the participants must agree to recognize the 418authority of the Governance Body and must operate within the Governance Framework and through the 419Governance Processes so defined. 420Being distributed and representing different ownership domains, a SOA participant is likely under the 421jurisdiction of multiple governance domains simultaneously and may individually need to resolve the 422consequent conflicts. The governance domains may specify precedence for governance conformance or 423it may fall to the discretion of the participant to decide on the course of actions they believe appropriate. 424SOA governance must account for interactions across ownership boundaries, which likely implies across 425enterprise governance boundaries. For such situations, governance emphasizes the need for agreement 426that some Governance Framework and Governance Processes have jurisdiction, and the governance 427defined must satisfy the Goals of the Participants for cooperation to continue. A standards development
  12. 12. 428organization such as OASIS is an example of voluntary agreement to governance over a limited domain 429to satisfy common goals. 430The specifics discussed in the Figure 3 apply equally to governance across ownership boundaries as 431within a single boundary. There is a charter agreed to when Participants become members of the 432organization, and this charter sets up the structures and processes that will be followed. Leadership may 433be shared by the leadership of the overall organization and the leadership of individual groups themselves 434chartered per the Governance Processes. There are Rules/Regulations specific to individual efforts for 435which Participants agree to local goals, and Enforcement can be loss of voting rights or under extreme 436circumstances, expulsion from the group. Thus, the major difference for SOA governance is an 437appreciation for the cooperative nature of the enterprise and its reliance on furthering common goals if 438productive participation is to continue. 440 Figure 4 Types of governance 441SOA governance applies to three aspects of service definition and use: 442 • SOA infrastructure – the “plumbing” that provides utility functions that enable and support the use 443 of the service 444 • Service inventory – the requirements on a service to permit it to be accessed within the 445 infrastructure 446 • Participant interaction – the consistent expectations with which all participants are expected to 447 comply 4485. Governance of SOA infrastructure 449The SOA infrastructure is likely composed of several families of SOA services that provide access to 450fundamental computing business services. These include, among many others, services such as 451messaging, security, storage, discovery, and mediation. By characterizing the environment as containing 452families of SOA services, the assumption is that there may be multiple approaches to providing the 453business services or variations in the actual business services provided. For example, discovery could be 454based on text search, on metadata search, on approximate matches when exact matches are not 455available, and numerous other variations. The underlying implementation of search algorithms are not the 456purview of SOA governance, but the access to the resulting service infrastructure enabling discovery 457must be stable, reliable, and extremely robust to all operating conditions. Such access enables other 458specialized SOA services to use the infrastructure in dependable and predictable ways, and is where 459governance is important.
  13. 13. 4605. Governance of the service inventory 461Given an infrastructure in which other SOA services can operate, a key governance issue is which SOA 462services to allow in the ecosystem. The major concern SHOULD be a definition of well-behaved services, 463where the required behavior will likely inherit their characteristics from experiences with distributed 464computing but will also evolve with SOA experience. A major requirement for ensuring well-behaved 465services is collecting sufficient metrics to know how the service affects the SOA infrastructure and 466whether it complies with established infrastructure policies. 467Another common concern of service approval is whether there will be duplication of function by multiple 468services. Some governance models talk to a tightly controlled environment where a primary concern is to 469avoid any service duplication. Other governance models talk to a market of services where the 470consumers have wide choices. For the latter, it is anticipated that the better services will emerge from 471market consensus and the availability of alternatives will drive innovation. 472It is likely that some combination of control and openness will emerge, possibly with a different 473appropriate balance for different categories of use. The governance issue for allowable services is in 474identifying the required attributes to adequately describe a service, the required target values of the 475attributes, and the standards for defining the meaning of the attributes and their target values. 476Governance may also specify the processes by which the attribute values are measured and the 477corresponding certification that some realized attribute set may imply. 478For example, unlimited access for using a service may require a degree of life cycle maturity that has 479demonstrated sufficient testing over a certain size community. Alternately, the policy may specify that a 480service in an earlier phase of its life cycle may be made available to a smaller, more technically 481sophisticated group in order to collect the metrics that would eventually allow the service to advance its 482life cycle status. 483This aspect of governance is tightly connected to description because, given a well-behaved set of 484services, it is the responsibility of the consumer (or policies promulgated by the consumer’s organization) 485to decide whether a service is sufficient for that consumer’s intended use. The goal is to avoid global 486governance specifying criteria that are too restrictive or too lax for the local needs of which global 487governance has little insight. 488Such an approach to specifying governance allows independent domains to describe services in local 489terms while still having the services available for informed use across domains. In addition, changes to 490the attribute sets within a domain can be similarly described, thus supporting the use of newly described 491resources with the existing ones without having to update the description of all the legacy content. 4925. Governance of participant interaction 493Finally, given a reliable services infrastructure and a predictable set of services, the third aspect of 494governance is prescribing what is required during a service interaction. Governance would specify 495adherence to service interface and service reach-ability parameters and would require that the result of 496an interaction MUST correspond to the real world effects as contained in the service description. It would 497also rely on sufficient monitoring by the SOA infrastructure to ensure services remain well-behaved during 498interactions, e.g. do not use excessive resources or exhibit other prohibited behavior. Governance would 499also require that policy agreements as documented in the execution context for the interaction are 500observed and that the results and any after effects are consistent with the agreed policies. It is likely that 501in this area the governance will focus on more contractual and legal aspects rather than the precursor 502descriptive aspects. SOA governance may prescribe the processes by which SOA-specific policies are 503allowed to change, but, likely, there are more business-specific policies that will be governed by 504processes outside SOA governance. 5055.2.4.3 Architectural Implications of SOA Governance 506The description of SOA governance indicates numerous architectural requirements on the SOA 507ecosystem: 508 • Governance is expressed through policies and assumes multiple uses of focused policy modules 509 that can be employed across many common circumstances. This requires the existence of: 510 o descriptions to enable the policy modules to be visible, where the description includes a 511 unique identifier for the policy and a sufficient, and preferably a machine process-able,
  14. 14. 512 representation of the meaning of terms used to describe the policy, its functions, and its 513 effects; 514 o one or more discovery mechanisms that enable searching for policies that best meet the 515 search criteria specified by the service participant; where the discovery mechanism will 516 have access to the individual policy descriptions, possibly through some repository 517 mechanism; 518 o accessible storage of policies and policy descriptions, so service participants can access, 519 examine, and use the policies as defined. 520 • Governance requires that the participants understand the intent of governance, the structures 521 created to define and implement governance, and the processes to be followed to make 522 governance operational. This requires the existence of: 523 o an information collection site, such as a Web page or portal, where governance 524 information is stored and from which the information is always available for access; 525 o a mechanism to inform participants of significant governance events, such as changes in 526 policies, rules, or regulations; 527 o accessible storage of the specifics of Governance Processes; 528 o SOA services to access automated implementations of the Governance Processes 529 • Governance policies are made operational through rules and regulations. This requires the 530 existence of: 531 o descriptions to enable the rules and regulations to be visible, where the description 532 includes a unique identifier and a sufficient, and preferably a machine process-able, 533 representation of the meaning of terms used to describe the rules and regulations; 534 o one or more discovery mechanisms that enable searching for rules and regulations that 535 may apply to situations corresponding to the search criteria specified by the service 536 participant; where the discovery mechanism will have access to the individual 537 descriptions of rules and regulations, possibly through some repository mechanism; 538 o accessible storage of rules and regulations and their respective descriptions, so service 539 participants can understand and prepare for compliance, as defined. 540 o SOA services to access automated implementations of the Governance Processes. 541 • Governance implies management to define and enforce rules and regulations. Management is 542 discussed more specifically in section 5.2.5, but in a parallel to governance, management 543 requires the existence of: 544 o an information collection site, such as a Web page or portal, where management 545 information is stored and from which the information is always available for access; 546 o a mechanism to inform participants of significant management events, such as changes 547 in rules or regulations; 548 o accessible storage of the specifics of processes followed by management. 549 • Governance relies on metrics to define and measure compliance. This requires the existence of: 550 o the infrastructure monitoring and reporting information on SOA resources; 551 o possible interface requirements to make accessible metrics information generated or 552 most easily accessed by the service itself. 5535.2.4.4 Considerations for Multiple Governance Chains 554As noted in section XXX, instances of the governance model often occur as a tiered arrangement, with 555governance at some level delegating specific authority and responsibility to accomplish a focused portion 556of the original level’s mandate. For example, a corporation may encompass several lines of business and 557each line of business governs its own affairs in a manner that is consistent with and contributes to the 558goals of the parent organization. Within the line of business, an IT group may be given the mandate to 559provide and maintain IT resources, giving rise to IT governance.
  15. 15. 560In addition to tiered governance, there are likely to be multiple governance chains working in parallel. For 561example, a company making widgets likely has policies intended to ensure they make high quality 562widgets and make an impressive profit for their shareholders. On the other hand, Sarbanes-Oxley is a 563parallel governance chain in the United States that specifies how the management must handle its 564accounting and information that needs to be given to its shareholders. The parallel chains may just be 565additive or may be in conflict and require some harmonization. 566Being distributed and representing different ownership domains, a SOA participant is likely under the 567jurisdiction of multiple governance domains simultaneously and may individually need to resolve 568consequent conflicts. The governance domains may specify precedence for governance conformance or 569it may fall to the discretion of the participant to decide on the course of actions they believe appropriate. 5705. Automating Support for Policies and Contracts 571There are many functional “control points” in a SOA ecosystem; for example, how messages are 572exchanged, what descriptions should be made available to which participant, what services should be 573offered and so on. 574An effective technique for managing these control points is via policies; together with mechanisms for 575distributing and applying policies appropriately. 576From the IT perspective, high level policies and contracts need to be translated into low level rules and 577measurable properties that programmatic elements can enforce. For low level rules and measurable 578properties, both contracts and policies are likely to be enforced by the same type of IT policy 579mechanisms. 5805. IT Mechanisms Supporting Policies and Contracts 581The mechanism for enforcing a permission-oriented constraint is typically prevention at the point of action. 582The mechanisms for enforcing obligation constraints are typically achieved by a combination of auditing 583and remedial action. 584A common phenomenon of many machines and systems is that they are much broader in their potential 585than is actually needed for a particular circumstance. As a result, the behavior and performance of the 586system tend to be under-constrained by the implementation. Policy statements define the choices that a 587service provider and/or service consumer (or other stakeholder) makes; these choices are used to guide 588the actual behavior of the system to the desired behavior and performance. 589While there are many possible approaches to the realization of policy/contracts for a SOA, one approach 590based on current policy standardization efforts is depicted in this section. The common policy architectural 591elements that are provided in this section are based on the minimal mechanisms required to provide 592policy guided delivery across distributed services within an ownership domain and across ownership 593domains. 5945. Architectural Implications of Policies and Contracts 595While policy and contract descriptions have much of the same architectural implications as described in 596Service Description, languages and mechanisms supporting policies and contracts also have the 597following architectural implications: 598• Policy and Contract language specifications will typically provide support for the following capabilities: 599 o expression of assertion and commitment policy constraints; 600 o expression of positive and negative policy constraints; 601 o expression of permission and obligation policy constraints; 602 o nesting of policy constraints allowing for abstractions and refinements of a policy constraint; 603 o definition of alternative policy constraints to allow for the selection of compatible policy 604 constraints for a consumer and provider; 605 o composition of policies to combine one or more policies. 606• Policy and contract mechanisms in a SOA ecosystem will require the following capabilities: 607 o decision procedures which must be able to measure and render decisions on constraints; 608 o enforcement of decisions; 609 o measurement and notification of obligation constraints; 610 o auditability of decisions, enforcement, and obligation measurements;
  16. 16. 611 o administration of policy and contract language artifacts; 612 o storage of policies and contracts; 613 o distribution of policies/contracts; 614 o conflict resolution or elevation of conflicts in policy rules; 615 o delegation of policy authority to agents acting on behalf of a client; 6165.2.5 Management of Services 617Governance decides on what policies are necessary for the operation of the organization in executing its 618mission; and as described in Section 5.1.3, typically, management enacts, enforces, and mediates the 619policies. Actually, the leadership (or governance body) may set/enact/create/promulgate the policies or 620may charge management with that responsibility (Shown in Figure 6). 621 622 Figure 5 Ensuring governance compliance model 623There is often confusion centered on the relationship between governance and management. As 624described earlier, governance is concerned with decision making what policies are needed. On the other 625hand, Management, on the other hand, is concerned with implementation and execution. Put another 626way, governance describes the world organization, as leadership wants it to operate; management 627implements and executes activities that intends to make the leadership’s desired world a reality. Where 628governance determines who has the authority and responsibility for making decisions and the 629establishment of guidelines for how those decisions should be made, management is the actual process 630of making, implementing, and measuring the impact of those decisions [Loeb]. Consequently, 631governance and management work in concert to ensure a well-balanced and functioning organization as 632well as an ecosystem of inter-related organizations. In the sections that follow, we elaborate further on 633the relationship between governance and management in terms of setting and enforcing service policies, 634contracts, and standards as well as addressing issues surrounding regulatory compliance. 635As with Governance, an organization must concern itself with managing three distinct categories of 636entities, the participant interactions, the SOA infrastructure, and the Services themselves in their lifecycle. 637The management participants of SOA-based systems have three separate but linked domains of interest. 638The first and most obvious domain is the management and support of the resources that are involved in 639any complex system – of which SOA-based systems are excellent examples. The second domain is the 640promulgation and enforcement of the policies and contracts agreed to by the stakeholders in SOA-based 641systems. The third domain is the management of the relationships of the participants in SOA-based 642systems – both to each other and to the services that they use and offer. 643There are many artifacts in a large system that may need management. As soon as there is the possibility 644of more than one instance of a thing, the issue of managing those things becomes relevant. Historically, 645systems management capabilities have been organized by the following functional groups known as 646“FCAPS” functions (based on ITU-T Rec. M.3400 (02/2000), "TMN Management Functions"): Fault 647management, configuration management, account management, performance, and security 648management.
  17. 17. 649In the context of SOA, we see many possible resources that may require management: services, service 650descriptions, service capabilities, policies, contracts, roles, relationships, security, and infrastructure 651elements. In addition, given the ecosystem nature of SOA, it is also potentially necessary to manage the 652business relationships between participants in the SOA. 653Managing systems that may be used across ownership boundaries raises issues that are not normally 654present when managing a system within a single ownership domain. For example, care is required 655managing a service when the owner of the service, the provider of the service, the host of the service and 656access mediators to the service may all belong to different stakeholders. In addition, it may be important 657to allow service consumers to communicate their requirements to the service provider so that they are 658satisfied in a timely manner. 659A given service may be provided and consumed in more than one version. Version control of services is 660important for both service providers and service consumers (who may need to ensure certainty in the 661version of the service they are interacting with). 662In fact, managing a service has quite a few similarities to using a service: suggesting that we can use the 663service oriented model to manage SOA-based systems as well as provide them. A management service 664would be distinguished from a non-management service more by the nature of the capabilities involved 665(i.e., capabilities that relate to managing services) than by any intrinsic difference. 666In this model, we show how the SOA framework may apply to managing services as well as using and 667offering them. There are, of course, some special considerations that apply to service management which 668we bring out: namely that we will be managing the life-cycle of services, managing any service level 669attributes, managing dependencies between services and so on. 670 671 672 Figure 6 Managing resources in a SOA 673The core concept in management is that of a manageability capability: 674Manageability Capability 675 The manageability capability of a resource is the capability that allows it to be managed with 676 respect to some property. Note that manageability capabilities are not necessarily part of the 677 managed entities themselves. 678 Manageability capabilities are the core resources that management systems use to manage: 679 each resource that may be managed in some way has a number of aspects that may be 680 managed. For example, a service’s life-cycle may be manageable, as may its Quality of Service 681 parameter; a policy may also be managed for life-cycle but Quality of Service would not normally 682 apply. 683Life-cycle manageability 684 A manageability capability associated with a resource that permits the life cycle of the resource to 685 be managed. As noted above, the life-cycle manageability capability of a resource is unlikely to 686 reside within the resource itself (you cannot tell a system that is not running to start itself). 687 The life-cycle management of a resource typically refers to how the resource is created, how it is 688 destroyed and what dependencies there might exist that must be simultaneously managed. 689Configuration manageability 690 A capability associated with the management of the configuration of resources. Service 691 configuration, in particular, may be complex in cases where there are dependencies between 692 services and other resources.
  18. 18. 693Event monitoring manageability 694 A capability associated with managing the reporting of events and faults is one of the key lower- 695 level manageability capabilities. 696Accounting manageability 697 A capability associated with resources that allows for the use of those resources to be measured 698 and accounted for. This implies that not only can the use of resources be properly measured, but 699 also that those using those resources also be properly identified. 700 Accounting for the use of resources by participants in the SOA supports the proper budgeting and 701 allocation of funding by participants. 702Quality of service manageability 703 A manageability capability associated with a resource that permits any quality of service 704 associated with the resource to be managed. Classic examples of this include bandwidth 705 requirements and offerings associated with a service. 706Business performance manageability 707 A manageability capability that is associated with services that permits the service’s business 708 performance to be monitored and managed. In particular, if there are business-level service level 709 agreements that apply to a service, being able to monitor and manage those SLAs is an 710 important role for management systems. 711 Building support for arbitrary business monitoring is likely to be challenging. However, given a 712 measure for determining a service’s compliance to business service level agreements, 713 management systems can monitor that performance in a way that is entirely similar to other 714 management tasks. 715Policy manageability 716 Where the policies associated with a resource may be complex and dynamic, so those policies 717 themselves may require management. The ability to manage those policies (such as 718 promulgating policies, retiring policies and ensuring that policy decision points and enforcement 719 points are current) is a management function. 720 In the particular case of policies, there is a special relationship between management and 721 policies. Just like other artifacts, policies require management in a SOA. However, much of 722 management is about applying policies also: where governance is often about what the policies 723 regarding artifacts and services should be, a key management role is to ensure that those 724 policies are consistently applied. 725Management service 726 A management service is a service that manages other services and resources. 727Management Policy 728 A management policy is a policy whose topic is a management topic. Just as with other aspects 729 of a SOA, the management of resources within the SOA may be governed by management 730 policies, contracts (such as SLAs). 731In a deployed system, it may well be that different aspects of the management of a given service are 732managed by different management services. For example, the life-cycle management of services often 733involves managing dependencies between services and resource requirements. Managing quality of 734service is often very specific to the service itself; for example, quality of service attributes for a video 735streaming service are quite different to those for a banking system. 736There are additional concepts of management that often also apply to IT management: 737Systems management 738 Systems management refers to enterprise-wide maintenance and administration of distributed 739 computer systems.
  19. 19. 740Network management 741 Network management refers to the maintenance and administration of large-scale networks such 742 as computer networks and telecommunication networks. Systems and network management 743 execute a set of functions required for controlling, planning, deploying, coordinating, and 744 monitoring the distributed computer systems and the resources of a network. 745However, for the purposes of this Reference Architecture, while recognizing their importance, we do not 746focus on systems management or network management. 747 - the specific identifier is not prescribed by this Reference Architecture but the structure and semantics 748 of the identifier must be indicated for the identifier value to be properly used. For example, part of 749 identity may include version identification. 750 For this, the configuration management plan or similar document from which the version number is 751 derived must be identified. 7525.2.5.1 Carrying Out Governance: One Objective of Management 753 754 Figure 7 Carrying Out Governance Model 755To carry out governance, Leadership charters a Governance Body to promulgate the Rules needed to 756make the Policies operational. The Governance Body acts in line with Governance Processes for its rule- 757making process and other functions. Whereas Governance is the setting of Policies and defining the 758Rules that provide an operational context for Policies, the operational details of governance are likely 759delegated by the Governance Body to Management. Management generates Regulations that specify 760details for Rules and other procedures to implement both Rules and Regulations. For example, 761Leadership could set a Policy that all authorized parties should have access to data, the Governance 762Body would promulgate a Rule that PKI certificates are required to establish identity of authorized parties, 763and Management can specify a Regulation of who it deems to be a recognized PKI issuing body. In 764summary, Policy is a predicate to be satisfied and Rules prescribe the activities by which that satisfying 765occurs. A number of rules may be required to satisfy a given policy; the carrying out of a rule may 766contribute to several policies being realized. 767Whereas the Governance Framework and Processes are fundamental for having Participants 768acknowledge and commit to compliance with governance, the Rules and Regulations provide operational 769constraints, which may require resource commitments or other levies on the Participants. It is important 770for Participants to consider the framework and processes to be fair, unambiguous, and capable of being 771carried out in a consistent manner and to have an opportunity to formally accept or ratify this situation. 772Rules and Regulations, however, do not require individual acceptance by any given participant although 773some level of community comment is likely to be part of the Governance Processes. Having agreed to 774governance, the Participants are bound to comply or be subject to prescribed mechanisms for 775enforcement.
  20. 20. 7765. Ensuring Compliance with Policies and Contracts 777Setting Rules and Regulations does not ensure effective governance unless compliance can be 778measured and Rules and Regulations can be enforced. Metrics are those conditions and quantities that 779can be measured to characterize actions and results. Rules and Regulations MUST be based on 780collected Metrics or there will be no way for Management to assess compliance. The Metrics are 781available to the Participants, the Leadership, and the Governance Body so what is measured and the 782results of measurement are clear to everyone. 783The Leadership in its relationship with Participants will have certain options that can be used for 784Enforcement. A common option may be to effect future funding. The Governance Body defines specific 785enforcement responses, such as what degree of compliance is necessary for full funding to be restored. 786It is up to Management to identify compliance shortfalls and to initiate the Enforcement process. 787Note, enforcement does not strictly need to be negative. Management can use Metrics to identify 788exemplars of compliance and Leadership can provide options for rewarding the Participants. Likely, the 789Governance Body defines awards or other incentives. 7905. Ensuring Governance Compliance 791 792Figure 8 Ensuring governance compliance 793Setting Rules and Regulations does not ensure effective governance unless compliance can be 794measured and Rules and Regulations can be enforced. Metrics are those conditions and quantities that 795can be measured to characterize actions and results. Rules and Regulations MUST be based on 796collected Metrics or there will be no way for Management to assess compliance. The Metrics are 797available to the Participants, the Leadership, and the Governance Body so what is measured and the 798results of measurement are clear to everyone. 799The Leadership in its relationship with Participants will have certain options that can be used for 800Enforcement. A common option may be to effect future funding. The Governance Body defines specific 801enforcement responses, such as what degree of compliance is necessary for full funding to be restored. 802It is up to Management to identify compliance shortfalls and to perform actions mandated by the 803Enforcement process. 804Note, enforcement does not strictly need to be negative. Management can use Metrics to identify 805exemplars of compliance and Leadership can provide options for rewarding the Participants. It is likely 806the Governance Body that defines awards or other incentives. 8075.2.5.2 Management of SOA Infrastructure 808In order for a service or other resource to be manageable there must be a corresponding manageability 809capability that can effect that management. The particulars of this capability will vary somewhat 810depending on the nature of the capability. For example, a service life-cycle manageability capability 811requires the ability to start a service, to stop the service, and potentially to pause the service. Conversely, 812in order to manage document-like artifacts, such as service descriptions, the capability of storing the
  21. 21. 813artifacts, controlling access to those artifacts, allowing updates of the artifacts to be deployed are all 814important capabilities for managing them. 815 816Elements of a basic service management infrastructure should include the following characteristics: 817 818• Integrate with existing security services 819• Monitoring 820• Heartbeat and Ping 821• Alerting 822• Pause/Restore/Restart Service Access 823• Logging, Auditing, Non-Repudiation 824• Runtime Version Management 825• Complement other infrastructure services (discovery, messaging, mediation) 826 827 * Message Routing and Redirection 828 * Failover 829 * Load-balancing 830 831 * QoS, Management of Service Level Objects and Agreements 832 * Availability 833 * Response Time 834 * Throughput 835 836• Fault and Exception Management 8375.2.5.3 Management of Service Lifecycle 838Managing a service’s life cycle involves managing the establishment of the service, managing its steady- 839state performance, and managing its termination. The most obvious feature of this is that a service cannot 840manage its own life cycle (imagine asking a non-functioning service to start). Another important 841consideration is that services may have resource requirements that must be established at various points 842in the services’ life cycles. These dependencies may take the form of other services being established; 843possibly even services that are not exposed by the service’s own interface. 8445.2.5.4 Management of Participant Interaction 845As we noted above, management can often be viewed as the application of contracts and policies to 846ensure the smooth running of the SOA. Policies play an important part in managing systems both as 847artifacts that need to be managed and as the guiding constraints to determine how the SOA should be 848managed. 849 8505.3 SOA Testing Model 851 Program testing can be used to show the presence of bugs, 852 but never to show their absence! 853 Edsger Dijkstra 854Testing for SOA combines the typical challenges of software testing and certification with the additional 855needs of accommodating the distributed nature of the resources, the greater access of a more 856unbounded consumer population, and the desired flexibility to create new solutions from existing 857components over which the solution developer has little if any control. The purpose of testing is to
  22. 22. 858demonstrate a required level of reliability, correctness, and effectiveness that enable prospective 859consumers to have adequate confidence in using a service. Adequacy is defined by the consumer based 860on the consumer's needs and context of use. As Dijkstra points out, absolute correctness and 861completeness cannot be proven by testing; however, for SOA, it is critical for the prospective consumer to 862know what testing has been performed, how it has been performed, and what the results were. 8635.3.1 Traditional Software Testing as Basis for SOA Testing 864SOA services are largely software artifacts and can leverage the body of experience that has evolved 865around software testing. IEEE-829 specifies the basic set of software test documents while allowing 866flexibility for tailored use. As such, the document structure can also provide guidance to SOA testing. 867IEEE-829 covers test specification and test reporting through use of the following document types: 868• Test plan documenting the scope (what will be tested, both which entity and what features of the 869entity), the approach (how it will be tested), and the needed resources (who will do the testing, for how 870long), with details contained in the: 871• Test design specification: features to be tested, test conditions (e.g. test cases, test procedures 872needed) and expected results (criteria for passing test); entrance and exit criteria 873• Test case specification: test data used for input and expected output 874• Test procedure specification: steps required to run the test, including any set-up preconditions 875• Test item transmittal to identify the test items being transmitted for testing 876• Test log to record what occurred during test, i.e. which tests run, who ran, what order, what 877happened 878• Test incident report to capture any event that happened during test which requires further 879investigation 880• Test summary as a management report summarizing test run and results, conclusions 881In summary, IEEE-829 captures (1) what was tested, (2) how it was tested, e.g. the test procedure used, 882and (3) the results of the test. 8835.3.1.1 Types of Testing 884There are numerous aspects of testing that, in total, work to establish that an entity is (1) built as required 885per policies and related specifications prescribed by the entity's owner, and (2) delivers the functionality 886required by its intended users. This is often referred to as verification and validation. 887Policies, as described in Section , that are related to testing may prescribe but are not limited to the 888business processes to be followed, the standards with which an implementation must comply, and the 889qualifications of and restrictions on the users. In addition to the functional requirements prescribing what 890an entity does, there may also be non-functional performance and/or quality metrics that state how well 891the entity does it. The relation of these policies to SOA testing is discussed further below. 892The identification of policies is the purview of governance (section 5.1) and the assuring of compliance 893(including response to noncompliance) with policies is a matter for management (section 5.3). 8945.3.1.2 Range of Test Conditions 895Test conditions and expected responses are detailed in the test case specification. The test conditions 896should be designed to cover the areas for which the entity's response must be documented and may 897include: 898• nominal conditions 899• boundaries and extremes of expected conditions 900• breaking point where the entity has degraded below a certain level or has otherwise ceased 901effective functioning 902• random conditions to investigate unidentified dependencies among combinations of conditions 903• errors conditions to test error handling
  23. 23. 904The specification of how each of these conditions should be tested for SOA resources, including the 905infrastructure elements of the SOA ecosystem, is beyond the scope of this Reference Architecture but is 906an area that will evolve along with operational SOA experience. 9075.3.1.3 Configuration Management of Test Artifacts 908The test item transmittal provides an unambiguous identification of the entity being tested, thus 909REQUIRING that the configuration of the entity is appropriately tracked and documented. In addition, the 910test documents (such as those specified by IEEE-829) MUST also be under a documented and 911appropriately audited configuration management process. as should other resources used for testing. 912The description of each artifact would follow the general description model as discussed in section 9134.1.1.1; in particular, it would include a version number for the artifact and reference to the documentation 914describing the versioning scheme from which the version number is derived. 915 916[EDITOR'S NOTE: TO WHAT EXTENT SHOULD CM BE EXPLICITLY INCLUDED IN THE 917MANAGEMENT SECTION?] 9185.3.2 Testing and the SOA Ecosystem 919[EDITOR’S NOTE: THE EMPHASIS THOUGH MUCH OF THE RA IS THE LARGER ECOSYSTEM BUT 920WE NEED WORDS IN SECTION 3 TO ACKNOWLEDGE THE EXISTENCE OF THE ENTERPRISE AND 921THAT AN ENTERPRISE (AS COMMONLY INTERPRETED) IS LIKELY MORE CONSTRAINED AND 922MORE PRECISELY DESCRIBED FOR THE CONTEXT OF THE ENTERPRISE. THE ECOSYSTEM 923PERSPECTIVE, THOUGH, IS STILL APPLICABLE FOR THE FOLLOWING REASONS: 924 9251. A GIVEN ENTERPRISE MAY COMPRISE NUMEROUS CONSTITUENT ENTERPRISES THAT 926RESEMBLE THE INDEPENDENT ENTITIES DESCRIBED FOR THE ECOSYSTEM. AN ENTERPRISE 927MAY ATTEMPT TO REDUCE VARIATIONS AMONG THE CONSTITUENTS BUT THE ECOSYSTEM 928VIEW ENABLES SOA TO BENEFIT THE ENTERPRISE WITHOUT REQUIRING THE ENTERPRISE 929ISSUES TO BE FULLY RESOLVED. 9302. RESOURCES SPECIFICALLY MOTIVATED BY THE CONTEXT OF THE ENTERPRISE CAN 931BE MORE READILY USED IN A DIFFERENT CONTEXT IF ECOSYSTEM CONSIDERATIONS ARE 932INCLUDED AT AN EARLY STAGE. THE CHANGE IN A CONTEXT MAY BE A FUNDAMENTAL 933CHANGE IN THE ENTERPRISE OR THE NEWLY DISCOVERED APPLICABILITY OF ENTERPRISE 934RESOURCES TO USE OUTSIDE THE ENTERPRISE. 935 936IN THIS REFERENCE ARCHITECTURE, REFERENCE TO THE SOA ECOSYSTEM APPLIES BUT 937WITH POSSIBLY LESS GENERALITY TO AN ENTERPRISE USE OF SOA.] 938Testing of SOA artifacts for use in the SOA ecosystem differs from traditional software testing for several 939reasons. First, a highly touted benefit of SOA is to enable unanticipated consumers to make use of 940services for unanticipated purposes. Examples of this could include the consumer using a service for a 941result that was not considered the primary one by the provider, or the service may be used in combination 942with other services in a scenario that is different from the one considered when designing for the initial 943target consumer community. It is unlikely that a new consumer will push the services back to anything 944resembling the initial test phase to test the new use, and thus additional paradigms for testing are 945necessary. Some testing may depend on the availability of test resources made available as a service 946outside the initial test community, while some testing is likely to be done as part of limited use in the 947operational setting. The potential responsibilities related to such "consumer testing" is discussed further 948below. 949Secondly, in addition to consumers who interact with a service to realize the described real world effects, 950the developer community is also intended to be a consumer. In the SOA vision of reuse, the developer 951will compose new solutions using existing services, where the existing services provides access to some 952desired real world effects that are needed by the new solution. The new solution is a consumer of the 953existing services, enabling repeated interactions with the existing services playing the role of reusable 954components. Note, those components are used at the locations where they individually reside and are not 955typically duplicated for the new solution. The new solution may itself be offered as a SOA service, and a
  24. 24. 956consumer of the service composition representing the new solution may be totally unaware of the 957component services being used. (See section 4.3.4 for further discussion on service compositions.) 958Another difference from traditional testing is that the distributed, unbounded nature of the SOA ecosystem 959makes it unlikely to have an isolated test environment that duplicates the operational environment. A 960traditional testing approach often makes use of a test system that is identical to the eventual operational 961system but isolated for testing. After testing is successfully completed, the tested entity would be 962migrated to the operational environment, or the test environment may be delivered as part of the system 963to become operational. This is not feasible for the SOA ecosystem as a whole. 964SOA services must be testable in the environment and under the conditions that can be encountered in 965the operational SOA ecosystem. As the ecosystem is in a state of constant change, so some level of 966testing is continuous through the lifetime of the service, leveraging utility services used by the ecosystem 967infrastructure to monitor its own health and respond to situations that could lead to degraded 968performance. This implies the test resources must incorporate aspects of the SOA paradigm, and a 969category of services may be created to specifically support and enable effective monitoring and 970continuous testing for resources participating in the SOA ecosystem. 971While SOA within an enterprise may represent a more constrained and predictable operational 972environment, the composability and unanticipated use aspects are highly touted within the enterprise. 973The expanded perspective on testing may not be as demanding within an enterprise but fuller 974consideration of the ecosystem enables the enterprise to be more responsive should conditions change. 9755.3.3 Elements of SOA Testing 976IEEE-829 identifies fundamental aspects of testing, and many of these should carry over to SOA testing: 977in particular, the identification of what is to be tested, how it is to be tested, and by whom the testing is to 978be done. While IEEE-829 identifies a suggested document tree, the availability of these documents in the 979SOA ecosystem is an additional matter of concern that will be discussed below. 9805.3.3.1 What is to be Tested 981The focus of this discussion is the SOA service. It is recognized that the infrastructure components of any 982SOA environment are likely also to be SOA services and, as such, will fall under the same testing 983guidance. Other resources that contribute to a SOA environment may not be SOA services, but will be 984expected to satisfy the intent if not the letter of guidance presented here. Specific differences for such 985resources are as yet largely undefined and further elaboration is beyond the scope of this Reference 986Architecture. 987The following discussion often focuses on a singular SOA service but it is implicit that any service may be 988a composite of other services. As such, testing the functionality of a composite service may effectively be 989testing an end-to-end business process that is being provided by the composite service. If new versions 990are available for the component services, appropriate end-to-end testing of the composite may be 991required in order to verify that the composite functionality is still adequately provided. The level of 992required testing of an updated composite will depend on policies of those providing the service, policies of 993those using the service, and mission criticality of those depending on the service results. 994The SOA service to be tested MUST be unambiguously identified as specified by its applicable 995configuration management scheme. Specifying such a scheme is beyond the scope of this Reference 996Architecture other than to say the scheme should be documented and itself under configuration 997management. 9985. Origin of Test Requirements 999In the Service Description model (Figure 21), the aspects of a service that need to be described are: 1000• the service functionality and technical assumptions that underlie the functionality; 1001• the policies that describe conditions of use; 1002• the service interface that defines information exchange with the service; 1003• service reachability that identifies how and where message exchange is to occur; and 1004• metrics access for any participant to have information on how a service is performing. 1005Service testing must provide adequate assurance that each of these aspects is operational as defined.
  25. 25. 1006The information in the service description comes from different sources. The functionality is defined 1007through whatever process identifies needs and the community for which these needs will be addressed. 1008The process may be ad hoc as serves the prospective service owner or strictly governed, but defining the 1009functionality is an essential first step in development. It is also an early and ongoing focus of testing to 1010ensure the service accurately reflects the described functionality and the described functionality 1011accurately addresses the consumer needs. 1012Policies define the conditions of development and conditions of use for a service and are typically 1013specified as part of the governance process. Policies constraining service development, such as coding 1014standards and best practices, require appropriate testing and auditing during development to ensure 1015compliance. While the governance process will identify development policies, these are likely to originate 1016from the technical community responsible for development activities. Policies that define conditions of 1017use often define business practices that service owners and providers or those responsible for the SOA 1018infrastructure want followed. These policies are initially tested during service development and are 1019continuously monitored during the operational lifetime of the service. 1020The testing of the service interface and service reachability are often related but essentially reflect 1021different motivations and needs. The service interface is specified as a joint product of the service 1022owners and providers who define service functionality, the prospective consumer community, the service 1023developer, and the governance process. The semantics of the information model must align with the 1024semantics of those who consume the service in order for there to be meaningful exchange of information. 1025The structure of the information is influenced by the consumer semantics and the requirements and 1026constraints of the representation as interpreted by the service developer. The service process model that 1027defines actions which can be performed against a service and any temporal dependencies derive from 1028the defined functionality and may be influenced by the development process. Any of these constraints 1029may be identified and expressed as policy through the governance process. 1030Service reachability conditions are the purview of the service provider who identifies the service endpoint 1031and the protocols recognized at the endpoint. These may be constrained by governance decisions on 1032how endpoint addresses may be allocated and what protocols should be used. 1033While the considerations for defining the service interface derive from several sources, testing of the 1034service interface is more straightforward and isolated in the testing process. At any point where the 1035interface is modified or exposes a new resource, the message exchange should be monitored both to 1036ensure the message reaches its intended destination and it is parsed correctly once received. Once an 1037interface has been shown to function properly, it is unlikely it will fail later unless something fundamental 1038to the service changes. 1039The service interface is also tested when the service endpoint changes. Testing of the endpoint ensures 1040message exchange can occur at the time of testing and the initial testing shows the interface is being 1041processed properly at the new endpoint. Functioning of a service endpoint at one time does not 1042guarantee it is functioning at another time, e.g. the server with the endpoint address may be down, 1043making testing of service reachability a continual monitoring function through the life of the service’s use 1044of the endpoint. Also, while testing of the service endpoint is a necessary and most commonly noted part 1045of the test regiment, it is not in itself sufficient to ensure the other aspects of testing discussed in this 1046section. 1047Finally, governance is impossible without the collection of metrics against which service behavior can be 1048assessed. Metrics are also a key indicator for consumers to decide if a service is adequate for their 1049needs. For instance, the average response time or the recent availability can be determining factors even 1050if there are no rules or regulations promulgated through the governance process against which these 1051metrics are assessed. The available metrics are a combination of those expected by the consumer 1052community and those mandated through the governance process. The total set of metrics will evolve 1053over time with SOA experience. Testing of the services that gather and provide access to the metrics will 1054follow testing as described in this section, but for an individual service, testing will ensure that the metrics 1055access indicated in the service description is accurate. 1056The individual test requirements highlight aspects of the service that testing must consider but testing 1057must establish more than isolated behavior. The emphasis is the holistic results of interacting with the 1058service in the SOA environment. Recall that the execution context is the set of agreements between a 1059consumer and a provider that define the conditions under which service interaction occurs. The 1060agreements are expected to be predominantly the acceptance of the standard conditions as enumerated 1061by the service provider, but it may include the identification of alternate conditions that will govern the 1062interaction.
  26. 26. 1063For example, the provider may prefer a policy where it can sell the contact information of its consumers 1064but will honor the request of a consumer to keep such information private. The identification of the 1065alternate privacy policy is part of the execution context, and it is the application of and compliance with 1066this policy that operational monitoring will attempt to measure. The collection of metrics showing this 1067condition is indeed met when chosen is considered part of the ongoing testing of the service. 1068Other variations in the execution context also require monitoring to ensure that different combinations of 1069conditions perform together as desired. For example, if a new privacy policy takes additional resources to 1070apply, this may affect quality of service and propagate other effects. These could not be tested during the 1071original testing if the alternate policy did not exist at that time. 10725. Testing Against Non-Functional Requirements 1073Testing against non-functional requirements constitutes testing of business usability of the service. In a 1074marketplace of services, non-functional characteristics may be the primary differentiator between services 1075that produce essentially the same real world effects. 1076As noted in the previous section, non-functional characteristics are often associated with policies or other 1077terms of use and may be collected in service level contracts offered by the service providers. Non- 1078functional requirements may also reflect the network and hardware infrastructure that support 1079communication with the service, and changes may impact quality of service. The service consumer and 1080even the service provider may not be aware of all such infrastructure changes but the changes may 1081manifest in shared states that impact the usability of the service. 1082In general, a change in the non-functional requirements results in a change to the execution context, but 1083as with any collection of information that constitutes a description, the execution context is unable to 1084capture explicitly all non-functional requirements that may apply. A change in non-functional 1085requirements, whether explicitly part of the execution context or an implicit contributor, may require 1086retesting of the service even if its functionality and the implementation of the functionality has not 1087changed. Depending on the circumstances, retesting may require a formal recertifying of end-to-end 1088behavior or more likely will be part of the continuous monitoring that applies throughout the service 1089lifetime. 10905. Testing Content and the Interests of Consumers 1091As noted in section, testing may involve verification of conformance with respect to policies and 1092technical specifications and validation with respect to sufficiency of functionality to meet some prescribed 1093use. It may also include demonstration of performance and quality aspects. For some of these items, 1094such as demonstrating the business processes followed in developing the service or the use of standards 1095in implementing the service, the testing or relevant auditing is done internal to the service development 1096process, and follows traditional software testing and quality assurance. If it is believed of value to 1097potential consumers, information about such testing could be included in the service description. 1098However, it is not required that all test or compliance artifacts be available to consumers, as many of the 1099details tested may be part of the opacity of the service implementation. 1100Some aspects of the service being tested will reflect directly on the real world effects realized through 1101interaction with the service. In these cases, it is more likely that testing results will be directly relevant to 1102potential consumers. For example, if the service was designed to correspond to certain elements of a 1103business process or that a certain workflow is followed, testing should verify that the real world effects 1104reflect that the business process or workflow were satisfactorily captured. 1105The testing may also need to demonstrate that specified conditions of use are satisfied. For example, 1106policies may be asserted that require certain qualifications of or impose restrictions on the consumers 1107who may interact with the service. The service testing must demonstrate that the service independently 1108enforces the policies or it provides the required information exchanges with the SOA ecosystem so other 1109resources can ensure the specified conditions. 1110The completeness of the testing, both in terms of the features tested and the range of parameters for 1111which response is tested, depends on the context of expected use: the more critical the use, the more 1112complete the testing. There are always limits on the resources available for testing, if nothing else than 1113the service must be available for use in a finite amount of time. 1114This again emphasizes the need for adequate documentation to be available. If the original testing is very 1115thorough, it may be adequate for less demanding uses in the future. If the original testing was more