Che cosa è SOA? 7 SOA Steps

Questo blog descrive i passaggi SOA che un’organizzazione deve intraprendere prima di poter avere veramente successo nel realizzare i vantaggi in termini di costi e agilità offerti dall’architettura orientata ai servizi aziendali. Discute cosa rappresenta SOA e le varie fasi dell’adozione di SOA descrivendo le tecnologie, i processi e le best practice disponibili per aiutare le aziende ad avere successo nelle loro iniziative di architettura orientata ai servizi.

Che cos’è SOA?

L’architettura orientata ai servizi (SOA) è un tipo di architettura utilizzata nella progettazione software che supporta l’orientamento ai servizi, in base al quale i servizi vengono forniti ad altri componenti attraverso un protocollo di comunicazione su una rete.

Cosa significa SOA?

La definizione di SOA, come fornito da Wikipedia:

Service-oriented architecture (SOA) è uno stile di progettazione software in cui i servizi sono forniti agli altri componenti da componenti applicativi, attraverso un protocollo di comunicazione su una rete. I principi di base dell’architettura orientata ai servizi sono indipendenti da fornitori, prodotti e tecnologie. Un servizio è un’unità discreta di funzionalità a cui è possibile accedere da remoto e agire e aggiornarsi in modo indipendente, come il recupero di un estratto conto della carta di credito online.

Un servizio ha quattro proprietà secondo una delle tante definizioni di SOA:

1. Rappresenta logicamente un’attività commerciale con un risultato specificato.
2. È autonomo.
3. È una scatola nera per i suoi consumatori.
4. Può essere costituito da altri servizi sottostanti.

Diversi servizi possono essere utilizzati in combinazione per fornire la funzionalità di una grande applicazione software, un principio SOA condivide con la programmazione modulare. L’architettura orientata ai servizi integra componenti software distribuiti, gestiti separatamente e distribuiti. È abilitato da tecnologie e standard che facilitano la comunicazione e la cooperazione dei componenti su una rete, in particolare su una rete IP.

Questo fornisce una risposta concisa a cosa significa SOA, ma non descrive le ragioni per cui un’organizzazione vorrebbe spostarsi verso un’architettura orientata ai servizi o i vantaggi di SOA.

Anche da Wikipedia su cosa significa SOA:

Alcuni architetti aziendali ritengono che SOA possa aiutare le aziende a rispondere in modo più rapido e più economico alle mutevoli condizioni di mercato.Questo stile di architettura promuove il riutilizzo a livello di macro (servizio) piuttosto che a livello di micro (classi). Può anche semplificare l’interconnessione e l’utilizzo di risorse IT esistenti (legacy).

Per alcuni aspetti, SOA potrebbe essere considerato come un’evoluzione architettonica piuttosto che come una rivoluzione. Cattura molte delle best practice delle architetture software precedenti. Nei sistemi di comunicazione, ad esempio, si è verificato uno scarso sviluppo di soluzioni che utilizzano collegamenti veramente statici per parlare con altre apparecchiature della rete. Adottando un approccio SOA, tali sistemi possono posizionarsi per sottolineare l’importanza di interfacce ben definite e altamente interoperabili.

Approfondendo questi concetti possiamo vedere che esiste una serie di funzionalità di base necessarie per ottenere i potenziali benefici di SOA. Wikipedia discute un certo numero di questi principi guida, tra i quali:

• Riutilizzare – la capacità di incapsulare e di esporre a grana grossa funzioni aziendali come servizi
• Loose-giunto – in modo che i consumatori sono sufficientemente astratto dall’implementazione fisica di un servizio di
• Identificazione e categorizzazione (reperibilità), verificare che i potenziali consumatori possono trovare i servizi di cui hanno bisogno

Non importa che SOA definizione in uso, questi principi fondamentali portare a un ordine naturale delle attività di un’organizzazione deve completare in modo incrementale, realizzare i benefici di service-oriented architettura.

Scopri perché Akana è un forte Performer nel Forrester Wave™: API Management Solutions, rapporto Q3 2020.

Scarica Report

Quali sono i sette passaggi SOA?

Ci sono sette passaggi SOA:

1. Crea/esposizione di Servizi
2. Register Servizi

Servizi

3. Gestisci (monitor) Servizi
4. Mediare e Virtualizzare i Servizi
5. Governare la SOA
6. SOA Integrazione Con ESB

SOA i passaggi da 2 a 6 descrivere cross-enterprise preoccupazioni che dovrebbero essere affrontate con una gestione centralizzata infrastruttura SOA platform. I passaggi 1 e 7 soddisfano esigenze specifiche e vengono spesso forniti come parte di uno stack di applicazioni enterprise esistente. Seguendo questi passaggi porterà un’organizzazione lungo la strada giusta per realizzare i benefici di SOA. Continua a leggere per approfondire ogni passo SOA.

Creare/Esporre servizi

Il primo passo per spostare un’organizzazione verso SOA è ovvio. Non ci può essere nessuna applicazione SOA senza servizi, quindi il primo passo deve essere quello di esporre o creare servizi che possono essere facilmente utilizzati da applicazioni abilitate ai servizi Web.

Ci sono una serie di decisioni interessanti che le aziende devono affrontare quando iniziano questo processo, non ultima la decisione di ricostruire le applicazioni esistenti utilizzando un paradigma orientato ai servizi o di esporre la logica applicativa esistente come un insieme di servizi. Questa non è una decisione binaria, naturalmente, e la maggior parte delle organizzazioni costruirà nuovi servizi da zero, spesso utilizzando J2EE e/o.NET, e esporrà anche servizi da mainframe esistenti e altre applicazioni aziendali.

Esiste una vasta gamma di soluzioni diverse per le aziende che desiderano esporre le applicazioni esistenti come servizi, tra cui SOLA, leader di mercato di Akana, che consente alle applicazioni mainframe CICS di esporre e utilizzare servizi affidabili, sicuri e ad alte prestazioni.

Qualsiasi azienda con un investimento significativo (più di 1000 MIPS secondo Gartner) in mainframe dovrebbe studiare modi per sfruttare meglio i vantaggi di questa piattaforma e dovrebbe utilizzare i servizi Web per integrare facilmente le proprie applicazioni mainframe con i sistemi moderni. La SOLA di Akana è collaudata in termini di produzione presso clienti come Merrill Lynch, dove elabora più di 2 milioni di transazioni al giorno da più di 600 servizi Web. SOLA è l’unico prodotto che offre ai programmatori mainframe un’interfaccia facile da usare e basata sul Web per esporre e consumare servizi dalle applicazioni CICS. Include il supporto integrato per funzionalità avanzate di servizi Web come WS-Security, XML-Encryption e XML-Signature.

La maggior parte delle aziende tradizionali enterprise Application Integration (EAI) stanno anche fornendo versioni dei loro adattatori che espongono i servizi Web piuttosto che i loro protocolli proprietari tradizionali. In effetti molte di queste piattaforme EAI stanno riemergendo come prodotti Enterprise Service Bus. L’ESB affronta diversi problemi, uno dei quali è la funzionalità di tipo commodity data services utilizzata per esporre le interfacce dei servizi Web dagli adattatori tradizionali.

Che cos’è un servizio Web?

Da Wikipedia:

In relazione ai Servizi Web W3C, il W3C ha definito un servizio web come: “Un servizio web è un sistema software progettato per supportare l’interazione macchina-macchina interoperabile su una rete. Ha un’interfaccia descritta in un formato processabile dalla macchina (in particolare WSDL). Altri sistemi interagiscono con il servizio Web in un modo prescritto dalla sua descrizione utilizzando i messaggi SOAP, in genere trasmessi tramite HTTP con una serializzazione XML in combinazione con altri standard relativi al Web.”

Questa definizione è interessante dal punto di vista tecnico, ma in realtà non arriva al cuore del valore che può essere derivato da SOA e servizi Web. Un aspetto fondamentale dei servizi Web è che dovrebbero esporre la logica di business tramite un’interfaccia basata su standard. Un aspetto importante dell’esposizione o della creazione di un servizio è la sua granularità. Ci sono molte diverse scuole di pensiero su ciò che costituisce un servizio (vedi sopra), ma la maggior parte degli architetti aziendali sarebbe d’accordo sul fatto che per essere utile in una SOA, un servizio deve essere sufficientemente grossolano per essere utile a più applicazioni diverse.

Questo, naturalmente, gel con uno dei principi fondamentali dei servizi in SOA – in modo che un servizio possa essere riutilizzato; deve essere generalmente utile e utilizzabile. Un esempio di un servizio generalmente utile potrebbe essere un servizio “getCustomerInfo” che restituirà i dettagli su un cliente da un identificatore cliente. Un servizio a grana più fine che potrebbe non essere generalmente utile potrebbe essere qualcosa di specifico per una particolare applicazione, ad esempio “setApplicationState”.

È importante considerare la granularità dei servizi sia quando si creano nuovi servizi, sia quando si espone la logica di business esistente come servizio. Ad esempio, sarebbe facile prendere una transazione CICS ed esporre più servizi diversi per impostare e ottenere vari parametri, mentre la realtà è che un servizio a grana più grossa che espone l’intera transazione come un singolo servizio potrebbe essere molto più generalmente utile e quindi prezioso.

Lettura correlata: scopri come l’API mainframe SOLA di Akana offre ai clienti un processo semplice e veloce per esporre le applicazioni mainframe come servizi Web sicuri e consente alle applicazioni mainframe di utilizzare i servizi Web.

Registrati

Ok, in modo da avere uno o più servizi disponibili nella vostra azienda. E ora?

Affinché un servizio possa essere utilizzato, figuriamoci riutilizzato, gli architetti di applicazioni e gli sviluppatori che potrebbero trarre vantaggio da questo servizio devono sapere che esiste. Questo è dove entra in gioco un registro. Al suo livello più semplice, un registro non è altro che un indice di libreria che aiuta i potenziali utenti dei servizi a trovare servizi a cui potrebbero essere interessati. Il registro dovrebbe offrire sia interfacce di ricerca che di ricerca e dovrebbe essere organizzato logicamente per facilitare la scoperta rapida e accurata dei servizi.

Nella SOA di oggi lo standard accettato per i servizi di registro di base è UDDI (Universal Discover, Description, and Integration). La specifica UDDI fornisce un modello di dati e un set di interfacce (tutti i servizi Web stessi) per la pubblicazione e la scoperta di servizi, nonché un ulteriore set di interfacce per la gestione del server di registro stesso.

Molti fornitori di registry hanno preso il concetto originale di registry un po ‘ oltre e stanno usando le tecnologie di registro come base per un repository più completo. I fornitori di registri aggiungono anche filtri basati su ” policy “ai loro strumenti di pubblicazione e offrono”soluzioni di governance in tempo di progettazione”.

Akana considera il registro come un elemento fondamentale di SOA. Tutti i nostri prodotti sfruttano UDDI come un unico negozio centrale per informazioni autorevoli sui servizi in un SOA. I prodotti possono funzionare con qualsiasi registro conforme UDDI e Akana include il proprio server di registro UDDIv3 con il suo prodotto Service Manager per le aziende che non dispongono già di un registro. A questo proposito registry sta riempiendo il ruolo per SOA che LDAP riempito per le soluzioni di gestione delle identità e degli accessi.

I prodotti Akana si concentrano sulla governance in tempo di esecuzione e sfruttano il registro come luogo centrale per trovare le politiche in tempo di esecuzione da implementare e applicare. Naturalmente, il registro incorporato è completamente funzionale server UDDIv3 e quindi rende anche un repository di servizio in tempo di progettazione ideale.

Beyond registry è l’intero concetto di servizi di policy e metadati che forniscono repository completi per tutti gli artefatti in fase di progettazione e runtime per i servizi in SOA. Questo concetto è trattato in modo più dettagliato nel whitepaper di Akana Il modello di riferimento dell’infrastruttura SOA.

Sicuro

Il mondo dei servizi SOA e Web non è tutto vino e rose. Supponendo che ora hai completato i passaggi uno e passo, fai un passo indietro e considera cosa hai fatto. Supponendo che si sta andando per il massimo valore di business, si rischia di aver preso applicazioni mission critical, li suddivisi in pezzi a grana grossa di funzionalità, esposto questa funzionalità come servizi, e poi pubblicato questi servizi a un registro di sistema universalmente accessibile.

Tutto ciò può sembrare una buona cosa, e nella maggior parte dei casi è una grande cosa, ma potresti aver inavvertitamente creato alcuni buchi di sicurezza spalancati nella tua organizzazione ed esposto informazioni sensibili o transazioni di alto valore a chiunque abbia rudimentali competenze di servizi Web. Garantire la sicurezza dei servizi significa creare un livello di applicazione della sicurezza presso i fornitori di servizi e un livello di implementazione della sicurezza presso i consumatori di servizi.

Un buon modo per comprendere i rischi per la sicurezza con i servizi Web è quello di ripensare alle tradizionali applicazioni mainframe green screen. L’unica sicurezza richiesta da queste applicazioni era la sicurezza di accesso, se si poteva accedere all’applicazione, si era in. Queste applicazioni contenevano gli stessi pezzi di base di un’applicazione moderna (interfaccia, logica di business, servizi dati), ma solo l’interfaccia era accessibile al di fuori dell’applicazione. Nel mondo dei servizi Web, è probabile che alcuni dei servizi di dati di base saranno esposti come servizi, alcune delle logiche di business certamente dovrebbe essere esposto, e l’applicazione non è stata scritta con uno di questi punti di accesso in mente. Ciò significa che è fondamentale proteggere i servizi esposti individualmente, non è possibile fare affidamento sugli interni dell’applicazione per garantire la propria sicurezza.

Quindi cosa significa proteggere un servizio Web? Gli stessi 5 principi di sicurezza che si applicano ad altre applicazioni si applicano anche ai servizi Web:

• Autenticazione-assicurarsi di conoscere l’identità del richiedente del servizio (e anche assicurarsi che il richiedente conosce l’identità del servizio che sta contattando). Esistono diversi standard di servizi Web per l’autenticazione delle richieste, che vanno da approcci semplici come l’autenticazione di base http, a meccanismi più complessi come SAML o firma X. 509. Un buon strumento di sicurezza dei servizi Web dovrebbe supportare tutte queste varie opzioni.
• Autorizzazione: assicurarsi che il richiedente sia autorizzato ad accedere al servizio o all’operazione richiesta. L’autorizzazione è un problema complesso e ci sono un certo numero di vari prodotti di decisione politica disponibili. La maggior parte delle grandi aziende avrà una soluzione esistente per l’autorizzazione (CA SiteMinder, IBM TAM, ecc.) e una buona soluzione di sicurezza dei servizi Web dovrebbe essere in grado di integrarsi con questi e fornire le proprie capacità di autorizzazione.
• Privacy-assicurati che i messaggi di richiesta e risposta non possano essere letti da terze parti non autorizzate. È qui che gli standard come la crittografia XML entrano in proprio, ma per utilizzare con successo la crittografia XML, la soluzione di sicurezza dei servizi Web deve fornire funzionalità efficaci di gestione e distribuzione di chiavi e certificati e, idealmente, alcuni strumenti lato client per aiutare gli sviluppatori consumer.
• Non ripudio: assicurarsi che il richiedente non possa negare l’invio di una richiesta e che il servizio non possa negare l’invio della risposta. Questo è il ruolo della firma XML, con la stessa disposizione di gestione e distribuzione delle chiavi come per la privacy.
• Auditing-assicurarsi che il sistema possa mantenere una registrazione accurata e tempestiva delle richieste e delle risposte secondo necessità.

Una domanda interessante, e punto di dibattito, che sorge intorno alla sicurezza dei servizi Web è dove questa sicurezza dovrebbe essere applicata. Alcuni fornitori sosterranno che la sicurezza dovrebbe essere una funzione centrale applicata attraverso un cluster di proxy distribuiti centralmente, mentre altri sosterranno che dovrebbe essere esclusivamente il dominio del fornitore di servizi o del contenitore. La realtà, naturalmente, è da qualche parte tra queste due posizioni. C’è certamente un ruolo importante per un proxy (o cluster di proxy) nel fornire servizi di autenticazione e rilevamento delle minacce ai margini della rete per la protezione contro le minacce esterne. Esiste anche un ruolo altrettanto importante per la sicurezza basata sul provider o sul container per garantire la sicurezza del servizio fino all’ultimo miglio.

Molte aziende tendono a trascurare la ricerca che mostra che la maggior parte delle minacce alla sicurezza sono interne all’azienda, non esterne, e quindi delegano la sicurezza a un tipo di soluzione firewall. Akana offre un proxy ad alte prestazioni che esegue funzioni di sicurezza edge centralizzate o di rete e un’ampia gamma di agenti in container per garantire la sicurezza dell’ultimo miglio dei servizi distribuiti.

La protezione dei servizi Web richiede:

• Distribuire completamente-funzionale-contenitore agenti per assicurare l’ultimo miglio di sicurezza e di distribuire il carico di operazioni crittografiche
• Deploy di rete ad alte prestazioni intermediari per il routing e la rete edge applicazione di misure di sicurezza
• Fornire completa di chiavi e certificati di distribuzione e di gestione per garantire che il prestatore di servizi e dei consumatori, gli sviluppatori possono implementare con successo, necessari criteri di sicurezza
• Fornire ai consumatori toolkit per gli sviluppatori di astratto consumatore sviluppatori la complessità di scoprire e di implementazione di enterprise security policy

Lettura correlata: scopri di più sulle best practice di sicurezza API.

Gestisci

Tre passaggi nell’approccio a 7 fasi di SOA e stiamo iniziando a fare progressi verso il raggiungimento del valore reale da enterprise SOA. Abbiamo alcuni servizi, sono pubblicati in un registro e possono essere scoperti da potenziali utenti, e abbiamo assicurato che siano sicuri. Di cos’altro potremmo aver bisogno?

Per rispondere a questa domanda dovremmo prima esaminare un potenziale scenario di disastro. Cosa succede quando i miei servizi diventano vittime del loro stesso successo? Cioè. un servizio è diventato così popolare che ci sono diversi (decine, o centinaia, o migliaia) diverse applicazioni che lo consumano e inizia a fibbia sotto il carico. Improvvisamente abbiamo decine, o centinaia, o migliaia di applicazioni che stanno fallendo o eseguendo male e non sappiamo perché, o come fermarlo.

Dobbiamo monitorare i nostri servizi in modo da sapere se stanno eseguendo entro i normali parametri operativi e in modo da vedere potenziali problemi prima che si verifichino implementando modelli di pianificazione della capacità.

La soluzione di monitoraggio che implementiamo dovrebbe essere in grado di monitorare i servizi per la disponibilità di base, le prestazioni (tempo di risposta), il throughput e persino estendere ai contenuti e al monitoraggio basato sull’utente. Dovrebbe essere in grado di monitorare e avvisare su specifiche soglie di SLA e dovrebbe essere in grado di applicare diversi SLA a diversi utenti dello stesso servizio o operazione.

Molti fornitori definiscono questa categoria di prodotti come una soluzione di gestione dei servizi Web, anche se molti analisti concordano sul fatto che la gestione è molto più ampia di una semplice soluzione di monitoraggio e dovrebbe includere gran parte delle funzionalità descritte nella fase successiva.

Idealmente, ovviamente, non dovremmo distribuire soluzioni separate per la sicurezza e il monitoraggio perché ogni volta che intercettiamo i messaggi attraverso e agente o intermediario aggiungiamo un altro collo di bottiglia delle prestazioni. Questo è il motivo per cui il Service Manager di Akana si combina con Network Director per fornire una piattaforma di sicurezza, monitoraggio e gestione SOA completa in un’unica soluzione ad alte prestazioni e facile da implementare.

Alcuni fornitori di gestione dei servizi Web (monitoraggio) posizionano le loro soluzioni come piattaforme di monitoraggio delle attività aziendali (BAM), sebbene BAM sia una soluzione complessa che richiede l’integrazione con molti sistemi e database di back – e front-office. Il monitoraggio delle interazioni dei servizi Web per i contenuti non deve essere considerato un’alternativa a una soluzione BAM aziendale.

Lettura correlata: Scopri di più sulla soluzione di gestione API end-to-end di Akana.

5. Mediare e virtualizzare

A questo punto sembrerebbe che il nostro SOA sia pronto per il primetime. E così è, almeno per un po’…

La prossima serie di sfide si verifica quando la SOA matura. È necessario introdurre nuove versioni di servizi o aumentare la capacità di un servizio eseguendo più istanze di esso, è necessario eseguire il provisioning di applicazioni per utilizzare istanze specifiche di servizi e offrire servizi che espongono una gamma più ampia di tipi di interfaccia diversi.

È qui che entra in gioco la virtualizzazione dei servizi. La virtualizzazione sembra complessa, ma la realtà è abbastanza semplice. Un servizio virtuale è un servizio completamente nuovo, definito dal proprio WSDL, con un proprio indirizzo di rete e parametri di trasporto. Non implementa alcuna logica di business; agisce semplicemente come proxy per uno o più servizi fisici, routing, bilanciamento del carico, trasformazione e mediazione tra diversi tipi e standard di messaggi di richiesta.

Pur essendo semplice in superficie, il concetto di virtualizzazione è estremamente potente. Fornisce la capacità di astrarre completamente i consumatori di servizi da qualsiasi conoscenza diretta del servizio fisico. Ad esempio, tramite un servizio virtuale, un client.NET che utilizza un’implementazione Microsoft di un protocollo di messaggistica affidabile con SOAP su http potrebbe utilizzare un semplice vecchio servizio XML esposto tramite IBM WebSphere MQ series da un’applicazione mainframe. Il client. NET avrebbe creduto che fosse una comunicazione con un servizio http che supportava il suo protocollo di messaggistica affidabile, mentre l’applicazione mainframe avrebbe creduto che fosse interrogato da un’altra applicazione nativa della serie MQ.

I servizi virtuali offrono una vasta gamma di funzionalità:

• Possono utilizzare le tecnologie di trasformazione XML per consentire agli utenti di continuare a utilizzare una versione precedente di un servizio che non esiste più trasformando i messaggi di richiesta e risposta tra la versione precedente e la nuova versione distribuita.
• Possono selezionare operazioni specifiche da più servizi diversi e combinarle in un unico WSDL funzionale per una specifica classe di applicazioni consumanti.
• Possono fornire diversi requisiti di policy per diverse classi di utenti (es. utenti interni con un set di criteri e un’altra implementazione del servizio che applica un set di criteri diverso per i consumatori esterni).
• Possono fornire un ponte di trasporto per servizi e consumatori su trasporti incompatibili (ad esempio http e JMS). * Possono mediare tra l’implementazione di standard diversi o anche versioni di standard.
• Possono mediare tra diversi stili di messaggistica: RSS, SOAP, REST, POX (semplice vecchio XML).
• Possono fornire un potente routing basato sul contenuto o sul contesto per offrire funzionalità avanzate di bilanciamento del carico e alta disponibilità.

La linea di fondo con i servizi virtuali è che sono necessari per qualsiasi routing o altri servizi Web avanzati e diventeranno rapidamente una parte essenziale di qualsiasi SOA aziendale.

Governare

Con 5 su 7 passi completati, l’enterprise SOA è praticamente pronto ad andare. Ora hai servizi sicuri e gestiti che sono disponibili per un vasto pubblico in modo affidabile e bilanciato dal carico e sono facilmente individuabili.

Il passo successivo è quello di legare insieme tutte le funzionalità fornite attraverso i primi 5 passi con un quadro di governance. La governance è un lavoro abusato e molto abusato, quindi diamo un’occhiata brevemente a una definizione di governance. Ancora da Wikipedia:

Il termine governance riguarda i processi e i sistemi con cui opera un’organizzazione o una società. Spesso viene istituito un governo per amministrare questi processi e sistemi.

Il punto chiave da prendere da questa definizione è che la governance riguarda processi e sistemi. Nel caso della governance SOA, stiamo discutendo di processi organizzativi come un consiglio di revisione dell’architettura e di sistemi come le tecnologie di registro, sicurezza e gestione discusse in questo blog.

La governance per SOA è spesso divisa in due parti separate, design-time governance e run-time governance. In fase di progettazione, le organizzazioni vogliono controllare (governare) i tipi di servizi che possono essere pubblicati, chi può pubblicarli, quali tipi di schema e messaggi questi servizi possono accettare, e una serie di altre regole sui servizi. In fase di esecuzione, le organizzazioni devono garantire la sicurezza, l’affidabilità e le prestazioni dei propri servizi e devono garantire che i servizi siano conformi alle politiche aziendali definite. La governance in tempo di progettazione è interessante e aiuta a garantire una SOA organizzata e ben progettata, ma diventa insignificante rispetto al controllo attivo della SOA in fase di esecuzione.

Il Service Manager di Akana è la piattaforma di governance runtime leader del settore, che offre una soluzione completa per la sicurezza, il monitoraggio, la gestione, la mediazione e il registro di sistema. La runtime governance fornisce essenzialmente un unico framework per il controllo e il monitoraggio dell’applicazione delle varie fasi di SOA descritte in questo documento. Fornisce un’unica soluzione globale che fornisce supervisione nel registro di servizio, sicurezza, gestione e mediazione. Una buona soluzione di governance in fase di esecuzione si manifesterà come una forma di workbench che fornisce strumenti per tutti i partecipanti attivi in una SOA.

• Sviluppatore del servizio: strumenti per pubblicare, classificare, definire meta-dati, il download di “agente”, virtualizzazione, versione scegliere la politica, scegli visibilità/diritti di accesso, partecipazione nella pianificazione delle capacità di accesso e di flusso di lavoro
• Servizio di Consumo: Strumenti per facilitare l’individuazione del servizio di selezione e di accesso del flusso di lavoro
• Operazioni del Personale: gli Strumenti per monitorare le prestazioni del servizio, la risoluzione dei problemi, monitor dipendenze, versione, servizi di virtualizzazione, gestione proxy
• Sicurezza Personale: Strumenti per le politiche di gestione, criteri di reporting, controllo di conformità, controllo della protezione
• Enterprise Architect: Tools for application monitoring, relationship management, design policy validation and definition, service version management, service to proxy assignment, service virtualization
• Enterprise IT Management: Reuse metric management, service reuse metrics, SOA statistics

SOA Integration With ESB

Guardando indietro ai risultati degli ultimi 6 passaggi verso un SOA, ci chiediamo cos’altro possa esserci. Ormai abbiamo una serie di servizi che vengono pubblicati in un registro, sicuro, gestito, affidabile e liberamente accoppiato, il tutto avvolto in una solida soluzione di governance di progettazione e runtime.

Il passaggio finale per alcune aziende consiste nel distribuire una o più implementazioni di bus di servizi aziendali (ESB) per integrare i servizi in servizi compositi o orchestrati di livello superiore. Questi ESB saranno spesso forniti come parte di una suite di applicazioni più ampia, come Oracle eBusiness applications o SAP. Alcuni ESB specializzati possono essere utilizzati per creare servizi compositi complessi e si estenderanno al campo della gestione dei processi aziendali (BPM).

Lettura correlata: scopri di più sulle soluzioni di integrazione di Akana.

Enterprise Service Bus (ESB) è un concetto sempre più popolare. Originariamente concepito come l’evoluzione di entrambe le soluzioni message-oriented middleware e EAI (enterprise Application integration), l’ESB significa cose molto diverse per le diverse organizzazioni. Come analisti, fornitori e clienti venire a patti con l’idea di un ESB, sembra che un ESB incapsula 3 concetti funzionali; adattatori presi da uno strumento EAI per garantire la connettività con le applicazioni legacy, servizi di messaggistica presi da una piattaforma middleware message-oriented per garantire la consegna affidabile, e orchestrazione dei processi per costruire applicazioni agili.

Il consenso tra gli analisti è che la maggior parte delle organizzazioni finirà con più piattaforme ESB di più fornitori, fornendo servizi nel proprio contesto. In questo ambiente è fondamentale che gli ESB utilizzino un’infrastruttura SOA centrale per garantire la conformità coerente con le politiche di sicurezza e messaggistica per i servizi che espongono e consumano.

I prodotti Service Manager e Network Director di Akana si combinano per fornire una soluzione completa per la governance e la mediazione tra più istanze ESB in un’azienda.

Ora che sai di più su cosa significa SOA e sui passaggi chiave SOA, dai un’occhiata ad Akana in azione!

Inizia la prova