Corso di web services a a 2010 2011 domenico rosaci soa
This presentation is the property of its rightful owner.
Sponsored Links
1 / 44

Corso di Web Services A A. 2010 2011 Domenico Rosaci SOA PowerPoint PPT Presentation


  • 68 Views
  • Uploaded on
  • Presentation posted in: General

Corso di Web Services A A. 2010 2011 Domenico Rosaci SOA. SOA: Bridging IT e Business. L’importanza di SOA non è solo a livelli tecnologico Essa fornisce un ponte tra tecnologia e business

Download Presentation

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

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Corso di web services a a 2010 2011 domenico rosaci soa

Corso diWeb ServicesA A. 2010 2011Domenico RosaciSOA

SOA


Soa bridging it e business

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


Patterns e soa

Patterns e SOA

SOA


Patterns e soa1

Patterns e SOA

SOA


Patterns e soa2

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


Example supply chain management

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


Supply chain management

Supply Chain Management

SOA


Passi dell approccio soa

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


Passi dell approccio soa1

Passi dell’approccio SOA

SOA


Passi del processo soa

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


1 domain decomposition

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


1 domain decomposition1

1 Domain decomposition

SOA


1 domain decomposition2

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


1 domain decomposition3

1. Domain decomposition

SOA


Domain decomposition

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


Domain decomposition1

Domain decomposition

SOA


Applicazione dei pattern

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


Usare i patterns

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


Usare i patterns1

Usare i Patterns

SOA


1 domain decomposition4

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


1 domain decomposition5

1-Domain Decomposition

SOA


1 domain decomposition6

1-Domain Decomposition

SOA


2 goal service model creation

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


Esempio di goal service model

Esempio di goal-service model

SOA


3 sub system analysis

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


Sub system analysis

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


Sub system analysis1

Sub-system analysis

SOA


Sub system analysis2

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


Esempio di risultato dell analisi

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


Esempio di risultato dell analisi1

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


Usare application patterns

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


Usare application patterns1

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


Usare application patterns2

Usare Application Patterns

SOA


4 service allocation

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


Service allocation

Service allocation

SOA


5 component specification

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


Component specification

Component Specification

SOA


Patterns per strutturare componenti e servizi

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


6 applicare i runtime patterns

6-Applicare i runtime patterns

SOA


Es di applicazione dei runtime patterns

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


Es di runtime patterns

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


7 technology realization mapping

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


Applicare il product mapping

Applicare il Product Mapping

SOA


Applicare il product mapping1

Applicare il product mapping

SOA


  • Login