Component interoperation style

A paradigm, exemplar or pattern for how components communicate. Four styles, varying from tightly-coupled to loosely-coupled, are DO, SOA, REST and EDA.

Distributed Objects style (DO)

A component interoperation paradigm in which an object on one computer invokes an operation on another object on another computer.

In the classic distributed objects style:

·         the invocation is an object-method pair

·         the server views the invocation as synchronous

·         a connection is maintained while the service request is processed

·         the server component is a stateful object (persists between operations).

(The idea is to scale up object-oriented program design from one computer to many - the wider system looks and behaves like one object-oriented program - the programmer writes code as though all the objects are local, and call each other directly.)

Service-Oriented Architecture style (SOA)

A component interoperation paradigm in which a process on one computer invokes a process on a remote computer by passing a message.

This style is a contrast to the DO style, meaning that:

·         the invocation can be a plain operation call rather than an object-method pair

·         the server views the invocation as asynchronous

·         no connection is maintained while the service request is processed

·         the server component is a stateless.

SOA is commonly associated with the use of web services, though these can be used to implement other styles.

Representational State Transfer style (REST)

A component interoperation paradigm in which a client identifies resources using URLs and processes those resources using only the generic operations in HTTP API.

A resource is anything can be found at a URL, including text and executable code. The generic HTTP operations are comparable with the operations Create, Read, Update and Delete on rows of database tables. A client does not need to know the extent or structure of the resource set.

A resource representation usually contains URLs that enable the client to navigate to related resources.

A client does not need to know the names of any operations specific to any resource. A client can retrieve a representation of any resource using the GET operation, and update that resource using PUT, POST and DELETE operations.

Event-Driven Architecture style (EDA)

A component interoperation paradigm in which any number of components can subscribe to receive an event or message published by another component.  The publisher and subscriber components are so loosely coupled that they not only operate asynchronously but also need know nothing of each other.

A subscriber must make themselves known to a publisher at subscription-time, but placing a broker between client and server removes even this one-time contact.