1. Perspectives on the Term Service
Ken Laskey
OASIS SOA-RM TC Chair
4 March 2011

2. Foundation Set by OASIS SOA-RM
OASIS SOA Reference Model defines
Service Oriented Architecture: “a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains”
(SOA) Services: “the mechanism by which needs and capabilities are brought together”.
Context: “the central focus of Service Oriented Architecture is the task or business function – getting something done.”
Together, these ideas describe an environment in which
Business functions realized in the form of services
Service implementations utilize capabilities to produce the (real world) effects that address business needs
Both the actors using the services and the capabilities may
Be distributed across ownership domains
Differ in policies and other conditions of use
Role of services in the SOA context is to enable effective business solutions in this distributed environment.
SOA is an architectural style that guides the identification, design, and implementation of services.

3. Limits Set by SOA-RM
OASIS SOA-RM limited the scope for which it would “completely account” for describing SOA principles by noting:
While service-orientation may be a popular concept found in a broad variety of applications, this reference model focuses on the field of software architecture. The concepts and relationships described may apply to other "service" environments; however, this specification makes no attempt to completely account for use outside of the software domain.
Intent was not to declare SOA to be solely software
Statement acknowledges wide applicability of service orientation
Positions SOA-RM
Consists of set of concepts and relationship
Focuses software development on the SOA principles critical to realizing SOA benefits.

4. Where SOA Services Fit The SOA-RM states:
services are the mechanism by which needs and capabilities are brought together
Idea of services as “between” needs and capabilities
introduced because of the all too prevalent situation of someone pointing to an ill-defined business problem and saying an equally undefined service was now the solution
SOA does not provide any domain elements of a solution that do not exist without SOA
SOA-RM emphasized capability as notional or existing business functionality
Address well-defined needs
Use of SOA principles to improve efficiency in bringing the capabilities to bear to meet those needs

5. Expanding Service: The SOA Ecosystem
Introduced in SOA Reference Architecture Foundation
Complex system more than a simple decomposition into parts and subsystems
Many autonomous parts are governing interactions
Holistic perspective that considers the relationships between the parts and their environment at least as important as the individual parts
Considerations
Resources are distributed across ownership boundaries
People and systems interacting with each other, also across ownership boundaries
Security, management and governance are similarly distributed across ownership boundaries
Interaction between people and systems primarily through the exchange of messages with reliability that is appropriate for the intended uses and purposes.

6. SOA and Business Services
SOA-RM goes on to note:
In actual use, maintaining this distinction may not be critical (i.e. the service may be talked about in terms of being the capability) but the separation is pertinent in terms of a clear expression of the nature of SOA and the value it provides.
In common use, the idea of a service in a SOA ecosystem
Combines the business functionality and the implementations of services
Includes artifacts made available as IT resources
SOA perspectives
Developer of software: the SOA service (as described in the SOA-RM) embodies principles to enable use of capabilities in an IT context
Consumer of software: SOA services and capabilities combine to deliver business functionality to produce intended real world effects without distinction among the underlying artifacts which make that delivery possible.

7. Operational View/Business Perspective
Business Process
Automation of Actions or set of actions within a business process
Logical
Enabling access to the capability
Operational View/Business Perspective
System View/Technology Perspective
Network Cloud
Capability
(Business Service)
Business Logic
Service
Message Processing Logic
Physical
©2008 The MITRE Corporation. All rights reserved. Approved for Public Release; Distribution Unlimited

8. Key Concepts: SOA Service Illustrated
Generally non-standard (proprietary) way to interact with capability
Standard way to interact with service
- network address
- transport protocol
- message schema
Network Cloud
Business Logic
(legacy app, data store, human in the loop, etc.)
Message Processing Logic
(service interface, transforma-tions, policy enforcement, etc.)
Accessible via the service, performed by software or human
Accessible via the network, performed by software
©2008 The MITRE Corporation. All rights reserved. Approved for Public Release; Distribution Unlimited

9. In Figure 1, a service is shown as the combination of a capability producing a real world effect and a mechanism for a consumer to access the capability. Figure 1 uses different colored dashed lines to demonstrate several combinations that satisfy different consumer needs. For example (black line), the Auto Shop storefront provides access to the Tire Rotation capability, and the real world effect is the rotated tires. As another example (green line), a human consumer can use an automated teller machine (ATM) to access the bank capability of withdrawing money from the consumer’s account; a real world effect is the withdrawal deducted from the consumer’s account balance and money is returned to the ATM user. However, the bank withdrawal capability can also be accessed through other interfaces. In the health club example (red line), the health club is the consumer using a machine to machine interface to access, i.e. reuse the withdraw money capability. The ATM and health club examples demonstrate the concept of composability and services as a major facilitator of reuse.

10. Services Reflecting Business
Usual SOA emphasis: Prescribed interface through which service interaction is accomplished
Enables predictable integration in the sense of traditional software development
Alone does not guarantee that services will be composable into business solutions.
What is meant by business?
Covers anything a stakeholder sees as their business.
Leaf raking is a business
Rocket design is a business.
SOA approach may be readily applicable to some businesses and may be less applicable (at the current time) to others.

11. Importance of Composability
Composability is the ability by which individual services providing defined business functionality can be combined to provide more complex business solutions
Key because many SOA benefits assume multiple uses for services
Multiple use requires the service deliver a business function that is applicable to multiple business solutions.

12. Realizing Composability
Identify capabilities that serve as building blocks for business solutions
Building blocks = services representing
well-defined business functions
operating under well-defined policies and other constraints
generating well-defined real world effects
Service building blocks should be relatively stable
Not force repeated changes in the compositions that utilize them
Readily support creating compositions that can be varied to reflect changing circumstances

13. Composition and Opacity
SOA-RM states that
the service could carry out its described functionality through one or more automated and/or manual processes that themselves could invoke other available services
Composition can be made available as a service
Details of the business functionality, conditions of use, and effects documented in its service description
Debate over whether details of composition must be publicly documented

14. SOA-RM Definition of Service
Backup
SOA-RM Definition of Service

15. Service – Formal Description (1 of 3)
A service is a mechanism to enable access to one or more capabilities, where
the access is provided using a prescribed interface and
[the access] is exercised consistent with constraints and policies as specified by [referenced in] the service description
A service is provided by an entity – the service provider – for use by others, but
the eventual consumers of the service may not be known to the service provider and
[the eventual consumers] may demonstrate uses of the service beyond the scope originally conceived by the provider
A service is accessed by means of a service interface, where the interface comprises the specifics of how to access the underlying capabilities
Not just any consumer can use any service BUT any consumer whose use would be consistent with the constraints and policies connected with the service can.
©2008 The MITRE Corporation. All rights reserved. Approved for Public Release; Distribution Unlimited

16. Service – Formal Description (2 of 3)
There are no constraints on what constitutes the underlying capability or how access is implemented by the service provider [or others]
The service could carry out its described functionality through one or more automated and/or manual processes that themselves could invoke other available services.
A service is opaque in that its implementation is typically hidden from the service consumer except for
the information and behavior models exposed through the service interface and
the information required by service consumers to determine whether a given service is appropriate for their needs
Entity providing service may not be the same one providing underlying capability.
Labeling requirements for food or drugs
©2008 The MITRE Corporation. All rights reserved. Approved for Public Release; Distribution Unlimited

17. Service – Formal Description (3 of 3)
The consequence of invoking a service is a realization of one or more real world effects:
information returned in response to a request for that information [the service consumer does not know how the information is generated],
a change to the shared state of defined entities [the service consumer does not know how the state change is effected], or
some combination of (1) and (2)
Recall, this description emphasizes a distinction between a capability and access to that capability but the distinction may not be critical in every use
©2008 The MITRE Corporation. All rights reserved. Approved for Public Release; Distribution Unlimited