Scope
Services are the grail of modular architectures as they provide packaged functionalities to be used independently of the service(s) implementing them. Clearly, patterns could help with their design if organised depending on the problems associated with service reuse.
Set within Service Oriented Architectures, service patterns stand on the enterprise/technical divide as they would have to deal with two different kinds of problems:
- Seen from enterprise architecture, service patterns deal with functional solutions to business processes, e.g authentication, authorization, or presentation.
- Seen from systems architecture, service patterns deal with technical solutions to service design, e.g composition, orchestration, or invocation.
The objective is to identify basic patterns on both sides and examine how they can be related.
Functional Concerns
Functional concerns may provide a coarse-grained taxonomy of services based upon their footprint in business processes:
- Persistency services manage business objects whose continuity and consistency must be supported independently of the activities using them.
- Communication services deal with the exchange of messages between activities. They are not meant to know what activities are about but must guarantee that messages are delivered as specified (resources, time, acknowledgment, …).
- Orchestration and choreography services deal with coordination and synchronization of activities.
- Directories services provide access to services.
- Applications deal with business specific activities.
- Authentication services check identities at entry points.
- Authorization services check accesses to resources.
- Interactions manage presentations and I/O
Clearly a more fine-grained taxonomy is necessary, in particular if infrastructure and integration concerns are to be taken apart:
- Infrastructure-oriented services deal with access to enterprise architecture assets: objects, processes, communication, information, etc.
- Integration-oriented services deal with the running of activities: data and control flows, messages, synchronization, etc.
Technical Concerns
Technical concerns address the way services are designed and implemented, independently of their business contents.
- Reusability: with regard to architecture (i.e disregarding business contents), a service is reusable if its design is confined within a single architecture layer: enterprise (business problems), systems (organizational problems), platforms (technical problems).
- Adaptability: requirements are meant to change with business contexts and opportunities, hence the need for modularity and cohesion of services, with granularity set according to reasons for change.
- Functional Coupling: modularity and cohesion usually entail functional dependencies between services.
- Temporal coupling
- Performance, availability, scalability
- Security
Further Reading
- Enterprise Architecture
- Architectures
- Models, Architectures, Perspectives (MAPs)
- Views, Models, & Architectures
- EA: The Matter of Layers
- Architecture Capabilities
- Feasibility & Capabilities
- Enterprise Systems & the OS Kernel Paradigm
- Agile Architectures: Versatility meets Plasticity
- Service Oriented Architectures
- EA: Maps & Territories
- EA: Work Units & Workflows
- EA: Legacy & Latency
- Relating to Functions
- Capabilities vs Processes
- From Processes to Services
- Use Cases Patterns
- Squaring Software To Value Chains