La Zone Enterprise Integration è presentato da DZone e FuseSource . Controlla la Zona EI per gli scenari reali di integrazione del mondo per aiutarli ad imparare la tecnologia che vi darà la soluzione più elegante. Per i sistemi open source basati su Apache Camel , ActiveMQ , o ServiceMix , guardare inFuseSource formazione 's e la tecnologia.
Un caso di studio e un finale anti-pattern capitolo del mio libro sono stati recentemente spinto alla MEAP , ed ecco uno schema aggiuntivo da capitolo 6 (modelli di consumo dei servizi):
Quando proviamo a pensare a consumatori di servizi, i candidati più ovvi sono, naturalmente, altri servizi.Tuttavia ci sono altri componenti software che interagiscono con i sistemi legacy ad esempio, servizi, Camere non-SOA sistemi esterni o database di reporting. Le offerte di compositi modello front-end con un altro tipo di consumatore di servizi - l'interfaccia utente.
Prima di tutto basta verificare che le interfacce utente non sono in realtà servizi. Uno dei motivi per interfacce utente, non sono servizi è che essi convergono diverse aree di business ad esempio, se si desidera inserire un ordine che ci si vuole probabilmente anche per cercare informazioni sul cliente, forse avresti anche voler sfogliare il catalogo prodotti, guarda aperto fatture, ecc Oltre alla convergenza, interfacce utente, piuttosto che fornire i dati di processo esso. Le interfacce utente sono i produttori di dati (in realtà c'è una sola eccezione a questo - in cui l'interfaccia utente è la parte anteriore di un "servizio umano" vedere coreografia schema orchestrato (nel capitolo 7) per maggiori dettagli.
Ok, quindi le interfacce utente, non sono servizi, non importa? Beh, lo fa e il problema non è che le interfacce utente non sono servizi di per sé. La sfida principale causata da interfacce utente proviene dalla loro differenza principale cioè l'aggregazione o di convergenza di numerosi servizi in una interfaccia utente coerente e utile.
6.1.1 Il Problema
Per comprendere meglio le sfide causate da un'interfaccia utente che lavora con servizi multipli, consideriamo un esempio con un solo punto di attrito.
In un progetto ho lavorato abbiamo progettato il C4ISR (Comando, Controllo, Comunicazioni, Computer, Intelligence, sorveglianza e ricognizione) sistema per un Unmanned Vehicle Patrol Naval (UNPV). Uno dei servizi del sistema è stata soprannominata "Common Operational Picture", o COP in breve. La responsabilità del COP 's è stato quello di gestire tutto ciò che viene rilevato da sensori ad esempio navi, aerei, quale che sia (c'è gergo tecnico per tutto ciò che gli obiettivi simili, rilevazioni, piste ecc, ma non è importante qui). Una delle rappresentazioni UI principali del COP era una mappa, come quella in figura 6,4 sottostante, che mostra tutti i rilevamenti. Cliccando sulla mappa l'icona, per esempio una nave, presenta alcune informazioni il COP lo sa, come id, nazionalità, ecc naturalmente
Figura 6.4 Un esempio semplificato di un front-end per un "Common Operational Picture" servizio di un comando navale e sistema di controllo. Vediamo una linea di costa e quindi utilizzando la simbologia NATO: 2 radar, un sottomarino e una nave (la Unmanned Vehicle Patrol Naval)
Il sistema aveva un paio di altri servizi oltre al COP, tra i quali c'era il "servizio UNPV". Il servizio UNPV era responsabile per tutto ciò che riguarda la stessa UNPV per esempio, l'impostazione su una rotta di navigazione, girando intorno, ecc Il servizio UNPV avuto diverse schermate dell'interfaccia utente per consentire la gestione e monitoraggio di tali funzioni. Un'altra responsabilità del servizio UNPV è stato quello di inviare la sua posizione al COP (sedi sono a carico del poliziotto, ricordate?) Così indietro nella UI, una delle icone della mappa è quello del UNPV.
Cosa succede quando un utente fa clic sull'icona UNPV sulla mappa? Ricordate, mentre il risultato desiderato è quello di visualizzare un popup con le opzioni relative al controllo del UNPV, il click è sulla mappa, un controllo servito da un altro servizio (la COP). In un sistema Object Oriented il UNPV potrebbe essere una sottoclasse di rilevamento in modo che sarebbe accettare stesso evento e rispondere un po 'diverso (in modo più specifico). Qui, tuttavia il COP e il UNPV sono servizi completamente diversi, sviluppati da due gruppi diversi e forse anche due aziende diverse.
Potremmo essere in grado di respingere questo esempio specifico e semplicemente risolvere con una soluzione specifica ad esempio aggiungere un 'se' qualche dichiarazione per richiamare i comandi corretti e di interagire con il servizio corretto (s). Il problema, tuttavia, è che questo esempio è solo la punta dell'iceberg. Ad esempio: come facciamo a gestire la sicurezza? - Abbiamo bisogno di login per ogni servizio separatamente? Come facciamo a gestire le cose che tutti i servizi hanno bisogno? SOA premessa è che avremmo avuto una sorta di lego-come impresa in cui possiamo comporre diversi processi di business facilmente. C'è un modo possiamo ottenere che l'interfaccia utente? In sintesi:
Come si fa a noi interagiamo con più servizi, ottenere un sistema integrato, interfaccia utente e coeso conservano ancora i principi SOA ei benefici modularità?
Una possibilità è, come detto sopra, scrivere codice specifico client. Usando questo approccio "un'applicazione", si intende qualsiasi composizione specifica dei servizi. Per l'esempio precedente, l'applicazione dovrebbe includere i due servizi (COP e UNPV) e un'interfaccia utente che li lega insieme. Il lato di questo approccio è che ogni applicazione fornisce un'esperienza uniforme per l'utente. Dopo tutto, una specifica applicazione o mirata può essere fatto di essere molto coeso. Inoltre ci sono molti modi collaudati per la costruzione di interfacce utente flessibili con una corretta separazione degli interessi, ad esempio utilizzando Model-View-Controller e le sue variazioni (in una moltitudine di rich client e tecnologie web) in modo saremmo probabilmente in grado di riutilizzare alcune della UI-logica lato andando anche da un'applicazione all'altra. Tuttavia, ci si perde sulla flessibilità. Per uno, qualsiasi cambiamento servizio che presenta aspetti di interfaccia utente deve essere rifatta per ciascuna delle sue istanze UI (applicazioni). Più così, dal momento che l'interfaccia utente lega specificamente molteplici cambiamenti servizi di uno servizio può causare mal di un'altra funzione all'interno dell'interfaccia utente unificata.Abbiamo anche perdere su Composability, o la capacità di sostituire i servizi e creare nuovi flussi di lavoro (relativamente) facili. Nel complesso è una cattiva opzione a lungo termine, ma può essere fatto funzionare come una soluzione a breve termine.
Un'opzione correlato sta adottando un approccio simile di legare diversi servizi insieme, ma, invece di integrarli sul lato client che integrare i servizi insieme sul lato server. Questo approccio condivide i pro ei contro con la soluzione precedente. Tuttavia ci sono circostanze specifiche in cui ha senso e si può leggere su di loro nel modello successivo (sezione 6.5 Client / Server / Service)
Infine, abbiamo la possibilità di avere i componenti dell'interfaccia utente indipendenti per servizio. Ciò consentirebbe di superare le limitazioni che abbiamo summenzionato, in quanto l'interfaccia utente corrispondente di ogni servizio può evolvere in modo indipendente e si può stipare un maggior numero di questi, come vi piace per creare un'applicazione. Purtroppo, con tutti i suoi benefici si tratta di una non ancora un'opzione qui, per definizione, non avremo i meccanismi per i componenti dell'interfaccia utente che funzionano servizi attraverso. vale a dire che non sarà effettivamente risolvere i problemi come quello nell'esempio e non possiamo ottenere una interfaccia utente coerente.
6.1.2 La soluzione
Quello che ci serve, in sostanza, è un modo di comporre servizi insieme pur mantenendo la loro rispettiva autonomia da un lato e fornire meccanismi per incollare insieme come un insieme coerente - Questo è ciò che il modello Frontend Composite è di circa:
Applicare il modello Composite Frontend ai servizi di aggregazione fornendo loro unificate client-side servizi come layout e la tematizzazione, nonché servizi di coordinamento per il client-side integrazione dei servizi
Applicare il modello Composite Frontend ai servizi di aggregazione fornendo loro unificate client-side servizi come layout e la tematizzazione, nonché servizi di coordinamento per il client-side integrazione dei servizi
Figura 6.5 Il pattern Composite Frontend. Ogni servizio dispone di un portlet che è un agente di servizio combinato con una logica di UI (Modello molto probabilmente in un pattern MVC UI). L'host interfaccia utente fornisce i servizi per i potlets diverse per tessere insieme in un'interfaccia utente coerente.
Il pattern Composite Frontend è di prendere le idee (e, talvolta, le tecnologie) dietro portale web e la loro applicazione ai servizi SOA. Portali Web forniscono punto di accesso unificato che le pagine web aggrega più. Essi forniscono inoltre single sign-one e la personalizzazione. Interfacce SOA bisogno di questo e altro ancora.
Il composito front-end modello è composto da due componenti principali: il portlet e l'host. I portlet sono i mattoni ", i compositi", che si fondono insieme per formare l'interfaccia utente. I portlet sono realizzate almeno due componenti. L'interfaccia logica utente (punti di vista e controller MVC in gergo). Il secondo componente, il proxy servizio (o agenti), è quello più interessante dal punto di vista SOA. Il servizio proxy è un client-side rappresentazione di un servizio. Il proxy serve da modello per i componenti delle interfacce utente. Di solito è consigliabile avere un singolo proxy per ogni servizio, proprio come è raccomandato per ogni servizio per mantenere il proprio archivio dati. Inoltre, dal punto di vista della gestione del prodotto può essere visto come parte del servizio stesso
L'host è la parte "a valore aggiunto" del modello frontend composito. L'host fornisce il collante che lega i portlet differenti in un insieme coerente. Come tale, l'host fornisce diversi ruoli. In primo luogo fornisce la tela o la superficie su cui vengono visualizzati i portlet. Inoltre controlla il ciclo di vita dei portlet e infine fornisce capacità (evitando i servizi caricati termine ...), come inter-portlet di comunicazione e single-sign-on.
Consente di rivedere il problema descritto nella sezione precedente. Abbiamo avuto un tasto destro del mouse su un componente ui, che avrebbe prodotto un menu contestuale con le opzioni dei due servizi.Come vorrei che farebbe con il modello frontend composito? Una possibilità è che un clic vuol essere il primo intercettato dal conduttore che sarebbe poi la spedizione verso qualsiasi portlet registrato. Un'altra opzione illustrato in figura 6.6, è per il click per essere intercettati dal primo portlet dell'immagine Operation comune (o COP), hanno poi a notificare l'host e avere l'host chiedere a tutti i portlet iixnvolved per rendere il menu del tasto destro. Il portlet COP dovrebbe passare abbastanza informazioni come parte della manifestazione per gli altri porlets essere in grado di fare qualcosa di significativo con.
Figura 6.6: Esempio di flusso di eventi in un Composite Frontend. Gli eventi vengono intercettati dai componenti dell'interfaccia utente di portlet individui, gli eventi vengono trasferiti all'host che li invia a protlets registrati per la movimentazione. L'host può quindi rendere i risultati per la visualizzazione
Il modello frontend composito è un modello di consumatore di servizi in modo che il proxy utilizzare i vari modelli di servizi di interazione come saga, richiesta / risposta, ecc (vedi capitolo 5) e può beneficiare dei vari modelli di composizione di servizi come Service Registry e Servicbus (vedi capitolo 7)
Hai accorge probabilmente l'uso dei portlet termine per descrivere gli agenti di servizio e si potrebbe chiedere perché il modello si chiama Frontend Composite piuttosto che Portal. Il motivo principale di ciò è che il modello può essere utilizzato anche con le implementazioni di rich client e non solo quelle web - esploriamo che ulteriormente nella sezione tecnologia di mappatura
6.1.3 Tecnologia Mapping
Normalmente, si preferisce non sarà sviluppare il proprio contenitore Frontend Composite e di utilizzare invece i prodotti esistenti che forniscono il quadro e di solito le attrezzature per aiutare a costruire i portlet.
L'esempio evidente per che sono strutture portale web. I moderni portali web aziendali in genere supportano qualsiasi cosa, da JSR 168/286 (Java Portlet specifica) a WSRP (Web Services for Remote Portlet) per aprire gli standard web come RSS, servizi REST semplici o standard come sociale aperto. Ci sono un sacco di prodotti in questo settore sia in termini commerciali come IBM WebSphere Portal Server e Microsoft Sharepoint e opzioni open source come JBoss Gatein e Lifray. Figura 6.7 qui di seguito si mostrano funzionalità di layout di accoglienza interfaccia utente, così come attuato in Jboss Gatein
Figura 6.7: La capacità di layout di un ospite Composite UI Frontend, così come attuato in Jboss Gatein portale.
Portali web non sono l'unica opzione per l'applicazione frontend compositi. È anche possibile implementare il concetto di desktop, "rich client") le applicazioni. Un esempio di ciò è il quadro prisma fatto da modello di Microsoft e di gruppo Practices. Prism implementa il pattern Composite Frontend sia per le applicazioni Silverlight e WPF. Prism fornisce tutte le funzionalità di un host interfaccia utente e consente di scrivere portlet che utilizzano queste capacità. Frammento di 6,4 codice di seguito dimostrano utilizzando un impianto che permette EventAggregator inter-portlet comunicazioni (come quello necessario per lo scenario campione nell'esempio componente mappa sopra):
Codice 6.4 utilizzo di esempio di EventAggregator Prism di inviare gli eventi tra porlets diverse unificate dalla shell prisma
01.[Export (typeof (SampleView))]. 02pubblica parziale class SampleView: UserControl03.{04.[ImportingConstructor]05.pubblica SampleView ([Import] IEventAggregator EventAggregator06.{. 07InitializeComponent ();08.. eventAggregator.GetEvent> () Iscriviti (OnItemSelectedReceived); # 109.}10.pubblica vuoto ItemSelectedReceived (voce ItemSelectedEvent)11.{12./ / fai qualcosa con voce ...13.}14.}
# 1 la sottoscrizione di uno temSelectedEvent. Un altro portlet può chiamare salire sul EventAggregator per ottenere un riferimento alla manifestazione ed aumentare senza sapere se Thare sono dei sottoscrittori
Infine, oltre ai quadri del portale web e un quadro del desktop si può rotolare una propria implementazione di Frontend Composite. Tuttavia, come già detto di solito è meglio scegliere una delle opzioni disponibili come un investimento abbastanza per farlo bene.
6.1.4 Attributi di qualità
Prima di passare allo schema successivo permette di esaminare alcune unità di business (o scenari) che possono guidare di usare il pattern Composite Frontend.
In sostanza, le unità principali Frontend Composite sono la flessibilità di aggiungere e modificare i servizi e il desiderio di un'interfaccia utente integrata che si sente come uno 6.X intera tabella fornisce un esempio per entrambi gli attributi di qualità:
Qualità Attribute (level1)
|
Qualità Attribute (level2)
|
Scenario di esempio
|
| Usabilità | Operabilità | In uso normale utente del sistema finale vuole realizzare attività aziendali correntemente. Il sistema dovrebbe riutilizzare i dati inseriti (ad esempio dati personali) tra i diversi compiti |
| Flessibilità | Changability | In condizioni normali, la modifica del processo di fatturazione per sostenere una nuova carta di credito fornitore di spazio, dovrebbe prendere meno di una settimana |
Tabella 6.3 composito di qualità modello frontend attribuisce scenari. Questi sono gli scenari architettonici che possono farci pensare di utilizzare pattern Composite frontend.
Frontend Composite è probabilmente il modo migliore per fornire un'interfaccia utente SOA. Tuttavia, un problema che dobbiamo ancora risolvere con l'integrazione delle interfacce utente è interfacce utente che non sono a conoscenza SOA - per esempio cosa succede quando abbiamo un utente esistente che si desidera esporre ai servizi? Il modello successivo sarà cercare di rispondere esattamente questo.
