Non bisogna dimenticare che pochissime soluzioni sono create senza considerare le applicazioni esistenti che forniranno
la funzionalità per supportare la soluzione o con cui è necessario che la soluzione interagisca. E' perciò vitale che
le applicazioni precedentemente esistenti che saranno riutilizzate come parti di ogni soluzione vengano catalogate e la
loro funzionalità identificata. Con una soluzione orientata al servizio, si è in grado di intraprendere alcune route
per integrare i servizi nuovi con la funzionalità. Sono illustrate nella figura seguente:
-
Wrapping della funzione esistente come servizio. In questo caso, è probabile che la funzione verrà lasciata
come è, si utilizzeranno i tool o il middleware per esporre la funzione esistente come servizio. Ad esempio, l'IBM
fornisce la capacità di esporre le transazioni CICS di tipo legacy come servizi web SOAP.
-
Wrapping e sostituzione della funzione esistente con un servizio. In questo caso, si esegue il wrapping di
una funzione come nel caso precedente, ma si utilizza la specifica di servizio risultante per sviluppare nuovamente
il servizio in una data successiva, sostituendo il servizio originale e dirigendo i client alla nuova
implementazione.
-
Utilizzo di un adattatore più riconducibile alla chiamata del servizio. In alcuni casi, non è possibile
eseguire il wrapping di una funzione ed esporla come servizio, ma si potrebbe eseguire il wrapping della funzione
in qualcosa maggiormente in grado di integrarsi, come un'interfaccia della coda messaggi o JCA (Java Connector
Architecture). Ciò consentirebbe ai nuovi servizi di accedere alla funzione sul posto.
-
Integrazione della funzione nel servizio. Ovviamente, in alcuni casi, è possibile per il servizio nuovo
accedere alla funzione legacy sul posto, utilizzando semplicemente la funzione come un componente logico
all'interno dell'implementazione del servizio.
Si dovrebbe considerare che la terza e la quarta opzione forniscono la massima flessibilità poiché utilizzano la
funzione esistente ma non continuano ad esporre la funzione così com'è ai client. D'altra parte, la prima e la seconda
opzione potrebbero introdurre problemi con il wrapping di funzioni esistenti come servizi poiché le prestazioni dei
protocolli dei servizi web e le incongruenze tra i formati di dati nativi e XML potrebbero introdurre problemi per le
prestazioni.
Gli asset del software esistenti e le loro dipendenze e interfacce dovranno essere analizzate per determinare se le
modifiche sono richieste per supportare la funzionalità di business. Ad
esempio, per creare l'interfaccia dei servizi Web per un'implementazione legacy di una funzione business, l'analisi
potrebbe riguardare l'esame della composizione ed il flusso delle transazioni online o una funzione batch, o archivi di
dati persistenti che aiutano ad eseguire quella funzione. Il progetto
corrente di queste applicazioni esistenti potrebbe dover cambiare per supportare la funzionalità. C'è anche una necessità di identificare le possibili barriere per creare
un'interfaccia del servizio Web con la qualità desiderata del servizio. Ad
esempio, un'implementazione batch monolitica di una funzione di business potrebbe richiedere un tempo di risposta di
subsecondi quando è richiamato come un servizio.
Wrapping delle risorse esistenti come modelli dei servizi
In alcuni casi, tuttavia, è un espediente sviluppare una partizione del servizio legacy dove viene esposto un insieme
di funzioni legacy di basso livello singolarmente come servizi. Questa partizione è accessibile solo a servizi di
livello superiore che l'utilizzano nella presentazione di una specifica più granulare allineata al business agli
utenti. Questo incapsulamento delle funzioni legacy andrebbe visto come una soluzione temporanea e dovrebbe essere
intrapreso solo se le caratteristiche delle prestazioni della tecnologia del wrapping sono state ben capite. Per
ulteriori informazioni consultare il concetto Partizionamento della soluzione.
Un modo per guardare al wrapping di una funzione legacy è una forma molto semplificata dell'elemento del modello di
Provider del servizio, con un singolo servizio che realizza una
specifica singola con solo una singola operazione. Il diagramma seguente mostra questo modello per la funzione legacy
"UpdateCustomerAddress".
Nel confezionare questo modello, si potrebbe desiderare eseguire quanto segue:
-
Probabilmente un insieme di funzioni esistenti verrà fornito dallo stesso componente così sarà necessario
utilizzare lo stesso provider del servizio.
-
Il modello precedente è stato generato automaticamente; sarebbe preferibile modificare il nome predefinito
dell'operazione da "exec${service}".
-
In modo simile, si potrebbero rinominare i messaggi generati; inoltre a questo punto, si potrebbero modellare le
strutture dei messaggi.
-
Il modello predefinito presume che l'operazione riceva un messaggio di input e restituisca un messaggio; è
possibile che la funzione legacy non restituisca messaggi oppure è solo una notifica e che sia necessario emendare
la firma dell'operazione generata.
-
E' necessario che l'architetto/progettista accerti che i valori corretti vengano specificati per la
proprietà"allowedBindings" sul provider del servizio.
|