Web Services - SOA
Day One Schedule ⌘
- Introduction
- Service-Oriented Architecture
- Web Services Overview
- XML
- SOAP
Service-Oriented Architecture ⌘
Learning Objectives
- To understand the relationship between SOA and Web services
- To understand what a service is
- To understand what a SOA is
- To be aware of the underlying principles behind SOA
SOA and Web Services ⌘
SOA using Web services
Service-Oriented Architecture ⌘
- Technology design approach that precedes Web services
- Early SOA seen in 1990s Object Request Broker (ORB)
Different Perspectives of SOA ⌘
The Blind Men and The Elephant John Godfrey Saxe (1816-1887)
- The man touching the trunk believes it to be a snake
- The man touching the tusk believes it to be a spear
- The man touching the ear believes it to be a fan
- The man touching the elephant’s side believes it to be a wall
- The man touching the tail believes it to be a rope
- The man touching the legs believes they are trees
SOA – Different Perspectives ⌘
The Blind Men and The Elephant John Godfrey Saxe (1816-1887)
And so these men of Indostan
Disputed loud and long,
Each in his own opinion
Exceeding stiff and strong,
Though each was partly in the right,
And all were in the wrong!
SOA Definitions ⌘
“A loosely-coupled architecture designed to meet the business needs of the organisation” (MSDN, 2013)
“A business-centric architectural approach based on service-oriented principles” (Jenson, 2013)
A Simple Definition of SOA ⌘
“The assembly of services – internal and external to an organisation” (Barry, 2013)
A Simple Service ⌘
Service Features ⌘
- Implements a business function
- Software and hardware
- Generally reusable (used in different ways)
- Can be used by multiple consumers
Atomic Service ⌘
- Indivisible
- Self-contained function
- Fine-grained or finer granularity
- No dependency on other services
Atomic Service Example ⌘
Composite/Compound Services ⌘
- Assembly of atomic or composite services
- Coarse-grained or larger granularity
- Internal services may be dependent on each other
Composite Service ⌘
Get Details of Atom Service
SOA Design ⌘
- Services designed to be components
- Components assembled in a variety of ways to support business functions
Basic SOA Building Block ⌘
Basic SOA Building Block ⌘
Web Service Implementation ⌘
Basic Service-Oriented Architecture ⌘
An Example SOA ⌘
SOA Principles ⌘
- Standardized service contracts
- Loose coupling
- Service abstraction
- Service reusability
- Service autonomy
- Service statelessness
- Service discoverability
- Service composability
Standardized Service Contracts ⌘
- Applied to ensure service contracts within organization adhere to same standards
- Service Contract typically includes:
-Policy documents
-For a Web service implementation:
- WSDL
- XML schema
Standardized Service Contracts ⌘
Loose Coupling ⌘
Loose Coupling Challenge ⌘
Service Abstraction ⌘
Service Reusability ⌘
- Service internal logic not related to specific business process – reusable in multiple processes
Service Autonomy ⌘
- Design-time autonomy
-Service designed so that underlying resources can be changed without affecting Consumer
- Run-time autonomy
-Service designed so that has control over how logic is processed by run-time environment
Service statelessness ⌘
- State = stored information to which service has access at a point in time
- Services designed to be separated from their state in order reduce overhead of managing state data
- Typically state data handled by, e.g:
-Shared middleware product external to service
-Dedicated database internal to service
Service Discoverability ⌘
- Service meta-data published
-Allows for resuse
-Avoids overlapping services
- Meta-data types
-Functional aspects of service’s capability
-Quality of service behaviour/limitations
Service Composability ⌘
- New Services created by composing services together
- Promotes reuse of services
- Dependent on previous principles
-E.g. standardized service contracts
Quiz – No Prizes! No Pressure! ⌘
