Formulario e schema dell'esame di Process and Service Design

N

1 abbiamo noto

- la

1 2 ?

D

end

- messere

con

charagraphy

mo

nel

. . . . . collaboration

↳ si

Nel collbation bianco

invertiti :

colori Sends

· receiver

i sono :

Receives

x X vende

scuo :

I sottoprocessi stat

tutti event

hanno ed end event

· una un

Si ?

vender

Coto

multi instance

· prò una

usar Do stuff

Con intende

attività nel

altre

fare

· A

mezzo

a i :... -

~ until

Receiver

attività Receive attento

Si cicliche X dice

quando "ever time"

B

-- N

· time .:

expired

come :

avve is a

possono y or

.

"For ander

each x"

Per terminar evento

· sola devo

instanza nella

di multipliatane (come

inseriva

una un mesaggio

una un ma

,

sotto entità rettangolo sotto

del tutte

nel altimenti terminerebbero ⑳

instanze

la

, : -

processo

man -

--LD

11

il de

NB : messaggio aniva può asse :

~

interating il flau cambia strada

tutta un'altra

il

- processo

e seque

: : continuano

mon-internativa actività padllo

l in

-

Un sttopasso notazioni

(ricordati

multimatanca

· la completezza

solo per

esse

può una ma

,

Nel collaboration hai mondati

⑧ allora anche

sincana messaggi poi

comunicazione sono

e

se

direttamente posto item

actività

delle

al send allora

invece è

inserire ~ se è

,

nel charoqaphs

le

meglio for activity come (Gremuleita)

Se ho partecipant dipartimenti entrambi

due modellali

deno ?

· separati

un con no

appur

,

Nella stema

· due dipartimenti

sotto

entità esplicita

(macro

pull lo scambio di

con man si , ma

menarsi

control

sfrutto flow

il

si

Kara rettando :

· del altrimenti

lato

V vender dx

or se e

sx a

, Sends Receives

x

Meglio eventi nel charogoghy pefe-incasino intilmente

· le

non mar case

Atomic activity

· tose sender

1 1 receive

:

Activity e n >

receive no icono

vor collaboration

nel

· !

Et

rober Mul plude

/bosic

transitions

stown a plo-pla

tra-tra

no no

,

mo a

sound)

S (Aud

AND O

SPUT merce

voR

Schemas

Service Design

1 - Service Oriented Architecture

Definition: SOA as architectural style to support SO

separation of concerns

composition

visibility and discoverability

SO Design Principles (8)

Standardized Service Contract

Functional → OpenAPI

Non-functional → non standard

Machine readable

Loose coupling

Independent from the consumer

Based only on the contract, not on the outside logic

Abstraction

Hide implementation

Only minimal information included in contract

Reusability

Allow reuse in other context, to generate value (API economy)

Scenario-agnostic, flexible, for different types of consumers

del tipo

Lindipendente di consumer

Autonomy

Self-* properties: self healing, configuration, optimizing,...

Properties are provided by the environment

Services have functional boundaries, and no overlap

Statelessness

State stored by consumer: scalability and flexibility

Contracts allow transmitting state data

State have to be parsed

Discoverability

Descriptive metadata, also human readable

Visibility level

UDDI has failed (lack of flexibility)

Registries and Service profile documents

Composability

Composition by Business process

Service reuse is not very important

Controllers may be stateful

SOA Benefits

Consistency in functionalities and data representation

Decoupling between units

Implementation independence

Reuse and composition

Predictability and availability

Easier integration

SOA Project lifecycle

Service inventory analysis

Service analysis (modeling)

Service contract design

Logic design

Development

Testing

Deploy and maintenance

Usage and monitoring

Discovery

Versioning

Reference architecture (5 + 4)

Goal: blueprint for design and evaluation

Structure: 5 layers and 4 cross-cutting layers

Provider layers (Bottom up):

Operational: applications, DB, ERP, CRM, …

Service component: software implementing the services

Hides complexity

Service layer: service description

Service search and composition

Visibility

Consumer layers (Bottom up):

BP: processes as service composition

Orchestration, choreography

Business-IT alignment

Consumer: access provided to the final user

Different channels

Can “skip” some layer

Cross cutting layers

Integration

QoS (security, monitoring)

Information architecture

Governance

Goal: Boundaryless information flow

Information should flow in the “internal space” and flow outside of it

Even if the space is “composed” of applications

Avoid silos

ESB: a possible solution

Common environment

Problems: cost and integration issues

Vocabulary agreement

Agreement on description…

Easier a “point to point” call to services

2 - API Design

Service Description

Separation of interface and implementation

1. Design the implementation

Functional and non-functional

Affected by technical implementation and design choice (how to serve stuff)

Good API: valuable, fits the needs, understandable (by humans and machines), easy

to integrate, reliable/secure/performant

Design choices

Architectural → pattern and style

Front-end → how the customer “sees” the service

Back-end → connect the business logic to API

Non-functional → cross cutting layers of SOA-RA

API design process

Consumer oriented: API as a product

Steps (6)

Domain analysis: identify users, purpose, what the user use it for

Architectural design

Architectural patterns (client-server, proxy, facade pattern, …)

Architectural style: RPC, SOAP, REST

API description

Prototyping

For critical aspects

Mock-up and code generation

Implementation: professional artifact

Publish

Website

Repository

Maintenance: remember backward-forward compatibility

Description Languages

Depending on the architectural style

SOAP → WSDL

REST → OpenAPI

Machine readable

Used for

Documentation

Design repository

API and client implementation

Simulation

Discovery

Architectural Design Decisions

Requirements

Responsibilities (what)

Data gathering, structuring, formatting

Data delivery

Security

Desirable properties (How)

Consumer-centric

Simple and clean (easy to understand, few parameters)

Clear (simple interaction)

Forward and backward compatible

Architectural patterns

Client-server → loose coupling, stateful or stateless

Facade pattern

Proxy

Architectural styles

RPC

SOAP → i.e. XML-ified RPC

REST

HATEOAS

Streaming

3 - REST API

Improve scalability wrt RPC-SOAP → Resource-oriented instead of method-oriented

Based on HTTP, plus some constraint (6)

Client server → decoupling

Uniform interface → HTTP methods and return codes

Stateless → all data is in the request

Cacheable → improve performance

Layered system → hide complexity

Code on demand (optional)

Statelessness

Two types of state

Application state → interaction client/server, context

Resource state → it’s about the resources, not client and server

We call it “resource representation”

Separation of resource and representation

media-type field

We are stateless in the sense of application state only

Uniform Interface and resources

Uniform interface

Describes API, resources, representations concetti

Resource-representation decoupled distingue i

Few methods

HATEOAS: messages include also the information to manage the resource

Reduce a-priori knowledge

Resource → an abstract data model

URI

Linked to other, or built in a hierarchy

Serializable → obtain a representation

Resource archetypes

Instance: atomic object, can contain link. Singular noun

Collection: server-managed repository. Plural noun

Store: client-managed repository. Plural noun

Controller: models a procedure for actions that are not CRUD actions. Use a

verb as name

e.g. POST /alerts/245743/resend

Content-type: specify the format of the content

Accept: specify the format required in the response

Request and responses

PUT: insert in a store or update a mutable resource

POST: insert in a collection or execute a controller

HEAD: get metadata about state

OPTIONS: get metadata about interactions

Parameters

Used to filter, sort, project a collection

Richardson Maturity Model

REST in three steps: URI, verbs, HATEOAS → like a “roadmap”

Level 0: single path, single method to serve all → not even REST

Level 1: each resource has its URI

Level 2: verbs → use the “correct” HTTP method to interact

Level 3: HATEOAS

Business Processes

4 - BPM

BP definition: collection of events, activities and decisions, involving actors and

objects. The goal is an outcome that is valuable to a customer

Organization: social entities with a goal, composed by structured activities, linked to

the external world

Porter’s value chain

Primary processes: characterize the organization (5)

Inbound logistic

Operations

Outbound logistics

Marketing and sales

Services

Support processes (4)

Firm infrastructure: finance, accounting, legal,...

HR

IT

Procurement: e.g. purchasing paper

Classification (5)

Organizational vs. Operational BP

Business goal and strategies

Organizational BP: high level, natural language

specifiche

Operational BP: formal specification, implementation agnostic

Implemented BP: executable BP

Intraorganizational (orchestration) vs Choreography

Automation vs. Human-in-the-loop

Repetitive vs. occasional

Structured vs. ad-hoc (e.g. case management)

BP Lifecycle (4)

Design and analysis

Design: BP identification (surveys) and modeling

Analysis: validation (reflects the need), simulation, verification (si comporta

come atteso)

Configuration

Implementation in a BPMS

Integration of existing SW

Adoption of SOA a