The notion of designing services to be loosely coupled is the most important, the most far reaching, and the least understood service characteristic.
WSDL/SOAP supports interoperability between heterogeneous platforms and programming languages: loosely coupled?
WSDL interface changes may break clients: tightly coupled?
How does the client locate the service?
How does the client address a service features?
Names outside of their scope need to be contextualized
Unique identifiers in a global address space
How deeply must clients understand a service?
Automatic WSDL generators
Leakage of internal data models/schemas
Standardized message formats mapped to/from internal model
How precisely services satisfy their clients?
API targets specific clients
HTTP GET, PUT, DELETE, POST
Generic API targeting all possible clients
When do clients interact with the service?
Clients and services must be available at the same time
Store and Forward: clients survive temporary service outages
When do clients locate the service?
Who writes the code to invoke a service?
RPC IDL, WSDL
Client recompilation is needed when service description changes
Clients are manually written without relying on any formal service description
Does interoperability require clients and services to use the same middleware platform or programming language?
DCOM, Java RMI
CORBA, WSDL/SOAP, JSON/HTTP
Are multiple interactions from the same client independent from the previous ones?
Service scaling limited by total number of connected clients
HTTP without session cookies
Service scaling limited by number of active client requests
How do clients know how to use a service?
Explicit description of the entire conversation
Decide next step based on results of the previous
|Binding||Early or Late||Late||Late|
Use a spacebar or arrow keys to navigate