Upload
cesare-pautasso
View
3.865
Download
3
Tags:
Embed Size (px)
DESCRIPTION
Topics of Informatics, USI Lecture, 15.12.2010
Citation preview
Service Oriented Architecturesand Web Services
Prof. Cesare PautassoFaculty of InformaticsUniversity of Lugano
[email protected]://www.pautasso.info@pautasso
©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/
Marcin Nowak
Saeed Aghaee
Dr. Achille PeternierDaniele Bonetta
©2010 - Cesare Pautasso 4
Software Architecture and Design
Software Engineering
Software Design and Evolution
I
II
III
Master Software Design
©2010 - Cesare Pautasso 5
Once upon a time
©2010 - Cesare Pautasso 6
Once upon a time
Software used to come in boxes
©2010 - Cesare Pautasso 7
Once upon a time
Today, software runs in the clouds
©2010 - Cesare Pautasso 8
Once upon a timeCloud Operating System?
©2010 - Cesare Pautasso 9
Once upon a timeCloud Operating System?
©2010 - Cesare Pautasso 10
SOA & WS
The Web(REST)
SoftwareArchitecture
Componentsvs. Services
Connectorsand Integration
Today’s plan
©2010 - Cesare Pautasso 11
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
©2010 - Cesare Pautasso 12
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
©2010 - Cesare Pautasso 13
Integration (by hand…)
©2010 - Cesare Pautasso 14
Once upon a timeIntegration (by hand…)
©2010 - Cesare Pautasso 15
Integration (…with SOA)
©2010 - Cesare Pautasso 16
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
©2010 - Cesare Pautasso 19
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.
©2010 - Cesare Pautasso 20
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
©2010 - Cesare Pautasso 21
Abstraction Layers
Application
Operating System
Hardware
©2010 - Cesare Pautasso 22
Application
Operating System
Hardware
Infrastructure as a Service
Platformas a
Service
Softwareas a Service
Layered Architectural Style
Infrastructure as a Service
Hardware
Hardware
Operating System
Platformas a
Service
Infrastructure as a Service
©2010 - Cesare Pautasso 25
ComponentReusable unit of composition
Made out of smallercomponents
Can be composedinto larger systems
©2010 - Cesare Pautasso 26
ConnectorGeneric enabler of composition
Transfer signals(data, control)between ports
Plug into matchingcomponent ports
©2010 - Cesare Pautasso 27
Services
Components
New Abstraction Levels
ObjectsC++ JavaC#
J2EE.NET
Eclipse
Web ServicesXMLREST
©2010 - Cesare Pautasso 28
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?
©2010 - Cesare Pautasso 29
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:
©2010 - Cesare Pautasso 30
IT as a “manufacturing” industry (ship software components)
IT as a “service” industry (publish software on the Web)
©2010 - Cesare Pautasso 31
Correctness & Verification
function f(x) {
…
return y;
}
while(true)
{
…
}
Will it terminate?Will it run forever?
©2009 - Cesare Pautasso 32
Service Lifecycle
DesignSystemArchitecture
Deploy
Change (FunctionalNon-Functional)
DefineInterfaceContracts
Refactor
Test
Run,Manage,Operate
BuildServices
©2010 - Cesare Pautasso 33
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
©2010 - Cesare Pautasso 34
From
Tom
as V
itvar
, Mas
hups
2010
Key
note
©2010 - Cesare Pautasso 35
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.
©2010 - Cesare Pautasso 36
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
©2010 - Cesare Pautasso 37
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
©2010 - Cesare Pautasso 38
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
©2010 - Cesare Pautasso 39
How to mix software not designed to be integrated?
Integration is bottom up
©2010 - Cesare Pautasso 40
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
©2010 - Cesare Pautasso 41
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
©2010 - Cesare Pautasso 43
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
©2010 - Cesare Pautasso 44
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
©2010 - Cesare Pautasso 45
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
©2010 - Cesare Pautasso 46
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
©2010 - Cesare Pautasso 47
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.
©2010 - Cesare Pautasso 48
Software Connectors for SOA
REST
WS-
*RPC ESB
WWW
©2010 - Cesare Pautasso 49
Interface Description Languages (IDL)
CORBAIDLRPC
IDL
DCOMMIDL
Java Interfaces
WSDL1.0
©2010 - Cesare Pautasso 50
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
©2010 - Cesare Pautasso 51
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
©2010 - Cesare Pautasso 52
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)
©2010 - Cesare Pautasso 53
Is this a Web Service?
©2010 - Cesare Pautasso 54
Web Sites (1992)
HTTP
HTMLWeb Browser
Web Server
(HTTP)
SOAP
ServerClient XMLWSDL
WS-* Web Services (2000)
©2010 - Cesare Pautasso 55
RESTful Web Services (2007)
Client HTTP
PO-XM
L
ATOM
JSON
Web Server
WADL
WS-* Web Services (2000)
(HTTP)
SOAP
ServerClient XMLWSDL
©2010 - Cesare Pautasso 56
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
©2010 - Cesare Pautasso 57
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
©2010 - Cesare Pautasso 58
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)
©2010 - Cesare Pautasso 59
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.
©2010 - Cesare Pautasso 60
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
©2010 - Cesare Pautasso 61
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
©2010 - Cesare Pautasso 62
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)
©2010 - Cesare Pautasso 63
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
©2010 - Cesare Pautasso 64
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
©2010 - Cesare Pautasso 65
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>
©2010 - Cesare Pautasso 66
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
©2010 - Cesare Pautasso 67
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
©2010 - Cesare Pautasso 68
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>
©2010 - Cesare Pautasso 69
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>
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
©2010 - Cesare Pautasso 70
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> result = sayHi(text)
©2010 - Cesare Pautasso 71
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)
©2010 - Cesare Pautasso 72
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
©2010 - Cesare Pautasso 73
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
©2010 - Cesare Pautasso 74
Design Issue
1 Communication “Endpoint”
Many Operations (WSDL)
Architecture Alternatives
Many URIs4 HTTP Verbs(GET, PUT, POST, DELETE)
©2009-2010 - Cesare Pautasso, Erik Wilde 75
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)
©2009-2010 - Cesare Pautasso, Erik Wilde 76
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
©2009-2010 - Cesare Pautasso, Erik Wilde 77
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
©2009-2010 - Cesare Pautasso, Erik Wilde 78
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
©2010 - Cesare Pautasso 79
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
©2010 - Cesare Pautasso 80
SOA & WS
The Web(REST)
SoftwareArchitecture
Componentsvs. Services
Connectorsand Integration
Today’s plan
©2010 - Cesare Pautasso 81
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
©2010 - Cesare Pautasso 82
Richard N. Taylor, Nenad Medvidovic,
Eric M. Dashofy, Software Architecture:
Foundations, Theory and Practice,
John-Wiley, January 2009,
ISBN 9780470167748
©2010 - Cesare Pautasso 83
Gustavo Alonso, Fabio Casati, Harumi Kuno, Vijay Machiraju, Web Services: Concepts, Architectures, and ApplicationsSpringer, September 2004, ISBN 3-540-44008-9
©2010 - Cesare Pautasso 84
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