TEST

Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.

For the best experience please use the latest Chrome, Safari or Firefox browser.


Loose Coupling:
the secret sauce of Web services?

Cesare Pautasso
http://www.pautasso.info
cesare.pautasso@usi.ch
@pautasso

University of Lugano (USI)

Faculty of Informatics

Architecture, Design and Web Information Systems Engineering

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

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?

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

RPCMessagingRESTful HTTP
DiscoveryCentralizedCentralizedDecentralized
IdentificationLocalLocalGlobal
ModelDependsDependsRepresentations
GranularityDependsDependsUniform Interface
InteractionSynchronousAsynchronousAsynchronous
BindingEarly or LateLateLate
Code GenerationAutomaticAutomaticManual
PlatformIndependentIndependentIndependent
Shared StateNoneNoneNone
ConversationStaticStaticDynamic

Tight Coupling Consequences

Conclusions

References

Use a spacebar or arrow keys to navigate