Operazione: Decisioni di realizzazione del servizio del documento
Questa attività si incentra sulla realizzazione di un modello del servizio in termini di componenti software da eseguire in ambienti middleware esistenti.
Scopo

Lo scopo di questa attività è di fornire un modello del progetto per l'implementazione che può essere utilizzato dagli sviluppatori per implementare i componenti del servizio per fornire i servizi richiesti.

Relazioni
Descrizione principale

Lo scopo del Modello del servizio è principalmente l'identificazione dei relativi servizi, dell'organizzazione, della collaborazione e della specifica dettagliata e completa. Il ruolo dell'implementazione è delegato al Modello di progettazione RUP (Rational Unified Process) e in modo specifico all'elemento del modelloComponente servizio. In generale, il modello del servizio viene realizzato da un modello di progettazione. Tuttavia, sarebbe possibile generare gli artefatti direttamente dal modello del servizio dove sono richieste semplicemente delle specifiche. Potrebbe essere utile creare un modello di casi d'uso dal modello del servizio che consenta un ulteriore descrizione dei servizi prima della costruzione.

Passi
Determinazione dell'approccio di origine

Esiste un numero di alternative da considerare relative alla decisione su come realizzare i servizi (vedere la figura di seguito riportata). Questo non è una semplice decisione di creazione rispetto a una decisione di acquisto; esistono anche altre interessanti opzioni. La "trasform"-azione utilizza una combinazione di tecniche inclusa l'estrazione delle regole di business per tirar fuori un segmento di funzionalità da utilizzare indipendentemente per la realizzazione del servizio del componente. L'"integrazione" è l'"allineamento" della funzionalità legacy per raggiungere la funzionalità; l'integrazione è basata sul richiamo. La sottoscrizione si basa sulla disponibilità di un modello a sottoscrizione pubblica (in un contesto middleware orientato al messaggio) nel quale un consumatore sottoscrive ai servizi forniti dal provider. Una delle opzioni è di esternalizzare (ad esempio Payroll) la funzionalità di alcuni altri business. Quando i servizi Web e l'integrazione business-to-business diventano prevalenti, questa opzione viene considerata per l'utilizzo su una base più ampia.

  • Creazione - per diversi motivi, la decisione è di andare avanti e sviluppare il servizio in-house.
  • Acquisto - acquisto di un servizio che potrebbe essere sviluppato e ospitato internamente.
  • Trasformazione - utilizza una combinazione di tecniche inclusa l'estrazione delle regole di business per tirar fuori un segmento di funzionalità da utilizzare indipendentemente per la realizzazione del servizio del componente.
  • Sottoscrizione - è basata sulla disponibiltà di un modello a sottoscrizione pubblica (in un contesto middleware orientato al messaggio) nel quale un consumatore sottoscrive ai servizi forniti dal provider.
  • Integrazione - è l'allineamento della funzionalità legacy per raggiungere la funzionalità; l'integrazione è basata sul richiamo.
  • Esternalizzazione - quando i servizi Web e l'integrazione business-to-business diventano prevalenti, questa opzione viene considerata per l'utilizzo su una base più ampia.

Le decisioni di realizzazione del servizio sono associate ai componenti del servizio. Ogni componente del servizio può essere considerato un contenitore di funzionalità necessario per realizzare un servizio. È composto di o utilizza i componenti funzionali e tecnici. È importante decidere come questi componenti del servizio verranno realizzati. Non si tratta di una semplice decisione di "acquisto o creazione". Ci sono altre considerazioni a cui bisogna guardare:

  • La trasformazione che potrebbe riguardare l'estrazione delle regole o l'esecuzione di clone di un codice esistente e la sua riscrittura per eseguire come un componente con interfaccia definita.
  • L'integrazione con la messaggistica o con i wrapper.

Esempio

Si desidera riportare le decisioni di realizzazione per l'esempio Noleggio auto, sebbene sia difficile fare questo nel modello UML lo si è utilizzato in un numero di esempi. Per un supporto in questo processo, il modello Matrice di realizzazione  può essere utilizzato per documentare il risultato di queste decisioni, come mostrato nella figura di seguito riportata.

Determinazione dell'approccio di sviluppo

Il vantaggio delle scelte descritte è che in qualsiasi scelta effettuata, vi è una connessione tra le altre in termini di tracciabilità dal modello di casi d'uso ad un modello di progettazione e quindi all'implementazione.

Il diagramma viene descritto nel contenuto testuale.

Si consiglia che il modello del servizio venga realizzato utilizzando un modello di progettazione. Ciò fornisce l'abilità per il Progettista e l'Implementatore di applicare i modelli al modello di progettazione, capacità e strutture ulteriori del modello prima di generare gli artefatti di implementazione.

Associazione a granularità complessa degli asset esistenti

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.

Il diagramma viene descritto nel contenuto testuale.

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".

 Il diagramma viene descritto nel contenuto testuale.

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.
Proprietà
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile
Ulteriori informazioni