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