• Computer Science at Politecnico di Milano, Italy
• Ph.D. at ETH Zürich (2004)
• Post-Doc at ETH Zürich
• Software: JOpera: Process Support for more than Web services
• Researcher at IBM Zurich Research Lab (2007)
• Assistant Professor at the Faculty of Informatics (since September 2007)
• Representations: Web

• Computer Science at Technical University of Berlin (TUB) (88-91)
• Ph.D. at ETH Zürich (92-97)
• Post-Doc at ICSI, Berkeley (97/98)
• book on Technical Foundations of the World Wide Web
• Various activities back in Switzerland (98-06)
• teaching at ETH Zürich and FHNW
• working as independent consultant (training, courses, consulting)
• research focus on Web architecture and XML technologies
• Professor at the School of Information (since Fall 2006)
• technical director of the Information and Service Design (ISD) program
• Representations: Web; twitter; blog

The notion of designing services to be loosely coupled is the most important, the most far reaching, and the least understood service characteristic.

Understanding SOA with Web Services, Eric Newcomer and Greg Lomow, Addison-Wesley, 2004

Loose Coupling is the secret sauce of Web services.

Service Orient or Be Doomed!, Jason Bloomberg and Ronald Schmelzer, Wiley, 2006

• Is interface description like WSDL loosely coupled?
• it is because it allows language-independent services to be used
• it is not because generated code breaks when the interface changes
• Coupling depends on perspectives and goals
• there is more than one perspective to look at SOA scenarios
• there is more than one goal to achieve for each of these perspectives
• allow to use various perspectives
• they are not dimensions because they are not completely independent
• it is to better figure out the dependencies

• Your system is loosely coupled? What do you mean by that?
• Your system is tightly coupled? What do you mean by that?
• Coupling is more than just a binary switch
• Apple's Push Service for the iPhone SDK
• pushing notifications is tightly coupled with Apple's infrastructure
• handling notifications is loosely coupled and works like a regular Web app
• iPhone map apps can now be built on an API
• apps are tightly coupled with the iPhone (web-based apps are loosely coupled)
• platform is tightly coupled with the device (high switching costs)
• data flow can be loosely coupled (for example with a RESTful service)

• Centralized Registration is tightly coupled
• services register with a centralized UDDI registry
• clients query the registry to discover new services
• Decentralized Referral is loosely coupled
• clients learn about new services by getting a link from other clients
• services may refer clients to other services

• Naming is one of the core tasks in information systems
• without naming, it is impossible to reliably identify anything
• Naming can be done centrally or independently
• centralized authorities often have a limited (non-global) scope
• federated naming has to insure that names and namespaces do not clash
• Tightly coupled naming binds name to a non-global scope
• names leaving that scope have to be contextualized to remain usable
• Loosely coupled naming uses globally unique names
• names can be safely used without additional scoping/context rules

• Early binding makes it hard to change binding decisions
• Late binding allows more dynamic approach (but may be expensive)
• Binding happens on various levels
• DNS names have to be resolved to IP addresses (CDNs exploit this fact)
• service interfaces could be resolved to service providers
• Discovery can be a compile-time or run-time process
• discovering interface descriptions compiles interfaces into code (tightly coupled)
• using uniform interfaces makes it easier to switch services (loose coupling)
• binding to expected resource representations also increases coupling
• Dynamically switching compile-time bindings is very hard
• in theory possible if the services implement the same technical model
• in practice hard to do reliably, rarely done, and tightly coupled

• Do two services need to be available at the same time in order to successfully interact?
• synchronous → tight coupling
• asynchronous → loose coupling

• APIs hide distribution and heterogeneity
• they also hide the actual protocol required to interact
• apps are tightly coupled with the specific API
• Protocols expose the rules for formats for communications
• they require clients to directly interact with services
• the protocol can be implemented by any service client
• there may/should be some internal separation in the client
• APIs are convenient, but protocols are more important

Die Bedeutung eines Wortes ist sein Gebrauch in der Sprache. (The meaning of a word is its use in language.)

Ludwig Wittgenstein, Philosophical Investigations, 1953

• Shared models often lead to 1:1 serializations of objects
• Shared representations require each peer to map from model to representation
• internally, they can use any model they like
• Model sharing should be limited as much as possible
• shared deep models of data → tight coupling
• representations as surface models → loose coupling

• Trade-off between:
• complexity/reusability of the service interface and
• number of interactions required to service a client
• fine-grained → tight coupling
• many functions, often derived from an implicitly shared model
• coarse-grained → loose coupling
• few functions that focus on exchanging agreed-upon representations

• Shared State requires expensive session tracking
• tight coupling because services need to keep track of clients
• Stateless Interactions keep state either on the client or in resources
• loose coupling because services can treat interactions in isolation

• Services should support versioning
• Compatibility can come in two different flavors
1. backward compatibility: an older client can work with an newer service
2. forward compatibility: a newer client can work with an older service
• Coupling can be associated with various compatibility issues
• tightly coupled scenarios require synchronized updates
• loosely coupled scenarios allow independent versioning

• Code generation takes interface descriptions and generates stubs
• it is based on compile-time binding to interface descriptions
• it creates a horizontal interface on top of the generated code
• Code can be generated/hardcoded for various aspects of service handling
• interaction code handles access functions and handling workflows
• resource handling processes representations in RESTful scenarios
• Extension mechanisms can be used to create less coupling
• browsers can be extended for handling new media types

• Services may provide functionality that requires clients to exchange a set of messages in a certain order
• design-time, explicit conversation description → tight coupling
• run-time, reflective discovery of the conversation → loose coupling

• The Web is only paralleled by the international phone system
• it looked like a step back from sophisticated GUIs and CORBA
• dumbing down GUIs creates powerful network effects
• enterprise IT experiences a crisis caused by weight and rigidity
• Web Services were invented to use the Web
• they were designed and built based on a non-Web architectural style
• in their WS-* flavor, they use the Web as transport layer
• as an alternative, RESTful Web services are built like the Web
• RESTful Web services are not the best solution
• but they may be good enough and a good fit for loose coupling
• How to decide when to use the Web and when to use something else?

• Find more facets and how they affect coupling
• Be more disciplined in exploring facet dependencies
• Come up with a better visualization of facets

• Many service-related decisions can be regarded as integration vs. cooperation
• Distribution and Federation are part of many scenarios
• Information system architectures have different goals
• implementing one integrated logical system with the goal of hiding distribution/heterogeneity
• enabling cooperation among communicating peers with little control of the individual peers
• Architectures and architectural styles are driven by requirements
• there is no such thing as the best architectural style
• there is no such thing as the best architecture
• architectural styles often are implicit by background or tradition