1. Introduction

A reference architecture is like an abstract machine. It is built to realize some function and it, in turn, relies on a set of underlying capabilites that must be present for it to perform. In the case of the SOA RA, its purpose is to enable a system to be a Service Oriented Architecture. The underlying capabilities are the particular technologies that are used to realize the SOA; in particular technology choices such as Web Service technologies, implementation technologies are not part of an abstract RA.

The purpose of the RA is reflected in the set of requirements that the RA must satisfy. We can structure these requirements into a set of goals, a set of critical success factors associated with these goals and a set of requirements that are connected to the CSFs that ensure their satisfaction.

Note that not all of the requirements are mapped to solutions within the scope of this RA. Indeed, the RA itself can be seen as generating a series of more explicit requirements for the realizing technology.

The overall requirements are illustrated in http://www.oasis-open.org/apps/org/workgroup/soa-rm-ra/download.php/18355/RA CFA.png

2. Goals of the Reference Architecture

2.1. Effectiveness

The RA should be an effective vehicle for enabling Service Oriented Architecture. According to the RM http://www.oasis-open.org/committees/download.php/16628/wd-soa-rm-pr1.pdf a SOA is a "paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains". Enabling the offering and utilizing of capablities across ownership domains is the definition of effectiveness of Service Oriented Architecture.

2.1.1. Critical Success Factors for Effectiveness

  1. Visibility
    • Without service consumers and providers being able to see each other, they cannot interact with each other. The RM goes on to identify three key concepts associated with visibility: awareness, willingness and reachability.

    • Descriptions
    • Mechanisms for discovery
    • Mechanism for detecting presence
      • Part of the reachability aspect of visiblity, it must be possible to determine if a service is active or not. In general this is difficult to be certain of (a service might become unavailable the instant after you have been informed that its available).
  2. Interaction
    • Interaction between service providers and consumers is how a service is effected. Supporting interaction is a major critical success factor for SOA.
    • Communication
      • One key requirement for interaction between service partners is communication: defined as the meaningful exchange of information that can be interpreted as part of a service interaction.
    • Information model
      • Successful interaction requires that the parties have agreement on the nature of the information that is exchanged. This is captured in the information model associated with the service.
    • Process model
      • The dynamics of interaction must also be effectively agreed to by the parties in the interaction.
  3. Real World Effect
    • The purpose of interacting with a service partner (both the service consumer and the provider) is to achieve desired effects - the real world effect. The RWE captures the result of bringing a capability to bear as a consequence of the interaction. How the RWE is represented in the RA is a critical aspect of SOA.
    • Realization of capabilities
    • Participants
      • The rights, obligations, roles and collaborative context of participants in service interactions must be accurately represented in the architecture. This is important from the perspective of the Real World Effect -- which is expressed in terms of the facts and committments shared by service participants -- and from the perspective of the security threats that any publicly visible system is subject to.
  4. Policy guided delivery
    • Any machine is necessarily broad in its applicability and is often under-constrained. To be able to constrain an SOA to deliver targetted functionality requires the choice and application of policies. A critical factor for SOA is that policy can can be specified, applied and enforced. Policies can be applied to many aspects of an SOA-based system; here we focus on the role of policy in delivering service functionality itself.
    • Policy instances
      • Policy instances are just individual policies. Supporting a potentially large number of policy instances is a requirement for the RA to be able to support policy guided delivery
    • Point of decision
      • A policy decision point is the location where a policy choice is made. It may be that there are different decision points for particular situations that arise. It should be possible to identify within the RA when and where policy choices are made.
    • Point of enforcement
      • A policy enforcement point is the location where a policy is enforced. It is often different to the decision point for several reasons: the same policy choice may be made multiple times, the technology required to make a policy choice is different to that required to enforce the policy.

2.2. Assurance

The RA should enable service providers and consumers to achieve their goals with the maximum possibility of safety in the interaction. Note that we distinguish any assurance associated with the delivery of a service from that resulting from the application of the service. The latter is beyond the scope of this RA. Assurance of service is of the essence when providers and consumers are in different ownership domains; and hence supporting the safety of that interaction is an important goal of the RA.

2.2.1. Critical Success Factors for Assurance

  1. Security
    • In any system which has exposure to the public, security is a paramount factor in its success. Security can be addressed from several perspectives: the threats that must be addressed, the mechanisms for addressing those threats and the management of those mechanisms. The key threats are against the privacy of communication, against the proper identification of systems and people interacting with services, against the improper use of services and against the possible later repudiation of previous interactions.
    • A coherent threat model that encompasses the major threats associated with security: privacy, identity, authority and repudiation.
    • A suitable set of abstract mechanisms that identify how security is maintained. This includes, for example, mechanisms for encryptions, authentication, authorization and non-repudiation. The extent to which a deployed system has all of these mechanisms is inherently domain and application specific.
    • A mechanism by which policies can be used to guide any security mechanisms and which permit stakeholders to express their particular security policies.
  2. Consistency
    • In order to effectively interact across ownership boundaries it is critical that the actual interaction matches expectations for that interaction. The key to this predictability is adequate and explicit descriptions of all facets of services; further supported by explicit policy statements.
    1. Descriptions
      • The architecture must provide for descriptions of all relevant elements of services and their deplyment; and there must be mechanisms where descriptions can be accessed and managed. Descriptions may or may not be expressed in formal languages; the extent to which a description is formal will effect the potential for automation.
    2. Explicit Policies
      • Where the descriptions of mechanisms is important to enable interactions, policy statements define the choices that a service provider and/or service consumer (or other stakeholder) makes. Access to these policy choices is an important aspect of ensuring predictability and consistency. The architecture should provide the means by which policy statements can be made in a way that is meaningful to service providers and consumers.
    3. Testability
      • A means of verifying the congruence between the description of a service or information and the entity itself.
  3. Graduated engagement
    • There is a fundamental principle in interacting across ownership boundaries that there be no 'unpleasant surprises'. While we cannot eliminate such unexpected consequences we can insist on a model where the expectations of the parties in an interaction are commensurate with their committments. I.e, as we gradually get deeper into an engagement with a service partner the committments and expectations become similarly deeper. For example, if a service receives a sequence of bytes that it cannot understand, it should not assume that its service has been validly invoked. Another example is the inadmissability (in many jurisdictions) of the so-called drive-by licence agreement: the user must perform an explicit action signaling agreement for it to be binding.
    1. Choreography
      • Support for explicit descriptions of the choreography, and their soundness, is a key requirement that supports graduated engagement.
    2. Dynamic patterns of interactions
      • The actual pattern on an interaction may not always be fixed in advance. This can include multiple choices in an interaction (using a credit card versus a company purchase order will result in different interaction) and may also include nested interactions.
    3. Support for transactions
      • Many interactions are transactional in nature: the committment is only fully entered into if the interaction reaches a particular stage. However, for long-running interactions committment may be required in multiple stages -- raising the potential for the need for recovery and compensation.
  4. Manageability
    • Where explicit choreographies might be said to support the service consumer's requirement for assurance, the managability of services reflects a similar requirement primarily on the part of the service provider. Given that a large-scale SOA is likely to be populated with many thousands of services, managing them becomes a critical factor for the assured delivery of services.
    1. Life-cycle
      • The specifics of a given service life-cycle are beyond the scope of this RA. However, all services have a life-cycle and being able to manage that life-cycle is important to service manageability.
    2. Versioning
      • A given service may be provided and consumed in more than one version. Version control of services is important both for service providers and service consumers (who may need to ensure certainty in the version of the service they are interacting with).
    3. Configurability
    4. Quality of Service management
    5. Descriptions

2.3. Wide scale adoption

2.3.1. Critical Success Factors for Wide Scale Adoption

  1. Scalability
    • Any architecture whose design principles are not effective across the wide range of possible scales from a small intra-Enterprise system to a full-scale Internet-wide deployment is unlikely to find general acceptance. Any givn instantiation of the architecture need not scale to the full Internet; the RA itself must be capable of such scale.
    1. Loosely coupled
      • A loosely coupled system is one in which the constraints on the interaction between components is minimal: sufficient to permit interoperation without additional constraints that may be an artifact of implementation technology. Each non-essential constraint may have negative impacts on the scalability of systems based on the architecture.
  2. Understandability
    • An architecture that is highly scalable, but which is complex and difficult to understand will not find general acceptance.
  3. Reusability
    • The extent to which services are reusable, descriptions, and other artifacts are reusable will be a critical factor in promoting adoption. Without reusability there is no investment and no growth.
    • Artifacts should be realized in appropriately compatible technology. There should not be unnecessary technological dependencies. Ed. note: imagine what happens when something is inappropriately represented.
    • Pre-existing capabilities should be made accessible as services with the minimum of transformation.
    • Services should be combinable in appropriate forms without unnecessary effort.
  4. Low cost of entry
    • A low cost of entry is an important critical success factor for wide-scale adoption.
    • The technology requirements for a given system should be commensurate with the complexity of that system. Simple service systems should be simple to design and build; complex systems with complex requirements should not be made more complex by the constraints of this architecture.
  5. Support for globalization and localization
    • Human ownership boundaries are not limited to single legal jurisdictions or geographic regions.
    • It should be possible for service providers and consumers to interact even across such boundaries.
    • It should be possible for services to be offered in ways that are sensitive to the local environment; the same service may have different presentations in different locales.
  6. Reduced dependence on one particular natural language
    • Although a natural language description of some item may be easier to understand for a native speaker of that language, natural language descriptions can become unnecessary barriers when they must be read by a non-native speaker. Formal descriptions, i.e., descriptions in a formal notation, may be more difficult to understand, they are more neutral that descriptions in any given natural language, and therefore are less likely to be mis-understood.
  7. Technology neutral
    • The extent to which the RA is technology neutral will greatly effect its applicability in different circumstances.
  8. Cross platform support
    • The counterpoint to being technology neutral is the ability to operate across several different kinds of platform. Enabling service providers and consumers to occupy different platforms is a key CSF that will help to drive adoption of the RA.
  9. Simplicity
    • A key factor in wide-scale adoption will be simplicity of design and realization. A complex architecture, or one that is difficult to understand, would be an impediment to wide-scale adoption. The hallmark of good design is simplicity. This is better expressed as sufficient complexity to satisfy requirements while avoiding unnecessary complexity. History shows us that it is often better to err on the side of reduced functionality if that promotes simplicity.
    1. Minimal assumptions
    2. Compositionality

Goals,_Critical_Success_Factors_and_Requirements (last edited 2009-08-12 18:05:11 by localhost)