avancier methods (am) - grahamberrisford.comgrahamberrisford.com/am 2 methods support... · restful...

Avancier

Copyright Avancier Limited 2007-2016

Avancier Methods (AM) Software Architecture

Decoupling - part 2 (REST, EDA etc.)

It is illegal to copy, share or show this document

(or other document published at http://avancier.co.uk)

without the written permission of the copyright holder

http://avancier.co.uk/

Avancier Principles example – a global organisation

1. Separate concerns (for flexibility and maintainability)

2. Build for competitive advantage / Buy for competitive parity

3. Encapsulate components (for CBD and SOA)

4. Use open APIs for inter-component communication

5. Loosely couple components (for flexibility and availability)

6. Use Event-Driven Architecture for broadcast updates

7. Maintain a single source of truth

8. Design for response time / latency

9. Design for graceful failure – informing users

10. Web first: design for browser and client device independence


Directives

Principle !

Avancier


Decoupling part 1 - recap

Feature Early OO design

presumptions Recent SOA design presumptions

Naming Clients use object identifiers

One name space

Clients use domain names

Multiple name spaces behind interfaces

Paradigm

Stateful objects/modules

Reuse by OO inheritance

Intelligent domain objects

Stateless objects/modules

Reuse by delegation

Intelligent process controllers

Time Request-reply invocations

Blocking servers

Asynchronous messaging

Non-blocking servers

Location Remember remote addresses Use brokers/directories/facades

Tightly-coupled Loosely-coupled Faster / Simpler More Flexible

COBOL

modules

Java objects

CORBA

Web

Services

Avancier Representational State Transfer (REST)

Roy Fielding defined REST

We want application components to communicate across a network,

and we use internet protocols

Why not capitalise on what the internet is good at?

Naming accessible resources

Locating remote resources using a domain name

Communication using protocols such as HTTP (and others perhaps)

Representation of component state using hypermedia

a nonlinear medium of information which includes graphics, audio, video, plain

text and hyperlinks.

Copyright Avancier 2007-2016

Avancier RESTful clients

Every source/sender and target/receiver component is given a

domain name

RESTful

Clients call server components using network protocol operation names

HTTP: get, put, post and delete

“This enables a distributed system to have desirable properties, such as

performance, scalability, simplicity, modifiability, visibility, portability, and reliability.”


Avancier Typical RESTful web API HTTP methods (Wikipedia)


Resource LIST ITEM

GET

(read)

List Retrieve

PUT

(update)

Replace Replace.

POST

(create)

Create Not generally used.

DELETE

(delete)

Delete. Delete

Avancier Typical RESTful web API HTTP methods (Wikipedia)


Resource Collection URI, such as

http://example.com/resources

Element URI, such as

http://example.com/resources/item17

GET

(read)

List the URIs and perhaps other details

of the collection's members.

Retrieve a representation of the addressed

member of the collection, expressed in an

appropriate Internet media type.

PUT

(update)

Replace the entire collection with

another collection.

Replace the addressed member of the

collection, or if it doesn't exist, create it.

POST

(create)

Create a new entry in the collection.

The new entry's URI is assigned

automatically and is usually returned by

the operation.

Not generally used.

Treat the addressed member as a collection in

its own right and create a new entry in it.

DELETE

(delete)

Delete the entire collection. Delete the addressed member of the collection.

Avancier


Traditional server-side component: one nouns, many verbs

Client -side Facade

listUsers()

addUser()

getUser()

updateUser()

removeUser()

findUser()

listLocations()

getLocation()

findLocation()

addLocation()

removeLocation()

updateLocation()

addAsset ()

assignAsset ()

Server-side

Asset Manager

listUsers()

addUser()

getUser()

updateUser()

removeUser()

findUser()

listLocations()

getLocation()

findLocation()

addLocation()

removeLocation()

updateLocation()

addAsset ()

assignAsset ()

Avancier

Client-side Facade

listUsers()

addUser()

getUser()

updateUser()

removeUser()

findUser()

listLocations()

getLocation()

findLocation()

addLocation()

removeLocation()

updateLocation()

addAsset ()

assignAsset ()


RESTful client: uses HTTP operation names BUT sends a parameter to qualify it

Server-side

Asset Manager

listUsers()

addUser()

getUser()

updateUser()

removeUser()

findUser()

listLocations()

getLocation()

findLocation()

addLocation()

removeLocation()

updateLocation()

addAsset ()

assignAsset ()

GET

POST

GET

POST

DELETE

GET

GET

GET

GET

POST

DELETE

POST

POST

POST

Avancier


REST-compliant servers: each has 1 noun and 4 verbs

Server-side

Domain names for the nouns

http://example.com/users/ (list users)

http://example.com/user/user (one per user)

http://example.com/user (get user form)

Internet operations for the verbs

userResource = new Resource('http://example.com/users/001')

userResource.delete()

User List

Put

Get

Post

Delete

User

Put

Get

Post

Delete

Loc List

Put

Get

Post

Delete

Loc

Put

Get

Post

Delete

User Search

Form

Put

Get

Post

Delete

Loc Search

Form

Put

Get

Post

Delete

Asset

Put

Get

Post

Delete

Client-side Facade

listUsers()

addUser()

getUser()

updateUser()

removeUser()

findUser()

listLocations()

getLocation()

findLocation()

addLocation()

removeLocation()

updateLocation()

addAsset ()

assignAsset ()

GET

POST

GET

POST

DELETE

GET

GET

GET

GET

POST

DELETE

POST

POST

POST

http://example.com/users/

http://example.com/user/user

Avancier RESTful and REST-compliant

Every source/sender and target/receiver component is given a

domain name

RESTful

Clients call server components using network protocol operation names

HTTP: get, put, post and delete

REST-compliant

Server components offer only the operations above

With no paramaterised variations


Avancier RESTful and REST-compliant Web Services

A Web Service

Has a URI

such as http://example.com/resources

Uses internet-friendly I/O data flow formats

Usually XML or JSON

An arbitrary Web Service

Offers operations using HTTP methods

e.g. GET, PUT, POST, or DELETE

But offers any number of operations (parameterised)

A REST-compliant Web service

Offers a uniform set of "stateless" operations.


Avancier


Would you use REST where you need

Fast response time?

High availability?

Guaranteed message delivery?

Transaction rollback?

Security?

Avancier


Would you use REST where you need

Fast response time?

It depends what you compare it with

High availability?

Probably

Guaranteed message delivery?

No (unless you do it by hand)

Transaction rollback?

No (unless you do it by hand)

Security?

HTTP is not secure

Avancier


More decoupling varieties

Feature Tight coupling Decoupling techniques

Data types Complex data types Simple data types

Version Version dependency Design to avoid version dependence

Apply the open-closed principle

Protocol Protocol dependency Design for multiple protocols

Integrity

constraints ACID transactions

BASE: compensating transactions and

eventual consistency

Often faster and/or simpler

Often more flexible, but more complex

Avancier Decoupling from complex data type



Data types Complex data types

Date: DD/MM/YY

Address: 5 line address

Simple data types

Date: days, months and years

Address: premises, road, town, county/state,

country

Faster and simpler More flexible and complex

Avancier Decoupling by version






More flexible and complex

Avancier Decoupling from integrity/consistency


Integrity

constraints

ACID transactions

Impractical when one process

spans distributed

components

Or process volumes are

extremely high



Decouples transactions within a process and

performs them separately within a longer

workflow

•improves availability of process start

•improves scalability

•at the cost of consistency

•requires compensating transactions

Most business are not like ebay and

Amazon!


Simpler More flexible and complex

Avancier


Decoupling part 1 + 2


Naming Clients use object identifiers

One name space

Clients use domain names

Multiple name spaces behind interfaces

Paradigm

Stateful objects/modules

Reuse by OO inheritance

Intelligent domain objects

Stateless objects/modules

Reuse by delegation

Intelligent process controllers

Time Request-reply invocations

Blocking servers

Asynchronous messaging


Location Remember remote addresses Use brokers/directories/facades

Data types Complex data types Simple data types




Integrity

constraints ACID transactions



Often faster and/or simpler

Often more flexible, but more complex

Avancier Finally, Event-Driven Architecture (EDA)

We’ve mostly been discussing request-reply transactions

What about event notification messages?


Avancier

Observer Observer

Observer (notification, pub/sub) pattern

Observer

A subject

notifies observers of changes to its state

Observers

register with the subject to be notified of changes.

unregister when no longer interested

Event-Driven Architecture (EDA)

Inserts a publisher (broker) between Subjects

and Observers, and so decouples

Copyright Avancier 2013

2 Publish event Subject

Observer 1 Subscribe

Observer Observer

3 Publish event

Publisher (Broker)

Event source and/or

Subscriber

1 Subscribe

2 Notify of event

Compare with EDA (hidden)

Avancier

r r r r

Event-Driven Architecture (EDA)

Two styles


r r

Shared Data

Space

Receiver Sender

r r Publisher Subscriber Event

Source

Topic A

Topic B

Topic C

Push

Pull

Push

Pull

Avancier

r r


Communication styles – summary overview

Client Server

RPC

Client Server

Intro Agent

Message Broker

Server Client

Shared Data

Space

Receiver Sender

Connected Disconnected

Active

Mediator

Passive

Mediator

Communication

Style

Point to Point Introduction

Agent

Under the covers, all communication is point

to point!

Directory

Message

Broker

Message

Bus

r r Publisher Subscriber Event

Source

Request-reply

Event broadcast

Event broadcast

Avancier

Copyright Avancier Limited 2013

Summary

Communication styles

Tightly-coupled Loosely-coupled

LPC RPC DO SOAP REST EDA

SOA

Interoperation styles

ORB XML WS HTTP DNS Pub/Sub Shared data space

Domain names Stateless modules Message passing


Object identifiers Stateful objects

Request-reply invocations Blocking servers

Interoperate using via intermediary pub/sub or

data space

Interoperate using domain names and the

operations of an internet protocol

Connected Disconnected

Indirect Broker

Active

Mediator

Shared space

Passive

Mediator

Communication

Style

Point to Point

Direct broker

Introduction

Agent

Message

Broker

Message

Bus

Avancier Footnotes

Left overs


Avancier

Modular design

Procedural & OO variations

Decoupling of technology

Decoupling of location

Decoupling of acquaintance

Decoupling of activity

A questionable family tree of software architecture concepts


SOA?

EDA

Object-Oriented Design (OOD)

Client-server Computing

Modular design

Programming to an interface

Point-to-Point distribution

Direct Broker Introduction Agent

Distributed Objects (DO)

Active Mediator Message Broker

Active Mediator Message Bus

Representational State Transfer (REST)

Web protocols and DNS

RPC, RDA

ORB

Publish and Subscribe

Mediator

Separation of user views from data sources

Inheritance and OOPLs

Interface Definition Languages

Encapsulation

Directories

Passive Mediator Shared Data Space

Avancier The architectural properties of REST

Client–server (separation of concerns)

Servers and clients can be developed and replaced independently, as long as the interface

between them is not altered.

Stateless

A server holds no client context between requests

Session state is held in the client, or in a database.

The client sends a request when it is ready to transition to a new state.

While requests are outstanding, the client is considered to be in transition.

The representation returned contains links the client may use initiate a new state-transition.

Cacheable

Responses must define themselves as cacheable, or not, to prevent clients from reusing stale or

inappropriate data

Layered system

A client cannot tell whether it is connected directly to the end server, or to an intermediary along

the way. Intermediary servers may improve system scalability load balancing, providing shared

caches and enforce security policies.

Code on demand (optional)

Servers can temporarily extend or customize the functionality of a client by the transfer of

executable code (e.g. Java applets and client-side scripts such as JavaScript.)


Avancier Also, Uniform interface

Identification of resources

Requests identify resources, usually using URIs

A server may represent its state in HTML, XML or JSON (none of which are the server's internal

representation)

Manipulation of resources through these representations

When a client holds a representation of a resource, including any metadata attached, it has

enough information to modify or delete the resource.

Self-descriptive messages

Each message includes enough information to describe how to process the message.

Responses also explicitly indicate their cacheability.

Hypermedia as the engine of application state

Clients make state transitions only through actions that are dynamically identified within

hypermedia by the server (e.g., by hyperlinks within hypertext).

A client does not assume that any particular action is available for any particular resources

beyond those described in representations previously received from the server.


Avancier


Interoperation styles versus technologies

Different interoperation styles have been topical at different times and places.

There has been drift from more closely coupled to more loosely coupled.

How to differentiate styles from the technologies?

DO, SOA and EDA as styles

We distinguish styles by implications they have for concepts such as object references, statefulness, synchronicity and message passing.

This make the concepts examinable without implying any particular standard or technology (XML, SOAP, HTTP, WS or ESB).

REST - part style - part technology

REST does come with presumptions about using universal internet protocols and technologies.

REST is usually contrasted with SOAP rather than SOA.

REST enables a loosely–coupled SOA that comes with various limitations.

avancier methods (am) - grahamberrisford.comgrahamberrisford.com/am 2 methods support... · restful...

Documents