Service Oriented Architectures

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.

Panopticon: Form follows Function

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.

Service Oriented Architectures delegate tasks to named unknowns.

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: Messages describe how to communicate with the service.
  • 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.
Services & Architecture Capabilities

Services & Architecture Capabilities

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.

Mapping business processes 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.
When seen from a Use Cases perspective services appear as actors

Use Case with SOA flavor

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.

Platforms and implementations disappear in clouds

That would not be possible without the level of indirection provided by SOAs.

External Links

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

Join 303 other followers

%d bloggers like this: