Service Oriented Architectures and Web Services - Semantic Scholar

Service Oriented Architectures and Web Services Prof. Cesare Pautasso Faculty of Informatics University of Lugano [email protected] http://www.pautasso.info

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/

©2009 - Cesare Pautasso

2

Master Software Design III

Software Design and Evolution

II

Software Architecture and Design

I

Software Engineering 3


This week’s plan

Software Architecture

Components vs. Services

SOA & WS Technology ©2009 - Cesare Pautasso

Connectors and Integration 4

Context 

Databases



Networking



Software Engineering



Programming Languages



Service Oriented Architectures



Web Services

How to build applications from scratch

How to reuse and compose two or more existing applications

5


Vermarktung

Angebotserstellung& Leistungsbereitstellung (Fulfillment)

Leistungserbringung (Assurance)

MQ

OMS extern FX MQ

CORBA

PeP LSM

Insight

esBill

PA, zLinux

PA

FTP

TOPM

TTS ARS SCHON Notes CORBA

ESW OPM

MERS

FTP

FTP FTP FTP CORBA

FTP

CSS TIS IPP+ FTP

Tuco

MIDAS

FTP

BASKAI FX

TIS CORBA

Direx

SAP

Peris DWH

BSK


Fakturierung (Billing)

OTTO, Windows , Lotus Notes SIF

ORCA

CORBA

What is the problem?

Operations

ES Archiv

AD

BDM BW

TTS extern FX

6

Integration (by hand…)


7

Integration (…with SOA)


8

Software Architecture ©2009 - Cesare Pautasso

Firmitatis


9

10

Venustatis ©2009 - Cesare Pautasso

11

Utilitatis Venustatis ©2009 - Cesare Pautasso

12

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. ©2009 - Cesare Pautasso

14

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

 Lines

60 40 20 0 1990 1995 2000 2005 2010 15


William (Bill) H. Gates, Chief Software Architect, Microsoft

(until June 2006) ©2009 - Cesare Pautasso

16

Process


17

Waterfall Model 1. 2.

Requirement Analysis Design Architecture

3. 4. 5.

Implementation Testing Maintenance


18

Top-down decomposition 1. 2. 3.

4. 5. 6.

Analyze requirements and goals Design a global structure for the overall architecture Refine it and Bind components into it: • Search for existing matching components (if you can afford to buy them) • Build missing components (if you can) • Add required data transformations and adapters (if necessary) Build Test Deploy into production


19

Bottom-up composition 5.

Deploy into production

4.

Build and test if it matches the requirements

3.

Add required data transformations and adapters (if necessary)

2.

Integrate them into an architecture

1.

Select available components from a library:  Lookup in your own catalog  Search in external component marketplaces


20

Real Design is Iterative Change, Rediscover s ent n Build New Components o mp o C ver o c s Di

Refactor Design System Architecture

Run, Manage Deploy

Build Components

Test

21


When to do Architecture? Software concept

They are the hardest ones to change at a later time

Architecture

Preliminary requirements analysis Design of architecture and system core

Develop a version Deliver a version

Incorporate customer feedback Elicit customer feedback


From John Reekie, Rohan McAdam

Architectural decisions are made early in the development lifecycle

22

Components ©2009 - Cesare Pautasso

23

Component  Reusable

unit of composition

Made out of smaller components

Can be composed into larger systems


24

Connector  Generic

enabler of composition

Plug into matching component ports

Transfer signals (data, control) between ports

25


Software Component  Locus

of computation and state in a system Processing

Provided Interface

State

Required Interface

Environment ©2009 - Cesare Pautasso

26

Software Component  Black

Boxes: only the interface is visible Processing

Provided Interface

State

Required Interface

Environment 27


New Abstraction Levels Services

Web Services XML

Components

J2EE .NET Eclipse

Objects


C++ Java Eiffel C#

28

Component vs. Objects 

Component  Encapsulate state and functionality  Coarse-grained  Reusable unit of composition  Well-defined (documented, standardized) interface contract with explicit dependencies  Architecture Element: Implementation not important (Black Box)  High Quality



Object  Encapsulate state and functionality  Fine-grained  Identifiable unit of instantiation  May not always provide a public interface  Hard to reuse by itself (lots of dependencies to other objects)  At run-time can “move” between components  Object-Oriented Programming Language Typing Construct

29


Programming Components in Darwin Required

Filter

From Muccini

Pipeline

Filter


Filter

component filter{ Interface provide output; require input; } component pipeline(int n){ F[0] provide output; Provided require input; Interface array F[n]: filter; forall k:0..n-1{ inst F[k] @ k+1; F[k] when k < n-1 bind F[k+1].input -Binding F[k].output; } bind F[n-1] F[0].input -- input; output -- F[n-1].output; } }

30

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?



4TB

31


Component vs. Service: Business Model 

How to sell a component?  Component developers charge on a perdeployment 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/yearly flat access fee  Services can be made available for free and providers can support them with advertising revenue

32

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

33


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. 34

Interface Description Languages (IDL) 1990s

2000s

1980s

RPC IDL

CORBA IDL

DCOM MIDL

WSDL 1.0

Java Interfaces 35


Component Interoperability 

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

Enterprise Java Beans

DCOM Objects

CORBA Objects

Web Services


Eiffel .NET Assemblies

Legacy COBOL Programs

36

Web Services for Interoperability 

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

Java Bean

Eiffel .NET Assembly

DCOM Object

Legacy COBOL Program

Web Service

CORBA Object

37


Interoperability Component (Platform A)

Adapter (Platform A)

Adapter (Platform B)

Component (PlatformB)

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

38

Connectors 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


40

Hot Folder

Write Copy Watch Read

File Transfer (Hot Folder)  



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 41


Shared Database

Create Read Update Delete ©2009 - Cesare Pautasso

Shared Database 



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 42

Linkage

Call Read/Write Load Unload

Linkage (Static/Dynamic) 



Statically Linking components enables them to call each other, but also to share data in the same address space Dynamic linking also enables the components to be loaded and unloaded without stopping the whole system 43


Data Stream

Send Receive 

 

Data Stream

Data streams let a pair of components exchange an infinite sequence of messages (discrete streams) or data (continuous streams, like video/audio) They are mostly used to set up pipelines in the pipe/filter architectural style A streaming connector may buffer data in transit and provide certain reliability properties


44

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 45


Tuple Space

In Out Rd    

Tuple Space

A tuple space acts like a shared database, but offers a much simpler set of primitives and persistence guarantees Components can write tuples into the space (with the Out operation) or read tuples from it (with the Rd operation). Components that read tuples can also atomically take them out of the space (with the In operation) Extensions for the connector are available that support different kinds of synchronization, in addition to the basic data flow primitives


46

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.


Integration

47

What is Integration? Application 1 Display Logic State

+

Application 2 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


49

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


50

Challenges of Integration

Heterogenenous Autonomous Distributed 51


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

52

“Enterprise” Architecture (?)


Picture from Eric Newcomer, IONA

CICS IMS

53

Integration is bottom up

How to mix software not designed to be integrated? ©2009 - Cesare Pautasso

54

How to do Integration? Application 1 Display Logic State

+

Application 2 Display Logic State

=?



How to build new applications out of the composition of existing ones?



Assumption: Existing applications cannot be modified (too much)

55


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

56

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

UI

It is also possible to bypass the application and directly access its database ©2009 - Cesare Pautasso

SOA

Application

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

DB 57

What is SOA? 

SOA = Service Oriented Architecture  Service = another name for coarse - grained components delivered via the network and wrapped behind a standard interface protocols  Architecture = SOA is intended as a way to structure applications and follows on architectural styles such as software bus, publish/subscribe, or REST



The part that it is not in the name  Loosely- coupled = the services are independent of each other, heterogeneous, distributed. The architecture embraces change and is meant to be easy to evolve  Message based = interaction is through message exchanges rather than through direct calls (unlike CORBA, RPC, etc.)


59

SOA: Before and After


60

The novelty behind SOA 

The concept of SOA is not new:  Message oriented middleware  Message brokers  Event based architectural styles



The current context is different  Emergence of standard interfaces (Web services)  Emphasis on simplifying development (automatic)  Use of complex underlying infrastructure (containers, middleware stacks, etc.)



Interest in SOA arises from a number of reasons:  Basic technology in place  More clear understanding of distributed applications  The key problem is integration not programming


61

Goals and Benefits of SOA


62

Web Services in Context

World Wide Web Web Services Interoperability Standards 63


Web Services in Context

World Wide Web Web Services


64

Is this a Web Service?

65


Web Sites (1992) Web Browser

HTML HTTP

Web Server

WS-* Web Services (2000) SOAP Client

XML

WSDL Server

(HTTP) ©2009 - Cesare Pautasso

66

RESTful Web Services (2007) RSS

PO-XML

JSON

Client

WADL Web Server

HTTP

WS-* Web Services (2000) SOAP

WSDL

XML

Client

Server

(HTTP) 67


Extending the Web with Services Web Browser

WS Client

HTML/HTTP

SOAP/HTTP

Web Server CGI

PHP

Java Servlet

ASP .NET

add your favourite here

Back-end Systems and Databases ©2009 - Cesare Pautasso

68

Web Services Interoperability Standards

Distributed Systems & Web Services  



Web services provide standards for developing large scale distributed systems One example: “the Grid” is adopting Web services as standard protocols to build a distributed infrastructure for utility based computing Web services on the path of success while CORBA distributed objects failed (This is nothing technical, only a matter of widespread industry acceptance)

The WWW

Web Services

Semantic Web

1973

1992

2000

?

Standard Network

Standard User Interface

Standard API

Standard API Metadata

The Internet


70

Standards for Distributed Systems   

Standard Network Protocol

Standard User Interface

Layers

Distributed systems are built using standardized layers of increasingly higher abstraction levels. It took 20 years to go from the TCP/IP (Internet, 1973) standard to the HTTP/HTML (World Wide Web, 1992) standards. By reusing HTTP, the time to standardize SOAP/XML was halved (Web Services, 2000).

Standard API SOAP XML

HTML HTTP TCP/IP

Ethernet

POTS

Wireless

WiMax


71

Web Services = Distributed Objects? 

Are Web services distributed objects? 1. XML Document Exchange can be used to implement RPC but is more general (and loosely coupled) 2. XML messages can be routed between different intermediaries which can transparently modify them for security and reliability purposes. 3. Web services are stateless: the session state is embedded in the XML Document. The state of a distributed objects goes through a complex lifecycle and needs to be garbage collected. 4. Distributed object can reference one another. 5. Distributed objects are chatty and can only be applied to local area networks 6. “SOAP” is just SOAP (no longer Simple “Object” Access Protocol, now could be read as the “SOA Protocol”)


72

CORBA vs. Web Services Standards Multi-language XML-based Loosely Coupled Service Description Message Transformation

CORBA Yes (OMG) Yes Can be No IDL

Web Services Yes (W3C, OASIS…) Yes Yes Yes WSDL, XML Schema

None

XSLT, XPath

CORBA interface Discovery repository, CORBA naming service Security IIOP/TLS Object References Yes (IOR) Load Balancing Yes Service Management No

UDDI HTTPS, WS-Security No No Yes (WS*M)


73

Web Services Standards 





“Standards are good because there are so many to choose from”  This also applies to Web services, where since 2000 hundreds of standards, standard proposals, specifications, revisions and drafts have appeared, disappeared and more will continue to appear. Without standards in place, Web services interoperability would not exist.  It takes time for a standard to reach widespread acceptance throughout the industry. A specification that begins with “WS” does not necessarily guarantee that interoperable tools exist. Main standard bodies relevant to Web services:  W3C (World Wide Web Consortium)  OASIS (Organization for the Advancement of Structured Information Standards)  WS-I (Web Services Interoperability Organization)  GGF (Global Grid Forum)


74

WS Standards and Specifications Transport

HTTP, IIOP, SMTP, JMS WS-Addressing

Messaging

XML, SOAP

Description

XML Schema, WSDL

WS-Policy, SSDL

UDDI

WS-MetadataExchange

Discovery Choreography Business Processes

WSCL

WSCI

WS-Coordination

WS-BPEL

BPML

WSCDL

Stateful Resources Transactions

WS-Resource Framework WS-CAF

WS-Atomic Transactions WS-Business Activities

Reliable Messaging

WS-Reliability

WS-ReliableMessaging

Security

WS-Security SAML, XACML

WS-Trust, WS-Privacy WS-SecureConversation

WS-Notification

WS-Eventing

Management

WSDM

WS-Management

Data Access

OGSA-DAI

SDO

Event Notification

75


Too many standards

WS-*

Web Services for Everything

WSAH

Web Services Acronyms Hell


76

Standardization Process 



There is a fundamental tension between:  standardization of implementations (de - facto standards)  and standardization of specifications (de - jure standards) that still have to be proven by a working implementation.  Web services vendors agree on standards and compete on the quality of the products implementing them.

Standard

Products Customers prefer standards because of the “warm fuzzy feeling” that they avoid to lock - in a specific vendor’s platform and tools.  This is true, as long as customers do not rely on proprietary non - standard extensions.


77

Defining Web Services

Web Services


78

What are Web services?   



The term Web services has become nowadays very popular and it is not always used with the same meaning. At one extreme, a Web service is any application program which is accessible through the World Wide Web More precisely, W3C defines Web services 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 The long-term goal is just-in-time integration of applications by discovering and orchestrating Web services available on the network


79

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)


80

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.


81

Web Services Architecture 

1. 2.

3.

A popular interpretation of Web services is based on IBM’s Web service architecture based on three elements: Service requester: The potential user of a service (the client) Service provider: The entity that implements the service and offers to carry it out on behalf of the requester (the server) 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


82

Web Service Architecture Service Requester

Service Registry

Service 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 83


Main Web Services Standards 

 

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)


UDDI

SOAP

WSDL 84

Web Services Technology ©2009 - Cesare Pautasso

85

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


86

SOAP RPC

HTTP Request SOAP SOAP Envelope Envelope SOAP header Transactional context SOAP Body Name of Procedure

SERVICE REQUESTER

Input parameter 1 Input parameter 2

SERVICE PROVIDER

Procedure

HTTP Response

HTTP engine

SOAP engine

HTTP engine

RPC call

SOAP engine

SOAP SOAP Envelope Envelope SOAP header Transactional context SOAP Body Return parameter


87

SOAP Request Response XML World Hello World


88

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 89


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

Message 2

Operation 1

Message 3

Message 4

Message 5

Operation 2

Operation 3

Port Type (abstract service) binding 1

binding 2

binding 3

binding 4

port 1

port 2

port 3

port 4

Service (the interface in all its available implementations) ©2009 - Cesare Pautasso

Message 6

Concrete description of the service

WSDL document

Abstract description of the service

Elements of WSDL (1.1)

90

Hello World WSDL

91


Hello World WSDL Request and Response Messages

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

Abstract Port Type and Operations

Concrete SOAP Binding Service HTTP Endpoint


92

Hello World WSDL

result = sayHi(text)


93

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)


94

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) 95

Demo


96

RPC over the Web

WS RPC  Demo:

Connect a simple Java ‘hallo world’ service with different clients written in Java and Python, and even also .NET


97

Java Service - Contract 

This is the Java “contract” (or interface) annotated with JAX-WS

import javax.jws.WebParam; import javax.jws.WebResult; import javax.jws.WebService; @WebService public interface Contract { @WebResult(name="result") String sayHi(@WebParam(name="text") String text); }


98

Java Service - Implementation import javax.jws.WebService; @WebService( endpointInterface = "ch.usi.inf.test.Contract", serviceName = "HelloWorld") public class Service implements Contract { public String sayHi(String text) { String result = "Hello "+text; System.out.println("sayHi called and said '“ +result+"'"); return result; } } ©2009 - Cesare Pautasso

99

Why not also .NET?

Time to Install


Disk Space

5 GB 3 reboots 4+ hours

100

.NET Client 



First you should import into your project a service reference (by giving the WSDL URL to the Visual Studio Wizard) This will generate some code that you can use to call the service


101

.NET Client namespace ConsoleApplication1 { class Program { static void Main(string[] args) { //setup the client “stub” object HelloWorld.ContractClient service = new HelloWorld.ContractClient(); //call the service operation String result = service.sayHi("C# .NET"); //process the result of the remote service call System.Console.Out.WriteLine(result); } } } ©2009 - Cesare Pautasso

102

Python Client #!/usr/bin/env python from ZSI import ServiceProxy MESSAGE = "Python!" def main(): server = ServiceProxy.\ ServiceProxy('http://localhost:9000/helloWorld?wsdl') print ' Sending: %s' % MESSAGE response = server.sayHi(text=MESSAGE) print 'Response: %s' % response['result']


103

JOpera Client 





Web services can also be consumed from business process modeling tools that use a visual notation to represent service interactions at a high level of abstraction The example shows the JOpera Visual Composition Language in action Download JOpera from www.jopera.org


104

Benefits of Web services 

One important difference with conventional middleware is related to the standardization efforts at the W3C that should guarantee:  Platform independence (Hardware, Operating System)  Reuse of existing networking infrastructure (HTTP has become ubiquitous)  Programming language neutrality (.NET talks with Java, and vice versa)  Portability across Middleware tools of different Vendors  Web services are “loosely coupled” components that foster software reuse  WS technologies should be composable so that they can be adopted incrementally


105

Problems of Web services 

    

What is the price to pay for interoperability? Complexity. For example:  This standard is so complex because we could not get all of the vendors to agree on a single definition  This 400 page long standard results from the merging of three existing, overlapping ones. Currently Web services standards are still rapidly evolving There are many competing and overlapping WS- *standard proposals. Not all standards are supported by tools. Tools must play catch - u p when standards are revised with new versions. The performance of some of the available tools and protocols is quite poor.


106

Does SOAP really go through firewalls? Loosely

Coupled?

107


SOAP and Firewalls  

One of the perceived advantages of SOAP lies in its ability to tunnel RPC calls through firewalls This works only because SOAP uses HTTP and firewalls do not typically block TCP port 80, the default one used by the HTTP protocol.

Firewall

FTP Client

Firewall

RPC Client

RPC Server FTP Server

SSH Client

SSH Server

HTTP Client

HTTP Server

INTERNET ©2009 - Cesare Pautasso

108

SOAP Firewalls? 



Once all communication traffic is encoded in SOAP and sent over HTTP, traditional TCP-level firewalls do not offer an acceptable level of protection because RPC services which were hidden behind specific TPC port numbers are now exposed as SOAP Web services. Thus, firewalls become more complex as they must allow or disallow HTTP connections based on the content of the SOAP messages

SOAP Firewall

SOAP request

SOAP Firewall

RPC Client

RPC Server

SOAP response HTTP Server

HTTP Client

INTERNET 109


WS-Security 





The SOAP standard does not make any provision for secure message exchange. As its name implies SOAP is meant to be a simple (but extensible) messaging protocol, and properties such as security can be added to it. WS-Security is a SOAP extension that addresses some of the security issues such as:  Message integrity (guarantee that a message is not tampered with)  Message confidentiality (guarantee that the content of a message is kept secret)  Sender authentication (identify the sender of the message) WS-Security builds upon XML Encryption and XML Digital Signature standard technologies










WS-Security prescribes how to use SOAP header blocks to store the digital signature of the message, as well as user identification information and passwords. WS-Security enables end-to-end secure message exchange, whereas SOAP on top of HTTPS only guarantees security across each hop (point to point). With SOAP/HTTPS messages are decrypted and re-encrypted by each intermediate receiver and there is no way to encrypt the SOAP message all the way between initial sender and ultimate receiver WS-Security also supports encryption of only specific blocks of a SOAP message (e.g., the ones carrying sensitive information, such as Credit Card numbers) 110

Loosely Coupled?

111


Defining Loosely Coupled 

Web Services and Service Oriented Architectures are usually presented as “loosely coupled”. What exactly does this mean? Why is it good? Is WSDL/SOAP/HTTP really loosely coupled?

Discovery How does the client locate the service?

Interaction Must the client directly connect to the service?

Service

Client

Timing Must Client and Service be available at the same time to exchange a message?


Platform How easy is it to substitute one service with an equivalent replacement?

Interface To what extent the operations/data model can change without breaking clients?

112

How coupled is WSDL/SOAP/HTTP? 

A loosely coupled, distributed architecture is easy to change because its parts fit together without them making too many assumptions about each other:  Discovery. Clients do not have to know where the services are located to send them a message.  Interaction. Clients do not have to directly connect to a service to send it a message  Timing. Services do not have to be available when a client sends them a message.  Interface. The interface of a service can be extended without affecting clients.  Platform independence. Clients do not know how services are implemented.



Web Services described with WSDL and accessed through SOAP/HTTP partially satisfy this definition of “loosely coupled”:  Discovery. Clients can dynamically lookup and bind to a service using UDDI. A WSDL contains all information necessary to locate a service endpoint.  Interaction. SOAP/HTTP is a synchronous RPC-like protocol, where clients directly connect to services, which must be available in order to exchange messages  Interface. Changing a WSDL typically breaks clients, although XML Schema provides some extensibility for Document-style interfaces. 113


Summary

Software Architecture

Components vs. Services

SOA & WS Technology ©2009 - Cesare Pautasso

Connectors and Integration 114

Richard N. Taylor, Nenad Medvidovic, Eric M. Dashofy, Software Architecture: Foundations, Theory and Practice, John - W iley, January 2009, ISBN 9780470167748

115


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


116

Master Software Design III

Software Design and Evolution

II

Software Architecture and Design

I

Software Engineering


117

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


118

Service Oriented Architectures and Web Services - Semantic Scholar

Service Oriented Architectures and Web Services - Semantic Scholar

Suggest Documents

Web Services and Service Oriented Architectures

Service Oriented Architectures and Semantic Web ... - CiteSeerX

Service-Oriented Architectures and Web Services: Course Tutorial Notes

Securing Web Services and Service- Oriented Architectures with ...

Service-Oriented Architectures and Mobile Services - Distributed ...

Autonomic Service Oriented Architectures with ... - Semantic Scholar

Development of Service-Oriented Architectures ... - Semantic Scholar

Service-Oriented Architectures for Embedded ... - Semantic Scholar

Services-Service-Oriented-Architectures-Cloud-Computing-ebook ...

Mobile Services Architectures based on Service-Oriented Architectures

Towards Web Services Oriented Unified ... - Semantic Scholar

Semantic Service Oriented Architectures for eGovernment ... - CiteSeerX

Testing of Service Oriented Architectures â A ... - Semantic Scholar

Experiments with service-oriented architectures for ... - Semantic Scholar

Hybrid Service-Oriented Architectures: A Case ... - Semantic Scholar

Compliance in Service-oriented Architectures: A ... - Semantic Scholar

Designing Dependable Service Oriented Web Services Security ...

Mobile Service Oriented Architectures (MOSOA)

Service Oriented Architectures, the DoD

Web services-oriented architectures for mobile SOLAP applications

Combining Generic Programming and Service-Oriented Architectures ...

Quality Attributes and Service-Oriented Architectures

Integration and Interoperability on Service Oriented Architectures ...

Service oriented architectures: approaches, technologies and ... - Core

Service Oriented Architectures and Web Services - Semantic Scholar