Architettura orientata ai servizi -...

Architettura dei Sistemi

Software

Luca Cabibbo

Luca Cabibbo ASWLuca Cabibbo ASW

Architettura orientata ai servizi

dispensa asw540

marzo 2018

Architettura orientata ai servizi1

One question I'm often bound to be asked is “what do you think of SOA

(Service Oriented Architecture)?”It's a question that's pretty much impossible

to answer, because SOA means so many different things to different people.

Martin Fowler

Luca Cabibbo ASW

- Fonti

Papazoglou, M.P. Web Services: Principles and Technology. Pearson, 2008.

Erl, T. SOA: Principles of Service Design. Prentice Hall, 2008.

Bell, M. Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley, 2008.


Luca Cabibbo ASW

Fonti

O’Brien, L., Bass, L., and Merson, P. Quality Attributes and Service-Oriented Architectures. Technical note CMU/SEI-2005-TN-014. 2005.

Bianco, P., Kotermanski, R., and Merson, P. Evaluating a Service-Oriented Architecture. Technical report CMU/SEI-2007-TR-015. 2007.

Bianco, P., Lewis, G.A., Merson, P., and Simanta, S. Architecting Service-Oriented Systems. Technical note CMU/SEI-2011-TN-008. 2011.

Manes, A.T. SOA is Dead; Long Live Services. Application Platform Strategies Blog, Burton Group. 2009.


Luca Cabibbo ASW

- Obiettivi e argomenti

Obiettivi

presentare e discutere l’architettura orientata ai servizi (SOA)

Argomenti

introduzione alla SOA

SOA e obiettivi di business

dai servizi alla SOA

dai principi per la progettazione dei servizi agli obiettivi di business

discussione

critica alla SOA


Luca Cabibbo ASW

* Introduzione alla SOA

In alcune dispense precedenti abbiamo presentato le capacità fondamentali delle tecnologie a servizi, nonché una nozione piuttosto generale di “architettura a servizi”

l’obiettivo fondamentale dell’architettura a servizi è sostenere la costruzione di sistemi informatici in grado di soddisfare gli obiettivi di business, correnti e futuri, delle organizzazioni

in effetti, esistono diversi tipi di “architetture a servizi”

questa dispensa presenta l’architettura orientata ai servizi – che è un importante caso specifico di “architettura a servizi”

ci concentriamo soprattutto su aspetti metodologici e di business – e non tanto su quelli tecnologici, che abbiamo già discusso


Luca Cabibbo ASW

Servizi e architettura orientata ai servizi

L’architettura orientata ai servizi (SOA) è basata sui servizi come tipo di elemento software (componente) fondamentale nello sviluppo e nell’integrazione di applicazioni distribuite

un servizio ha l’obiettivo di incapsulare una ben precisa funzionalità di business (logica applicativa), per renderla disponibile e accessibile come servizio software da parte di client software sul web – ciascun servizio può essere usato per costruire diverse applicazioni e processi di business

l’architettura orientata ai servizi (SOA, Service-OrientedArchitecture) è uno stile architetturale per la costruzione di una molteplicità di sistemi o applicazioni sulla base della composizione di un insieme di servizi – e non semplicemente per la costruzione di un singolo sistema come composizione di un insieme di servizi


Luca Cabibbo ASW

Architettura a componenti e SOA

Si confrontino l’architettura a componenti e l’architettura orientata ai servizi – con le loro tecnologie e i loro obiettivi

nell’architettura a componenti

ogni componente implementa delle funzionalità – il contenitore si occupa delle loro qualità tecnologiche

i componenti sono pensati per realizzare un’applicazione (di interesse per un’organizzazione) come composizione (statica) di componenti

nell’architettura orientata ai servizi

anche ogni servizio implementa delle funzionalità – i servizi sono interoperabili e sono componibili in modo flessibile

i servizi sono pensati per sostenere la realizzazione di una molteplicità di applicazioni (di interesse anche per più organizzazioni) come composizione (dinamica e flessibile) di servizi


Luca Cabibbo ASW

Architettura a componenti e SOA

Si considerino anche queste definizioni

una application architecture è l’architettura di una singola applicazione o di un singolo sistema software

una enterprise architecture è l’architettura complessiva di tutte le applicazioni e i sistemi software di un’organizzazione

Si confrontino ancora l’architettura a componenti e l’architettura orientata ai servizi alla luce di queste definizioni

l’architettura a componenti è usata soprattutto come applicationarchitecture – anche se talvolta può essere usata per la enterprise architecture di un’organizzazione

l’architettura orientata ai servizi ha obiettivi più ambiziosi, poiché si propone decisamente come enterprise architecture di un’organizzazione


Luca Cabibbo ASW

Architettura orientata ai servizi e qualità

SOA è uno stile architetturale che, come ogni altro stile, si propone di perseguire un certo numero di obiettivi di qualità

SOA – come gli altri stili architetturali discussi finora – sostiene diversi attributi di qualità “tecnologica”

in primo luogo l’interoperabilità – ma anche sicurezza, affidabilità, disponibilità, ...

questo aspetto è stato già discusso nella dispensa sull’architettura a servizi (Architettura a servizi [SAP])


Luca Cabibbo ASW

Architettura orientata ai servizi e qualità

SOA è uno stile architetturale che, come ogni altro stile, si propone di perseguire un certo numero di obiettivi di qualità

inoltre, SOA – diversamente da altri stili architetturali – cerca anche di sostenere obiettivi di “business”, correnti e futuri, delle organizzazioni

agilità di business – integrazione dei processi di business all’interno dell’organizzazione – integrazione dei processi di business con partner, fornitori e clienti – possibilità di monitorare/governare l’efficacia dei miglioramenti nei processi di business – …

discutiamo ora questi aspetti


Luca Cabibbo ASW

* SOA e obiettivi di business

In generale, l’architettura del software è il ponte tra gli obiettivi di business di un’organizzazione e i loro sistemi software

le tecnologie e gli stili architetturali studiati finora (come, ad es., l’architettura a componenti) si pongono soprattutto l’obiettivo di sostenere attributi di qualità “tecnologica” – prestazioni, scalabilità, sicurezza, ...

nell’architettura orientata ai servizi – grazie anche alla maggior maturità delle tecnologie sottostanti – l’attenzione si sposta anche e soprattutto sugli aspetti e gli obiettivi di business, correnti e futuri, delle organizzazioni

questa sezione discute tali obiettivi di business


Luca Cabibbo ASW

Contesto

Il contesto in cui si muovono oggi le grandi organizzazioni

alta competitività e alta incertezza

integrazione globale – di informazioni e processi

le organizzazioni richiedono agilità

per offrire i propri servizi (in senso aziendale) in modo più efficiente/efficace

per offrire servizi innovativi, per offrire servizi a nuovi mercati

un’organizzazione deve poter cambiare rapidamente i propri processi di business (processi aziendali) – e deve poterli continuare a cambiare in modo flessibile

inoltre, il ruolo dell’IT è oggi tale che il business di un’organizzazione può spesso essere flessibile solo quanto la sua infrastruttura IT

lo stile SOA si propone di far sì che l’IT sostenga – anziché ostacolare – l’agilità di business delle organizzazioni


Luca Cabibbo ASW

Limiti dell’architettura a componenti

L’architettura a componenti offre numerosi vantaggi

ad esempio, poter definire componenti che incapsulano funzionalità di business

tuttavia, nei contesti di integrazione, ciascun componente deve essere opportunamente collegato ad altri componenti, in modo statico – aumentando la complessità del sistema


web orders

pricingcustomers

inventory

sales orders

shipments

Luca Cabibbo ASW

Architettura orientata ai servizi

Nell’architettura orientata ai servizi

ciascun servizio incapsula una funzionalità di business

i servizi possono essere integrati e composti per formare applicazioni e sistemi

i servizi devono essere debolmente accoppiati – per rendere più facile, più flessibile e più agile la loro integrazione e composizione


sales orders

shipments

web orders

pricing customers

inventory

Luca Cabibbo ASW

Riuso dei servizi

Un valore primario della SOA è la possibilità di riusare in modo flessibile il patrimonio software esistente

ciascuna funzionalità di business che è stata già implementata può essere incapsulata ed offerta come servizio

questo richiede in genere una decomposizione in servizi dei sistemi software di un’organizzazione

questi servizi possono poi essere consumati – individualmente, oppure come dei servizi composti che eseguono delle funzioni di business più complesse

inoltre un’organizzazione può anche consumare i servizi offerti da altre organizzazioni – così come può offrire i propri servizi ad altre organizzazioni

ogni servizio può essere così riusato in modi diversi, e combinato con altri servizi per eseguire delle funzioni di business specifiche


Luca Cabibbo ASW

SOA e innovazione

L’innovazione può essere definita come il processo di effettuare un cambiamento per realizzare o fare qualcosa di nuovo

nei sistemi tradizionali, hardware, software e reti sono integrati in modo rigido – per questo è difficile effettuare cambiamenti

SOA rende più semplici i cambiamenti e l’innovazione

nell’architettura orientata ai servizi, l’IT è realizzato come un insieme di “componenti” che è facile assemblare e riconfigurare

ciascuno di questi “componenti” è un servizio di business –erogato dalla propria organizzazione oppure anche da un’altra organizzazione

nella SOA, i servizi possono essere combinati (e poi anche ricombinati dinamicamente) come si vuole, in modo flessibile

questo sostiene cambiamento e innovazione – ma anche efficienza ed efficacia


Luca Cabibbo ASW

Un’analogia

SOA, per sostenere innovazione e cambiamento, è come … i mattoncini Lego www.youtube.com/watch?v=A3_QlYJRVvk

nella SOA, i tuoi sistemi informatici sono costruiti con componenti assemblati in modo modulare, che possono essere riconfigurati facilmente – come i mattoncini Lego

ciascun mattoncino rappresenta un servizio di business – come verificare il saldo di un conto corrente o il livello di inventario di un prodotto, o tracciare lo stato di consegna di una spedizione

nella SOA è possibile comporre i tuoi sistemi informatici e processi di business come con i mattoncini Lego – è quindi possibile assemblare i tuoi servizi, in modo semplice e flessibile, per creare un processo adatto al mercato

se nel mercato c’è bisogno di un processo diverso, anziché iniziare da zero, tu puoi prendere gli stessi mattoncini, e riconfigurarli per fare qualcosa di diverso – risparmiando tempo e denaro


Luca Cabibbo ASW

- Un esempio – punto di partenza

Un processo di business tradizionale

processo realizzato in più applicazioni separate

funzioni di business accoppiate alle applicazioni

alcune funzioni sono replicate in più applicazioni – con interfacce proprietarie, il riuso è difficile

i passi manuali complicano la situazione

difficile monitorare il processo di business

difficile cambiare il processo di business


una funzione di business

Marketing App

Order Mgmt App

Fulfillment App

compiti eseguiti manualmente

funzioni ripetute in più applicazioni

Luca Cabibbo ASW

Un esempio

Il seguito dell’esempio mostra come la SOA

consente il riuso dei sistemi informatici esistenti

fornisce la possibilità a più sistemi informatici di lavorare insieme

tecnologicamente – mediante un insieme di standard per l’interoperabilità

sostiene flessibilità nel cambiamento/evoluzione dei processi di business

sostiene in particolare un allineamento tra business e tecnologia, consentendo all’uno di cambiare insieme all’altro

il business di un’organizzazione può essere flessibile solo quanto la sua infrastruttura tecnologica (IT) – se l’IT non può cambiare, non può cambiare nemmeno il business


Luca Cabibbo ASW

Il (nuovo) punto di partenza

il processo di business viene (ri)definito come composizione di un insieme di servizi

le funzionalità individuali del processo esistente – di solito realizzate mediante un’implementazione a componenti –vengono incapsulate e offerte come servizi

poi il processo di business viene (ri)definito come composizione di questi servizi


Division

Luca Cabibbo ASW

Interazione diretta con il cliente

il processo può essere poi migliorato in molti modi

ad esempio, si può consentire al cliente di acquistare direttamente dal web

un partner commerciale (cliente) può fare ordini B2B mediante un servizio web

i diversi clienti sono serviti meglio


Division

Customer

Luca Cabibbo ASW

Condivisione di servizi

i servizi di business comuni possono essere condivisi dall’intera organizzazione – e consolidati

riduzione delle ridondanze – dei relativi costi di sviluppo e di gestione – possibilità di ottenere economie di scala


Division

Shared services

Customer

Luca Cabibbo ASW

Inventario gestito dal fornitore

possibilità di delegare funzionalità a partner commerciali (fornitori) mediante interazioni B2B

riduzione dei costi e servizio migliore


Supplier

Division

Shared services

Customer

inventory management

Luca Cabibbo ASW

Outsourcing

possibilità di dare in outsourcing funzionalità relative a competenze non fondamentali

riduzione di costi e delle infrastrutture di spedizione


Supplier

Division

Shared services

Customer

Outsourced shipping

Luca Cabibbo ASW

Miglioramento del processo

possibilità di modificare il processo e le regole di gestione dello stesso

la definizione e la ridefinizione di un processo è vista più come un’attività di assemblaggio di servizi/compiti che non come un’attività di sviluppo


Supplier

Division

Shared services

Customer

Outsourced

servizi e percorsi alternativi

Luca Cabibbo ASW

- SOA e obiettivi di business

Contesto per l’architettura orientata ai servizi

ai fini del successo di un’organizzazione (o di un’azienda), è di fondamentale importanza la costruzione di sistemi informatici che soddisfano e sostengono gli obiettivi di business, correnti e futuri, dell’organizzazione

Problemi e obiettivi di business per la SOA

allineare business e IT, in modo che possano variare insieme

sostenere agilità di business

sulla base dello sviluppo agile di nuove applicazioni

realizzate come applicazioni composte

basate sul riuso di servizi software già esistenti all’interno dell’organizzazione

nonché sulla possibilità di fruire anche di servizi software esterni all’organizzazione


Luca Cabibbo ASW

SOA e obiettivi di business

Detto in altro modo [SEI 2005, SEI 2011], ecco i principali obiettivi di business e driver architetturali, comuni a molte organizzazioni, affrontati dallo stile SOA

abilitare un’integrazione semplice e flessibile con i propri sistemi legacy – interoperabilità

ottimizzare i propri processi di business, per aumentarne efficienza ed efficacia e ridurre i costi operativi – manutenibilità, modificabilità

agilità per gestire rapidamente il cambiamento dei processi di business (ad es., per offrire servizi innovativi ai clienti e adattarsi a opportunità e minacce competitive) – estendibilità

Questi obiettivi possono essere raggiunti applicando un insieme di principi di progettazione per i sistemi orientati ai servizi – tra cui i principi per la progettazione dei servizi, già discussi in una precedente dispensa


Luca Cabibbo ASW

* Dai servizi alla SOA

Per ricapitolare

l’architettura orientata ai servizi (SOA) è uno stile architetturale per la costruzione di una molteplicità di sistemi o applicazioni, basato sulla composizione di un insieme di servizi

un servizio è un’implementazione di un ben definito pezzo di funzionalità di business, con un’interfaccia pubblicata e che può essere scoperta e che può essere usata dai consumatori del servizio nel costruire diverse applicazioni e processi di business

si noti, nella definizione di SOA, che

non c’è nessun riferimento delle specifiche tecnologie per l’implementazione dei servizi

la composizione dei servizi è un aspetto fondamentale


Luca Cabibbo ASW

Dai servizi alla SOA

Organizzazione di una SOA

ogni servizio implementa una funzionalità di business discreta

ogni applicazione è creata assemblando e coordinando le attività tra quell’insieme appropriato di servizi che serve a realizzare un processo di business di interesse

il sistema orientato ai servizi di un’organizzazione comprende più applicazioni/processi di business

ciascun servizio può essere riusato in più applicazioni

infatti, ogni applicazione che ha bisogno di eseguire una specifica funzionalità, può invocare il servizio condiviso per quella funzionalità

affinché ciò sia possibile, i servizi devono essere progettati sulla base di opportuni principi

ad es., i servizi devono essere debolmente accoppiati – tra loro e con le applicazioni/processi – riusabili e componibili


Luca Cabibbo ASW

Dai servizi alla SOA

L’architettura orientata ai servizi è di solito organizzata attorno a due livelli (strati) principali – i cui componenti rappresentano rispettivamente

servizi di business

ogni servizio implementa una specifica funzionalità di business discreta

applicazioni o processi di business

ogni applicazione è creata assemblando e coordinando le attività tra quell’insieme appropriato di servizi che serve a realizzare un processo di business di interesse

ogni processo di business è definito come composizione di servizi – la composizione è di solito un’attività di assemblaggio, e solo raramente un’attività di sviluppo

per questo i processi di business possono essere definiti o modificati “rapidamente”


Luca Cabibbo ASW

SOA, servizi e processi di business

Il modello SOA dell’IBM


Luca Cabibbo ASW



Infrastructure services

Business (service) domain

Business processes

Business services

Distribution

Component-based service realizations

Order managementPurchasing Inventory

Create, modify, suspend, cancel orders,

schedule orders, create, modify, delete bulk orders,

order progress

operational systems DatabasesPackaged

applicationsLegacy

applicationsERPCRM

Logical

Physical

Process decomposition/composition

Luca Cabibbo ASW



domini di business (portali)

logica applicativa (componenti)

servizi di business –incapsulano (e astraggono) la logica applicativa e le risorse tecnologiche

servizi che implementano logica/processi di business

acco

ppia

men

to d

ebol

ede

com

posi

zion

e/(r

i)com

posi

zion

e

Luca Cabibbo ASW



domini di business (portali)

logica applicativa (componenti)

servizi di business –incapsulano (e astraggono) la logica applicativa e le risorse tecnologiche

servizi che implementano logica/processi di business

acco

ppia

men

to d

ebol

ede

com

posi

zion

e/(r

i)com

posi

zion

e

un accoppiamento debole tra processi di business e servizi di business consente a ciascuna delle due parti di rispondere in modo efficiente a cambiamenti nell’altra

Luca Cabibbo ASW

Dai servizi ai processi di business

Quando si presenta una nuova opportunità di business per l’organizzazione, gli sviluppatori possono realizzare rapidamente un nuovo processo di business – assemblando una nuova applicazione a partire dai servizi disponibili, e creando nuovi servizi se necessario

l’organizzazione potrebbe aver già definito dei servizi – da riusare nella realizzazione di nuove applicazioni

in alcuni casi può essere necessario implementare nuove funzionalità – bisogna valutare la possibilità di implementare queste nuove funzionalità come servizi, per poterli poi usare in altre applicazioni

inoltre, può essere anche utile considerare servizi forniti dall’esterno dell’organizzazione


Luca Cabibbo ASW

* Dai principi per la progettazione deiservizi agli obiettivi di business

Ricordiamo i principi per la progettazione dei servizi di [Erl 2008] e [SEI 2005] – già discussi in una precedente dispensa

i servizi condividono un contratto formale

i servizi realizzano un’astrazione della logica sottostante

i servizi sono debolmente accoppiati

i servizi sono riusabili

i servizi sono componibili

i servizi sono autonomi

i servizi sono stateless

i servizi possono essere scoperti

i servizi hanno un’interfaccia accessibile in rete

la locazione dei servizi è trasparente


Luca Cabibbo ASW

Dai principi agli obiettivi di business

Discutiamo ora come l’architettura orientata ai servizi sostiene gli obiettivi di business presentati in precedenza – questa sezione è basata su [SEI 2005]

in particolare, discutiamo la possibilità di raggiungere i seguenti obiettivi di business

agilità – capacità di adattarsi a opportunità e minacce competitive

capacità di offrire servizi innovativi

ottimizzazione dei processi

integrazione con i sistemi legacy

l’ipotesi è che i servizi soddisfino i principi per la progettazione dei servizi appena ricordati


Luca Cabibbo ASW

Agilità

Agilità – essere capaci di adattarsi rapidamente a nuove opportunità e potenziali minacce in un contesto competitivo

l’agilità è sostenuta da alcuni principi per la progettazione dei servizi

in particolare, riusabilità e componibilità dei servizi – ma anche accoppiamento debole e condivisione della specifica formale

inoltre, l’agilità è favorita dall’uso di servizi standardizzati, dalla conformità a standard, e dalla definizione di servizi a grana (abbastanza) grossa

ad es., se cambiano le regole di business associate a una specifica funzione, allora è necessario modificare solo il servizio che implementa quella funzione – tutte le applicazioni che usano il servizio vengono automaticamente adattate all’uso delle nuove regole di business


Luca Cabibbo ASW

Offrire servizi innovativi

Offrire servizi innovativi – essere i primi nel mercato con servizi innovativi per i propri clienti

questo obiettivo è sostenuto dalla possibilità di

comporre servizi, combinandoli in modi nuovi e diversi

usare sia servizi interni che servizi esterni

aggiungere nuovi servizi ove necessario

ad es., quando si presenta una nuova opportunità di business, gli sviluppatori possono rapidamente implementare un processo di business innovativo – assemblando una nuova applicazione dai servizi disponibili, e aggiungendo se richiesto dei nuovi servizi


Luca Cabibbo ASW

Ottimizzazione dei processi

Ottimizzare i propri processi di business – per aumentare efficienza ed efficacia, e ridurre i costi operativi

l’integrazione e l’ottimizzazione dei processi di business è un fattore critico di successo del business di un’organizzazione

questo obiettivo è sostenuto soprattutto dalla possibilità di

comporre servizi

usare sia servizi interni che servizi esterni

ad es., è possibile cambiare la definizione di un processo di business in termini di una nuova composizione di servizi

ad es., ogni singola funzionalità applicativa può essere offerta come singolo servizio nell’ambito dell’organizzazione, e poi consumato da tutte le applicazioni, indipendentemente dalle tecnologie con cui esse sono realizzate – è anche possibile vendere questi servizi ad altri – perseguendo economie di scala e riducendo i costi di gestione della diverse funzionalità


Luca Cabibbo ASW

Integrazione con i sistemi legacy

Abilitare un’integrazione semplice e flessibile con i propri sistemi legacy

molti sistemi legacy implementano un insieme ricco di funzionalità – queste funzionalità possono essere esposte come servizi, per essere (ri)usati come elementi di una SOA

se questo viene fatto usando tecniche e strumenti non invasivi, allora, allo stesso tempo

i sistemi legacy possono rimanere integri, e continuare ad offrire le loro funzionalità

queste funzionalità possono essere fruite anche da altri consumatori di servizi

poiché il costo di re-implementare un sistema legacy è di solito inaccettabilmente alto, rendere le sue funzionalità accessibili come servizi è un’alternativa economica che viene perseguita da molte organizzazioni


Luca Cabibbo ASW

* Discussione

Per riassumere

i servizi sono la risorsa architetturale primaria della SOA

l’architettura orientata ai servizi (SOA) è uno stile architetturale

per organizzare un insieme distribuito di servizi – controllati da una o più organizzazioni – e consentire la loro fruizione

per costruire una molteplicità di sistemi e applicazioni che usano un insieme di servizi – e non solo un singolo sistema come un insieme di servizi

per consentire alle organizzazioni di sviluppare, interconnettere e mantenere applicazioni e servizi di tipo enterprise in modo efficiente ed economico

per far sì che i beni, le informazioni, e i processi di business di un’organizzazione possano essere organizzati in modo flessibile per sostenere piani strategici e livelli di produttività come richiesto da ambienti di business competitivi


Luca Cabibbo ASW

Discussione

Gli obiettivi di business principali di interesse per la SOA sono

allineare business e IT, in modo che possano variare insieme

sostenere agilità di business

sulla base dello sviluppo flessibile di applicazioni realizzate come composizione di servizi – interni oppure esterni all’organizzazione

Per raggiungere questi obiettivi

i servizi devono essere basati su degli opportuni principi di progettazione dei servizi

le applicazioni e i sistemi rappresentano processi di business definiti come composizione flessibile di servizi di business –interni a un’organizzazione o condivisi tra più organizzazioni


Luca Cabibbo ASW

- Analisi e progettazione di servizi

Un aspetto critico dell’architettura orientata ai servizi è l’analisi e la progettazione dei servizi – ovvero, l’identificazione di quali pezzi di funzionalità dovranno diventare servizi, e definire con cura le loro interfacce

infatti, quando i servizi vengono implementati, e le loro interfacce vengono pubblicate e usate da varie applicazioni, diventa difficile modificare la definizione di questi servizi, perché questo potrebbe avere impatto su tutte le applicazioni che li utilizzano – questi cambiamenti vanno se possibile evitati

Per gli aspetti metodologici relativi alla SOA, si veda, per esempio

Papazoglou, M.P. Web Services: Principles and Technology. Pearson, 2008.

Chapter 15: Web services lifecycle management

Bell, M. Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley, 2008.


Luca Cabibbo ASW

* Critica alla SOA

L’articolo SOA is Dead; Long Live Services (2009) ha presentatoquesta opinione (motivata anche dalla recessione economica di quegli anni): l’architettura orientata ai servizi (SOA) è morta

per molte organizzazioni, il tentativo di applicare lo stile SOA è stato infatti un esperimento fallimentare – che non ha portato all’agilità di business promessa né al miglioramento dell’efficienza e dell’efficacia

tuttavia, è anche vero che diverse organizzazioni sono riuscite ad applicare lo stile SOA con successo

in effetti, il problema non è nei servizi o nella SOA in sé, ma nel modo in cui lo stile SOA è stato applicato

dunque, come suggerisce il titolo dell’articolo, anche se la SOA può considerarsi morta, i servizi sono comunque una buona idea, e cui augurare una vita ancora lunga – magari nel contesto di altri “stili a servizi”, un po’ diversi dalla SOA


Luca Cabibbo ASW

Critica alla SOA

Alcune osservazioni importanti da SOA is Dead; Long Live Services

Successful SOA (i.e., application re-architecture) requires disruption to the status quo.

SOA is not simply a matter of deploying new technology and building service interfaces to existing applications; it requires redesign of the application portfolio. And it requires a massive shift in the way IT operates.

The small select group of organizations that has seen spectacular gains from SOA did so by treating it as an agent of transformation. In each of these success stories, SOA was just one aspect of the transformation effort.

And here’s the secret to success: SOA needs to be part of something bigger. If it isn’t, then you need to ask yourself why you’ve been doing it.


Luca Cabibbo ASW

Critica alla SOA

Alcune conclusioni

l’utilizzo di una tecnologia a servizi, da sola, non garantisce che il risultato sia una (buona) architettura orientata ai servizi

lo sforzo richiesto per la realizzazione di una buona architettura orientata ai servizi è molto alto

infatti, la SOA richiede un ripensamento complessivo di un’organizzazione e dei suoi sistemi informatici

la SOA può fornire agilità – tuttavia, questo non significa che è uno stile adatto a team di sviluppo agili

gli obiettivi della SOA sono molto ambiziosi

ma un’organizzazione richiede davvero una SOA completa?

ad es., è richiesta davvero una enterprise architecture? la composizione di servizi deve poter essere specificata direttamente dagli esperti del dominio di business?

inoltre, non c’è consenso su come applicare bene lo stile SOAArchitettura orientata ai servizi47

Architettura orientata ai servizi -...

Documents

Transcript of Architettura orientata ai servizi -...