Service Oriented Architectures and Web Services

Service Oriented
Architectures
and Web Services
Prof. Cesare Pautasso
Faculty of Informatics
University of Lugano

c.pautasso@ieee.org
http://www.pautasso.info
@pautasso

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/

©2010 - Cesare Pautasso 2

Marcin Nowak
Dr. Achille Peternier
Daniele Bonetta
Saeed Aghaee

Master Software Design

III Software Design and Evolution

II Software Architecture and Design

I Software Engineering


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 time
Cloud Operating System?


Today’s plan

Software The Web
Architecture (REST)

SOA & WS

Components Connectors
vs. Services and Integration

Context
 Databases
 Networking How to build
applications
 Software Engineering from scratch
 Programming Languages

 Service Oriented
Architectures How to reuse and compose two
or more existing applications
 Web Services


What is the problem? Operations

Vermarktung Angebotserstellung& Leistungserbringung Fakturierung
Leistungsbereitstellung (Assurance) (Billing)
(Fulfillment)

OTTO, Windows , Lotus Notes

SIF MQ
ORCA
OMS
extern FX
CORBA

MQ
PeP

LSM Insight esBill
PA, zLinux

PA FTP

TTS ARS TOPM
SCHON
Notes
CORBA

ESW OPM MERS
FTP
CORBA

FTP
FTP

FTP
CORBA
CSS
TIS IPP+
FTP

FTP
Tuco FTP BASKAI FX
MIDAS

TIS
CORBA

Direx Peris SAP BDM
TTS
DWH BW
extern FX
BSK ES Archiv AD


Integration (by hand…)


Once upon a hand…)
Integration (by time


Integration (…with SOA)


Integration Example


Integration (… with JOpera)

©2009-2010 - Cesare Pautasso, Erik Wilde 17

De Architectura
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

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)

60
Millions of LOC

40

20

0
1990 1995 2000 2005 2010

Abstraction Layers

Application

Operating System

Hardware


Software
as a Service
Application
Platform
as a
Operating System Service

Infrastructure
as a Service
Hardware


Layered Architectural Style

Infrastructure
as a Service
Hardware

Platform
as a
Operating System Service

Infrastructure
as a Service
Hardware

Component
 Reusable unit of composition

Made out of smaller
components

Can be composed
into larger systems


Connector
 Generic enabler of composition

Plug into
matching
component
ports

Transfer signals
(data, control)
between ports


New Abstraction Levels

Web Services
Services XML
REST
Components J2EE
.NET
Eclipse
Objects
C++
Java
C#


Component vs. Service: Example
Map 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?


Component vs. Service:
Business Model
 How to sell a component?  How to sell a service?
 Component developers  Service providers can
charge on a per- charge on a per-call basis:
deployment basis: each time an existing
whenever a new client client interacts with a
downloads the component. service by exchanging a
 Component upgrades may new message.
be sold separately to  Service providers can
generate a revenue stream charge a monthly/yearly
 Components can be flat access fee
licensed to be redistributed  Services can be made
within larger systems and available for free and
developers can demand providers can support
royalties from the revenue them with advertising
of the final product revenue


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

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


Correctness & Verification

function f(x)
{
… while(true)
return y; {
} …
}

Will it terminate?
Will it run forever?


Service Lifecycle

Change (Functional Refactor
Non-Functional) Design
System
Architecture
Run,
Define
Manage,
Interface
Operate
Contracts
Deploy
Build
Test Services

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 Tomas Vitvar, Mashups 2010 Keynote

Component vs. Service: Technology
 To be used a component must:  To be used a service must:
 be packaged to be deployed  be published on the Web
as part of some larger (once)
application system  advertise its description and
 fit with the existing framework location to potential clients
used to develop the system across the Web so that they
 There are many component can access it using standard
frameworks available for building protocols
distributed systems (e.g., J2EE,  Like components, services can be
DCOM, .NET, CORBA). reused, composed into larger
 The problem is: they are not systems and (of course) they can
compatible (as an exercise try to be found on the Web.
use a .NET assembly to make an  Unlike components, services do
Eclipse plug-in and see what not have to be downloaded and
happens) 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?

Application 1 Application 2

Display
Logic
State
+ Display
Logic
State
=?
 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


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

Integration is bottom up

How to mix
software not
designed to
be integrated?

Integration Techniques
 Given two (or more)  Examples:
existing applications,  Manual Data Transfer
how can you compose  Manual (with Copy & Paste)
them?  File based integration (Hot Folder)
 It depends on whether  API extraction and publishing
you can change the  Command line scripting
applications to make  Wrap existing software
them talk together.  Screen Scraping
 How much integration  Data transformation and conversion
can be done  Message based integration
automatically?  Point to Point
 Centralized, Peer to Peer
 Mashup


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

UI
Well designed
applications
Application have an API
It is also possible that we can call
to bypass the directly.
application and
directly access DB
its database


RPC

Call
Remote Procedure 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

Write
Copy File Transfer
(Hot Folder)

Watch  Transferring files does not
require to modify components

Read
 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

Create
Read Shared Database

Update  Sharing a common database
does not require to modify
components, if they all can

Delete 
support the same schema
Components can communicate
by creating, updating and
reading entries in the
database, which can safely
handles the concurrency

Bus

Publish
Subscribe
Message Bus
 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)

Get
Put
Delete
Post 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

RPC ESB

WS-*
WWW

REST

Interface Description
Languages (IDL)

WSDL
CORBA 1.0
DCOM
RPC IDL
MIDL
IDL
Java Interfaces


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

Enterprise
Java DCOM
.NET
Beans Objects
Assemblies

Web Legacy
CORBA
Services COBOL
Objects
Programs


Web Services for Interoperability
 If the components are published as Web services, they can
interoperate across different component frameworks.
(Interoperability through Wrapping)

Java DCOM .NET
Bean Object Assembly

Web Legacy
CORBA COBOL
Object Service
Program


Interoperability

Component Adapter Adapter Component
(Platform A) (Platform A) (Platform B) (PlatformB)

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


Is this a Web Service?


Web Sites (1992)

Web HTML Web
Browser HTTP Server

WS-* Web Services (2000)

SOAP WSDL
Client XML Server
(HTTP)

RESTful Web Services (2007)

PO-XML
ATOM
JSON
WADL
Web
Client
HTTP Server

WS-* Web Services (2000)

SOAP WSDL
Client XML Server
(HTTP)

Extending the Web with Services

Web Browser WS Client

HTML/HTTP SOAP, XML or JSON/HTTP

Web Server
add your
Java ASP
CGI PHP favourite
Servlet .NET here

Back-end Systems and Databases

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

Service Service Service
Requester Registry Provider

Service
Description 1. Publish

2. Lookup

3. Invoke

Clients use the Registry to lookup published service
descriptions that will enable them to perform the actual
service invocation with the provider


Main Web Services Standards
 The Web service architecture
proposed by IBM is based on UDDI
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 SOAP
done with:
 SOAP (Simple Object
Access Protocol)
 UDDI (Universal Description
and Discovery Protocol)
 WSDL (Web Services WSDL
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

HTTP Request

SOAP RPC SOAP Envelope
SOAP header
Transactional
context

SOAP Body
Name of Procedure

Input parameter 1
SERVICE REQUESTER SERVICE PROVIDER
Input parameter 2

Procedure
RPC call
HTTP engine

HTTP engine
SOAP SOAP
engine engine
HTTP Response
SOAP Envelope
SOAP header
Transactional
context

SOAP Body

Return parameter


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

Abstract description of the service
Types (type information for the document, e.g., XML Schema)

Message 1 Message 2 Message 3 Message 4 Message 5 Message 6

Operation 1 Operation 2 Operation 3

Port Type (abstract service)

binding 1 binding 2 binding 3 binding 4

Concrete description
of the service
port 1 port 2 port 3 port 4

Service (the interface in all
its available implementations)

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" />
<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>


Hello World WSDL

Types (type information for the document, e.g., XML Schema)
</wsdl:types>
Request and Response Messages

Abstract Port Type and Operations
</wsdl:operation>
</wsdl:portType>

Concrete SOAP Binding
</wsdl:operation>
</wsdl:binding>
Service HTTP Endpoint
</wsdl:service>
</wsdl:definitions>


Hello World WSDL
</wsdl:types>
</wsdl:operation>
</wsdl:portType>
</wsdl:operation>
</wsdl:binding>

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


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  Originally, UDDI was conceived as an
and Integration “Universal Business Registry” similar
 Services offered through the to search engines (e.g., Google) which
Internet to other companies will be used as the main mechanism
require much more information to find electronic services provided by
than a typical middleware service companies worldwide. This triggered
 In many middleware and EAI a significant amount of activity
efforts, the same people develop around very advanced and complex
the service and the application scenarios (Semantic Web, dynamic
using the service binding to partners, automatic
 This is obviously no longer the partner selection at runtime, etc.)
case and, therefore, using a  Nowadays UDDI is far more pragmatic
service requires much more and recognizes the realities of B2B
information than is typically interactions: it presents itself as
available for internal company name and directory service (i.e.,
services binder in RPC) applied to Web
 This documentation has three services and mostly used in
aspects to it: constrained environments (internally
 basic information within a company or among a
predefined set of business partners)
 categorization
 technical data

WS Technology Design Space
Representations
WS-*
REST Many Message Formats
(XML, JSON, ATOM, HTML, CSV, …)

1 Message Format (SOAP)
1 Communication
“Endpoint”
4 HTTP Verbs
Many URIs (GET, PUT, POST, DELETE)
Many Operations (WSDL)
Interface
Resources


Architectural Decision Modeling
Design Issue

Architecture Alternatives

1 Communication
“Endpoint”
4 HTTP Verbs
Many URIs (GET, PUT, POST, DELETE)

Many Operations (WSDL)


REST Richardson Maturity Model
0. 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

Web Server
HTTP Client Database
Application Server
(Web Browser)

SELECT *
GET /book?ISBN=222 FROM books
WHERE isbn=222

POST /order INSERT
INTO orders
301 Location: /order/612

PUT /order/612 UPDATE orders
WHERE id=612


WS-* Service Example
(from REST perspective)
Web Server Web Service
HTTP Client
Application Server Implementation
(Stub Object)

POST /soap/endpoint
return getBook(222)

POST /soap/endpoint
return new Order()

POST /soap/endpoint
order.setCustomer(x)


Protocol Layering
“The Web is the universe of “The Web is the universal
globally accessible information” (tunneling) transport for
(Tim Berners Lee) messages”
 Applications should publish  Applications get a chance
their data on the Web to interact but they remain
(through URI) “outside of the Web”

AtomPub JSON POX … SOAP (WS-*)

HTTP HTTP HTTP HTTP HTTP
SMTP MQ…
GET POST PUT DEL POST

(Many) Resource URI 1 Endpoint URI

Application Application


Is REST really used?
Atom, 2%
Gdata, 1%
XMPP, 0%
JavaScript, 6%
XML-RPC, 2%
SOAP, 17% JSON-RPC, 0%

SMS, 2000+ APIs
0%
RSS, 1%
ProgrammableWeb.com
Summer 2010
REST,
71%


Today’s plan

Software The Web
Architecture (REST)

SOA & WS

Components Connectors
vs. Services and Integration

Looking Back

You don’t
What is a What is have a
Web site? Why do Web
your Web you need a
site? API?!?
Web API?

From Tomas Vitvar, Mashups 2010 Keynote
The Web
WWW Services
1992 2000 2010


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 Applications
Springer,
September 2004,
ISBN 3-540-44008-9


More References
Christopher Alexander, The Timeless Way of Building, Oxford University
Press 1979
Grady Booch, Handbook of Software Architecture,
http://booch.com/architecture/
Stewart Brand, How Buildings Learn, Penguin 1987
Thomas Erl, SOA Principles of Service Design, Prentice Hall, 200
Thomas Erl, SOA Design Patterns, Prentice Hall, 2009
Ian Gordon, Essential Software Architecture, Springer 2004
Nicolai M. Josuttis, SOA in Practice: The Art of Distributed System
Design, O’Reilly, 2007
Cesare 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


Service Oriented Architectures and Web Services

More Related Content

What's hot

Viewers also liked

Similar to Service Oriented Architectures and Web Services

More from Cesare Pautasso

Recently uploaded

Service Oriented Architectures and Web Services