Agenda for Week 1

1. 01Why SOA exists — the integration problem
2. 02Business and technical drivers
3. 03Defining SOA and its core vocabulary
4. 04Anatomy of a service
5. 05SOA vs other architectural styles
6. 06The eight service-orientation principles
7. 07Service models and layers
8. 08Granularity, coupling, cohesion
9. 09Benefits, challenges, a worked example
10. 10Lab 1 brief and reading

Learning Outcomes

By the end of Week 1 you will be able to:

• Explain the business and technical drivers behind SOA.
• Compare SOA with monolithic, client-server, component-based, and object-oriented approaches.
• State and explain the eight service-orientation principles.
• Identify service types and produce a first service decomposition of a business domain.

The Problem: IT Silos

Enterprises grow by adding systems over time:

• CRM, ERP, billing, inventory, HR — each built separately.
• Different vendors, languages, data models, and protocols.
• Point-to-point integrations multiply: n systems can need up to n(n−1)/2 connections.

Result

A brittle, expensive “spaghetti” of integrations that resists change.

Fig. 01

What Goes Wrong Without an Architecture

• Duplication: the same logic (e.g. “validate customer”) reimplemented everywhere.
• Tight coupling: changing one system breaks others.
• Poor agility: a new requirement touches many code bases.
• No reuse: functionality is locked inside applications.
• Misalignment: IT capabilities don’t map cleanly to business activities.

Fig. 02

SOA is a response to all five.

Business Drivers of SOA

• Agility: respond faster to changing market and regulatory needs.
• Reuse: build a capability once, consume it everywhere.
• Cost reduction: lower integration and maintenance cost over time.
• Business–IT alignment: services map to capabilities the organisation actually recognises.
• Mergers & partnerships: easier to expose and integrate across organisational boundaries.

Technical Drivers of SOA

• Interoperability across platforms and languages via open standards.
• Loose coupling to isolate change.
• Abstraction of legacy systems behind clean interfaces.
• Standardized contracts so consumers and providers evolve independently.
• Discoverability & reuse through registries.

What Is SOA?

“

Service-Oriented Architecture is an architectural style in which application functionality is provided and consumed as a set of services — self-contained units of business logic exposed through well-defined, standardized contracts and accessed over a network.

SOA is a design philosophy, not a specific product or technology.

Core Vocabulary

• Service — a logical unit of functionality with a published contract.
• Service provider — exposes and hosts the service.
• Service consumer — invokes the service.
• Service contract — the agreement: operations, messages, data formats, policies.
• Service registry / repository — where services are published and discovered.
• Message — the unit of communication exchanged between consumer and provider.

The Find–Bind–Invoke Triangle

The classic SOA interaction model:

1. 01Publish — provider registers the contract in a registry.
2. 02Find — consumer discovers a suitable service.
3. 03Bind & invoke — consumer connects and calls the provider.

Fig. 03

Anatomy of a Service

• Contract — what it does and how to call it (the public face).
• Implementation — the code/logic, hidden from consumers.
• Boundary — clear separation of inside vs outside.
• Data it owns or operates on.
• Policies — security, reliability, quality-of-service.

Key rule

Consumers depend only on the contract, never on the implementation.

Fig. 04

The Landscape

We compare SOA against four reference points:

• Monolithic architecture
• Client–server / distributed architecture
• Component-based development (CBD)
• Object-oriented design (OOP)

The contrast clarifies what SOA adds and when it is worth the cost.

Fig. 05

Monolithic Architecture

• All functionality compiled and deployed as a single unit.
• Modules call each other in-process.

Client–Server & Distributed

• Functionality split across a network boundary (e.g. RPC, CORBA, DCOM).
• Introduced remote calls, but often tightly coupled to specific platforms and binary protocols.

Component-Based Development

• Software assembled from reusable components with defined interfaces.
• Reuse and encapsulation at the code/binary level (DLLs, JavaBeans, EJBs).

SOA is componentization raised to the enterprise, cross-platform level.

SOA vs OOP vs CBD — At a Glance

Left → right: coupling loosens and reuse scope widens — at the cost of communication overhead.

Where SOA Fits

SOA does not replace OOP or components — it builds on top of them:

• Objects/components implement the logic inside a service.
• SOA governs how that logic is exposed, discovered, and combined across the enterprise.

Think in layers

objects → components → services → business processes

Fig. 06

The Eight Principles

The design principles (Thomas Erl) that make a service truly “service-oriented”:

1. 01Standardized contract
2. 02Loose coupling
3. 03Abstraction
4. 04Reusability
5. 05Autonomy
6. 06Statelessness
7. 07Discoverability
8. 08Composability

Fig. 07

How the Principles Reinforce Each Other

• Abstraction + standardized contract → enable loose coupling.
• Loose coupling + statelessness + autonomy → enable reuse and scalability.
• Discoverability + composability → enable agility (fast assembly of new processes).

Service Models / Layers

A common layering of services:

• Entity services — centred on a business entity (Customer, Invoice); highly reusable.
• Task / business services — encapsulate a specific process step.
• Utility services — cross-cutting functions (logging, notification, auth).
• Orchestration services — coordinate others into end-to-end processes.

Fig. 08

Granularity, Coupling & Cohesion

• Granularity: too fine → chatty, slow (“nano-services”); too coarse → low reuse, hard to change.
• Cohesion: a service should do one well-defined thing, fully.
• Coupling: minimize dependencies between services.

Aim for

Business-meaningful, cohesive, coarse-enough services with loose coupling.

Fig. 09

Benefits of SOA

• Increased reuse and reduced duplication.
• Greater agility — assemble new processes from existing services.
• Interoperability across heterogeneous systems.
• Encapsulation of legacy behind clean contracts.
• Better business–IT alignment.

Challenges & Pitfalls

• Upfront investment in design, governance, and infrastructure.
• Performance overhead from network calls and message processing.
• Governance is essential — without it, sprawl and duplication.
• Distributed complexity: failure handling, latency, versioning, security.
• The ESB-as-bottleneck and wrong-granularity anti-patterns.

SOA pays off at enterprise scale; it can be over-engineering for small systems.

Worked Example — Online Retailer

Lab 1 — Brief

Goal: produce a first service decomposition.

Given a business case (online retailer or university enrollment):

1. 01Identify candidate services.
2. 02Classify each (entity / task / utility / orchestration).
3. 03Draft an informal contract per service (operations, inputs, outputs, responsibility).
4. 04Justify your granularity choices.
5. 05Produce a service inventory diagram.

Reading

• Erl, Service-Oriented Architecture: Concepts, Technology, and Design — introductory chapters.
• Erl, SOA Principles of Service Design — the eight principles in depth.

Key Takeaways

• SOA is an architectural style, not a product — functionality as reusable, contract-based services.
• It exists to solve integration cost, duplication, and lack of agility.
• The eight principles work together for loose coupling, reuse, and composability.
• Governance and good granularity are what make SOA succeed.
• Composability sets up everything we do in later weeks.