The essential and simple concept of SOA is … service. Usually the services are located on a distributed architecture. SOA is the logical successor of DOA (distributed object architecture).
Service orientation is one of the most appraised paradigms in software engineering and enterprise IT. Service based architectures are generally viewed as a major improvement over monolithic applications.
However, the flexibility of service architecture comes with a price that needs to be addressed when deisigning them:
It represents a business activity with a specified outcome
It is self contained
It is a black box for its consumers
It may consist of underlying services
Service types
Business services: Coarse-grained. Usually XML, WSDL or BPEL based. Used for business operations.
Enterprise services: Implement the functionality defined by business services. Rely on application and infrastructer services.
Application services: Bound to a specific application
Infrastructure services: non functional tasks such as authentication, auditing, security, and logging.
Contract
The service contract is the agreement between a service and a consumer (client).
Two types of contracts:
service-based contracts (the service owns the contract)
consumer-driven contracts (contract is established by collaboration)
Contracts should be versioned. Two types of versioning strategy:
homogeneous versioning: version number is embedded in contract
heterogeneous versioning: better suited for consumer-driven contracts
Architecture
Layers:
Services/APIs
Application
Application Server
Managed Runtime Environment
Operating System
Hypervisor
Storage
Network
Hardware
Roles
Service provider
Service broker (or registry, repository)
Service consumer (requester)
Implementation
A SOA can be implemented with web services such as SOAP, REST, CORBA, Jini.
Security
Authentication
Authorization
With micro-services, security is quite a challenge: no middlewere helps because each service must handle authentication and authorization by itself.
Transaction management
Service based architectures typically rely on BASE rather than ACID.
Orchestration vs choreography
Orchestration: workflow driven
Choreography: loosly copuled, peer to peer. Better suited for Cloud
Orchestration relies on a central system to control and call (micro-)services to complete a task.
With Choreography, each (micro-)service acts as a state machine and reacts based on the input from other services.
Orchestration services are often called synchronously, choreography services asynchronously.
Design principles
Service autonomy
Standardized service contract (Contract based design)
Service loose coupling
Service abstraction
Service reusability
Service statelessness
Service discoverability
Service composability
Service repository
A service repository lists the available services in a specific environment or network (such as ESB).
Service vs Components
A component is a piece of software to be used locally by another piece of software. So, a component might be a DLL, jar file, object file, an imported source etc.)
A service is used remotely via a well defined interface (such as web service, RPC call etc.) in a distributed system.
BASE (as opposed to ACID)
BASE = Basic Availability Soft state Eventual consistency
Basic Availability: Partial failing within architecture is supported (sharding)
Soft state: State might be out of sync for a period of time
Eventually consistent: Eventually, all data becomes consistent (given reliable hardware)
BASE typically describes the properties of NoSQL databases.
BASE doesn't have an explicit rollback.
Eventual Consistency means neither lack of transactions nor lack of consistency: after a certain but unknown time, the system will reach a consistent state.
When a service is used and a functional or technical error occurs, it's the responsibility of the service to deal with the error and to send an according message back to the consumer.
The service should make sure that the integrity of the system is not impacted.
Micro Services
The services tend to become simpler, the architecture tends to become more complex.
Process & tools: development, code deployment, maintenance, product management
Culture: shared set of values. Ubuiquitous language in domain driven design (DDD)
Organization: Structure, direction of authority, granularity, team composition
Solution: coordination of input/output. Macro level view allows designer to focus more on desirable system behaviour
TODO
SOMF: the service oriented modeling framework.
Protocols
Microservices
SOA governance
SOA governance extends IT governance with the focus on the lifecycle of services. Thus, it tries to make sure that the business value of SOA is maintained.