Linea guida: Mediazione del servizio
Questa linea guida descrive le modalità in cui la comunicazione tra utenti e servizi incompatibili viene abilitata tramite la mediazione, trasformando le richieste o i protocolli dell'utente in forme che i provider del servizio sono in grado di capire.
Relazioni
Descrizione principale

Introduzione

La mediazione è l'intervento tra le parti in conflitto per promuovere una riconciliazione o un compromesso. In particolare, sono richieste tre forme comuni di riconciliazione nei sistemi distribuiti in generale e nelle soluzioni orientate al servizio in particolare.

  • Mediazione di interfaccia; nell'interfaccia dei sistemi basati sull'oggetto o sul componente, la mediazione è la modifica tra le definizioni delle operazioni tra il mittente ed il destinatario. In una soluzione orientata al servizio, ciò è visto come una incongruenza nel contenuto/schema del messaggio tra mittente e destinatario.
  • Mediazione di protocollo; le soluzioni più comuni basate sull'oggetto o sul componente tendono ad essere basate attorno ad un protocollo comune o ad un insieme di protocolli per la comunicazione. Nelle soluzioni orientate al servizio, è comune una miscela di protocolli attraverso l'intera soluzione ed è uno dei vantaggi dell'architettura. Per comunicare tra i servizi, i messaggi dovranno attraversare diversi protocolli tra il mittente ed il destinatario.
  • Mediazione dell'operazione; anche questa forma di mediazione potrebbe sembrare familiare agli sviluppatori. E' relativa al pattern di strategia comune. Un componente è in grado di selezionare una di un insieme di implementazioni di un servizio o di un operazione particolari basati su parametri di runtime o sul contenuto della richiesta. Questa operazione è nota come routing basato sul contenuto.

E' importante notare che sempre più piattaforme middleware forniscono le capacità per una mediazione avanzata senza dover sviluppare componenti di mediazione specifici. In questo caso, poiché il middleware rileva incongruenze nella struttura di dati o nei protocolli delle comunicazioni, sarà possibile eseguire la mediazione nel relativo runtime. E' inoltre possibile per queste piattaforme fornire i mediatori che agiscono come scambi basati sul contenuto del messaggio e sulla regole del business per selezionare l'implementazione corretta di una richiesta dell'utente fornita.

Mediazione dati nelle attività

In termini di servizi di connessione dove la definizione dei messaggi non corrisponde o i messaggi richiedono una trasformazione tra mittente e destinatario, è possibile utilizzare una capacità fornita dalle attività UML 2.0 per indicare la trasformazione tra mittente d destinatario. Questa capacità, l'associazione di un comportamento UML 2.0 ad un ObjectFlow tra due azioni, consente l'identificazione di un comportamento di trasformazione riutilizzabile che è in grado di trasformare un messaggio in un altro(in modo specifico dalla specifica UML 2.0 Modifica o sostituisce i token dei dati che passano lungo i contorni).

Come precedentemente notato, la trasformazione è un elemento riutilizzabile. Pertanto, è possibile identificarla per trasformare un tipo di messaggio in un altro e quindi utilizzata laddove necessario nella mediazione dei messaggi tra un servizio di invio ed uno di ricezione. Si noti che, sebbene l'UML fornisca un insieme di azioni per la navigazione, la lettura e l'aggiornamento di una struttura, queste sono relativamente complesse e potrebbero risultare troppo complesse da utilizzare nella definizione delle trasformazioni. Si prevede che la trasformazione si collegherà ad una rappresentazione più compatta(considerare il linguaggio XSL/T) oppure ad un nuovo modo di esprimere le azioni UML da fornire.

E' possibile trattare la mediazione dei dati anche come un pattern concreto di iterazione del servizio. Ad esempio, esiste un responsabile esplicito del servizio di mediazione per l'implementazione di una o più trasformazioni di dati. In questo caso, il mediatore deve rispondere ai messaggi inviati dall'utente, trasformare il messaggio e passare al servizio, some precedentemente mostrato.

Il diagramma viene descritto nel contenuto testuale.

Mediazione del protocollo sui gateway del servizio

La mediazione del protocollo d'altra parte è ben compresa ed esplicitamente supportata nel modello. Poiché le informazioni sul protocollo sono specificare come binding per un canale del servizio, è possibile introdurre ulteriori elementi del modello del <<Servizio>> o del <<Gateway del servizio>>che alterano la specifica del protocollo. Ad esempio, nel diagramma della struttura seguente si visualizzano due partizioni, una per i servizi rivolti al web ed una per i servizi interni ed esiste un canale del servizio tra le partizioni con un binding "HTTP-SOAP", cosa comune per i servizi rivolti al web.

Il diagramma viene descritto nel contenuto testuale.

La questione è che, per supportare i livello richiesto delle prestazioni e di altri requisiti non funzionali, tutte le comunicazioni nelle partizioni interne avranno luogo su protocolli specifici della piattaforma. Il diagramma seguente mostra il modo in cui un servizio è collegato al gatway del servizio "Port : ISvcTwo" utilizzando il protocollo Java RMI, ma come si collega allora la partizione web allo stesso gateway utilizzando HTTP-SOAP?

Il diagramma viene descritto nel contenuto testuale.

La risposta è che lo stesso gateway del servizio può mediare il protocollo convertendo le strutture del messaggio e le chiamate da un formato ad un altro. Questa è una funzionalità comune fornita di solito da middleware come ORB (Object Request Brokers) o Message Brokers. Infatti, sarebbe possibile generare dal modello precedente nel middleware se richiesto oppure to reify "Port : ISvcTwo" come un servizio in pieno diritti che prende le chiamate dalla partizione web e le reinvia ai servizi inclusi.

Ancora, è possibile che la mediazione venga modellata esplicitamente come servizio, piuttosto che come gateway del servizio, che espone l'interfaccia corretta con il binding dal lato dell'utente e deleghi l'implementazione al servizio provider con un binding diverso.

Mediazione di chiamata mediante la composizione del servizio

Come descritto nell'introduzione, è comune definire una struttura in cui un servizio è dipendente su un altro servizio per alcune operazioni. Tuttavia, il servizio attuale che verrà chiamato per qualsiasi richiesta particolare è dipendente dai dettagli integrati nella richiesta, l'identità del richiedente e le regole del business applicate mediante queste informazioni. L'esempio comunemente fornito i questo caso è una richiesta dell'utente, il servizio di ricezione potrebbe scegliere una o due implementazioni basate sul livello dell'utente. Ad esempio, gli utenti conosciuti che spendono più denaro potrebbero ottenere un trattamento diverso.

Il diagramma viene descritto nel contenuto testuale.

Come precedentemente descritto, è importante in questo tipo di mediazione tentare di esternare le regole utilizzate per scegliere uno o più provider dell'implementazione reale dell'operazione. Nel diagramma precedente, ciò viene illustrato come un componente della regola collegato al servizio di mediazione. Ovviamente, è possibile creare la soluzione dome un insieme di servizi dove il mediatore, le regole e tutti gli implementatori sono servizi separati. E' possibile visualizzare ciò di seguito.

Il diagramma viene descritto nel contenuto testuale.

Come si può vedere, il componente di mediazione è proprietario non solo della specifica di servizio realizzata, ma anche di una specifica di servizio richiesta da implementare da tutti i servizi che media. Ciò consente di definire sia la struttura composta del servizio (sopra illustrata) che il comportamento dinamico illustrato in basso. Si noti che nella struttura precedente, la parte che rappresenta i servizi mediati viene indicata dall'interfaccia richiesta e mostrata con una molteplicità illimitata.

Il diagramma viene descritto nel contenuto testuale.

Ancora, è possibile che questo tipo di routing dei messaggi basato sul contenuto o basato sulle regole venga realizzato dalla piattaforma del middleware scelta come parte dell'architettura della soluzione.