service oriented architectures and web services

Service Oriented Architecturesand Web Services

Prof. Cesare PautassoFaculty of InformaticsUniversity of Lugano

[email protected]://www.pautasso.info@pautasso

http://www.pautasso.info/�

©2010 - Cesare Pautasso 2

Prof. Cesare Pautasso Ph.D. at ETH Zürich (2004) Post-Doc at ETH Zürich in the Systems (IKS) Group Researcher at IBM Zurich Research Lab (2007) Assistant Professor at the new Faculty of Informatics,

University of Lugano (USI), Switzerland (since September 2007)

Research Interests: Software Architecture and Software Composition Business Process Management Service Oriented Architectures and Web Services Web 2.0 Mashups and RESTful Web Services Autonomic Computing Grid Computing (Scientific Workflow Management)

More Information: http://www.pautasso.info/ Follow me on: http://twitter.com/pautasso/

http://www.ethz.ch/index_EN�

http://www.iks.inf.ethz.ch/�

http://www.zurich.ibm.com/�

http://www.inf.unisi.ch/�

http://www.unisi.ch/�

http://www.pautasso.info/�

http://twitter.com/pautasso/�

Marcin Nowak

Saeed Aghaee

Dr. Achille PeternierDaniele Bonetta


Software Architecture and Design

Software Engineering

Software Design and Evolution

I

II

III

Master Software Design


Once upon a time


Once upon a time

Software used to come in boxes


Once upon a time

Today, software runs in the clouds


Once upon a timeCloud Operating System?


SOA & WS

The Web(REST)

SoftwareArchitecture

Componentsvs. Services

Connectorsand Integration

Today’s plan


Context Databases

Networking

Software Engineering

Programming Languages

Service Oriented Architectures

Web Services

How to build applicationsfrom scratch

How to reuse and compose two or more existing applications


What is the problem

?

Vermarktung Angebotserstellung &Leistungsbereitstellung(Fulfillment)

Leistungserbringung(Assurance)

Fakturierung(Billing)

Operations

OTTO, Windows, Lotus Notes

OMSextern FX

ESW OPM

PeP

LSM Insight

CSS

Tuco

BSK ES Archiv AD

PerisDirex SAP

BASKAI FX

BDM

MIDAS

TIS

TIS IPP+

TTS ARS TOPM

esBill

PA

DWH TTSextern FX

MERS

ORCA

CORB

A

FTP

CO

RBA

FTP

SCHONNotes

FTP

SIF

FTP

CORBA

CORBA

FTP

FTP

CORBA

FTP

FTP

MQ

MQ

BW

PA, zLinux


Integration (by hand…)


Once upon a timeIntegration (by hand…)


Integration (…with SOA)


Integration Example

©2009-2010 - Cesare Pautasso, Erik Wilde 17

Integration (… with JOpera)

firmitatis utilitatis venustatis

Durability: the building should last for a long time without falling down on the people inside it

Utility: the building should be useful for the people living in it

Beauty: the building should look good and raise the spirits of its inhabitants

Vitruvio, De Architectura, 23BC

De Architectura


Software Architecture

As the size and complexity of a software system increase, the principal design decisions and the global structure of a system become more important than the selection of specific algorithms and data structures in order to determine its quality.


Large Software Project Lines of code: 50 Million Number of developers: 2000 Time to compile: 24 hours Time to ship: 5 years (from previous release)

0

20

40

60

1990 1995 2000 2005 2010

Mill

ions

of L

OC


Abstraction Layers

Application

Operating System

Hardware


Application

Operating System

Hardware

Infrastructure as a Service

Platformas a

Service

Softwareas a Service

Layered Architectural Style


Hardware

Hardware

Operating System

Platformas a

Service



ComponentReusable unit of composition

Made out of smallercomponents

Can be composedinto larger systems


ConnectorGeneric enabler of composition

Transfer signals(data, control)between ports

Plug into matchingcomponent ports


Services

Components

New Abstraction Levels

ObjectsC++ JavaC#

J2EE.NET

Eclipse

Web ServicesXMLREST


Component vs. Service: ExampleMap Drawing Component

Map getMap(lat, long, zoom)

(lat, long) centers the map on any location on the planet Earth and zoom can show details up to 1m precision

What is the “size” of this component?

How to deliver the component to customers so that it can be reused in their own applications?


Business Model How to sell a component? Component developers

charge on a per-deployment basis: whenever a new client downloads the component.

Component upgrades may be sold separately to generate a revenue stream

Components can be licensed to be redistributed within larger systems and developers can demand royalties from the revenue of the final product

How to sell a service? Service providers can

charge on a per-call basis: each time an existing client interacts with a service by exchanging a new message.

Service providers can charge a monthly/yearlyflat access fee

Services can be made available for free and providers can support them with advertisingrevenue

Component vs. Service:


IT as a “manufacturing” industry (ship software components)

IT as a “service” industry (publish software on the Web)


Correctness & Verification

function f(x) {

…

return y;

}

while(true)

{

…

}

Will it terminate?Will it run forever?


Service Lifecycle

DesignSystemArchitecture

Deploy

Change (FunctionalNon-Functional)

DefineInterfaceContracts

Refactor

Test

Run,Manage,Operate

BuildServices


More than 500 million active users

30 billion pieces of content

20 million applications installed every day

Launched February 2004

Around the year 2010…

Google answers 5 billion API queries every day

Amazon S3 stores over 100 billion objects

75% of all the traffic (3 billion calls/day) of Twitter goes through its API


From

Tom

as V

itvar

, Mas

hups

2010

Key

note


Component vs. Service: Technology

To be used a component must: be packaged to be deployed

as part of some larger application system

fit with the existing framework used to develop the system

There are many component frameworks available for building distributed systems (e.g., J2EE, DCOM, .NET, CORBA).

The problem is: they are not compatible (as an exercise try to use a .NET assembly to make an Eclipse plug-in and see what happens)

To be used a service must: be published on the Web

(once) advertise its description and

location to potential clients across the Web so that they can access it using standard protocols

Like components, services can be reused, composed into larger systems and (of course) they can be found on the Web.

Unlike components, services do not have to be downloaded and deployed in order to be used by clients. Instead, a client may discover and access their functionality by using standard protocols (WSDL, SOAP, UDDI) based on XML standards.


What is Integration?

+ = ? New applications are built out of the composition of existing ones

Prefer to reuse, extend, and recombine existing systems as opposed to develop new ones from scratch

State

LogicDisplay

State

Logic

Application 1

Display

Application 2


Why integration matters Useful information systems evolve over time by growing in size and by

incorporating functionality of existing standalone systems. Applications originally intended to operate separately, are required to interoperate with others later on.

Technology change affects all layers, legacy does not go away so easily.

The architecture of the enterprise information system depends on constraints related to the technology but also to the organization.

In the case of B2B, each company owns its information system and will not open it up more than strictly necessary as it is part of their competitive advantage. For example, not all business processes are going to be shared, as business processes are mostly kept secret.

Within an enterprise, each department may have its own IT infrastructure, systems and databases which are maintained independently. Integrating them may bring additional value through cost reduction to the company.

Mergers, acquisitions and spin-offs leave a long lasting trace in the information systems of the corresponding companies


Challenges of Integration Many problems to be addressed in Enterprise Application Integration

stem from having to integrate standalone applications which have been developed independently, operate autonomously, and were not originally indended to be integrated with one another.

Heterogeneous – each application implements its own data model. Concepts may be shared, but representation mismatches are to be expected. Mappings and transformations are required.

Autonomous – applications update their state independently without coordinating with each other. The systems to be integrated are maintained independently and upgraded at different times.

Distributed – in the worst case, every application runs on a completely separate environment, e.g., database storage is not shared among applications. Message-based communication through the network is the only possibility to exchange information.

This part is taken from C. Bussler, B2B Integration, Springer, 2004


How to mix software not designed to be integrated?

Integration is bottom up


Integration Techniques Given two (or more)

existing applications, how can you compose them?

It depends on whether you can change the applications to make them talk together.

How much integration can be done automatically?

Examples: Manual Data Transfer Manual (with Copy & Paste) File based integration (Hot Folder) API extraction and publishing Command line scripting Wrap existing software Screen Scraping Data transformation and conversion Message based integration Point to Point Centralized, Peer to Peer Mashup


Layers as integration points

Application

DB

UI

Integration at the presentation layer (screen scraping) is always possible, but the least recommended.

Well designed applications have an API that we can call directly.

It is also possibleto bypass the application and directly access its database

Connectors


RPC

Remote Procedure Call

Call

Procedure/Function Calls are the easiest to program with connector.

They take a basic programming language construct and make it available across the network (Remote Procedure Call) to connect distributed components

Remote calls are often used within the client/server architectural style, but call-backs are also used in event-oriented styles for notifications


Hot Folder

File Transfer(Hot Folder)

WriteCopy

WatchRead

Transferring files does not require to modify components

A component writes a file, which is then copied on a different host, and fed as input into a different component

The transfers can be batched with a certain frequency


Shared Database

Shared Database

CreateRead

UpdateDelete

Sharing a common database does not require to modify components, if they all can support the same schema

Components can communicate by creating, updating and reading entries in the database, which can safely handles the concurrency


Bus

Message Bus

PublishSubscribe A message bus connects a variable number of components,

which are decoupled from one another. Components act as message sources by publishing messages

into the bus; Components act as message sinks by subscribing to message types (or properties based on the actual content)

The bus can route, queue, buffer, transform and deliver messages to one or more recipients

The “enterprise” service bus is used to implement the SOA style


Web (RESTful Web services)

GetPut

DeletePost Web

The Web is the connector used in the REST (Representational State Transfer) architectural style

Components may reliably transfer state among themselves using the GET, PUT, DELETE primitives. POST is used for unsafe interactions.


Software Connectors for SOA

REST

WS-

*RPC ESB

WWW


Interface Description Languages (IDL)

CORBAIDLRPC

IDL

DCOMMIDL

Java Interfaces

WSDL1.0


Component Interoperability

EnterpriseJava

BeansDCOM

Objects

LegacyCOBOL

Programs

.NET Assemblies

CORBAObjects

WebServices

Due to lack of interoperability, it is not always possible to build a distributed system using heterogeneous components


Web Services for Interoperability If the components are published as Web services, they can

interoperate across different component frameworks. (Interoperability through Wrapping)

JavaBean

DCOMObject

LegacyCOBOL

Program

.NET Assembly

CORBAObject

WebService


Interoperability

Component(Platform A)

Adapter(Platform A)

Component(PlatformB)

Components of different platforms can interoperate throughadapters mapping the internal message format to a common(standard) representation

Adapter(Platform B)


Is this a Web Service?


Web Sites (1992)

HTTP

HTMLWeb Browser

Web Server

(HTTP)

SOAP

ServerClient XMLWSDL

WS-* Web Services (2000)


RESTful Web Services (2007)

Client HTTP

PO-XM

L

ATOM

JSON

Web Server

WADL

WS-* Web Services (2000)

(HTTP)

SOAP

ServerClient XMLWSDL


Extending the Web with Services

Back-end Systems and Databases

CGI JavaServletPHP

Web Server

Web Browser

HTML/HTTP

ASP.NET

SOAP, XML or JSON/HTTP

WS Client

add yourfavourite

here


Defining Web Services W3C defined Web services in the early 2000s as:

a software application identified by a URI,whose interfaces and bindings are capable of being defined, described and discovered as

XML artifacts.

A Web service supports direct interactions with other software agents using XML-based messages exchanged via the Internet


Properties of Web Services The W3C definition emphasizes different aspects: In order to be accessed by clients, a Web Service should be

defined, described and discovered. XML is the foundation for all standards that are going to be

used (SOAP, WSDL, UDDI) to do so. Web services are intended to be used as components that

can be readily integrated into more complex distributed applications.

Web services are meant for software based consumption (clients are programs)

Web-based applications are meant to be used by humans equipped with a WWW browser(clients are users)


Web Services and SOA Web Services can also be seen as the technology used to implement

service oriented architectures (SOA) SOA are about building distributed applications out of the

interconnection of loosely coupled, heterogeneous services. To do so, interoperability is paramount and Web services are meant to

deliver it. In a service oriented architecture services are:

Interoperable – Services seamlessly work with one another and can be easily composed into complex applications

Heterogeneous – Standard service interfaces virtualize the underlying mechanisms and protocols of the middleware platform

Distributed – Services can (in principle) be located across the Web Autonomous – Services belong to different organizations and may

evolve independently of each other Loosely Coupled – Services should make very few assumptions

about one another so that they can be easily moved, replaced and even interact without being available at the same time.


Web Services Architecture A popular interpretation of Web

services is based on IBM’s Web service architecture based on three elements:

1. Service requester: The potential user of a service (the client)

2. Service provider: The entity that implements the service and offers to carry it out on behalf of the requester (the server)

3. Service registry: A place where available services are listed and that allows providers to advertise their services and requesters to lookup and query for services


Web Service Architecture

ServiceRequester

ServiceProvider

Clients use the Registry to lookup published servicedescriptions that will enable them to perform the actualservice invocation with the provider

ServiceRegistry

ServiceDescription 1. Publish

2. Lookup

3. Invoke


Main Web Services Standards

UDDI

SOAP

WSDL

The Web service architecture proposed by IBM is based on two key concepts: architecture of existing

synchronous middleware platforms

current specifications of SOAP, UDDI and WSDL

The architecture has a remarkable client/server flavor

It reflects only what can be done with: SOAP (Simple Object

Access Protocol) UDDI (Universal Description

and Discovery Protocol) WSDL (Web Services

Description Language)


What is SOAP? The W3C started working on SOAP in 1999. The current W3C

recommendation is Version 1.2 Originally: Simple Object Access Protocol SOAP covers the following main areas:

Message construct: A message format for one-way communication describing how a message can be packed into an XML document

Processing model: rules for processing a SOAP message and a simple classification of the entities involved in processing a SOAP message. Which parts of the messages should be read by whom and how to react in case the content is not understood

Extensibility Model: How the basic message construct can be extended with application specific constructs

Protocol binding framework: Allows SOAP messages to be transported using different protocols (HTTP, SMTP, …)• A concrete binding for HTTP

Conventions on how to turn an RPC call into a SOAP message and back as well as how to implement the RPC style of interaction


SOAP Envelope

SOAP header

Transactionalcontext

SOAP Body

Input parameter 1

Input parameter 2

Name of Procedure

HTTP Request

SOAP Envelope

SOAP header

Transactionalcontext

SOAP Body

Return parameter

HTTP Response

SERVICE REQUESTER SERVICE PROVIDER

RPC call

HTT

P en

gine

SOAPengine

Procedure

HTT

P en

gine

SOAPengine

SOAP RPC


SOAP Request Response XML<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body><ns2:sayHi xmlns:ns2="http://test.inf.usi.ch/">

<text>World</text></ns2:sayHi>

</soap:Body></soap:Envelope>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body>

<ns2:sayHiResponse xmlns:ns2="http://test.inf.usi.ch/"><result>Hello World</result>

</ns2:sayHiResponse></soap:Body>

</soap:Envelope>


What is WSDL? The Web Services Description Language specification is in version

1.1 (March 2001) and currently under revision (v2.0 is in the candidate recommendation stage, Jan 2006)

WSDL 1.1 discusses how to describe the different parts that comprise a Web service interface the type system used to describe the service data model (XML

Schema) the messages involved in the interaction with the service the individual operations composed of 4 possible message

exchange patterns the sets of operations that constitute a service the mapping to a transport protocol for the messages the location where the service provider resides groups of locations that can be used to access the same service

It also includes specification indicating how to bind WSDL to the SOAP, HTTP (POST/GET) and MIME protocols


Elements of WSDL (1.1)WSDL document

Types (type information for the document, e.g., XML Schema)

Message 1 Message 4Message 3Message 2

Operation 1 Operation 3Operation 2

Message 6Message 5

Port Type (abstract service)

binding 1

port 1

binding 2

port 2

binding 3

port 3

binding 4

port 4

Service (the interface in all its available implementations)

Abst

ract

des

crip

tion

of th

e se

rvic

eCo

ncre

te d

escr

iptio

n of

the

serv

ice


Hello World WSDL<?xml version='1.0' encoding='UTF-8'?><wsdl:definitions name="HelloWorld" targetNamespace="http://test.inf.usi.ch/" xmlns:ns1="http://schemas.xmlsoap.org/soap/http"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://test.inf.usi.ch/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<wsdl:types> <xs:schema elementFormDefault="unqualified" targetNamespace="http://test.inf.usi.ch/" version="1.0" xmlns:tns="http://test.inf.usi.ch/" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="sayHi" type="tns:sayHi" /><xs:element name="sayHiResponse" type="tns:sayHiResponse" /> <xs:complexType name="sayHi"> <xs:sequence> <xs:element minOccurs="0" name="text" type="xs:string" /> </xs:sequence> </xs:complexType> <xs:complexType name="sayHiResponse"> <xs:sequence> <xs:element minOccurs="0" name="result" type="xs:string" /> </xs:sequence> </xs:complexType> </xs:schema>

</wsdl:types> <wsdl:message name="sayHiResponse"> <wsdl:part element="tns:sayHiResponse" name="parameters"> </wsdl:part> </wsdl:message> <wsdl:message name="sayHi"> <wsdl:part element="tns:sayHi" name="parameters"> </wsdl:part> </wsdl:message> <wsdl:portType name="Contract">

<wsdl:operation name="sayHi"> <wsdl:input message="tns:sayHi" name="sayHi"> </wsdl:input> <wsdl:output message="tns:sayHiResponse" name="sayHiResponse"> </wsdl:output>

</wsdl:operation> </wsdl:portType><wsdl:binding name="HelloWorldSoapBinding" type="tns:Contract">

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> <wsdl:operation name="sayHi">

<soap:operation soapAction="" style="document" /> <wsdl:input name="sayHi"> <soap:body use="literal" /> </wsdl:input><wsdl:output name="sayHiResponse"> <soap:body use="literal" /> </wsdl:output>

</wsdl:operation></wsdl:binding><wsdl:service name="HelloWorld">

<wsdl:port binding="tns:HelloWorldSoapBinding" name="ServicePort"><soap:address location="http://localhost:9000/helloWorld" /> </wsdl:port>

</wsdl:service> </wsdl:definitions>












</wsdl:service> </wsdl:definitions>

Types (type information for the document, e.g., XML Schema)

Request and Response Messages

Abstract Port Type and Operations

Concrete SOAP Binding

Service HTTP Endpoint












</wsdl:service> </wsdl:definitions> result = sayHi(text)


WSDL as an IDL WSDL can be best understood when we approach it as an XML version of

an IDL that also covers the aspects related to integration through the Internet and the added complexity of Web services

An IDL in conventional middleware and enterprise application integration platforms has several purposes: description of the interfaces of the services provided (e.g., RPC) serve as an intermediate representation for bridging heterogeneity by

providing a mapping of the native data types to the intermediate representation associated to the IDL in question

serve as the basis for development through an IDL compiler that produces stubs and libraries that can be use to develop the application

A conventional IDL does not include information such as: location of the service (implicit in the platform and found through

static or dynamic binding) different bindings (typically an IDL is bound to a transport protocol) sets of operations (since an interface defines a single access point

and there is no such a thing as a sequence of operations involved in the same service)


What is UDDI? Universal Description, Discovery

and Integration Services offered through the

Internet to other companies require much more information than a typical middleware service

In many middleware and EAI efforts, the same people develop the service and the application using the service

This is obviously no longer the case and, therefore, using a service requires much more information than is typically available for internal company services

This documentation has three aspects to it: basic information categorization technical data

Originally, UDDI was conceived as an “Universal Business Registry” similar to search engines (e.g., Google) which will be used as the main mechanism to find electronic services provided by companies worldwide. This triggered a significant amount of activity around very advanced and complex scenarios (Semantic Web, dynamic binding to partners, automatic partner selection at runtime, etc.)

Nowadays UDDI is far more pragmatic and recognizes the realities of B2B interactions: it presents itself as name and directory service (i.e., binder in RPC) applied to Web services and mostly used in constrained environments (internally within a company or among a predefined set of business partners)

WS Technology Design Space


1 Message Format (SOAP)1 Communication “Endpoint”

Many Operations (WSDL)

Many Message Formats(XML, JSON, ATOM, HTML, CSV, …)

Many URIs4 HTTP Verbs(GET, PUT, POST, DELETE)

WS-*

REST

Representations

Resources Interface

Architectural Decision Modeling


Design Issue

1 Communication “Endpoint”

Many Operations (WSDL)

Architecture Alternatives

Many URIs4 HTTP Verbs(GET, PUT, POST, DELETE)


REST Richardson Maturity Model0. HTTP as an RPC Protocol

(Tunnel POST+POX or POST+JSON)I. Multiple Resource URIs

(Fine-Grained Global Addressability)II. Uniform HTTP Verbs

(Contract Standardization)III. Hypermedia

(Protocol Discoverability)(Decentralized Service Discovery by Referral)


RESTful Web Service Example

HTTP Client

(Web Browser)

Web Server

Application Server Database

GET /book?ISBN=222SELECT *

FROM books WHERE isbn=222

POST /order INSERT INTO orders301 Location: /order/612

PUT /order/612 UPDATE ordersWHERE id=612


WS-* Service Example (from REST perspective)

HTTP Client

(Stub Object)

Web Server

Application Server

POST /soap/endpoint

POST /soap/endpoint

POST /soap/endpoint

return getBook(222)

return new Order()

order.setCustomer(x)

Web Service

Implementation


Protocol Layering“The Web is the universe of globally accessible information” (Tim Berners Lee) Applications should publish

their data on the Web (through URI)

“The Web is the universal (tunneling) transport for messages” Applications get a chance

to interact but they remain “outside of the Web”

Application

(Many) Resource URI

HTTPPOST

Application

1 Endpoint URI

HTTPGET

HTTPPUT

HTTPDEL

HTTPPOST

SOAP (WS-*)

MQ…SMTP

AtomPub JSON …POX


Is REST really used?

Atom, 2%

Gdata, 1%

JavaScript, 6%

JSON-RPC, 0%

REST, 71%

RSS, 1%

SMS, 0%

SOAP, 17%XML-RPC, 2%

XMPP, 0%

2000+ APIs

ProgrammableWeb.com

Summer 2010


SOA & WS

The Web(REST)

SoftwareArchitecture

Componentsvs. Services

Connectorsand Integration

Today’s plan


Looking Back

TheWWW

Web Services

1992 2000 2010

What is a Web site?

What is your Web

site?

Why do you need a Web API?

You don’t have a Web

API?!?

From

Tom

as V

itvar

, Mas

hups

2010

Key

note


Richard N. Taylor, Nenad Medvidovic,

Eric M. Dashofy, Software Architecture:

Foundations, Theory and Practice,

John-Wiley, January 2009,

ISBN 9780470167748


Gustavo Alonso, Fabio Casati, Harumi Kuno, Vijay Machiraju, Web Services: Concepts, Architectures, and ApplicationsSpringer, September 2004, ISBN 3-540-44008-9


More ReferencesChristopher Alexander, The Timeless Way of Building, Oxford University

Press 1979Grady Booch, Handbook of Software Architecture,

http://booch.com/architecture/Stewart Brand, How Buildings Learn, Penguin 1987Thomas Erl, SOA Principles of Service Design, Prentice Hall, 200Thomas Erl, SOA Design Patterns, Prentice Hall, 2009Ian Gordon, Essential Software Architecture, Springer 2004Nicolai M. Josuttis, SOA in Practice: The Art of Distributed System

Design, O’Reilly, 2007Cesare Pautasso, Olaf Zimmermann, Frank Leymann, RESTful web

services vs. "big"' web services: making the right architectural decision, WWW 2008

Eberhardt Rechtin, Systems Architecting: Creating and Building Complex Systems, Prentice Hall 1991

Process Support for More Than Web Services: www.jopera.org

http://booch.com/architecture/�

http://www.jopera.org/docs/publications/2008/restws�



http://www.jopera.org/�

©2010 Cesare Pautasso 85

http://ecows2011.inf.usi.ch/�

http://ecows2011.inf.usi.ch/�

http://twitter.com/ecows2011�

http://twitter.com/ecows2011�

service oriented architectures and web services

Technology

time2010 cesare pautasso

ports2010 cesare pautasso

hand2010 cesare pautasso

soa2010 cesare pautasso

cesare pautasso28

clouds2010 cesare pautasso7

service infrastructureas

service applicationplatformas