lecture 24

62
Lecture 24 E nterprise S ystems D evelopment ( CSC447) COMSATS Islamabad Assistant Professor

Upload: barclay-young

Post on 31-Dec-2015

19 views

Category:

Documents


0 download

DESCRIPTION

Lecture 24. COMSATS Islamabad. E nterprise S ystems D evelopment (  CSC447 ). Muhammad Usman, Assistant Professor . Service Orientation. Overview. Services, service description, service communication Service-Oriented Architecture (SOA) - PowerPoint PPT Presentation

TRANSCRIPT

Lecture 24

Enterprise

Systems

Development( CSC447)

COMSATS Islamabad

Muhammad Usman, Assistant Professor

Service Orientation

3

Overview

Services, service description, service communication Service-Oriented Architecture (SOA) Web services SOSE: Service-Oriented Software Engineering

4

Italian restaurant analogy

Restaurant provides food: a service

After the order is taken, food is produced, served, …: service may consist of other services

The menu indicates the service provided: a service description

The order is written down, or yelled at, the cook: services communicate through messages

5

Main ingredients

Services Service descriptions Messages

Implementation: through web services

6

Other example

Citizen looking for a house: Check personal data System X Check tax history System Y Check credit history System Z Search rental agencies System A,B …

7

What’s a service

Platform-independent computational entity that can be used in a platform-independent way

Callable entities or application functionalities accessed via exchange of messages

Component capable of performing a task

Often just used in connection with something else: SOA, Web services, …

8

What’s a service, cnt’d

Shift from producing software to using software You need not host the software Or keep track of versions, releases Need not make sure it evolves Etc

Software is “somewhere”, deployed on as-needed basis SaaS: Software as a Service

9

Key aspects

Services can be discovered Services can be composed to form larger services Services adhere to a service contract Services are loosely coupled Services are stateless Services are autonomous Services hide their logic Services are reusable Services use open standards Services facilitate interoperability

10

Service discovery

Service registry

Service provider

Service requestor

lookup

bind

publish

11

Service discovery

Rental agency 1Rental agency 2

Rental agency 2Municipality

system

Apartment(immediate, cheap) publish

Agency 1

Apartment?

Rental agreement

Rental agency 1

Rental agency 1

12

Service discovery

Discovery is dynamic, each invocation may select a different one

Primary criterion in selection: contract

Selection may be based on workload, complexity of the question, etc optimize compute resources

If answer fails, or takes too long select another service more fault-tolerance

13

Is discovery really new?

Many design patterns loosen coupling between classes

Factory pattern: creates object without specifying the exact class of the object.

14

Services can be composed

Service can be a building block for larger services

Not different from CBSE and other approaches

15

Services adhere to a contract

Request to registry should contain everything needed, not just functionality

For “normal” components, much is implicit: Platform characteristics Quality information Tacit design decisions

Trust promises?

Quality of Services (QoC), levels thereof

Service Level Agreement (SLA)

16

Service discovery

Rental agency 1Rental agency 2

Rental agency 1Municipality

system

Apartment(immediate, cheap)

Agency 1

Apartment?

Rental agreement

17

Services are loosely coupled

Rental agencies come and go

No assumptions possible

Stronger than CBSE loose coupling

18

Services are stateless

Rental agency cannot retain information: it doesn’t know if and when it will be invoked again, and by whom

19

Services are autonomous, hide their logic

Rental agency has its own rules on how to structure its process

Its logic does not depend on the municipality service it is invoked by

This works two ways: outside doesn’t know the inside, and vice versa

20

Services are reusable

Service models a business process: Not very fine grained Collecting debt status from one credit company is not a

service, checking credit status is

Deciding on proper granularity raises lots of debate

21

Service use open standards

Proprietary standards vendor lockin

There are lots of open standards: How services are described How services communicate How services exchange data etc

22

Services facilitate interoperability

Because of open standards, explicit contracts and loose coupling

Classical CBSE solutions pose problems: Proprietary formats Platform differences Etc

Interoperability within an organization (EAI) and between (B2B)

23

Overview

Services, service description, service communication

Service-Oriented Architecture (SOA)

Web services SOSE: Service-Oriented Software Engineering

24

Service-Oriented Architecture

Architecture: the fundamental organization of a system in its components,

their relationships to each other and to the environment and the principles guiding its design and evolution

SOA: Any system made out of services?

25

What is SOA?

Infrastructure service layer

Orchestration/coordination layer

Business services layer

serv

ice b

us

service

serviceservice

service

logicalphysical

26

Service bus

Event-based messaging engine

Origin: EAI, solve integration problems

Often takes care of: Mediation: protocol translation, data transformation, etc Quality of Service issues: security, reliable delivery of messages, etc Management issues: logging, audit info, etc. Service discovery

Can be central (broker, hub), or decentral (smart endpoints)

27

Service coordination

Orchestration: central control

Choreography: decentral control

28

Overview

Services, service description, service communication Service-Oriented Architecture (SOA)

Web services

SOSE: Service-Oriented Software Engineering

29

Web services

Implementation means to realize services Based on open standards:

XML SOAP: Simple Object Access Protocol WSDL: Web Services Description Language UDDI: Universal Description, Discovery and Integration BPEL4WS: Business Process Execution Language for Web

Services

Main standardization bodies: OASIS, W3C

30

Coordination of Web services

BPEL4WS

WSDL

Java

WSDL

Java

WSDL

Java

31

Web services stack

BPEL4WS

WSDL UDDI

HTTP, FTP, …

SOAP

composition

description

messages

network

discovery

32

XML

Looks like HTML Language/vocabulary defined in schema: collection of trees Only syntax Semantic Web, Web 2.0: semantics as well: OWL and

descendants

33

SOAP

Message inside an envelope Envelop has optional header (~address), and mandatory

body: actual container of data SOAP message is unidirectional: it’s NOT a conversation

SOAP Message Structure

Request and Response messages Request invokes a method on a remote

object Response returns result of running the

method

SOAP specification defines an “envelop”

“envelop” wraps the message itself Message is a different vocabulary Namespace prefix is used to distinguish

the two parts

Application-specific message

vocabulary

SOAP Envelop vocabulary

SOAP Request Message

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body xmlns:m="http://www.stock.org/stock">

</soap:Body>

</soap:Envelope>

<m:GetStockPrice>

<m:StockName>IBM</m:StockName>

</m:GetStockPrice>

SOAP Envelope

Message

SOAP Envelope

Namespace

Message

Namespace

SOAP Response Message

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body xmlns:m="http://www.stock.org/stock">

</soap:Body>

</soap:Envelope>

<m:GetStockPriceResponse>

<m:Price>34.5</m:Price>

</m:GetStockPriceResponse>

SOAP Envelope

Message

Result

returned in

Body

Why SOAP?

Other distributed technologies failed on the Internet Unix RPC – requires binary-compatible Unix implementations at

each endpoint CORBA – requires compatible ORBs RMI – requires Java at each endpoint DCOM – requires Windows at each endpoint

SOAP is the platform-neutral choice Simply an XML wire format Places no restrictions on the endpoint implementation

technology choices

38

WSDL

Four parts: Web service interfaces Message definitions Bindings: transport, format details Services: endpoints for accessing service. Endpoint =

(binding, network address)

39

UDDI

Three (main) parts: Info about organization that publishes the services Descriptive info about each service Technical info to link services to implementation

40

UDDI (cnt’d)

Original dream: one global registry Reality: many registries, with different levels of visibility

Mapping problems

41

BPEL4WS

Three main parts: Partnerlinks: dependencies between services: who sends what to

whom Global variables Workflow model: “program”

BPEL4WS is an orchestration language; executable WS-CDL (Web Services Choreography Description

Language) is a choreography language; not executable

42

Overview

Services, service description, service communication Service-Oriented Architecture (SOA) Web services

SOSE: Service-Oriented Software Engineering

43

SOSE life cycle

Service orientedanalysis

Service orienteddesign

Servicedevelopment

Servicetesting

Servicedeployment

Serviceadministration

44

Terminology

service oriented environment (or service oriented ecosystem)

business process + supporting services

application (infrastructure) service

business service Task-centric business service Entity-centric business service

hybrid service

45

Terminology

orderfulfilmentservice

purchaseorder

service

sendutility

service

wrapperservice

customerprofileservice

hybrid services

business services

infrastructure services

entity-centric

verifyPO

service

task-centric

notificationservice

hybrid services

business services

infrastructure services

task centric

entity centric

46

Strategies for life cycle organization

Top-down strategy

Bottom-up strategy

Agile strategy

47

Top-down strategy

Service orientedanalysis

Service orienteddesign

Servicedevelopment

Servicetesting

Servicedeployment

48

Top-down SO analysis

Define enterprisebusiness models

Define enterpriseservice model

Compose SOA

Perform serviceoriented analysis

Service orienteddesign

....

step 1 step 2

step 3 step 4

step 1

step 4step 3

step 2

49

Bottom-up strategy

Model applicationservices

Design applicationservice

Developapplication

services

Testservices

Deployservices

application service = infrastructure service

50

SO analysis

SO design

Develop services

Test service operations

Deploy services

Revisit business(and process) services

Top-downanalysis

on-going

align withcurrent state

businessmodels

align withcurrent state

businessmodels

Agile strategy

51

Service oriented analysis

The process of determining how business automation requirements can be represented through service orientation

52

Goals of SO analysis

Appropriateness for intended use Identify preliminary issues that may challenge required

service autonomy Define known preliminary composition models

Service operation Service operation

candidatescandidates

Service candidates Service candidates

(logical contexts)(logical contexts)

53

3 Analysis sub-steps

Service orientedanalysis

Service orienteddesign

Defineanalysis scope

Identifyautomation

systems

Modelcandidate services

step 3

step 2

step 1

...

54

Step 1: Define analysis scope

Mature and understood business requirements S = ∑i Si, where smaller services may still be quite complex

Can lead to process-agnostic services/service operations (generic service

portfolio) services delivering business-specific tasks

Models: UML use case or activity diagrams

55

Order Fulfillment Process

start

receive PO

validate PO

POvalid

TransformPO

ImportPO

Send POto queue

stopSendnotification

yes

no

56

Step 2: Identify automation systems

What is already implemented? encapsulate replace

Models: UML deployment diagram, mapping tables

57

Order Fulfillment Process

start

receive PO

validate PO

POvalid

TransformPO

ImportPO

Send POto queue

stopSendnotification

yes

no

alreadyautomatedby Orderfulfillmentservice

same asprevious

same asprevious

(XML -> native format)(currently custom component)service candidate

(into accounting sys.)service candidate(currently custom legacy)service candidate

(to accounting clerk'swork queue)same as previous

58

Step 3: Model candidate services

How to compose services?

Service (candidates) conceptual model operations + service contexts SO principles

Focus on task- and entity-centred services

Models: BPM, UML use case or class diag.

59

Example service operation candidates

Receive PO document

PO processingservice

Validate PO document

(If PO document is invalid,)send rejection notification

(and end process)

Transform PO document into native

electronic PO format

<<include>>

<<include>>

...

60

Example business process logic

Not service operation candidates if PO document is valid, proceed with the transform PO

document step if the PO document is invalid, end process

61

Task- versus entity-centred services

Task-centred (+) direct mapping of

business requirements (-) dependent on specific

process

Entity-centred (+) agility (-) upfront analysis (-) dependent on

controllers

Reference

SE, Servic Orientation, Hans van Vliet

62