Corso di Web Services A A. 2010 2011 Domenico Rosaci SOA

1. Corso diWeb ServicesA A. 2010 2011Domenico RosaciSOA SOA

2. 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 SOA

3. Patterns e SOA SOA

4. Patterns e SOA SOA

5. 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. SOA

6. 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 SOA

7. Supply Chain Management SOA

8. 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 SOA

9. Passi dell’approccio SOA SOA

10. 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 SOA

11. 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. SOA

12. 1 Domain decomposition SOA

13. 1 Domain decomposition • Quindi decomponiamo ogni area funzionale in processi, sotto processi e use cases. • Nel nostro esempio avremo i seguenti use cases: • 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

14. 1. Domain decomposition SOA

15. 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 SOA

16. Domain decomposition SOA

17. 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. SOA

18. 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 SOA

19. Usare i Patterns SOA

20. 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 SOA

21. 1-Domain Decomposition SOA

22. 1-Domain Decomposition SOA

23. 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 sotto-obiettivi, e si continua così finchè non siano emersi i servizi candidati SOA

24. Esempio di goal-service model SOA

25. 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: SOA

26. 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 SOA

27. Sub-system analysis SOA

28. Sub-system analysis • Nell’esempio del sottosistema Retailer, dopo il passo del goal-service 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” SOA

29. 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. SOA

30. 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. SOA

31. 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 SOA

32. 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. SOA

33. Usare Application Patterns SOA

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

35. Service allocation SOA

36. 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 SOA

37. Component Specification SOA

38. 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 SOA

39. 6-Applicare i runtime patterns SOA

40. 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 SOA

41. 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 SOA

42. 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 SOA

43. Applicare il Product Mapping SOA

44. Applicare il product mapping SOA