University of New South Wales School of Computer Science ...

Wrap Up ...

Helen Paik

School of Computer Science and EngineeringUniversity of New South Wales

Wrap Up Week

H. Paik (CSE, UNSW) Wrap Up Wrap Up Week 1 / 82

This is the picture that started everything ...

complex/distributed/global information systems in enterprises.Pick any sizeable organisation: it has many departments performingdifferent functionality - in silos, often supported by software systems

Business Partner A

Business Partner B

Business Partner C


A typical Purchase Order process

Reality: communication/coordination between the silos needed

In a business process, to achieve a certain goal, multiple parties interact - in certainorder and exchange artefacts/messages


The Problem at a Glance

How do we make this picture easy ... (business process automation - applicationintegration ...)

1

MTAT.03.229Enterprise System Integration

Lecture 1: Introduction

Marlon Dumas

marlon.dumas ät ut.ee

Part I

Organizational Issues

3

Course Objective

The objective of this course is to introduce the principles and methods of software architecture in an enterprise environment, with an emphasis on the design, management and integration of large-scale information and software systems. The course will introduce modern approaches to enterprise system integration, including service-oriented architectures. In addition to technical aspects, the course will also cover organizational aspects of enterprise system integration, including architecture governance and Business-IT alignment.

4

The Problem at a GlanceSupplierPurchaser

Order

Order Response

Change Order

Change Confirmation

Shipment Notice

Invoice

Procurement

SupplierRelationshipManagement

FinancialApproval

Accounts Payable

InventoryPlanning

InventoryManagement

Logistics

CustomerRelationshipsManagement

Invoicing

Ordertracking

5

But if it’s working, why should I fix it?

InformationTechnology

Change andinnovation

Yields

Yields

BusinessValue

Index Group (1982)

Enables

6

Structure of the Course

• Lectures (Mondays, weeks 1-15)

• Labs (Wednesdays, weeks 1-15)– Some labs on Java (using NetBeans & Glassfish)

– Others on .Net (Sandstorm server)

• Project (weeks 8-15, presentation on 15 Dec.)

• Readings (weeks 1-14) – Examinable!

• See details on the Wiki pages:– http://courses.cs.ut.ee/2008/esi

• Make sure you register to the course mailing list– [email protected]

We learned how to build a standalone web site

How do we build a system when intended ’user’ is not necessarily a human-being ...


Service-Oriented Thinking ...

What do we do when we have a complex problem ?

we break things down into smaller bits

we abstract

... that is, we need a model

... and methodology for model design

... and implementation/execution platform for realising the model

Service-orientation or Service Oriented Architecture is such an approach.

An analogy:

OO allows us to model/implement software components as objects,

SO allows us to model/implement software systems in terms ofservices


Simplified View of Service Orientation:


Architecture of an Information System

3-Tier: middleware

1

Application logic layer: Middleware introduces an additional layer ofbusiness logic encompassing all underlying systems. It simplifies the designof clients by reducing the number of interfaces it needs to know.

1c©Springer Verlag 2004


The middleware in 3-Tier

2

It enables transparent access to the underlying systems, the integration ofsystems built using other architectures

2c©Springer Verlag 2004


The Service Bus (as middleware)

The service bus can be seen as a refactoring of the basic Web servicearchitecture, where a higher degree of loose coupling has been added.

©Gustavo Alonso, D-INFK. ETH Zürich. 24

The Service BusThe service bus can be seen as a refactoringof the basic W eb service architecture, w here a higher degree of loose coupling has been added.

Service Bus


Enterprise Service Bus (ESB)

http://enterprisearchitecture.nih.gov/NR/rdonlyres/3FE0F87BEB46-4605-8EFA-40B9A9796F1E/0/

EnterpriseServiceBusPattern.jpg


http://enterprisearchitecture.nih.gov/NR/rdonlyres/3FE0F87BEB46-4605-8EFA-40B9A9796F1E/0/EnterpriseServiceBusPattern.jpg

http://enterprisearchitecture.nih.gov/NR/rdonlyres/3FE0F87BEB46-4605-8EFA-40B9A9796F1E/0/EnterpriseServiceBusPattern.jpg

The Service Bus

Functionality:

service invocation: synchronous and asynchronous communication

message mediation: adapters, protocol transformation, messagetransformation, message

service choreography, orchestration: implementation of complexbusiness processes

quality of service: security, reliable delivery, transaction management

management: monitoring, audit, logging, metering, admin console

Note: these are (largely) common in other middleware architectures ...


Learning Outcomes

What we hoped that we’d achieve by now:

motivation (problem space) behind SO paradigm,

How to design and implement services,

How to design and implement the application integrationlogic/workflow using services

Also: you should know different ‘flavours’ of services (WS-*, RESTful,Data Service, etc.)

These concepts/technologies are basically about how to ‘expose’ yourapplication functionality and data as services for potential consumers.


Starting with ... Web ServicesKey concept:

Allow applications to share data and invoke capabilities from other applications

Without regard to how those applications were built, what operatingsystem or platform they run on, and what devices are used to accessthem.

Can be called across platforms and operating systems, regardless of programminglanguage.

Key facts:

A standardised way of application-to-application communication based on XMLopen standards (ie., SOAP, WSDL and UDDI) over an Internet protocol backbone.

Unlike traditional client/server models, web services do not require GUI, HTML orbrowser.


Web Services

Bouguettaya 2009

What is a Web Service?

FunctionalityAvailable on

The Web

Web Service

Discoverable Composable

Accessible via

Is a

ProgrammaticMeans

Has properties


Web Service Standards


Distributed messaging using SOAP (p.124 Mike Book)

SOAP is at the heart of Web services architecture in terms of enabling messageexchanges

SOAP server: Simply special code that listens for SOAP messages and acts as adistributor and interpreter of SOAP documents


Binding SOAP with a Transfer Protocol

HTTP Post Request

param 1

param 2

SOAP Envelope

SOAP BodyMethod Request Name

SOAP Header

return order_id

SOAP Envelope

SOAP BodyMethod Return

SOAP Header

HTTP Response SOAP Engine&

HTTP Engine

Service Requestor

SOAP Engine&

HTTP Engine

Service Provider


SOAP processing model

In a SOAP server (handlers == nodes):

Request: process the header blocks, Response: generates the header blocksH. Paik (CSE, UNSW) Wrap Up Wrap Up Week 18 / 82

SOAP communication model: RPC-style

<env:Envelope ...>

<env:Header> some header </env:Header>

<env:Body>

<m:GetProductPrice>

<product-id> 450R60P </product-id>

</m:GetProductPrice>

</env:Body>

</env:Envelope>

<env:Envelope ...>


<env:Body>

<m:GetProductPriceResponse>

<product-price> 134.32 </product-price>

</m:GetProductPriceResponse>

</env:Body>

</env:Envelope>

Key point: SOAP Body must conform to a structure that indicates the method name and

contains a set of parameters


SOAP communication model: Document-style

<env:Envelope ...>


<env:Body>

<po:PurchaseOrder orderDate="2004-12-02">

<po:from>

<po:accountName> RightPlastics </po:accountName>

<po:accountNumber> PSC-0343-02 </po:accountNumber>

</po:from>

<po:to>

<po:supplierName> Plastic Supplies Inc.</po:supplierName>

<po:supplierAddress> Yarra Valley Melbourne</po:supplierAddress>

</po:to>

<po:product>

<po:product-name> injection molder </po:product-name>

<po:product-model> G-100T </po:product-model>

<po:quantity> 2 </po:quantity>

<po:product>

</po:PurchaseOrder>

</env:Body>

</env:Envelope>

Key point: SOAP actually contains ’XML data’ (not a method call). Message-driven

communication modelH. Paik (CSE, UNSW) Wrap Up Wrap Up Week 20 / 82

WSDL Structure: Webber book (p.101)


Service Discovery

Service discovery is the process of locating Web service providers,and retrieving Web services descriptions that have been previouslypublished.

Interrogating services involve querying the service registry for Webservices matching the needs of a service requestor.

A query consists of search criteria such as: the type of the desiredservice, preferred price and maximum number of returned results, andis executed against service information published by service provider.

After the discovery process is complete, the service developer or clientapplication should know the exact location of a Web service (URI), itscapabilities, and how to interface with it.


UDDI and the big idea

Problem to solve: How to find the service a client

wants among a large collection of services and providers.

(2) Query for all

registry

(3) Discoveryresults

(1) Registrationrequest for

service description

ServiceRegistrymatching services in

(2) Query for all

registrymatching services in

the

(2) Query for all

registry




service description


service description

ServiceRegistryServiceregistry

services and providers.

The client does not necessarily need to know which provider provides the service.

E-serviceprovider

(4) Requestfor selected

service information

(6) Invocation requestincluding possible inputs

INVOKE

SEARCH

PUBLISH

Service provider

Service requester(7) Invocation results

(5) Serviceinformation of

selected service

E-serviceprovider


service information


service information



INVOKE

SEARCH

PUBLISH

Service providerServiceprovider

Service requesterServicerequestor

(7) Invocation results


selected service


selected service

Centralised (Market, possibly brokered) place to advertise/discover Web services


Web Service Standards: WS-* extensions

The term “WS-*” refers to the second generation of Web servicesstandards/specifications.On top of the basic standards (WSDL, SOAP and UDDI), theseextensions focus on providing supports for various issues in enterprisecomputing environment


Web Service Standards: WS-* extensions

e.g., WS-Security (wsse:)

<soap:Envelope>

<soap:Header xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext">

<wsse:UsernameToken>

<wsse:Username>scott</wsse:Username>

<wsse:Password Type="wsse:PasswordDigest">

KE6QugOpkPyT3Eo0SEgT30W4Keg=</wsse:Password>

</wsse:UsernameToken>

</soap:header>

<soap:body> ...</soap:body>

e.g., WS-ReliableMessaging (wsrm:)

<soap:Envelope>

<soap:header>

<wsrm:sequenceacknowledgement>

<wsrm:identifier>http://Business456.com/RM/ABC</wsrm:identifier>

<wsrm:acknowledgementrange lower="1" upper="1" />

<wsrm:acknowledgementrange lower="3" upper="3" />

</wsrm:sequenceacknowledgement>

</soap:header>

<soap:body> ...</soap:body>


Business Processes - Modelling and Implementation

What is a business process?

The word “process” could mean: a program running in an OS, a procedureto handle ‘work’ (e.g., processing an error, message), a set of proceduresfor achieving a goal ... In each case, the connotations are movement, workand time.

Normally, we use the term “business process” to refer to the step-by-steprules specific to the resolution of some business problem, e.g., travelbooking, hiring an employee, applying for a university, ...

More specifically:

A collection of activities performed by human users or softwareapplications that together form the different steps to becompleted to achieve a particular business objective.


Business Processes - Modelling and Implementation

Of course ... this is also a business process ...

Mentioned earlier that we consider “business process” as glue to put Web servicestogether. For COMP9322 context, business process technology is the one thatimplements “’application integration logic”’


Business Processes in Web Services

The technique is called Web Service Composition or ServiceOrchestration (central controller view).e.g., the procurement client implementation = composed service;

1 Sends requestQuotes to two different suppliers.2 Chooses the supplier that offers a better deal.3 Obtains an approval from its finance department4 Sends an order and then makes the payment

customer(client)

supplier(Web Service)

another supplier(Web Service)

approval(Web Service)

requestQuote

orderGoods

makePayment

requestQuotenotifyPayment


Web Service Composition

e.g., the client program itself can be a procurement ’Web Service’ to otherclients

supply chain

inventorymanagement

accounting

procurement

approvalstocktake data miningsupplier

another supplier

An Integrated Application

Once it becomes a web service, it may be integrated into a biggerapplication as a component that provides procurement functionality.

This allows to maintain higher levels of abstraction (i.e., the ’composer ofWeb services’ does not necessarily know the “inside” of each service


Web Service Composition Development

External services

graphical programming environment

WS composition

Schema Developer

SchemaDefinitionsSchemaDefinitions

Schemaand WS

Definitions

SOAP engine

Web service composition enrivonment

other service

other service

other service

run-time environmentInternal

SOAP engine

SOAP engine

SOAP engine

Conversationcontroller

other service other

service other service


A Graphical Development Env. (e.g., Eclipse plugin)


Business Process Execution Language (BPEL)

BPEL is one of the most popular standards for Web Service composition(referred to as “business process” in this language). BPEL Specification:OASIS standard - http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html

BPEL is an XML programminglanguage. Two types of files:

WSDL files: specifyinginterfaces of the servicesimplemented by and calledby the process

BPEL files: each encodes, inXML form, the definition ofa process including activities,routing options, etc.

BPEL in WS-* Stack

Transports

Messaging

Description and Discovery

Transactions Reliability Security

Business Processes Management

First Generation WS

Second Generation WShttp://www.ibm.com/developerworks/webservices/standards/


BPEL : Basic Activities


BPEL : Structuring Activities (Nesting)


BPEL concepts: .bpel (process) and .wsdl (interfaces)

The result of a composition (business process) using BPEL isrecursively published as WSDL.BPEL processes interact with WSDL services exposed by businesspartners


BPEL concepts: partners and partner link types

BPEL, as the controller in the orchestration, is ’consumed’ by services and also’consumes’ services.

{ {Partner Link Partner Link


BPEL concepts: partners and partner link types

partners are the actors in acomposition who play roles.

partner link types characterizesthe conversational relationshipbetween two services by definingthe “roles” played by each ofthe services

Each role in a partner link typeis linked with a WSDL port type

Web services playing the role arerequired to support suchoperations

in WSDL

in BPEL


BPEL Design - I declare what I need and offer


BPEL in a nutshell

Scope of the BPEL specifications:

Supplier Process (BPEL)

receive orderGoods

invokecheckLocalStock

invokecheckShipAvailable

invokecancelOrder

invokeconfirmOrder

Customer

local service offered by the

supplier

Warehouse

orderGoodsconfirmOrder

cancelOrder

checkLocalStock

checkShipAvailable

inStock=false

inStock=true

shipppingAvailable=false

shipppingAvailable=true

Roles

Port Types

coordination, variables,exception handling, message correlation

Variables:{warehouse: URIinStock, shippingAvailable: boolcustomer: String}

(Partner Links and Partner Link Types)


BPEL

Study the lecture notes and lab again (the BPEL examples) ...

Flow and Links

Message Correlation


Workflow/Process Modelling

Static Modelling vs. Process-Oriented Modelling

What does (or does not) an ER diagram tell you? e.g., an ER model for Insurance Claim


Processing Modelling: eg., insurance claim

1. Recording

2. Establish Type

3. Policy 4. Premium

5. Reject?

6. Reject!

7. Size of claim 9. Emergency?8. Assessor

11. Settlement

12. Reaction

13. Objection

14. Proceedings

10. Measures

16. Close

15. Pay


Processing Modelling

.basic terminology

tasks: a process that cannot be subdivided (unit of work)

sequence: some tasks need to be performed in a strict order

selection (’if ...’): certain tasks do not need to be carried out

parallel: some tasks can be performed in parallel

synchronisation: some tasks need to wait for the result of previoustasks

.modelling languages

petri net

BPMN


Modelling Workflows with Petri Nets

Classical Petri Nets

A Petri Net consists of places (circle) and transitions (rectangle)

claim record underconsideration

pay

send_letter

ready

token transition place

Two types of arcs: a place → a transition, a transition → a place

These arcs determine input places and output places

Places hold tokens: tokens can be distributed among the places(through firing of a transition)

The firing of transitions is subject to strict rules


Nicer Notations - BPMN

Tasks, Gateways, Message Flows, Swimlanes/Pools


Workflow Management Systems

Scheduling and work allocation are the basic tasks of a WfMS.

Resource Allocation Broker

Workflow Engine

Workflow EngineWorkflow EngineWorkflow Definitions

Workflow Designer

completed work items

outbound queue

inbound queue

resource 1

resource 2

resource n

The resources that interact with the engine could be human/softwareservices or a mix of the two.


The idea is a model to execution ...


Alternative Service Implementation - REST ...

REST Principles

Resources:

Resource: Any *thing* (noun) that is worthy of being given a uniqueID (URI) and be accessible via client

Resources are something the server is responsible for managing

Resources must have representations to be ’transmitted’ to client

Resources are ’addressable’ ...

e.g., resources in the starbucks example: order, payment (represented inXML) ... resources in the assignment ??


REST: Uniform Interface

Uniform Interface: Uniform ‘verbs’ that go with the resources (noun)

Given a resource (coffee order): a representation in XML

<order xmlns="urn:starbucks">

<drink>latte</drink>

</order>

Resources and Uniform Interface

POST /starbucks/ordersreturns: location: /starbucks/orders/order?id=1234

GET /starbucks/orders/order?id=1234

PUT /starbucks/orders/order?id=1234

DELETE /starbucks/orders/order?id=1234


Connectedness/Links

Connectedness/Links: Resources may contain links to other resources

e.g., Order resource is linked to Payment resource

In response to POSTing an order

201 Created

Location: /starbucks/orders/order?id=1234

Content-Type: application/xml

Content-Length: ...

<order xmlns="urn:starbucks">

<drink>latte</drink>

<link rel="payment" href="/starbucks/payments/order?id=1234"

type="application/xml"/>

</order>

Both forward/backward links, when possible (e.g., order having ’cancel/delete’ link)


REST: Safety and Idempotency

Safety and Idempotency

GET (and HEAD): safe

PUT, DELETE: idempotent

POST: not safe nor idempotent

The two properties let a client make reliable HTTP requests over anunreliable network.

Your GET request gets no response? make another one. It’s safe.

Your PUT request gets no response, make another one. Even if yourearlier one got through, your second PUT will have no side-effect.

Of course ... these properties are something YOU have to enforce in yourown REST implementation ...


REST Satefy, Idempotence


Multiple representations: One API for All

One resource, multiple representations (it is the client’s choice):


Building Workflows with REST

The customer workflow:

OrderPlaced

OrderUpdated

Paid DrinkReceivedPlace Order Pay Pickup

Order Updated

Update AcceptedUpdate Rejected

The barista workflow:

OrderChosen

DrinkMade

DrinkReleased

LookupNext Order

MakeDrink

Take Payment

LookupNext Order

Each transition in two state machines is implemented as a RESTFulHTTP interaction with a Web resource. Each transition is thecombination of a HTTP verb on a resource via its URI, causing statechanges (i.e., progression in the workflow).


REST and scalability

Being Statelessness:

Every action happens in isolation: This is a good thing!

In between requests the server knows nothing about youKeeps the interaction protocol simplerMakes recovery, scalability, failover much simpler too

Be work-shy - needs ’server-client’ collaboration:

Provide guard clauses in requests so that servers can determine easilyif there’s any work to be done

If-Modified-Since, If-None-Match/ETag

Web infrastructure uses these to determine if its worth performing therequest

And often it isn’t, so an existing representation can be returned


REST and security

REST relies on the elements of the Web for security too ...

Basic security properties ?

HTTPS (SSL)

“Strong” server authentication, confidentiality and integrity protection

The only feasible way to secure against man-in-the-middle attacks

Not cache friendly

Performance vs. security – choice.


REST and security

Security properties: authentication and authorisation:

Authentication (401 Unauthorized) vs. Authorisation (403 Forbidden):

HTTP Basic (and Digest) Authentication: IETF RFC 2617

Have been around since 1996 (Basic)/1997 (Digest)

Pros:

Respects Web architecture:stateless design (retransmit credentials)headers and status codes are well understood:

Cons:

Basic Auth must be used with SSL/TLS (plaintext password)Only one-way authentication (client to server)

OAuth Protocol - now standard HTTP-based authorisation method toaccess third-party content


Web API Design for RESTful services

API - a way for the clients to access your services (or is it a way for you toexpose your servics to the clients ?)

A well-designed API should make iteasy for the clients to understand yourservice without having to “study” theAPI documents in-depth.

self-describing, self-documenting asmuch as possible

the clients are like developers yourself,so probably they would like to have anAPI that is easy to pick up and go

The RESTful service principles actuallygive us a straightforward guideline fordesigning the Web API ...


Start with URI Design ...

We want to move away from the RPC-style interface design wherelots of ‘operation names’ are used in the URL

e.g., /getCoffeeOrders, /createOrder, /getOrder?id=123

We want to separate the resources from the actions

Use nouns (preferrably plurals) (e.g., orders)

e.g., /orders, /renewal notices,

Could show relationships:

e.g., /orders/{order}/payment, /customers/{customer id}/orders

These resources indicate the type of ‘concepts’ the clients canmanipulate in your service


How to Apply Actions and Status Codes

Resource (URI) GET POST PUT DELETE/coffeeOrders get orders new order batch update ERROR (?)

return a list,status code200

return neworder + newURI, statuscode 201

status code(200, 204)

status code(e.g., 400 -client error)

/coffeeOrders/123 get 123 ERROR (?) update 123 delete 123

return anitem, statuscode 200

return errorstatus code(400 - clienterror)

updateditem, statuscode (200,204)

status code(204, 200)

Note: PUT could also return 201 if the request resulted in a new resource


Decide on the Design of your Responses

Should support multiple formats (JSON, XML at least) and allow theclient content negotiation to do its jobUse simple objects.

A single result should return a single object.Multiple results should return a collection - wrapped in a container.

/coffeeOrders/123{ “Id”: “123”, “type”: “latte”, “extra shot”: “no”, “payment”: { “date”: “2015-04-15”, “credit card”: “123457” }, “served_by”: “mike”}

/coffeeOrders{ “resultSize”: 25, “results”: [ { “id”: “100”, “type”: “latte”, “extra shot”: “no”, “payment”: { “date”: “2015-04-15”, “credit card”: “22223” }, “served_by”: “sally” }, { … }, ]}


Taking your API to the Next Level

SOAP-based service vs. HATEOAS

SOAP-based service is on a single endpoint. The same endpoint receivesrequests for operations. The body of request details which operation torun with what parameters.

In SOAP, HTTP is merely a carrier of the SOAP messages. HTTP itselfdoesn’t play a big role in the protocol of the servicedesign/implementation/interaction.

In REST, HTTP is at the center of the API. Given that HTTP (Hypertext)is about allowing the users to navigate the site using links, HTTP-basedAPI also should allow the clients to navigate the service using links.


Not using HATEOAS

Not implementing the links in REST API would look like this:

/coffeeOrders{ “resultSize”: 25, “results”: [ { “id”: 100, “type”: “latte”, }, { “id”: “101”, “type”: “cap”, { … }, ]}

GET /coffeeOrders/100

{ “Id”: “100”, “type”: “latte”, “extra shot”: “no”, “payment”: { “date”: “2015-04-15”, “credit card”: “22223” }, “served_by”: “sally”}

You assume that the client knows how to construct the next requestpath (i.e., combine /coffeeOrders and id:100) - maybe by readingyour API document?


Using HATEOAS/coffeeOrders/123

{ “Id”: “123”, “type”: “latte”, “extra shot”: “no”, “payment”: { “date”: “2015-04-15”, “credit card”: “123457” }, “served_by”: “mike” “links”: [ { “href”: “/coffeeOrders/123”, “rel”: “self” }, { “href”: “/payments/123”, “rel”: “next” } ]}

/coffeeOrders{ “resultSize”: 25, “links”: [{ “href”: “/coffeeOrders” “rel”: “self” }, { “href”: “/coffeeOrders?page=1”, “rel”: “alternative” } { “href”: “/coffeeOrders?page=2”, “rel”: “nextPage” } ], “results”: [ { “id”: “100”, “type”: “latte”, “links”: [ { “href”: “/coffeeOrders/100”, “rel”: “details” }] }, { … }, ]} H. Paik (CSE, UNSW) Wrap Up Wrap Up Week 64 / 82

The Richardson Maturity Model

Leonard Richardson: can we measure to what level your service isRESTful?

Level 0: One URI (single endpoint) exposed, requests containoperation details

Level 1: Expose resource URIs - individual URIs for each resource.Requests could still contain some operation details

Level 2: HTTP Methods - use the standard HTTP methods, statuscodes with the resource URIs,

Level 3: HATEOAS - self-documenting responses, responses includelinks that the client can use

in picture: https://technobeans.files.wordpress.com/2012/09/richardson-maturity-model.png


h

REST vs SOAP - Technology

User-driven interaction via richWeb client application

Few operations on manyresources

URI - consistent naming forresources

focus on Scalability andperformance

Distributed hypermedia systems

Composition= mashups

Orchestrated, reliableevent/message flows

Many operations (WSDLinterface) on few resources

Lack of standard namingmechanism

focus on design of integratedenterprise applications

composition = businessprocesses


REST vs SOAP - ProtocolREST vs SOAP - ProtocolXML in – XML out (with POST)URI in – XML out (with GET)

SOAP in – SOAP out (with POST)

Self-Describing” XML

HTTP only

Strong Typing (XML Schema)

“Transport independent”HTTP only

HTTP/SSL is enough – no need for more standards

Transport independentHeterogeneity in QoS needs.Different protocols may be used

HTTP is an application protocolSynchronous

HTTP as a transport protocolSynchronous and Asynchronous

Do-it-yourself when it comes to “reliable message delivery”, “distributed transactions”

Foundation for the whole WS* advanced protocol stack

45

p

REST vs. SOAP Design MethodologyIdentify resources to be exposed as services (e.g., book catalog, purchase order)

List what are the service operations (the “verbs”) into the service’s WSDL documentp )

Define “nice” URLs to address them

Define a data model for the content of the messages exchanged by the service (XML

Distinguish read-only and side-effects free resources (GET) from modifiable resources (POST, PUT, DELETE)

e c a ged by e se ce (Schema data types)

Choose an appropriate transport protocol to bind the operationPUT, DELETE)

Relationships (e.g., containment, reference) between resources correspond to hyperlinks that can

protocol to bind the operationmessages and define the corresponding QoS, security, transactional policies

correspond to hyperlinks that canbe followed to get more details

Implement and deploy on Web server

Implement and deploy on the Web service container (note the corresponding SOAP engine end-point)

46

server

Is it really one or the other?

Each have their advantages and disadvantages, and so their use casesand so their use cases

Choosing the right one is an architectural decision that should be made based on the application

SOAP-based Web services can be RESTfulSOAP 1.2 is not restricted to use over HTTP POST

SOAP 1 2 HTTP binding supports HTTP GETSOAP 1.2 HTTP binding supports HTTP GET

Response can use SOAP extensions, e.g. encryption of part of the message

One can design a system made of resources and use SOAPOne can design a system made of resources, and use SOAPwith HTTP GET and POST where appropriate

Web services technologies can be useful in the context of non SOAP based REST ser ices

47

non-SOAP-based REST services

RESTful Web Services


REST vs. SOAP Design MethodologyREST vs SOAP - Protocol

XML in – XML out (with POST)URI in – XML out (with GET)

SOAP in – SOAP out (with POST)

Self-Describing” XML

HTTP only

Strong Typing (XML Schema)

“Transport independent”HTTP only

HTTP/SSL is enough – no need for more standards

Transport independentHeterogeneity in QoS needs.Different protocols may be used

HTTP is an application protocolSynchronous

HTTP as a transport protocolSynchronous and Asynchronous

Do-it-yourself when it comes to “reliable message delivery”, “distributed transactions”

Foundation for the whole WS* advanced protocol stack

45

p

REST vs. SOAP Design MethodologyIdentify resources to be exposed as services (e.g., book catalog, purchase order)

List what are the service operations (the “verbs”) into the service’s WSDL documentp )

Define “nice” URLs to address them

Define a data model for the content of the messages exchanged by the service (XML

Distinguish read-only and side-effects free resources (GET) from modifiable resources (POST, PUT, DELETE)

e c a ged by e se ce (Schema data types)

Choose an appropriate transport protocol to bind the operationPUT, DELETE)

Relationships (e.g., containment, reference) between resources correspond to hyperlinks that can

protocol to bind the operationmessages and define the corresponding QoS, security, transactional policies

correspond to hyperlinks that canbe followed to get more details

Implement and deploy on Web server

Implement and deploy on the Web service container (note the corresponding SOAP engine end-point)

46

server

Is it really one or the other?

Each have their advantages and disadvantages, and so their use casesand so their use cases

Choosing the right one is an architectural decision that should be made based on the application

SOAP-based Web services can be RESTfulSOAP 1.2 is not restricted to use over HTTP POST

SOAP 1 2 HTTP binding supports HTTP GETSOAP 1.2 HTTP binding supports HTTP GET

Response can use SOAP extensions, e.g. encryption of part of the message

One can design a system made of resources and use SOAPOne can design a system made of resources, and use SOAPwith HTTP GET and POST where appropriate

Web services technologies can be useful in the context of non SOAP based REST ser ices

47

non-SOAP-based REST services

RESTful Web Services


Data Services (in a “lightweight” sense)

Data is everywhere, but they are locked behind applications

Let us expose data (in a standard-sort-of way) so that it is easilyshared over “the Web”

Making it easy for clients (mainly other applications/services) toaccess the data

New way of ’thinking’ about data integration and interoperabilityacross a broad range of data consumers


Data Services

Data-level integration (i.e., many data sources) – wants/needs uniformaccess and management of data across all data sources – one layer to dealwith from data consuming application view point


What is a Data Service?

A data service is a query-based access layer that facilitates theability of calling applications to access and manage disparate data.

Typically, a data service models a unit of information, such as acustomer, sales order, or product.

Data service functions:

Read functions: Returning data in the form of the data service XMLtype.Navigate functions: Returning data from related data services.


XML and Data Services

Just like Web Services are built around ’agreed standards’, Dataservices should be built around standards.

However, there is no consensus yet on the standard representationand access models. But generally agreed that the XML and its accesstechnologies - XSLT/XQuery are most suitable.

Some commercial frameworks:

Microsoft ADO.NET Data services

BEA/Oracle AquaLogic Data services

IBM WebSphere eXtreme Scale REST data service

Core/Common Technologies: X.M.L. again! (XSLT and XQuery)


XQuery, XSLT and XPath

2H. Paik (CSE, UNSW) Wrap Up Wrap Up Week 73 / 82

XSLT ... for Transformation

Output Process

XML

StyleSheet

Transformation Process

XML

Text

HTMLSource

DocumentSource Tree

Result Tree

documents are represented as ’Trees’

XSLT relies on the XML parser to get the trees

two steps: structure transformation, formatting and serialisation


XQuery - sample

Sample XQuery

<bib>

{for $b in doc("http://bstore1.example.com/bib.xml")/bib/book

where $b/publisher = "Addison-Wesley" and $b/@year > 1991

return

<book year="{ $b/@year }">{ $b/title }

</book>

}</bib>

Can you ’read’ it ? ... We also went through a few practical examples ofusing XQuery ... revise them.


A Data service platform: DataDirect


Evolution of Information System Architectures

3

13

Issues with 2-tier architecture

• The client is responsible for knowing where things are, how to get to them, and how to ensure consistency!

• Little that can be done to solve this problem within the 2-tier model. An additional level of indirection is needed: The Middleware

Server A Server B

• Problematic for a client to access multiple apps:

– the systems don’t know each other

– no common business logic.

© Gustavo Alonso, ETH Zurich14

3-tier architecture: Middleware arrives

• Middleware is a level of indirection between clients and other layers:

– Simplifies the design of the clients by reducing the number of interfaces.

– Encapsulates integration logic and high level application logic.

– Locates resources, accesses them, and gathers results (mediates between business logic/data layer).

Middleware or global application logic

clients

Local resource managers

Local application logic

Server A Server B

middleware

© Gustavo Alonso, ETH Zurich

15

N-tier Architectures: The Web arrives

• N-tier architectures result from connecting several 3- tier systems and/or adding a layer to allow clients to access the system through a Web server (“Web layer”)

• The Web layer is hosted in a Web application server: a middleware accessible through the Web.

• Web application servers are taking also parts of the functionality of traditional middleware – the boundary between the Web layer and the middleware is blurred.

client

resource management layer

application logic layer middleware

presentationlayer

Web server

Web browser

HTML filter

© Gustavo Alonso, ETH Zurich16

Flexibility versus Performance

• The more boxes, the more modular the system: more opportunities for distribution and parallelism; more extensibility points.

• The more boxes, the more arrows: more connections need to be maintained, more coordination is needed. Complexity increases.

• The more boxes, the greater the number of context switches and intermediate steps to get to the data. Performance degrades.

• System designers try to balance the flexibility of modular design with performance demands.

There is no problem in system design that cannot be solved by

adding a level of indirection. There is no performance

problem that cannot be solved by removing a level of

indirection.

© Gustavo Alonso, ETH Zurich

17

Evolution of Information System Architectures

Workflow / Middleware

Client Device

Database System

Application

Data

Control Flow

User Interface

Application Logic

Application

Data

Integration Logic

User Interface

Application Logic

Database System

Application

Data

Integration Logic

Application Logic

User Interface

Client Device

Database System

Application

Data

Integration Logic

Application Logic

User Interface

BPMS / SOA Platform

Client Device

Database System

Application

Data

Integration Logic

Service

User Interface

ServiceService

1960s 1970s 1980s 1990s 2000s

© Michael Rosemann, QUT18

Integration Styles (classified by layer)

• Data level– Shared/synchronized databases– Data warehousing

• Business logic level– Reuse application APIs– File transfer– RPC, message queues, workflow

• Presentation level– Screen scraping, revamping – Portlets, mashups

F. Daniel, J. Yu, B. Benatallah, F. Casati, M. Matera, R. Saint-Paul: “Understanding UI Integration”. IEEE Internet Computing, Volume 11, Number 3, May/June 2007, IEEE, Pages 59-66.


Quiz 1-4


So ... for exam questions ...

Exam questions are sourced from: Lecture Notes, Quizzes, Labs andAssignments

2 hours, Total 55 Marks (will be mapped to 60)

Section 1: 25 Multiple choice + short answer questions (1 markeach) - choose all that apply

Section 2: 6 written answer questions (each 4-5 marks).

one from Intro lectureone from WSDLone from SOAPone from XSLT (coding)one from BPMN (draw one)one from REST (design/coding)


Sample Questions

Multiple ChoiceWeb Services allow service-to-service interactions using:

1 Remote procedure interaction style

2 Document interaction style

3 REST Invocation interaction style

4 Asynchronous notification

5 Publish/subscribe event architectures

6 1 and 2

7 1, 2, and 4

8 None of 1, 2, 3, 4, and 5


Sample Questions: MCQ

Which of the following is NOT a correct statement about BPEL? :1 It provides constructs for specifying data caching policies2 It provides constructs for specifying control flow logic among Web

services3 It defines roles of the partners that are involved in providing a

composite service4 It provides constructs for specifying data flow logic among Web

services5 It provides constructs for specifying exception handling policies

In XPath, ./para/para is short for:1 self::node()/descendant-or-self::node()/child::para2 ./[child::para/child::para]3 self::node()/child::para/child::para4 self::node()/child::node()/[name=‘para’]


Sample Questions

Written Answer

Describe with an illustrating example the structure of SOAP message.

Discuss the basic characteristics of Web services.

Describe the differences between REST and WS-* services.


University of New South Wales School of Computer Science ...

Documents