SE457 Week 2 – Introduction and Overview Part 2
Steven Engelhardt
DePaul University
Spring 2021
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 1 / 93
Table of Contents
1 Last Week
2 Service Abstraction
3 Service Autonomy
4 Service Composability
5 Service Discoverability
6 Service Reusability
7 Service Statelessness
8 Wrap-Up
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 2 / 93
Summary of Last Week
• Please turn on your camera during the lecture but keep yourself muted unless you would like to say something.
• Software architecture is the structure of a system which enables or inhibits key quality attributes such as availability, performance, security, and scalability.
• Service-oriented architecture (SOA) is a design paradigm where rather than building a single, monolithic business application, we instead build a set of self-contained, typically application-agnostic services, plus a relatively small business application layer which uses these services.
• Broadly speaking, we can classify these services into three buckets: entity services, task services, and utility services.
• The theoretical goals & benefits of SOA include increased federation, increased ROI, increased organizational agility, and reduced IT burden. Naturally, the quality of the SOA implementation has a massive influence on whether it achieves these benefits.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 3 / 93
Table of Contents
1 Last Week
2 Service Abstraction
3 Service Autonomy
4 Service Composability
5 Service Discoverability
6 Service Reusability
7 Service Statelessness
8 Wrap-Up
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 4 / 93
Principle
Short Version
• The services act as black boxes, that is their inner logic is hidden from the consumers.
Long Version
• Service contracts only contain essential information and information about services is limited to what is published in service contracts.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 5 / 93
Abstraction, like coupling, requires a careful balance
• The more information that’s published in a service contract, the greater the chance of consumer-to-contract coupling.
• This also translates into greater knowledge about the underlying implementation, which can increase consumer-to-implementation coupling.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 6 / 93
Four types of “meta-abstraction”
• Technology – Describes the technical implementation of the service.
• Functional – Describes the service’s capabilities.
• Programmatic – Describes how a service performs its capabilities.
• Quality of Service – Describes service behavior, limitations, and interaction requirements.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 7 / 93
Technology abstraction
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 8 / 93
Functional abstraction
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 9 / 93
Programmatic abstraction
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 10 / 93
Quality-of-service abstraction
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 11 / 93
Functional abstraction can be inferred from contract content
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 12 / 93
Service abstraction can…
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 13 / 93
Table of Contents
1 Last Week
2 Service Abstraction
3 Service Autonomy
4 Service Composability
5 Service Discoverability
6 Service Reusability
7 Service Statelessness
8 Wrap-Up
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 14 / 93
Principle
Short Version
Long Version
• Services are independent and control the functionality they encapsulate, from a design-time and a run-time perspective.
• Services exercise a high level of control over their underlying execution environment.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 15 / 93
What’s autonomy?
• The ability of a service to make its own decisions without outside influence, control, or involvement.
• The more independent that a service is from unpredictable outside influences, the more reliable it will be.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 16 / 93
There are two types of autonomy
Design Time
• The level of freedom we have to make changes to a service over its lifetime given that other services depend on it. In other words, the independence with which the services could be evolved without impacting their service consumers.
• The greater the control over the service’s design and implementation, the greater our control over its runtime autonomy.
Runtime
• The level of control that a service has over the way its solution logic is processed by the run-time environment.
• The more control a service has over its run-time environment, the more predictable is its behavior.
• The more the service uses outside logic or resources, the less the chance that it can meet its non-functional requirements like reliability, performance, and availability.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 17 / 93
There are different kinds of autonomy
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 18 / 93
Types of autonomy
Level
Service Contract
Shared
Service Logic
Pure
Description
Service contracts are designed in alignment with each other to avoid functional overlaps. The logic and resources of the service are shared with other parts of the enterprise
The service logic is isolated, but data is shared with other parts of the enterprise
The logic and data are both isolated and dedicated to the service
Focus
Contract Implementation Implementation Implementation
Scope
Contract Capability Capability Capability
Implementa- tion Isolation
N/A None Partial Full
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2
Spring 2021
19 / 93
Services can be normalized…
• Service normalization is a design pattern that is used to minimize the amount of functional redundancy within a service inventory.
• This is one of the benefits of top-down SOA with an emphasis on the inventory blueprint.
• Normalized services are more easily composed.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 20 / 93
While contracts can be denormalized…
• Contract denormalization is a design pattern that is used to split one capability into multiple forms to better meet consumer needs.
• This needs to be planned and targeted.
• The goal is maintain a many operationally distinct capabilities as we can.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 21 / 93
Shared autonomy bridges between SOA and non-SOA services
• Shared autonomy recognizes that we might decide to expose parts of the existing organization via services.
• These parts may still be access and used in ways other than the service contract.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 22 / 93
Service logic autonomy provides for services with shared components
• This kind of autonomy results when we build new, isolated services that share some component, such as a database, in common.
• This can result in:
• Unpredictable concurrent data
access.
• Record or page locking.
• Prolonged query execution
times.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 23 / 93
Pure isolation can be accomplished at the functional level…
• Each service has its own resources and those resources neither overlap nor are shared.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 24 / 93
To an even more absolute level…
• Each service has its own resources and those resources neither overlap nor are shared.
• Each service has its own computing resources either in terms of dedicated hardware or VMs.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 25 / 93
Autonomy can vary with the service model
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 26 / 93
Considerations with service autonomy
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 27 / 93
Service autonomy can…
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 28 / 93
Table of Contents
1 Last Week
2 Service Abstraction
3 Service Autonomy
4 Service Composability
5 Service Discoverability
6 Service Reusability
7 Service Statelessness
8 Wrap-Up
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 29 / 93
Principle
Short Version
• Services can be used to compose other services.
Long Version
• Services are effective composition participants, regardless of the size and complexity of the composition.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 30 / 93
Service composition is closely related to process decomposition
• By splitting a larger problem into smaller ones, we begin to be able to identify and construct the services that can solve those smaller problems.
• Those services can then be recombined to solve the original problem.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 31 / 93
Agnostic services lend themselves to reuse when solving other problems
• If we’ve done our jobs right, we’ll end up with an inventory of services that are process agnostic enough that they can be used to solve other problems.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 32 / 93
Composition is nothing new
Object-Orientation
SOA
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 33 / 93
A service can be either a composition controller or member
• It is the capability being invoked that defines the role of the service.
• One service might play both controller and member roles within the same capability.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 34 / 93
Service activities represent inter-service messages
• These activities are useful for modeling the sequence of activities that are completed during a service capability request.
• They are not used to model what happens in the underlying logic of each of the composed capabilities.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 35 / 93
These interactions can be complex if there is significant composition
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 36 / 93
Service inventories evolve beginning with initial service delivery projects…
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 37 / 93
Then move into hybrid applications as the inventory grows…
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 38 / 93
And gradually evolve toward complex compositions…
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 39 / 93
Considerations with service composability
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 40 / 93
Service composability can…
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 41 / 93
Table of Contents
1 Last Week
2 Service Abstraction
3 Service Autonomy
4 Service Composability
5 Service Discoverability
6 Service Reusability
7 Service Statelessness
8 Wrap-Up
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 42 / 93
Principle
Short Version
• Services are discoverable.
Long Version
• Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 43 / 93
Service discovery is concerned with whether to build or reuse
• Discovery implies that we need to understand what we’re looking for.
• This means that we need to be able to search the data for each service including its purpose, capabilities, and limitations.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 44 / 93
Service discovery requires meta information that is…
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 45 / 93
Poorly defined or inadequate meta data will result in…
• The loss of an opportunity to reuse and existing service, and
• The delivery of a new resource whose functionality overlaps that of an existing resources.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 46 / 93
Information about services and their meta data resides in a registry
• A service registry is part of the overall infrastructure.
• Its role is to maintain information about services in the inventory.
• In this respect it’s similar to a configuration management database (CMDB).
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 47 / 93
Searching for services in the registry is a human-centric task
• This is typically done at design time, so that project planners will know if additional development will be required.
• The inventory blueprint is useful in providing guidance about what services will be required and when.
• It’s possible to perform runtime discovery, but this hasn’t been widely adopted.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 48 / 93
The first step is to publish discoverable meta data to the registry
• A service that provides this kind of information is said to have some degree of discoverability.
• The degree to which a service is discoverable is directly related to quantity and quality of the meta data provided in the registry.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 49 / 93
A human can then search the registry for services based on functionality
• This is one reason that the meta data needs to be well defined and crafted. Failure to do so will make the search process extremely cumbersome and error prone.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 50 / 93
Service discoverability needs to be addressed during analysis and design
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 51 / 93
Service discovery and availability
• Service discoverability is not necessarily limited to service contracts. It also can extend to load balancing, which can improve availability and/or performance.
• Load balancing requires service registration, where service instances inform the registry that they are ready to respond to service requests.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 52 / 93
Load Balancing
Client-Side Load Balancing
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 53 / 93
Server-Side Load Balancing
Registration Options
Self-Registration
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 54 / 93
Third-Party Registration
Considerations with service discoverability
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 55 / 93
Service discoverability can…
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 56 / 93
Table of Contents
1 Last Week
2 Service Abstraction
3 Service Autonomy
4 Service Composability
5 Service Discoverability
6 Service Reusability
7 Service Statelessness
8 Wrap-Up
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 57 / 93
Principle
Short Version
• Logic is divided into various services, to promote reuse of code.
Long Version
• Services contain and express agnostic logic and can be positioned as reusable enterprise resources.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 58 / 93
Reuse initiatives have failed for a variety of reasons
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 59 / 93
Successful reuse asks key questions during service design
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 60 / 93
Reuse can be categorized
• Tactical – Only the services needed for immediate use will be built.
• Targeted – The highest-priority features identified during service-oriented analysis are built.
• Complete – All of the features identified during service-oriented analysis are built. This should only be attempted if there is a service inventory blueprint based on an inventory analysis.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 61 / 93
We need to measure our reuse to determine our success
• The number of actual consumers of the service. If there is a roadmap, we should be able to compare with the number that were intended to use the service.
• The frequency at which the consumers use the service.
• This can be measured down to the capability level.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 62 / 93
The most effective reuse is for process-agnostic services
• The service’s capabilities are not specific to any one business process.
• The service’s capabilities are useful for the automation of more than one business process.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 63 / 93
The service inventory blueprint helps define reusable services…
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 64 / 93
…but relies on each project team to play by the rules
• Logic centralization is an SOA design pattern that limits the choice of which service to use to exactly one option:
1 Either an existing service will be used, or
2 A new service will be developed.
• This requires well-defined functional service boundaries to prevent duplication.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 65 / 93
Logic and contract centralization are complementary
• Logic centralization is concerned with service logic, but not how that logic is accessed.
• Contract centralization is concerned with how a service is accessed, but not with that service’s logic.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 66 / 93
Achieving enterprise-wide service reuse may be impossible
• The domain inventory pattern is used to constrain reuse efforts to more manageable scales such as particular departments or functional areas.
• This allows for a phased rollout rather than a big bang.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 67 / 93
There can be cultural concerns over consuming reusable services…
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 68 / 93
…as well as over delivering reusable services
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 69 / 93
Governance can also be a problem
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 70 / 93
And there are always architectural and development concerns
• Reliability • Security • Agility
• Roadmap
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 71 / 93
Reusability can…
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 72 / 93
Table of Contents
1 Last Week
2 Service Abstraction
3 Service Autonomy
4 Service Composability
5 Service Discoverability
6 Service Reusability
7 Service Statelessness
8 Wrap-Up
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 73 / 93
Principle
Short Version
• Services minimize statefulness.
Long Version
• Services are stateless, that is either return the requested value or give an exception hence minimizing resource use.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 74 / 93
Purpose
• Statelessness results in reduction of the resources consumed by a service as the actual state data management is delegated to an external component or to an architectural extension.
• By reducing resource consumption, the service can handle more requests in a reliable manner.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 75 / 93
State management in 2-tier topology
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 76 / 93
State management in 3-tier topology
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 77 / 93
State deferral in 3-tier topology
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 78 / 93
Services often have high concurrency requirements
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 79 / 93
There are many kinds of state
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 80 / 93
A service constantly shifts between states during its life
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 81 / 93
Two ways to handle its active state
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 82 / 93
Different kinds of state data
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 83 / 93
Context state includes data and rules
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 84 / 93
Service statelessness is not binary
• Statelessness is a property of individual capabilities rather than of a service as a whole.
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 85 / 93
Non-deferred state management (high statefulness)
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 86 / 93
Partially deferred memory (reduced statefulness)
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 87 / 93
Partial architectural state management deferral (moderate statelessness)
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 88 / 93
Full architectural state management deferral (high statelessness)
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 89 / 93
Considerations with service statelessness
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 90 / 93
Service statelessness can…
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 91 / 93
Table of Contents
1 Last Week
2 Service Abstraction
3 Service Autonomy
4 Service Composability
5 Service Discoverability
6 Service Reusability
7 Service Statelessness
8 Wrap-Up
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 92 / 93
Next Steps
• Chapters 8-13 in the text.
• Homework 1 due Tuesday, April
13 at 5:30PM
Steven Engelhardt (DePaul University) SE457 Week 2 – Introduction and Overview Part 2 Spring 2021 93 / 93