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
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
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
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
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.
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
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.
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.
85 A contract represents an agreement by two or more participants to constrain their behavior and
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
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.
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.
1126.96.36.199 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.
12188.8.131.52 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
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
156 Figure 2 Policies and Contracts
158 A policy constraint is a measurable proposition that characterizes the intent of the policy.
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.
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
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
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
195Architecture is inclusive of legally binding contracts for a SOA, contracts do not always have to be legally
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.
2184.108.40.206 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 220.127.116.11.
2285.1.2 Policy Metrics
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
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.
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:
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.
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
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
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.
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).
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
316 A contract represents an agreement by two or more participants to constrain their behavior and
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.
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.
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.
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
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.
3518.104.22.168 Motivating Governance
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
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.
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.
3722.214.171.124 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.
39126.96.36.199 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
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
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
446 • Participant interaction – the consistent expectations with which all participants are expected to
44188.8.131.52.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.
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.
49184.108.40.206.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
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,
512 representation of the meaning of terms used to describe the policy, its functions, and its
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
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.
55220.127.116.11 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.
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
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
5918.104.22.168.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;
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).
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
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.
672 Figure 6 Managing resources in a SOA
673The core concept in management is that of a manageability 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
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.
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.
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.
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.
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.
726 A management service is a service that manages other services and resources.
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:
738 Systems management refers to enterprise-wide maintenance and administration of distributed
739 computer systems.
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.
7522.214.171.124 Carrying Out Governance: One Objective of Management
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
77126.96.36.199.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
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
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
813artifacts, controlling access to those artifacts, allowing updates of the artifacts to be deployed are all
814important capabilities for managing them.
816Elements of a basic service management infrastructure should include the following characteristics:
818• Integrate with existing security services
820• Heartbeat and Ping
822• Pause/Restore/Restart Service Access
823• Logging, Auditing, Non-Repudiation
824• Runtime Version Management
825• Complement other infrastructure services (discovery, messaging, mediation)
827 * Message Routing and Redirection
828 * Failover
829 * Load-balancing
831 * QoS, Management of Service Level Objects and Agreements
832 * Availability
833 * Response Time
834 * Throughput
836• Fault and Exception Management
83188.8.131.52 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.
84184.108.40.206 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
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
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
878• Test incident report to capture any event that happened during test which requires further
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.
88220.127.116.11 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).
8918.104.22.168 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
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
902• random conditions to investigate unidentified dependencies among combinations of conditions
903• errors conditions to test error handling
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
922.214.171.124; 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.
916[EDITOR'S NOTE: TO WHAT EXTENT SHOULD CM BE EXPLICITLY INCLUDED IN THE
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:
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.
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
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
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
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
99126.96.36.199.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.
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
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
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
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
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.
107188.8.131.52.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
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
10905.3.3.1.3 Testing Content and the Interests of Consumers
1091As noted in section 184.108.40.206, 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
1116constrained, then well-documented test results establish the foundation on which further testing can be
1117defined and executed.
11220.127.116.11 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.
11318.104.22.168 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
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.
11722.214.171.124 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
12126.96.36.199 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.
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.
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 188.8.131.52 and 184.108.40.206.
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.
125220.127.116.11 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
12718.104.22.168 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
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
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.
12922.214.171.124 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.
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.
133126.96.36.199 Fundamental Questions for SOA Testing
1333In order for the transition to the SOA operational environment to proceed, it is necessary to answer two
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 188.8.131.52 notes various levels of sophistication of service mocks and different
1340communities are likely to be responsible for different levels. Section 184.108.40.206 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 220.127.116.11, 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.
1373 Security concerns the set of mechanisms for ensuring and enhancing trust and confidence in the
1374 SOA ecosystem.
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
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.
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.
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.
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.
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.
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.
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
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
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.
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.
1466 Figure 9 Trust
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.
14718.104.22.168 Trust Domain
1474The Trust Domain in Figure 10 models abstract concepts behind the formation of policy-based trusted
1477 Figure 10 Trust 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.
14822.214.171.124 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.
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.
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.
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
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.
15126.96.36.199 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
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.
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
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.
1542 Figure 14 Security Layers
154188.8.131.52 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.
155184.108.40.206 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.
156220.127.116.11 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
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.
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.
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.
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
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
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).
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.
16318.104.22.168 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
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).
16622.214.171.124 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
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
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
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;
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.