Scope
Architectures are about shared concerns, resources and mechanisms. Like Russian dolls, they are organized along hierarchical layers:
- Enterprise architectures deal with business objectives, human and financial resources, and organization.
- Functional architectures deal with systems functionalities, services, and collaboration mechanisms.
- Technical architectures deal with platforms capabilities, technical resources, and communication mechanisms.
Service Oriented Architectures (SOAs) epitomize functional architectures by fully describing systems through their symbolic behavior, presenting a uniform facade to enterprise concerns independently of their technical implementation.
From Functionalities to Services
Service Oriented Architectures (SOAs) introduce a new paradigm for systems architectures, replacing a resource perspective by a functional one: while traditional approaches view systems’ technical architecture and resources as through a white box, SOAs takes them as black boxes providing services to business processes.
Given that functional perspective, services are best described in terms of architecture capabilities:
- Who: Service customers describe components with symbolic capabilities that may call on the service.
- What: Business objects describe objects identified across architecture.
- How: Contract describes what can be expected from the service; it regroup all the relevant messages.
- Where: Endpoints are addresses or places where the service can be obtained.
- When: Policies are the run-time counterparts of contracts as they describe the terms and conditions of actual execution.
With services defined in terms of architecture capabilities, engineering can be neatly organized according architecture concerns:
- Enterprise concerns: how business processes are supported by services.
- Functional concerns: collaboration between services.
- Technical concerns: implementation of services.
That brings the whole engineering process under a single modelling roof.
SOA & Enterprise Architecture
Service oriented architectures and model driven engineering can be seen as the two faces of the same coin, with services understood as a symbolic bridge between enterprise concerns and functional architecture.
With regard to business processes, enterprise concerns stand between corporate objectives and organization on one hand, business opportunities on the other hand. Since those objectives are not necessarily aligned, system analysts may get confused as where to put the divide between shared assets and specific developments. But their task could be significantly furthered were building blocs of business processes be mapped to symbolic functionalities.
Such benefits of SOA can be demonstrated when requirements are expressed with use cases:
- Collaboration between systems can be represented by interactions with secondary actors independently of implementations (users, legacy systems, other domains, etc).
- Contracts can be set upfront according business requirements without being immediately and directly traced to component design.
- Business defined interfaces can be set apart as messages whose implementation details will be delayed until communication architectures are known.
- Quality of Service (aka user driven non functional) requirements can be factored out as service policies.
Given requirements duly analyzed and consolidated, the corresponding supporting functionalities can be directly associated to services.
SOA & Functional Architecture
With regard to functional architecture, SOA is best described as symbolic, asynchronous, anonymous, and peer-to-peer:
- Symbolic: services communicate through symbolic messages independently of implementation languages.
- Asynchronous: since synchronous communication depends on technical architecture, nothing is supposed to occur between requests and the answers.
- Anonymous: requests don’t have to name the targeted services.
- Peer-to-Peer: services collaborate on the same level.
By replacing a panoply of heterogeneous solutions (ESB, DB, Files, etc) by a comprehensive, uniform and consistent framework for systems integration, those features are the keys to SOA benefits:
- Modularity and reuse: separation of concerns between enterprise, systems and implementations greatly enhances the homogeneity and independence of services (functional architecture), business objects (enterprise architecture) and system components (technical architecture).
- Adaptability and maintenability : service contents and modus operandi can be managed independently through contracts and policies.
Providing requirements can be consolidated into functional patterns, services could be used to build a bridge of patterns between functional and technical architectures.
SOA & Technical Architecture
With regard to technical architecture, SOA can be seen as some kind of Distributed Object Oriented Design:
- Contracts and messages replace interfaces, and policies are added to deal with asynchronous collaboration within operational contexts.
- Syntax and semantics are negotiated in order to mask the specificity of languages and legacy systems disappear behind wrappings.
- Inheritance at system (as opposed to component) level is replaced by composition and delegation as new applications are built by calling on core business services.
- Objects continuity and consistency are masked behind services.
As it happens, SOA may reconcile two different approaches often seen as conflicting, namely Aspect and Object Oriented designs.
Services and Clouds
At the beginnings there were mainframes serving users through proprietary software; then came powerful client workstations calling on identified servers through standard middle-ware. Now the pendulum goes back in its track: it is not just clients workstations delegating more and more of their tasks to servers, but the servers themselves being anonymous systems running on interchangeable resources managed somewhere in otherworldly clouds. As a consequences, what was once a methodological recommendation is becoming a compelling obligation: requirements must “blind date” systems.
That would not be possible without the level of indirection provided by SOAs.