Corso di
Web Services
A A. 2010 2011
Domenico Rosaci
SOA
D. Rosaci
SOA
SOA: Bridging IT e Business
• L’importanza di SOA non è solo a livelli tecnologico
• Essa fornisce un ponte tra tecnologia e business
• L’IT fornisce interfacce ai business service e li
combina in applicazioni che supportano i rapidi
cambiamenti del business stesso
• Identificare l’insieme di servizi che un business
richiede al proprio IT non è semplice
• E’ necessaria un’attività specifica (Service
Identification) che determini i servizi e le loro
interdipendenze, così come i componenti a “grana
grossa” che li supportano
D. Rosaci
SOA
2
Patterns e SOA
D. Rosaci
SOA
3
Patterns e SOA
D. Rosaci
SOA
4
Patterns e SOA
• Il Self-Service business pattern permette agli utenti di
interagire con i business services.
• Il Collaboration pattern permette le collaborazioni tra business
• partners che in parte coinvolgono l’integrazione di servizi e in
parte coinvolgono persone e workflow
• L’Extended Enterprise business pattern permette ad un
business di interagire con altri business services.
• Questi Business patterns sono combinati al front-end usando
Access Integration pattern e al back-end usando Application
Integration pattern.
D. Rosaci
SOA
5
Example: Supply Chain
Management
• Scenario di business: Supply Chain semplificata per un
commerciante in elettronica (retailer)
• I consumers possono accedere al sito Web, consultare il
catalogo prodotti ed inserire ordini (TV, DVD players, video
camere, ecc.): B2C E-Commerce
• Per ogni voce dell’ordine, il sistema verifica se c’è merce
disponibile in magazzino. Altrimenti, viene ordinata la merce al
fornitore esterno (Manifacturer):B2B E-Commerce
• Il fornitore esterno non soddisfa immediatamente l’ordine, ma
aspetta di raccogliere un certo numero di ordini
D. Rosaci
SOA
6
Supply Chain Management
D. Rosaci
SOA
7
Passi dell’approccio SOA
• Metodo per scoprire servizi (top down) e per sfruttare servizi
esistenti (bottom up)
• Sette step principali
• Non sono step necessariamente sequenziali, ma spesso
seguono un approccio iterativo ed esplorativo
• Il processo può essere ottimizzato determinando quali step
condurre in parallelo e quali sono invece dipendenti da altri
step
D. Rosaci
SOA
8
Passi dell’approccio SOA
D. Rosaci
SOA
9
Passi del processo SOA
• Il processo inizia quando il business problem suggerisce l’uso
di un approccio service-oriented. Tipici candidati sono i
business problem che necessitano l’esposizione di un back
office verso l’esterno dell’azienda
• L’aspetto top down si evidenzia col prendere in considerazioni
le prospettive di business aziendale: le business functions, i
processi ed i sottoprocessi sono elaborati per delineare le
componenti software
• Le componenti sono i “mattoni” consentono la realizzazione
dei servizi, che sono le unità software rese disponibili per
l’orchestration, la choreography e la composizione delle
applicazioni
D. Rosaci
SOA
10
1. Domain decomposition
• Il dominio è suddiviso in
–
–
–
–
Value chain
Business processes
Sub processes
Use cases
Il dominio consiste di una serie di aree funzionali, lungo le dimensioni
chiamate value-net o value-chain.
D. Rosaci
SOA
11
1 Domain decomposition
D. Rosaci
SOA
12
1 Domain decomposition
• Quindi decomponiamo ogni area funzionale in processi, sotto
processi e use cases.
• Nel nostro esempio avremo i seguenti use cases:
–
–
–
–
–
–
–
–
D. Rosaci
UC1: Purchase Goods
UC2: Source Goods
UC3: Replenish Stock
UC4: Supply Finished Goods
UC5: Manufacture Finished Goods
UC6: Configure and Run Demo (non implementato)
UC7: Log Events
UC8: View Events
SOA
13
1. Domain decomposition
D. Rosaci
SOA
14
Domain Decomposition
• Noi possiamo usare gli use cases per decomporre
ulteriormente il dominio.
• Gli use cases identificati sono buoni candidati ad essere
servizi che dovranno essere “esposti” come Web services su
componenti aziendali
D. Rosaci
SOA
15
Domain decomposition
D. Rosaci
SOA
16
Applicazione dei pattern
• Ad ogni passo dell’approccio SOA, è possibile sfruttare assets
provenienti da esistenti Patterns per e Business
• Si inizia con i Business Patterns, per definire i partecipanti al
business e le loro relazioni, usando le aree funzionali e gli use
cases identificati nella domain decomposition
• Nell’esempio abbiamo due modelli di Business da
rappresentare:
– Un’interazione B2C tra il consumer e il business system del retailer
– Un’interazione B2B tra il warehouse del retailer e i manifacturer esterni
Questo implica l’uso del Self-Service business pattern e dell’Extended
Enterprise business pattern.
D. Rosaci
SOA
17
Usare i patterns
• Possiamo anche usare l’Application Integration pattern per
integrare i service consumers ed i service providers nella
supply value chain
• Inoltre possiamo usare l’Extended Business Pattern per i
service consumers ed i service providers ai “confini” aziendali
D. Rosaci
SOA
18
Usare i Patterns
D. Rosaci
SOA
19
1-Domain Decomposition
• A questo punto, possiamo descrivere i collegamenti tra i
business use cases della supply chain management e le aree
funzionali venute fuori dalla domain decomposition
• Per ogni use cases, specificheremo il pattern per l’e-business
applicato
D. Rosaci
SOA
20
1-Domain Decomposition
D. Rosaci
SOA
21
1-Domain Decomposition
D. Rosaci
SOA
22
2-Goal-service model
creation
• L’identificazione dei servizi permette di stabilire quali sono i
servizi da esporre per l’azienda
• Gli use cases identificati nella domain decomposition sono
buoni candidati come servizi
• La completezza dei servizi candidati viene testata attraverso
un modello goal-service
• Questo modello si realizza intervistando i proprietari
dell’azienda circa gli obiettivi dell’azienda stessa
• Ogni obiettivo viene poi partizionato in un insieme di sottoobiettivi, e si continua così finchè non siano emersi i servizi
candidati
D. Rosaci
SOA
23
Esempio di goal-service
model
D. Rosaci
SOA
24
3-Sub-system analysis
• Dopo aver completato i due step precedenti, abbiamo un’idea
delle aree funzionali di cui si compone il nostro business
domain
• Adesso vogliamo muoverci verso decisioni di “design” e
architetturali
• La sub system analysis raffina i business use cases in system
use cases che supportano un dato processo di business
• Durante questa analisi i componenti “business” e tecnici sono
identificati come segue:
D. Rosaci
SOA
25
Sub-system analysis
• Si analizza il flusso di processo del sottosistema (spesso una
sequenza di use case) per scoprire/identificare dei componenti
business “candidati”
• Si utilizzano requisiti non funzionali per identificare
componenti tecniche
• Si identificano le funzionalità richieste per ogni componente
business, cioè gli use cases a livello di sistema che il
componente deve supportare
• Nel nostro scenario di esempio, i quattro sottosistemi
identificati sono Retailer, Warehouce, Manifacturer e Logging
Facility
• Ognuno di questi sottosistemi espone un insieme di servizi
business
D. Rosaci
SOA
26
Sub-system analysis
D. Rosaci
SOA
27
Sub-system analysis
• Nell’esempio del sottosistema Retailer, dopo il passo del goalservice model, il business use case “Purchase Goods” è stato
decomposto nei servizi “Get Catalog” e “Submit Order”
• Ogni sottosistema sfrutta componenti business e tecniche per
realizzare lo use case associato e supportare i servizi
business esposti, come ad esempio “Submit Order”
D. Rosaci
SOA
28
Esempio di risultato
dell’analisi
• Dopo aver completato l’analisi, individuiamo le seguenti
componenti a grana grossa che saranno implementate come
servizi:
• Retailer Service fornisce le funzionalità di accedere al
catalogo prodotti e di emettere un ordine
• Warehouse Service supporta la consegna dei prodotti
ordinati e aggiorna l’iventario del magazzino. Quando
l’inventario scende sotto una certa soglia, esso sottometterà
un Purchase Order (PO) al Manufacturer
• Warehouse Callback Service riceve una notifica dal
manufacturer che il PO è stato processato.
D. Rosaci
SOA
29
Esempio di risultato
dell’analisi
• Manufacturer Service accetta sottomissioni di PO e inizia il
processo di manifattura.
• Logging Service registra gli eventi che accadono e supporta
la ricerca di eventi nel registro degli eventi
• E’ a questo punto che I servizi a grana grossa possono essere
composti in un’orchestration. Tools di flow-modeling come IBM
WebSphere Business Integration possono essere utilizzati a
questo punto.
D. Rosaci
SOA
30
Usare Application Patterns
• Gli application patterns aiutano a strutturare i servizi business
e tecnici.
• In questa soluzione semplificata, mostriamo i cinque servizi
essenziali al business
–
–
–
–
–
Retailer service
Warehouse service
Warehouse callback service
Logging facility service
Manifacturer service
Tra i servizi interni all’impresa, si userà un Direct Connection pattern, il più
semplice tipo di interazione 1:1, che permette ad un consumer e ad un
provider di comunicare direttamente. Per esempio, quando un customer
sottomette un ordine, il Retailer Service manderà un messaggio al
Warehouse Service per richiedere l’evazione dell’ordine
D. Rosaci
SOA
31
Usare Application Patterns
•
•
Il pattern Exposed Router è applicato per la necessità del Warehouse di dover
sottomettere un ordine al Manifacturer. Questo pattern si applica a soluzioni in
cui un’applicazione source inizia un’interazione con una o più applicazioni
target
Il pattern Exposed Direct Connection è utilizzato pedr il Warehouse Callback
Service. Questo pattern in genere si utlizza per i servizi che possono essere
invocati dall’esterno dell’impresa, da entità esterne come, in questo caso, il
Manifacturer.
D. Rosaci
SOA
32
Usare Application Patterns
D. Rosaci
SOA
33
4-Service allocation
• Dopo aver identificato i servizi tramite una combinazione di
domain decomposition e goal-service modeling, adesso
vogliamo assicurarci che ogni servizio abbia un corretto
“posizionamento”
• La service allocation si chiede quali componenti forniranno un
dato servizio ed il suo management
• I consumers vogliono la flessibilità di poter rimpiazzare
un’implementazione sulla base di nuovi requisiti funzionali,
non funzionali o economici
• D’altra parte i providers vogliono poter implementare le
interfacce sulla base di componenti esistenti
D. Rosaci
SOA
34
Service allocation
D. Rosaci
SOA
35
5-Component Specification
• Con l’analisi di sottosistema, abbiamo identificato le interfacce
dei sottosistemi, i system use cases ed i technical use case, le
loro iterdipendenze e il loro flusso
• Con la service allocation abbiamo identificato quali
componenti implementano ogni servizio
• Con la component specification per ogni componente occorre
specificare le proprietà e le regole che devono soddisfare
D. Rosaci
SOA
36
Component Specification
D. Rosaci
SOA
37
Patterns per strutturare
componenti e servizi
• Possiamo usare i runtime patterns per stabilire la struttura
middleware necessaria a supportare i servizi identificati
• Quindi possiamo assegnare ogni servizio ad un nodo
middleware
D. Rosaci
SOA
38
6-Applicare i runtime patterns
D. Rosaci
SOA
39
Es. di applicazione dei
runtime patterns
• Tre distinti runtime patterns
• Per l’interazione U2B, abbiamo la variazione 1 dello Stand
Alone Single Channel runtime pattern. Questa variazione usa
un Web Server redirector che contiene un Web server ed un
Application server, che splitta le funzioni di application server
su due macchine. L’application server risiede nella rete
interna, per ragioni di sicurezza, e il suo nodo realizzerà sia la
logica di presentazione che di business
• Il Web server fornisce pagine statiche, ed un Web server
redirector è usato per forwardare le richieste dal Web server
all’application server
D. Rosaci
SOA
40
Es. di runtime patterns
• Per l’interazione tra i servizi interni all’organizzazione, è
utilizzato il Direct Connection runtime pattern. I connettori
forniscono la connettività tra due componenti
• L’Exposed Direct Connection runtime pattern fornisce la
connettività per i servizi esterni al logging facilitator
• Per l’interazione B2B, è utilizzata la variazione Router
dell’Exposed Broker runtime pattern. Il router può operare il
routing intelligente verso un servizio target alla volta.
• Queste sono solo alcune tra le alternative possibili
D. Rosaci
SOA
41
7-Technology realization
mapping
• Adesso occorre specificare l’implementazione delle
componenti dei servizi
• Possiamo utilizzare materiale già esistente, o acquistarne di
nuovo
• In generale, le alternative sono le seguenti:
• Costruire nuove funzionalità su software esistente.
• Trasformare vecchi sistemi per riusarne le funzionalità in
forma di servizi
• Integrare sistemi legacy
• Comprare e integrare prodotti di terze parti
• Usare parzialmente risorse esterne, specialmente via Web
services
D. Rosaci
SOA
42
Applicare il Product Mapping
D. Rosaci
SOA
43
Applicare il product mapping
D. Rosaci
SOA
44