Loose Coupling:
the secret sauce of Web services?
Cesare Pautasso
http://www.pautasso.info
[email protected]
@pautasso
University of Lugano (USI)
Faculty of Informatics
- Opened 2004
- 25 Professors
- 100+ PhD/Postdoc researchers
- Research: Software, Systems and Services Engineering
- Award-winning Innovative Teaching Curriculum
Architecture, Design and Web Information Systems Engineering
- BenchFlow - a benchmark for workflow management systems
- Liquid Web Streams and Liquid Software Architecture
- Fundamentals of Parallel Programming for Platform-as-a-Service Clouds
- ASQ - Interactive Scalable Lectures
- NaturalMash - Web Service Composition with Natural Language
The notion of designing services to be loosely coupled is the most important, the most far reaching, and the least understood service characteristic.
Eric Newcomer and Greg Lomow, Understanding SOA with Web Services
, Addison-Wesley, 2004
Web API
Interfaces = Decoupling
Connectors = Coupling
Loosely Coupled?
Many Facets
WSDL/SOAP supports interoperability between heterogeneous platforms and programming languages: loosely coupled?
WSDL interface changes may break clients: tightly coupled?
Some Coupling Facets
- Discovery
- Identification
- Model
- Granularity
- Interaction
- Binding
- Code Generation
- Platform
- Shared State
- Conversation
Discovery
How does the client locate the service?
Centralized registration
UDDI
Decentralized referral
Hypermedia
Identification
How does the client address a service features?
Local
WSDL Names
Names outside of their scope need to be contextualized
Global
URI
Unique identifiers in a global address space
Model
How deeply must clients understand a service?
Contract-last
Automatic WSDL generators
Leakage of internal data models/schemas
Contract-first
REST Representations
Standardized message formats mapped to/from internal model
Granularity
How precisely services satisfy their clients?
Fine-grained
WSDL
API targets specific clients
Coarse-grained
HTTP GET, PUT, DELETE, POST
Generic API targeting all possible clients
Interaction
When do clients interact with the service?
Synchronous
RPC
Clients and services must be available at the same time
Asynchronous
Messaging
Store and Forward: clients survive temporary service outages
Binding
When do clients locate the service?
Early: Compile time, Deployment time
Late: Invocation time
Very Late: Recovery time
Code Generation
Who writes the code to invoke a service?
Automatic
RPC IDL, WSDL
Client recompilation is needed when service description changes
Manual
REST
Clients are manually written without relying on any formal service description
Platform
Does interoperability require clients and services to use the same middleware platform or programming language?
Yes
DCOM, Java RMI
No
CORBA, WSDL/SOAP, JSON/HTTP
Shared State
Are multiple interactions from the same client independent from the previous ones?
No, shared session state
WebSockets
Service scaling limited by total number of connected clients
Yes, stateless interactions
HTTP without session cookies
Service scaling limited by number of active client requests
Conversations
How do clients know how to use a service?
Built-in Plan
Process Models
Explicit description of the entire conversation
Dynamic Protocol Discovery
Hypermedia
Decide next step based on results of the previous
Coupling Facets Summary
Coupling and Connectors
| RPC | Messaging | RESTful HTTP | |
| Discovery | Centralized | Centralized | Decentralized |
| Identification | Local | Local | Global |
| Model | Depends | Depends | Representations |
| Granularity | Depends | Depends | Uniform Interface |
| Interaction | Synchronous | Asynchronous | Asynchronous |
| Binding | Early or Late | Late | Late |
| Code Generation | Automatic | Automatic | Manual |
| Platform | Independent | Independent | Independent |
| Shared State | None | None | None |
| Conversation | Static | Static | Dynamic |
Tight Coupling Consequences
- Violations of assumptions made by one side will break the other side
- Changes need to be applied everywhere in lock-step (expensive upgrades, may involve downtime)
- Hard to relinquish control over parts of the system and deliver its software truly as a service to a large number of unknown clients
Conclusions
- Coupling between services is a multi-faceted concept that involves both their interface design (e.g., granularity, model abstraction) and the connectors between them
- Loose Coupling is not guaranteed when using Web services
- RESTful HTTP significantly reduces the degree of coupling relative to Messaging and RPC
References
- Jason Bloomberg and Ronald Schmelzer, Service Orient or Be Doomed!, Wiley, 2006
- Doug Kaye, Loosely Coupled: The Missing Pieces of Web Services, RDS Press, 2003
- Cesare Pautasso, Erik Wilde. Why is the Web Loosely Coupled? A Multi-Faceted Metric for Service Design, Proc. of WWW 2009, p.911-920
- Eric Newcomer and Greg Lomow, Understanding SOA with Web Services, Addison-Wesley, 2004
Use a spacebar or arrow keys to navigate
