Lecture 11 - CEMS

fortnecessityusefulDéveloppement de logiciels

14 déc. 2013 (il y a 3 années et 7 mois)

78 vue(s)

Software Architecture Patterns
(3)

Web Architecture & Web Services


“The
Web's architecture has very simple principles
revolving around the ideas of
placing a heavy
emphasis

on a
consistent

and
global

identification
mechanism for resources
,
a
standardized

way of
how resource
representations

can be retrieved,
and a standardized way of how resource
representations should be
usable

by using
standardized
media
types
.”

Erik Wilde

The Architecture of the Web
:

Loose coupling vs. tight coupling

o
fewer requirements for cooperation mean fewer potential sources
of problems

o
taking independent developments into consideration (graceful
degradation)

Parsimony may conflict with optimization

o
a fully
backlinked

Web would be a very different hypermedia system

o
modifying resources would be expensive and require considerable
efforts

o
an uncontrolled Web allows failure and innovative development

Programming Languages vs. Frameworks

o
programming languages are very simple and very powerful

o
frameworks are more complex and have some choices built into
them

o
both
can be used to build good
systems

o
framework applications are more likely to not do really innovative
things

The Architecture of the Web
:
Parsimony

Keep it Simple (KISS)


“There
are two ways of constructing a software design: One way
is to make it so simple that there are

obviously

no deficiencies,
and the other way is to make it so complicated that there are
no

obvious

deficiencies. The first method is far more difficult
.”

The Architecture of the Web
:
Parsimony

Simple isn’t always that simple


C. A. R. Hoare
,

The Emperor's Old Clothes, 1980 Turing Award Lecture

o
Web architecture is an additional set of constraints

o
it is not a very complicated set of constraints

o
but it still makes life more complicated than in an unconstrained world

o
it may require a major redesign of an application

o
Technology providers sometimes ignore Web architecture

o
multimedia presentation concepts are often disconnected from the
Web

o
hypermedia researchers often regard the Web as inferior (or not as
hypermedia at all)

o
questions of client capabilities are often ignored (or brushed aside
using statistics)

o
Integration vs. Transport

o
integrating into the Web requires applications to conform to Web
architecture

o
sitting on top of the Web just requires to use HTTP for data transfer

o
many

Web Technologies

are

not

integrated into the Web

o
many

Web Applications

are

not

integrated into the Web

The Architecture of the Web
:
Parsimony

Technology Blinders


The Architecture of the Web
:
Principles

Identification


o
Everything should be identified in a uniform way

o
Identification and access methods evolve over time

o
sms
:

and

tel
:

did not exist when the Web was created

o
Identification and access support evolve over time

o
tel
:

now can be supported by an increasing number of
clients

o
The Web is one huge proof for the power of

network
effects

o
it also is a lesson for many who did not take it seriously
and failed

o
Many URI schemes are named after protocols

o
http:

can be accessed using the

Hypertext Transfer Protocol (HTTP)

o
ftp:

can be accessed using the

File Transfer Protocol (FTP)

o
mailto:

sends electronic mail using the

Simple Mail Transfer Protocol
(SMTP)

o
Some URI schemes do not directly specify a protocol

o
mailto:

sends electronic mail using the

Simple Mail Transfer Protocol
(SMTP)

o
mailto:

may use any other appropriate technology for sending email

o
instead of using protocols directly, they can be used indirectly through
services

o
Some URI schemes have no protocol for dereferencing resources

o
urn:

URIs are abstract names from some namespace

o
urn:ietf:rfc:2648

identifies an IETF standard and not some specific
copy

o
geo:27.988056,86.925278

identifies a physical resource (accessing it is
really hard)

The Architecture of the Web
:
Principles

Interaction




o
Some things on the Web can be inconsistent

o
guaranteeing consistency by design can lead to tight
coupling

o
well
-
defined ways of handling inconsistencies are better
scalable

o
Some things on the Web are not perfect

o
technologies being used in ways not anticipated (XML,
XML Namespaces)

o
company goals vs. the greater good (
browser war
)

o
The ideal Web

vs.

the real Web

o
dealing with a given landscape can introduce additional
constraints

o
handling these constraints should not violate the general
principles

The Architecture of the Web
:
Constraints


o
Design for openness and extensibility is a key factor

o
design for and support evolution and extension and reuse

o
try to be a good Web citizen by embracing reuse and
repurposing

o
Design with the Web in mind

o
use Web standards where appropriate (URIs for identification)

o
even intranet applications typically evolve and should be
designed for the Web

o
Make content visible, accessible, usable, reusable

o
URI design guidelines should be defined and followed

o
think about aggregation and granularity and access to resources

o
use well
-
defined and well
-
documented XML for B2B scenarios

o
reuse existing vocabularies or vocabulary parts whenever
possible

The Architecture of the Web
:
Good Practices


Services on the Web (1)

definition(s)
:

Service
-
oriented architecture

(
SOA
) is a flexible set of
design

principles used during the phases of
systems
development

and
integration

in
computing
. A system
based on a SOA will package functionality as a suite of
interoperable

services

that can be used within multiple
separate systems from several business domains.

wikipedia

A service
-
oriented architecture is essentially a collection of
services. These services communicate with each other.
The communication can involve either simple data passing
or it could involve two or more services coordinating some
activity.

www.service
-
architecture.com

a service in a SOA context is:

a software component that provides behaviour that can
be used by any other component based only on its
interface contract. A service has a network
-
addressable
interface. A service stresses interoperability and a
service may be dynamically discovered and used.

properties of services in a SOA context

services are:

self
-
contained

-
on the client side, no additional software is required (i.e. access via exposed interface)

self
-
describing


-
neither the client nor the server knows or cares about anything besides the format and
content of the request and response messages (loosely coupled application
integration)

can be published, located, and invoked across the network (internet)

-
uses established lightweight standards such as HTTP and it leverages existing
infrastructure

inherently open and standard
-
based

-
open
-
source, vendor agnostic, uses http, xml,
json

etc.

dynamic


-
can automate description and discovery

composable

-
can be chained together and aggregated to provide more complex
behaviours

loosely coupled

-
independent, self
-
contained & encapsulated

provide programmatic access

-

no
gui
, operates at the code level, implementation hidden (encapsulation)

wrap (abstract out) existing applications

-

legacy, stand
-
alone applications can be wrapped with a service interface

service consumer

-

an application, component or other software module that requests a
service; finds the service provider in a service registry, sends a service
request and consumes the service


service provider

-

is a network
-
accessible application or software component that provides
a service to the consumer; the service provider publishes its contract in a
service registry to make itself discoverable to service consumers.


service contract

-

is a specification of the way in which a service consumer can access the
functionality of a service
-

it informs the service consumer of the
acceptable format of a service request; the service contract is stored in a
service registry, allowing service consumers to discover and utilise the
services offered by the provider.


service registry

-

is a network
-
accessible registry that accepts and stores service
contracts from providers and makes them discoverable to service
consumers.

the 4 essential components of a service in a SOA context are:

provider, consumer & registry (directory) in SOAP context:

SOAP is a lightweight protocol intended for
exchanging structured information in a
decentralized, distributed environment. SOAP
uses XML technologies to define an extensible
messaging framework, which provides a message
construct that can be exchanged over a variety of
underlying protocols. The framework has been
designed to be independent of any particular
programming model and other implementation
-
specific semantics.

Simple Object Access Protocol (SOAP):

SOAP message consists of three parts:

-

SOAP Envelope

-

SOAP Header (optional)

-

SOAP Body

SOAP message format:

<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
> <soap:Header> <!
--

optional
--
>



<!
--

header blocks go here...
--
>



</soap:Header>


<soap:Body>



<!
--

payload or fault element goes here...
--
>



</soap:Body>

</soap:Envelope>

POST /InStock HTTP/1.1

Host: www.example.org

Content
-
Type: application/soap+xml; charset=utf
-
8

Content
-
Length: nnn


<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap
-
envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap
-
encoding">


<soap:Body xmlns:m="http://www.example.org/stock">



<m:GetStockPrice>



<m:StockName>IBM</m:StockName>



</m:GetStockPrice>

</soap:Body>


</soap:Envelope>

example SOAP message (query stock price):

HTTP/1.1 200 OK

Content
-
Type: application/soap+xml; charset=utf
-
8

Content
-
Length: nnn


<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap
-
envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap
-
encoding">


<soap:Body xmlns:m="http://www.example.org/stock">



<m:GetStockPriceResponse>



<m:Price>34.5</m:Price>



</m:GetStockPriceResponse>

</soap:Body>


</soap:Envelope>

example SOAP response (stock price):

Web Service Description Language (WSDL) &
Universal Discovery, Description & Integration (UDDI)

wsdl

-
is an xml vocabulary for describing a web
service, where the service is located, the
protocols, operations and methods the
service supports and the parameters it
expects and responds with


uddi

-
is a searchable directory that stores
information about web services and the
interfaces to those services described by
wsdl


relationship between WSDL, UDDI, SOAP & WS

SOA is evolving
-

from SOA to WOA:

a
lphabet soup
-

service oriented, web oriented and
resource oriented architectures: