Your SlideShare is downloading. ×

5.2.5

252
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
252
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. 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. 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. 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. 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. 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 5.2.4.4.
  • 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. 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. 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. 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. 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. 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.2.4.2.1 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. 4605.2.4.2.2 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.2.4.2.3 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. 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. 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.2.4.4.1 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.2.4.4.1.1 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.2.4.4.2 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. 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. 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. 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. 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. 7765.2.5.1.1 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.2.5.1.2 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. 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. 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. 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. 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.3.3.1.1 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. 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. 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.3.3.1.2 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.3.3.1.3 Testing Content and the Interests of Consumers 1091As noted in section 5.4.1.1, 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
  • 27. 1116constrained, then well-documented test results establish the foundation on which further testing can be 1117defined and executed. 11185.3.3.2 How Testing is Performed 1119Testing should follow well-defined methodologies and, if possible, should reuse test artifacts that have 1120proven generally useful for past testing. For example, IEEE-829 notes that test cases are separated from 1121test designs to allow for use in more than one design and to allow for reuse in other situations. In the 1122SOA ecosystem, description of such artifacts, as with description of a service, enables awareness of the 1123item and describes how the artifact may be accessed or used. 1124As with traditional testing, the specific test procedures and test case inputs are important so the tests are 1125unambiguously defined and entities can be retested in the future. Automated testing and regression 1126testing may be more important in the SOA ecosystem in order to re-verify a service is still acceptable 1127when incorporated in a new use. For example, if a new use requires the services to deal with input 1128parameters outside the range of initial testing, the tests could be rerun with the new parameters. If the 1129testing resources are available to consumers within the SOA ecosystem, the testing as designed by test 1130professionals could be consumed through a service accessed by consumers, and their results could 1131augment those already in place. This is discussed further in the next section. 11325.3.3.3 Who Performs the Testing 1133As with any software, the first line of testing is unit testing done by software developers. It is likely that 1134initial testing will be done by those developing the software but may also be done independently by other 1135developers. For SOA development, unit testing is likely confined to a development sandbox isolated from 1136the SOA ecosystem. 1137SOA testing will differ from traditional software testing in that testing beyond the development sandbox 1138must incorporate aspects of the SOA ecosystem, and those doing the testing must be familiar with both 1139the characteristics and responses of the ecosystem and the tools, especially those available as services, 1140to facilitate and standardize testing. Test professionals will know what level of assurance must be 1141established as the exposure of the service to the ecosystem and ecosystem to the service increases 1142towards operational status. These test professionals may be internal resources to an organization or may 1143evolve as a separate discipline provided through external contracting. 1144As noted above, it is unlikely that a complete duplicate of the SOA ecosystem will be available for isolated 1145testing, and thus use of ecosystem resources will manifest as a transition process rather than a step 1146change from a test environment to an operational one. This is especially true for new composite services 1147that incorporate existing operational services to achieve the new functionality. The test professionals will 1148need to understand the available resources and the ramifications of this transition. 1149As with current software development, a stage beyond work by test professionals will make use of a 1150select group of typical users, commonly referred to as beta testers, to report on service response during 1151typical intended use. This establishes fitness by the consumers, providing final validation of previously 1152verified processes, requirements, and final implementation. 1153In traditional software development, beta testing is the end of testing for a given version of the software. 1154However, although the initial test phase can establish an appropriate level of confidence consistent with 1155the designed use for the initial target consumer community, the operational service will exist in an 1156evolving ecosystem, and later conditions of use may differ from those thought to be sufficient during the 1157initial testing. Thus, operational monitoring becomes an extension of testing through the service lifetime. 1158This continuous testing will attempt to ensure that a service does not consume an inordinate amount of 1159ecosystem resources or display other behavior that degrades the ecosystem, but it will not undercover 1160functional errors that may surface over time. 1161As with any software, it is the responsibility of the consumers to consider the reasonableness of solutions 1162in order to spot errors in either the software or the way the software is being used. This is especially 1163important for consumers with unanticipated uses that may go beyond the original test conditions. It is 1164unlikely the consumers will initiate a new round of formal testing unless the new use requires a 1165significantly higher level of confidence in the service. Rather the consumer becomes a new extension to 1166the testing regiment. Obvious testing would include a sanity check of results during the new use. 1167However, if the details of legacy testing are associated with the service through the service description 1168and if testing resources are available through automated testing services, then the new consumers can
  • 28. 1169rerun and extend previous testing to include the extended test conditions. If the test results are 1170acceptable, these can be added to the documentation of previous results and become the extended basis 1171for future decisions by prospective consumers on the appropriateness of the service. If the results are not 1172acceptable or in some way questionable, the responsible party for the service or testing professionals can 1173be brought in to decide if remedial action is necessary. 11745.3.3.4 How Test Results are Reported 1175For any SOA service, an accurate reporting of the testing a service has undergone and the results of the 1176testing is vital to consumers deciding whether a service is appropriate for intended use. Appropriateness 1177may be defined by a consumer organization and require specific test regiments culminating in a 1178certification; appropriateness could be established by accepting testing and certifications that have been 1179conferred by others. 1180The testing and certification information should be identified in the service description. Referring to the 1181general description model of , tests conducted by or under a request from the service owner (see 1182Ownership in section 3.?) would be captured under Annotations from Owners. Testing done by others, 1183such as consumers with unanticipated uses, could be associated through Annotations from 3rd Parties. 1184The annotations should clearly indicate what was tested, how the testing was done, who did the testing, 1185and the testing results. The clear description of each of these artifacts and of standardized testing 1186protocols for various levels of sophistication and completeness of testing would enable a common 1187understanding and comparison of test coverage. It will also make it more straightforward to conduct and 1188report on future testing, facilitating the maintenance of the service description. 1189Consumer testing and the reporting of results raises additional issues. While stating who did the testing is 1190mandatory, there may be formal requirements for authentication of the tester to ensure traceability of the 1191testing claims. In some circumstances, persons or organizations would not be allowed to state testing 1192claims unless the tester was an approved entity. In other cases, ensuring the tester had a valid email 1193may be sufficient. In either case, it would be at the discretion of the potential consumer to decide what 1194level of authentication was acceptable and which testers are considered authoritative in the context of 1195their anticipated use. 1196Finally, in a world of openly shared information, we would see an ever-expanding set of testing 1197information as new uses and new consumers interact with a service. In reality, these new uses may 1198represent proprietary processes or classified use that should only be available to authorized parties. 1199Testing information, as with other elements of description, may require special access controls to ensure 1200appropriate access and use. 12015.3.4 Testing SOA Services 1202Testing of SOA services should be consistent with the SOA paradigm. In particular, testing resources 1203and artifacts should be visible in support of service interaction between providers and consumers, where 1204here the interaction is between the testing resource and the tester. In addition, the idea of opacity of the 1205implementation should limit the details that need to be available for effective use of the test resources. 1206Testing that requires knowledge of the internal structure of the service or its underlying capability should 1207be performed as part of unit testing in the development sandbox, and should represent a minimum level 1208of confidence before the service begins its transition to further testing and eventual operation in the SOA 1209ecosystem. 12105.3.4.1 Progression of SOA Testing 1211Software testing is a gradual exercise going from micro inspection to testing macro effects. The first step 1212in testing is likely the traditional code reviews. SOA considerations would account for the distributed 1213nature of SOA, including issues of distributed security and best practices to ensure secure resources. It 1214would also set the groundwork for opacity of implementation, hiding programming details and simplifying 1215the use of the service. 1216Code review is likely followed by unit testing in a development sandbox isolated from the operational 1217environment. The unit testing is done with full knowledge of the service internal structure and knowledge 1218of resources representing underlying capabilities. It tests the interface to ensure exchanged messages 1219are as specified in the service description and the messages can be parsed and interpreted as intended.
  • 29. 1220Unit testing also verifies intended functionality and that the software has dealt correctly with internal 1221dependencies, such as structure of a file system or access to other dedicated resources. 1222Some aspects of unit testing require external dependencies be satisfied, and this is often done using 1223mock objects to substitute for the external resources. In particular, it will likely be necessary to include 1224mocks of existing operational services, both those provided as part of the SOA infrastructure and services 1225from other providers. 1226Service Mock 1227 A service mock is an entity that mimics some aspect of the performance of an operational service 1228 without committing to the real world effects that the operational service would produce. 1229Mocks are discussed in detail in sections 5.4.4.3 and 5.4.4.4. 1230After unit testing has demonstrated an adequate level of confidence in the service, the testing must 1231transition from the tightly controlled environment of the development sandbox to an environment that 1232more clearly resembles the operational SOA ecosystem or, at a minimum, the intended enterprise. While 1233sandbox testing will use simple mocks of some aspects of the SOA environment, such as an interface to 1234a security service without the security service functionality, the dynamic nature of SOA makes a full 1235simulation infeasible to create or maintain. This is especially true when a new composite service makes 1236use of operational services provided by others. Thus, at some point before testing is complete, the 1237service will need to demonstrate its functionality by using resources and dealing with conditions that only 1238exist in the full ecosystem or the intended enterprise. Some of these resources may still provide test 1239interfaces -- more on this below -- but the interfaces will be accessible via the SOA environment and not 1240just implemented for the sandbox. 1241At this stage, the opacity of the service becomes important as the details of interacting with the service 1242now rely on correct use of the service interface and not knowledge of the service internals. The workings 1243of the service will only be observable through the real world effects realized through service interactions 1244and external indications that conditions of use, such as user authentication, are satisfied. Monitoring the 1245behavior of the service will depend on service interfaces that expose internal monitoring or provide 1246required information to the SOA infrastructure monitoring function. The monitoring required to test a new 1247service is likely to have significant overlap with the monitoring the SOA infrastructure includes to monitor 1248its own health and to identify and isolate behavior outside of acceptable bounds. This is exactly what is 1249needed as part of service testing, and it is reasonable to assume that the ecosystem transition includes 1250use of operational monitoring rather than solely dedicated monitoring for each service being tested. 1251Use of SOA monitoring resources during the explicit testing phase sets the stage for monitoring and a 1252level of continual testing throughout the service lifetime. 12535.3.4.2 Testing Traditional Dependencies vs. Service Interactions 1254A SOA service is not required to make use of other operational services beyond what may be required for 1255monitoring by the ecosystem infrastructure. The service can implement hardcoded dependencies which 1256have been tested in the development sandbox through the use of dedicated mocks. While coordination 1257may be required with real data sources during integration testing, the dependencies can be constrained to 1258things that can be tested in a more traditional manner. Policies can also be set to restrict access to pre- 1259approved users, and thus the question of unanticipated users and unanticipated uses can be eliminated. 1260Operational readiness can be defined in terms of what can be proven in isolated testing. While all this 1261may provide more confidence in the service for its designed purpose, such a service will not fully 1262participate in the benefits or challenges of the ecosystem. This is akin to filling a swimming pool with sea 1263water and having someone in the pool say they are swimming in the ocean. 1264In considering the testing needed for a fully participating service, consider the example of a new 1265composite service that combines the real world effects and complies with the conditions of use of five 1266existing operational services. The developer of the composite service does not own any of the 1267component services and has limited, if any, ability to get the distributed owners to do any customization. 1268The developer also is limited by the principle of opacity to information comprising the service description, 1269and does not know internal details of the component services. The developer of the composite service 1270must use the component services as they exist as part of the SOA environment, including what is 1271provided to support testing by new users. This introduces requirements for what is needed in the way of 1272service mocks.
  • 30. 12735.3.4.3 Use of Service Mocks 1274Service mocks enables the tested service to respond to specific features of an operational service that is 1275being used as a component. It allows service testing to proceed without needing access to or with only 1276limited engagement with the component service. Mocks can also mimic difficult to create situations for 1277which it is desired to test the new service response. For composite services using multiple component 1278services, mocks may be used in combination to function for any number of the components. Note, when 1279using service mocks, it is important to remember that it is not the component service that is being tested 1280(although anomalous behavior may be uncovered during testing) but the use of the component in the new 1281composite. 1282Individual service mocks can emphasize different features of the component service they represent but 1283any given mock does not have to mimic all features. For example, a mock of the service interface can 1284echo a sent message and demonstrate the message is reaching its intended destination. A mock could 1285go further and parse the sent message to demonstrate the message not only reached its destination but 1286was understood. As a final step, the mock could report back what actions would have been taken by the 1287component service and what real world effects would result. If the response mimicked the operational 1288response, functional testing could proceed as if the real world effect actually occurred. 1289There are numerous ways to provide mock functionality. The service mock could be a simulation of the 1290operational service and return simulated results in a realistic response message or event notification. It is 1291also possible for the operational service to act as its own mock and simply not execute the commit stage 1292of its functionality. The service mock could use a combination of simulation and service action without 1293commit to generate a report of what would have occurred during the defined interaction with the 1294operational service. 1295As the service proceeds through testing, mocks should be systematically replaced by the component 1296resources accessed through their operational interfaces. Before beta testing begins, end-to-end testing, 1297i.e. proceeding from the beginning of the service interaction to the resulting real world results, should be 1298accomplished using component resources via their operational interfaces. 12995.3.4.4 Providers of Service Mocks 1300In traditional testing, it is often the test professionals who design and develop the mocks, but in the 1301distributed world of SOA, this may not be efficient or desirable. 1302In the development sandbox, it is likely the new service developer or test professionals working with the 1303developer will create mocks adequate for unit testing. Given that most of this testing is to verify the new 1304service is performing as designed, it is not necessary to have high fidelity models of other resources 1305being accessed. In addition, given opacity of SOA implementation, the developer of the new service may 1306not have sufficient detailed knowledge of a component service to build a detailed mock of the component 1307service functionality. Sharing existing mocks at this stage may be possible but the mocks would need to 1308be implemented in the sandbox, and for simple models it is likely easier to build the mock from scratch. 1309As testing begins its transition to the wider SOA environment, mocks may be available as services. For 1310existing resources, it is possible that an Open Source model could evolve where service mocks of 1311available functions can be catalogued and used during initial interaction of the tested service and the 1312operational environment. Widely used functions may have numerous service mocks, some mimicking 1313detailed conditions within the SOA infrastructure. However, the Open Source model is less likely to be 1314sufficient for specialty services that are not widely used by a large consumer community. 1315The service developer is probably best qualified for also developing more detailed service mocks or for 1316mock modes of operational services. This implies that in addition to their operational interfaces, services 1317will routinely provide test interfaces to enable service mocks to be used as services. As noted above, a 1318new service developer wanting to build a mock of component services is limited to the description 1319provided by the component service developer or owner. The description typically will detail real world 1320effects and conditions of use but will not provide implementation details, some of which may be 1321proprietary. Just as important in the SOA ecosystem, if it becomes standard protocol for developers to 1322create service mocks of their own services, a new service developer is only responsible for building his 1323own mocks and can expect other mocks to be available from other developers. This reduces duplication 1324of effort where multiple developers would be trying to build the same mocks from the same insufficient 1325information. Finally, a service developer is probably best qualified to know when and how a service mock 1326should be updated to reflect modified functionality or message exchange.
  • 31. 1327It is also possible that testing organizations will evolve to provide high-fidelity test harnesses for new 1328services. The harnesses would allow new services to plug into a test environment and would facilitate 1329accessing mocks of component services. However, it will remain a constant challenge for such 1330organizations to capture evolving uses and characteristics of service interactions in the real SOA 1331environment and maintain the fidelity and accuracy of the test systems. 13325.3.4.5 Fundamental Questions for SOA Testing 1333In order for the transition to the SOA operational environment to proceed, it is necessary to answer two 1334fundamental questions: 1335• Who provides what testing resources for the SOA operational environment, e.g. mocks of 1336interfaces, mocks of functionality, monitoring tools? 1337• What testing needs to be accomplished before operational environment resources can be 1338accessed for further testing? 1339The discussion in section 5.4.4.4 notes various levels of sophistication of service mocks and different 1340communities are likely to be responsible for different levels. Section 5.4.4.4 advocates a significant role 1341for service developers, but there needs to be community consensus that such mocks are needed and that 1342service developers will agree to fulfilling this role. There is also a need for consensus as to what tools 1343should be available as services from the SOA infrastructure. 1344As for use of the service mocks and SOA environment monitoring services, practical experience is 1345needed upon which guidelines can be established for when a new service has been adequately tested to 1346proceed with a greater level of exposure with the SOA environment. Malfunctioning services could cause 1347serious problems if they cannot be identified and isolated. On the other hand, without adequate testing 1348under SOA operational conditions, it is unlikely that problems can be uncovered and corrected before 1349they reach an operational stage. 1350As noted in section 5.4.4.2, some of these questions can be avoided by restricting services to more 1351traditional use scenarios. However, such restriction will limit the effectiveness of SOA use and the result 1352will resemble the constraints of traditional integration activities we are trying to move beyond. 13535.3.5 Architectural Implications for SOA Testing 1354The discussion of SOA Testing indicates numerous architectural implications on the SOA ecosystem: 1355• The distributed, boundary-less nature of the SOA ecosystem makes it infeasible to create and 1356maintain a single mock of the entire ecosystem to support testing activities. 1357• A standard suite of monitoring services needs to be defined, developed, and maintained. This 1358should be done in a manner consistent with the evolving nature of the ecosystem. 1359• Services should provide interfaces that support access in a test mode. 1360• Testing resources must be described and their descriptions must be catalogued in a manner that 1361enables their discovery and access. 1362• Guidelines for testing and ecosystem access need to be established and the ecosystem must be 1363able to enforce those guidelines asserted as policies. 1364• Services should be available to support automated testing and regression testing. 1365• Services should be available to facilitate updating service description by anyone who has 1366performed testing of a service. 13675.4 Security Model 1368Security is one aspect of confidence – the confidence in the integrity, reliability, and confidentiality of the 1369system. In particular, security focuses on those aspects of assurance that involve the accidental or malign 1370intent of other people to damage or compromise trust in the system and on the availability of SOA-based 1371systems to perform desired capability. 1372Security 1373 Security concerns the set of mechanisms for ensuring and enhancing trust and confidence in the 1374 SOA ecosystem.
  • 32. 1375Providing for security for Service Oriented Architecture is somewhat different than for other contexts; 1376although many of the same principles apply equally to SOA and to other systems. The fact that SOA 1377embraces crossing ownership boundaries makes the issues involved with moving data more visible. 1378Any comprehensive security solution must take into account the people that are using, maintaining and 1379managing the SOA. Furthermore, the relationships between them must also be incorporated: any security 1380assertions that may be associated with particular interactions originate in the people that are behind the 1381interaction. 1382However, the fact that we aim to explicitly relate the IT architecture with the human architecture (see ) 1383makes it possible to give a more complete accounting of security. In effect, an analysis of the social 1384structures in place around a SOA-based system forms a backdrop and context for security. 1385Concepts such as constitutions, roles, and authority within social structures play an important part in the 1386establishment of ownership and trust boundaries within and between social structures. 1387In addition, security often revolves around resources: the need to guard certain resources against 1388inappropriate access – whether reading, writing or otherwise manipulating those resources. The basic 1389resource model that informs our discussion is outlined in Section . 1390We analyze security in terms the social structures that define the legitimate permissions, obligations and 1391roles of people in relation to the system, and mechanisms that must be put into place to realize a secure 1392system. The former are typically captured in a series of security policy statements; the latter in terms of 1393security guards that ensure that policies are enforced. 1394How and when to apply these derived security policy mechanisms is directly associated with the 1395assessment of the threat model and a security response model. The threat model identifies the kinds of 1396threats that directly impact the message and/or application of constraints, and the response model is the 1397proposed mitigation to those threats. Properly implemented, the result can be an acceptable level of risk 1398to the safety and integrity of the system. 13995.4.1 Security Concepts 1400We can characterize security in terms of key security concepts [ISO/IEC 27002]: confidentiality, integrity, 1401authentication, authorization, non-repudiation, and availability. 1402Confidentiality 1403 Confidentiality concerns the protection of privacy of participants in their interactions. 1404 Confidentiality refers to the assurance that unauthorized entities are not able to read messages or 1405 parts of messages that are transmitted. 1406 Note that confidentiality has degrees: in a completely confidential exchange, third parties would 1407 not even be aware that a confidential exchange has occurred. In a partially confidential exchange, 1408 the identities of the participants may be known but the content of the exchange obscured. 1409Integrity 1410 Integrity concerns the protection of information that is exchanged – either from unauthorized 1411 writing or inadvertent corruption. Integrity refers to the assurance that information that has been 1412 exchanged has not been altered. 1413 Integrity is different from confidentiality in that messages that are sent from one participant to 1414 another may be obscured to a third party, but the third party may still be able to introduce his own 1415 content into the exchange without the knowledge of the participants. 1416Availability 1417 Availability concerns the ability of systems to use and offer the services for which they were 1418 designed. One of the threats against availability is the so-called denial of service attack in which 1419 attackers attempt to prevent legitimate access to the system. 1420 We differentiate here between general availability – which includes aspects such as systems 1421 reliability – and availability as a security concept where we need to respond to active threats to 1422 the system.
  • 33. 1423Authentication 1424 Authentication concerns the identity of the participants in an exchange. Authentication refers to 1425 the means by which one participant can be assured of the identity of other participants. 1426Authorization 1427 Authorization concerns the legitimacy of the interaction. Authorization refers to the means by 1428 which an owner of a resource may be assured that the information and actions that are 1429 exchanged are either explicitly or implicitly approved. 1430Non-repudiation 1431 Non-repudiation concerns the accountability of participants. To foster trust in the performance of 1432 a system used to conduct shared activities it is important that the participants are not able to later 1433 deny their actions: to repudiate them. Non-repudiation refers to the means by which a participant 1434 may not, at a later time, successfully deny having participated in the interaction or having 1435 performed the actions as reported by other participants. 1436Note that these security goals are never absolute: it is not possible to guarantee 100% confidentiality, 1437non-repudiation, etc. However, a well designed and implemented security response model can ensure 1438acceptable levels of security risk. For example, using a well-designed cipher to encrypt messages may 1439make the cost of breaking communications so great and so lengthy that the information obtained is 1440valueless. 1441While confidentiality and integrity can be viewed as primarily the concerns of the direct participants in an 1442interaction; authentication, authorization, and non-repudiation imply the participants are acting within a 1443broader social structure. 14445.4.2 Where SOA Security is Different 1445The core security concepts are fundamental to all social interactions. The evolution of sharing information 1446using a SOA requires the flexibility to dynamically secure computing interactions in a computing 1447ecosystem where the owning social groups, roles, and authority are constantly changing as described in 1448section . 1449SOA is primarily about action and events. This model focuses on the issues around these concepts more 1450than simple data exchange. 1451SOA policy-based security can be more adaptive for a computing ecosystem than previous computing 1452technologies allow for, and typically involves a greater degree of distributed mechanisms. Section 1453provides one example of distributed policy-based computing mechanisms that may be present as part of 1454the realization of SOA security. Distributed security mechanisms allow for centralized identity and policy 1455services as well as centralized or decentralized authentication and authorization services. 1456Standards for security, as is the case with all aspects of SOA, play a large role in flexible security on a 1457global scale. SOA security may also involve greater auditing and reporting to adhere to regulatory 1458compliance established by governance structures. 14595.4.3 Trust 1460Trust is an assertion as to the behavior of participants in relation to each other. In terms of security 1461assurance, trust often refers to the confidence that target systems may have as to the identity and validity 1462of a participant as they interact with the system. However, in general, trust is a far larger topic. 1463Figure 9 models trust in terms of a participant, the participant’s identity and credentials, and the 1464participant’s authorization to perform an action.
  • 34. 1465 1466 Figure 9 Trust 1467Credentials 1468 The role and/or set of attributes a stakeholder uses to determine authorization to actions. 1469Trust is not easily modeled as a single number or other scalar value. The motivation for this definition of 1470trust is to allow us to distinguish the purpose of the trust as well as the degree of trust. For example, one 1471may trust a stranger to hold a space in a queue for the Cinema, but one would typically not trust that 1472same person to hold one’s car keys for a fortnight’s vacation. 14735.4.3.1 Trust Domain 1474The Trust Domain in Figure 10 models abstract concepts behind the formation of policy-based trusted 1475social groups. 1476 1477 Figure 10 Trust Domain 1478Trust Domain 1479 An abstract space of actions which all share a common trust requirement; i.e., all participants that 1480 perform any of the actions must be in the same trust relationship. 1481There are various kinds of trust domain: at the infrastructure level, a trust domain may refer to the 1482networking equipment that is under the control of the owners of a SOA and is used to propagate 1483communication. At an application level, a trust domain may refer to a social structure (see Section ) within 1484which members have previously established a certain degree of trust. 14855.4.3.2 Centralized and Decentralized Trust Authority 1486Generally, there are special procedures necessary to communicate across trust domains: for example, 1487participants may need to present credentials to participate in a trust domain. Once authenticated, 1488credentials would typically not be needed to continue within that trust domain.
  • 35. 1489Trust domains will require a centralized and/or decentralized authentication and authorization authority to 1490form trust relationships. An example of a centralized authority might be a governing body that requires 1491regulatory compliance for all participants performing a specific action. A decentralized trust authority 1492gives individual participant’s more authority to authenticate and authorize actions and events. 1493 1494 Figure 11 Centralized Trust Authority 1495Figure 11 depicts a hierarchical central trust authority. A participant’s credentials and identity are 1496authenticated by a centralized authentication authority. A web browser will often use a centralized 1497authority in establishing secure communications with a service provider such as a bank. Actions and 1498events also have centralized authorization authorities in this model. Centralized trust authorities tend to 1499provide stronger regulatory control and more efficient revocation of participants. 1500In the context of a SOA that is used by many people, there may not be a single repository for information 1501that can justify trust. Often different aspects of trust are managed by different entities. For example, a 1502corporate directory might be used to verify the employment of an individual, whereas a bank would be 1503used to verify their credit worthiness and a government agency used to verify their residency. Figure 12 1504depicts chains of trust between participants that are established by participants who introduce other 1505participants into the chain of trust. 1506 1507 Figure 12 Decentralized Trust Authority 1508Together, the various entities that provide corroboration of an individual’s authenticity and trustworthiness 1509to perform actions and raise events form a chain of trust. Chain’s of trust need not be functionally
  • 36. 1510organized: third parties who are known to both may also be used to facilitate trust. A long chain of trust is 1511likely to be more fragile and less trustworthy than a simple one. 1512Complex trust domains are likely to be composed of a combination of centralized and decentralized trust 1513authorities. For SOA, the level of complexity of a trust domain can achieve is dependent on the policy 1514language’s and IT mechanism’s ability to express trust relationships. 15155.4.3.3 Policy Mechanisms for Security 1516When a participant wishes to perform an action that requires access to a trust domain, depending on the 1517policies that are in place, he/she must provide suitable identification and/or credentials before continuing 1518the interaction. 1519Security policies are not equivalent to security. However, they are very important as the expression of 1520choices that can be used by security mechanisms to enforce security. 1521The role of a machine readable security policy is to permit stakeholders to express their choices; and, on 1522the other hand, to act as instructions for security enforcement mechanisms. 1523Figure 13 depicts security interactions based on Section . In the context of security, the diagram has been 1524modified with recognized policy, identity, and attribute authorities in the SOA ecosystem. Additional 1525auditing has also been depicted. 1526 1527 Figure 13 Policy Based Security 1528Mechanisms are not the same as solutions; a combination of security mechanisms and their control via 1529explicit policies can form the basis of a solution. Elsewhere in the architecture policies are used to 1530express routing constraints, business constraints and information processing constraints. Security policies 1531are used to marry stakeholders’ choices with mechanisms to enforce security. 15325.4.4 Security Layers 1533Security concepts can be described in terms of three primary layers when discussing the deployment of 1534SOA-based systems. The commonly known OSI seven-layer model provides an expanded view of these 1535three primary layers, each one of the OSI seven layers requires specific application of security. However, 1536discussing the seven layers of the OSI seven-layer model is beyond the scope of this reference 1537architecture. 1538Figure 14 depicts three generalized layers of security to consider and their relationship to ownership 1539domains when deploying SOA-based systems. The lowest level of abstraction is the network layer, the 1540next level of abstraction is the transport layer, and the third level of abstraction is the application layer.
  • 37. 1541 1542 Figure 14 Security Layers 1543 15445.4.4.1 Network Layer 1545At the lowest level of abstraction in the security model are the network devices and the hardware that 1546links the network devices, referred to as the network layer. The network layer includes devices like 1547routers and firewall appliances and it also includes protocols such as the Internet Protocol (IP), Border 1548Gateway Protocol (BGP), Open Shortest Path First (OSPF) protocol, etc. Network devices, however, can 1549have policy-based SOA security mechanisms built in so there is not always a clear distinction between 1550network device and network layer. 1551In order for a SOA-based system to operate, the network must be available to provide network services. 1552Control of the network layer is required in order to address the security concept of availability such as 1553protection from Denial of Service (DoS) attacks. 1554The network layer may also address general availability by defining policies or service level agreements 1555(SLAs) about the quality of service of the network layer operation and then translating hose commitments 1556into measurable constraints carried out by the network devices for such things as guaranteed service 1557delivery or specific bandwidth allocations. 15585.4.4.2 Transport Layer 1559The transport layer may pass through network layers belonging to many ownership domains. The 1560transport layer is primarily concerned with establishing a secure communications channel between sender 1561and receiver, a good example being the interaction with a bank through a web browser. The transport 1562layer may include protocols like HTTP over Transport Layer Security (TLS) as well as HTTP over Secure 1563Sockets Layer (SSL). 1564Given the nature of SOA-based communications across multiple ownership boundaries, security provided 1565at the transport layer cannot be relied upon for protection of message confidentiality. 15665.4.4.3 Application Layer 1567The application layer accounts for the security of messaging between participants within a SOA 1568ecosystem, where participants may have policy based roles and authority to act within and across 1569ownership domains. Web service standards like WS-Security, XML Digital Signature, XML Encryption, 1570and SAML are all examples of standards addressing the security concepts at the application layer. 1571Application layer security for SOAs may be built into network devices so network devices may have 1572network layer and application layer security built in. 1573In a SOA ecosystem where participants interact through many ownership domains and any number of 1574unknown network domains, the application layer may be the only layer the basic security principles of 1575confidentiality, integrity, authentication, authorization, and non-repudiation are assured. Assurance of 1576availability is addressed at the network layer but may be controlled by the application layer and/or 1577transport layer.
  • 38. 15785.4.5 Security Threats 1579There are a number of ways in which an attacker may attempt to compromise the security of a system. 1580The two primary sources of attack are third parties attempting to subvert interactions between legitimate 1581participants and an entity that is participating but attempting to subvert its partner(s). The latter is 1582particularly important in a SOA where there may be multiple ownership boundaries and trust boundaries. 1583The threat model lists some common threats that relate to the core security concepts listed in Section 15845.4.1. Each technology choice in the realization of a SOA can potentially have many threats to consider. 1585Message alteration 1586 If an attacker is able to modify the content (or even the order) of messages that are exchanged 1587 without the legitimate participants being aware of it then the attacker has successfully 1588 compromised the security of the system. In effect, the participants may unwittingly serve the 1589 needs of the attacker rather than their own. 1590 An attacker may not need to completely replace a message with his own to achieve his objective: 1591 replacing the identity of the beneficiary of a transaction may be enough. 1592Message interception 1593 If an attacker is able to intercept and understand messages exchanged between participants, 1594 then the attacker may be able to gain advantage. This is probably the most commonly understood 1595 security threat. 1596Man in the middle 1597 In a man in the middle attack, the legitimate participants believe that they are interacting with 1598 each other; but are in fact interacting with the attacker. The attacker attempts to convince each 1599 participant that he is their correspondent; whereas in fact he is not. 1600 In a successful man-in-the-middle attack, legitimate participants will often not have a true 1601 understanding of the state of the other participants. The attacker can use this to subvert the 1602 intentions of the participants. 1603Spoofing 1604 In a spoofing attack, the attacker convinces a participant that he is really someone else – 1605 someone that the participant would normally trust. 1606Denial of service attack 1607 In a denial of service attack, the attacker attempts to prevent legitimate users from making use of 1608 the service. A DoS attack is easy to mount and can cause considerable harm: by preventing 1609 legitimate interactions, or by slowing them down enough, the attacker may be able to 1610 simultaneously prevent legitimate access to a service and to attack the service by another 1611 means. 1612 A variation of the DoS attack is the Distributed Denial of Service attack. In a DDoS attack the 1613 attacker uses multiple agents to the attack the target. In some circumstances this can be 1614 extremely difficult to counteract effectively. 1615 One of the features of a DoS attack is that it does not require valid interactions to be effective: 1616 responding to invalid messages also takes resources and that may be sufficient to cripple the 1617 target. 1618Replay attack 1619 In a replay attack, the attacker captures the message traffic during a legitimate interaction and 1620 then replays part of it the target. The target is persuaded that a similar transaction to the previous 1621 one is being repeated and it will respond as though it were a legitimate interaction. 1622 A replay attack may not require that the attacker understand any of the individual 1623 communications; the attacker may have different objectives (for example attempting to predict 1624 how the target would react to a particular request).
  • 39. 1625False Repudiation 1626 In false repudiation, a malicious user completes a normal transaction and then later attempts to 1627 deny that the transaction occurred. For example, a customer may use a service to buy a book 1628 using a credit card; then, when the book is delivered, refuse to pay the credit card bill claiming 1629 that someone else must have ordered the book. 16305.4.6 Security Responses 1631Performing threat assessments, devising mitigation strategies, and determining acceptable levels of risk 1632are the foundation for an effective process to mitigating threats in a cost-effective way.1 The choice in 1633hardware and software to realize a SOA will be the basis for threat assessments and mitigation 1634strategies. The stakeholders of a specific SOA implementation should determine acceptable levels of risk 1635based on threat assessments and the cost of mitigating those threats. Example mitigation strategies are 1636provided for threats listed in Section 5.4.5. 16375.4.6.1 Privacy Enforcement 1638The most efficient mechanism to assure confidentiality is the encryption of information. Encryption is 1639particularly important when messages must cross trust boundaries; especially over the Internet. Note that 1640encryption need not be limited to the content of messages: it is possible to obscure even the existence of 1641messages themselves through encryption and ‘white noise’ generation in the communications channel. 1642The specifics of encryption are beyond the scope of this architecture. However, we are concerned about 1643how the connection between privacy-related policies and their enforcement is made. In Section , we show 1644how policies in general are enforced using a combination of Policy Decision Points (PDP) and Policy 1645Enforcement Points (PEP). 1646A PEP for enforcing privacy may take the form of an automatic function to encrypt messages as they 1647leave a trust boundary; or perhaps simply ensuring that such messages are suitably encrypted. 1648Any policies relating to the level of encryption being used would then apply to these centralized 1649messaging functions. 16505.4.6.2 Integrity Protection 1651To protect against message tampering or inadvertent message alteration, and to allow the receiver of a 1652message to authenticate the sender, messages may be accompanied by a digital signature. Digital 1653signatures provide a means to detect if signed data has been altered. This protection can also extend to 1654authentication and non-repudiation of a sender. 1655A common way a digital signature is generated is with the use of a private key that is associated with a 1656public key and a digital certificate. The private key of some entity in the system is used to create a digital 1657signature for some set of data. Other entities in the system can check the integrity of the signed data set 1658via signature verification algorithms. Any changes to the data that was signed will cause signature 1659verification to fail, which indicates that integrity of the data set has been compromised. 1660A party verifying a digital signature must have access to the public key that corresponds to the private key 1661used to generate the signature. A digital certificate contains the public key of the owner, and is itself 1662protected by a digital signature created using the private key of the issuing Certificate Authority (CA). 16635.4.6.3 Message Replay Protection 1664To protect against replay attacks, messages may contain information that can be used to detect replayed 1665messages. The simplest requirement to prevent replay attacks is that each message that is ever sent is 1666unique. For example, a message may contain a message ID, a timestamp, the intended destination. 1667By caching message IDs, and comparing each new message with the cache, it becomes possible to 1668verify whether a given message has been received before (and therefore should be discarded). 11 In practice, there are perceptions of security from all participants regardless of ownership boundaries. Satisfying 2security policy often requires asserting sensitive information about the message initiator. The perceptions of this 3participant about information privacy may be more important than actual security enforcement within the SOA for this 4stakeholder.
  • 40. 1669The timestamp may be included in the message to help check for message freshness. Messages that 1670arrive after their message ID could have been cleared (after receiving the same message some time 1671previously) may also have been replayed. A common means for representing timestamps is a useful part 1672of an interoperable replay detection mechanism. 1673The destination information is used to determine if the message was misdirected or replayed. If the 1674replayed message is sent to a different endpoint than the destination of the original message, the replay 1675could go undetected if the message does not contain information about the intended destination. 1676In the case of messages that are replies to prior messages, it is also possible to include seed information 1677in the prior messages that is randomly and uniquely generated for each message that is sent out. A 1678replay attack can then be detected if the reply does not embed the random number that corresponds to 1679the original message. 16805.4.6.4 Auditing and Logging 1681False repudiation involves a participant denying that it authorized a previous interaction. An effective 1682strategy for responding to such a denial is to maintain careful and complete logs of interactions which can 1683be used for auditing purposes. The more detailed and comprehensive an audit trail is, the less likely it is 1684that a false repudiation would be successful. 1685The countermeasures assume that the non-repudiation tactic (e.g. digital signatures) is not undermined 1686itself. For example, if private key is stolen and used by an adversary, even extensive logging cannot 1687assist in rejecting a false repudiation. 1688Unlike many of the security responses discussed here, it is likely that the scope for automation in rejecting 1689a repudiation attempt is limited to careful logging. 16905.4.6.5 Graduated engagement 1691The key to managing and responding to DoS attacks is to be careful in the use of resources when 1692responding to interaction. Put simply, a system has a choice to respond to a communication or to ignore 1693it. In order to avoid vulnerability to DoS attacks a service provider should be careful not to commit 1694resources beyond those implied by the current state of interactions; this permits a graduation in 1695commitment by the service provider that mirrors any commitment on the part of service consumers and 1696attackers alike. 16975.4.7 Architectural Implications of SOA Security 1698Providing SOA security in an ecosystem of governed services has the following implications on the policy 1699support and the distributed nature of mechanisms used to assure SOA security: 1700 • Security expressed through policies have the same architectural implications as described in 1701 Section for policies and contracts architectural implications. 1702 • Security policies require mechanisms to support security description administration, storage, and 1703 distribution. 1704 • Security policies should: 1705 o be able to express trust relationships and trust domains; 1706 o provide the ability to update policy trust relationships and trust domains in a way that 1707 does not require upgrades to software and hardware; 1708 o be able to express standard protocols used to provide confidentiality, integrity, 1709 authentication, authorization, non-repudiation, and availability. 1710 • Service descriptions supporting security policies should: 1711 o have a meta-structure sufficiently rich to support security policies; 1712 o be able to reference one or more security policy artifacts; 1713 o have a framework for resolving conflicts between security policies. 1714 • The mechanisms that make-up the execution context in secure SOA-based systems should: 1715 o provide protection of the confidentiality and integrity of message exchanges;
  • 41. 1716 o be distributed so as to provide centralized or decentralized policy-based identification, 1717 authentication, and authorization; 1718 o ensure service availability to consumers; 1719 o be able to scale to support security for a growing ecosystem of services; 1720 o be able to support security between different communication technologies; 1721 • Common security services include: 1722 o services that abstract encryption techniques; 1723 o services for auditing and logging interactions and security violations; 1724 o services for identification; 1725 o services for authentication; 1726 o services for authorization; 1727 o services for intrusion detection and prevention; 1728 o services for availability including support for quality of service specifications and metrics. 1729