ce este SOA? 7 pași SOA

acest blog descrie pașii SOA pe care o organizație trebuie să îi ia înainte de a putea avea cu adevărat succes în realizarea beneficiilor de cost și agilitate oferite de arhitectura orientată spre servicii pentru întreprinderi. Acesta discută ceea ce reprezintă SOA și diferitele etape ale adoptării SOA prin Descrierea tehnologiilor, proceselor și celor mai bune practici disponibile pentru a ajuta companiile să reușească în inițiativele lor de arhitectură orientate spre servicii.

ce este SOA?

arhitectura orientată spre servicii (SOA) este un tip de arhitectură utilizat în proiectarea software-ului care acceptă orientarea către servicii, prin care serviciile sunt furnizate altor componente printr-un protocol de comunicare printr-o rețea.

ce înseamnă SOA?

definiția SOA, așa cum este furnizată de Wikipedia:

arhitectura orientată spre servicii (SOA) este un stil de proiectare software în care serviciile sunt furnizate celorlalte componente de către componentele aplicației, printr-un protocol de comunicare printr-o rețea. Principiile de bază ale arhitecturii orientate spre servicii sunt independente de furnizori, produse și tehnologii. Un serviciu este o unitate discretă de funcționalitate care poate fi accesată de la distanță și acționată și actualizată independent, cum ar fi recuperarea online a unui extras de card de credit.

un serviciu are patru proprietăți conform uneia dintre multele definiții ale SOA:

1. în mod logic, reprezintă o activitate de afaceri cu un rezultat specificat.
2. este autonom.
3. este o cutie neagră pentru consumatorii săi.
4. poate consta din alte servicii subiacente.

diferite servicii pot fi utilizate împreună pentru a oferi funcționalitatea unei aplicații software de mare, un principiu acțiuni SOA cu programare modulară. Arhitectura orientată spre servicii integrează componente software distribuite, întreținute separat și implementate. Este activat de tehnologii și standarde care facilitează comunicarea și cooperarea componentelor printr-o rețea, în special printr-o rețea IP.

aceasta oferă un răspuns concis la ceea ce înseamnă SOA, dar nu descrie motivele pentru care o organizație ar dori să se îndrepte spre arhitectura orientată spre servicii sau beneficiile SOA.

de asemenea, de la Wikipedia despre ceea ce înseamnă SOA:

unii arhitecți de întreprinderi consideră că SOA poate ajuta întreprinderile să răspundă mai rapid și mai eficient din punct de vedere al costurilor la condițiile de piață în schimbare.Acest stil de arhitectură promovează reutilizarea la nivel macro (serviciu), mai degrabă decât la nivel micro (clase). De asemenea, poate simplifica interconectarea și utilizarea activelor IT (moștenite) existente.

în unele privințe, SOA ar putea fi privită mai degrabă ca o evoluție arhitecturală decât ca o revoluție. Acesta surprinde multe dintre cele mai bune practici ale arhitecturilor software anterioare. În sistemele de comunicații, de exemplu, a avut loc puțină dezvoltare a soluțiilor care utilizează legături cu adevărat statice pentru a vorbi cu alte echipamente din rețea. Prin adoptarea unei abordări SOA, astfel de sisteme se pot poziționa pentru a sublinia importanța interfețelor bine definite, foarte interoperabile.

Forând în aceste concepte putem vedea că există un set de capacități de bază care sunt necesare pentru a obține beneficiile potențiale ale SOA. Wikipedia discută o serie de aceste principii directoare, printre care se numără:

• reutilizare – capacitatea de a încapsula și expune funcțiile de afaceri cu granulație grosieră ca servicii
• cuplare liberă-asigurarea faptului că consumatorii de servicii sunt suficient de abstractizați de implementarea fizică a unui serviciu
• identificare și clasificare (descoperire) – asigurarea faptului că potențialii consumatori pot găsi serviciile de care au nevoie

indiferent de definiția SOA directorii conduc la o ordine naturală a activităților pe care o organizație trebuie să le finalizeze pentru a realiza treptat beneficiile orientate către servicii arhitectura.

vedeți De ce Akana este un Performer puternic în Forrester Wave XV: API Management Solutions, raportul Q3 2020.

descărcați raportul

care sunt cei șapte pași SOA?

există șapte pași SOA:

1. creare/expunere servicii
2. Înregistrare servicii
3. servicii securizate
4. gestionare (monitorizare) servicii
5. mediere și virtualizare servicii
6. guvernează SOA
7. integrare SOA cu ESB

etapele soa de la 2 la 6 descriu preocupările între întreprinderi care ar trebui abordate cu o platformă centralizată de infrastructură SOA. Pașii 1 și 7 abordează nevoile specifice și sunt adesea livrați ca parte a unei stive de aplicații existente pentru întreprinderi. Urmând acești pași va conduce o organizație pe calea cea bună pentru a realiza beneficiile SOA. Continuați să citiți pentru a merge mai adânc în fiecare pas SOA.

creare/expunere servicii

primul pas în mutarea unei organizații către SOA este evident. Nu poate exista nicio aplicație SOA fără servicii, deci primul pas trebuie să fie expunerea sau crearea de servicii care pot fi consumate cu ușurință de aplicațiile activate pentru servicii Web.

există o serie de decizii interesante cu care se confruntă companiile pe măsură ce încep acest proces, nu în ultimul rând decizia de a reconstrui aplicațiile existente folosind o paradigmă orientată spre servicii sau de a expune logica aplicațiilor existente ca un set de servicii. Aceasta nu este o decizie binară, desigur, și cele mai multe organizații vor construi noi servicii de la zero, de multe ori folosind J2EE și/sau.NET, și va expune, de asemenea, servicii de mainframe existente și alte aplicații de afaceri.

există o gamă largă de soluții diferite pentru companiile care doresc să expună aplicațiile existente ca servicii, inclusiv SOLA lider de piață Akana, care permite aplicațiilor CICS mainframe să expună și să consume servicii fiabile, sigure și de înaltă performanță.

orice companie cu o investiție semnificativă (mai mult de 1000 MIPS conform Gartner) în mainframe ar trebui să investigheze modalități de a valorifica mai bine avantajele acestei platforme și ar trebui să utilizeze servicii Web pentru a-și integra cu ușurință aplicațiile mainframe cu sistemele moderne. SOLA Akana este dovedit de producție la clienți precum Merrill Lynch, unde procesează peste 2 milioane de tranzacții pe zi de la peste 600 de servicii Web. SOLA este singurul produs care oferă programatorilor mainframe o interfață ușor de utilizat, bazată pe Web, pentru expunerea și consumarea serviciilor din aplicațiile CICS. Acesta include built-in suport pentru capabilități avansate de servicii web, cum ar fi ws-securitate, XML-criptare, și XML-semnătură.

majoritatea companiilor tradiționale de integrare a aplicațiilor pentru întreprinderi (EAI) livrează, de asemenea, versiuni ale adaptoarelor lor care expun serviciile Web mai degrabă decât protocoalele lor tradiționale proprietare. De fapt, multe dintre aceste platforme EAI sunt re-emergente ca Enterprise Service Bus produse. ESB abordează mai multe probleme diferite, dintre care una este funcționalitatea de tip commodity data services utilizată pentru a expune interfețele serviciilor Web de la adaptoarele tradiționale.

ce este un serviciu Web?

De La Wikipedia:

în ceea ce privește serviciile web W3C, W3C a definit un serviciu web ca: „un serviciu web este un sistem software conceput pentru a sprijini interacțiunea mașină-mașină interoperabilă printr-o rețea. Are o interfață descrisă într-un format procesabil de mașină (în special WSDL). Alte sisteme interacționează cu serviciul web într-o manieră prescrisă de descrierea sa folosind mesaje SOAP, transmise de obicei folosind HTTP cu o serializare XML împreună cu alte standarde legate de web.”

această definiție este interesantă din punct de vedere tehnic, dar nu ajunge cu adevărat la inima valorii care poate fi derivată din SOA și serviciile Web. Un aspect fundamental al serviciilor Web este că acestea ar trebui să expună logica de afaceri printr-o interfață bazată pe standarde. Un aspect important al expunerii sau creării unui serviciu este granularitatea acestuia. Există multe școli diferite de gândire cu privire la ceea ce constituie un serviciu (vezi mai sus), dar majoritatea arhitecților de întreprinderi ar fi de acord că pentru a fi util într-un SOA, un serviciu trebuie să fie suficient de grosier pentru a fi util pentru mai multe aplicații diferite.

acest lucru, desigur, se potrivește cu unul dintre principiile fundamentale ale serviciilor din SOA – pentru ca un serviciu să fie reutilizat; trebuie să fie în general util și utilizabil. Un exemplu de serviciu în general util ar putea fi un serviciu” getCustomerInfo ” care va returna detalii despre un client de la un identificator de client. Un serviciu cu granulație mai fină, care poate să nu fie în general util, ar putea fi ceva specific unei anumite aplicații, de exemplu „setApplicationState”.

este important să se ia în considerare granularitatea serviciilor atât atunci când se construiesc noi servicii, cât și atunci când se expune logica de afaceri existentă ca serviciu. De exemplu, ar fi ușor să luați o tranzacție CICS și să expuneți mai multe servicii diferite pentru a seta și a obține diverși parametri, în timp ce realitatea este că un serviciu cu granulație mai grosieră care expune întreaga tranzacție ca un singur serviciu ar putea fi mult mai general util și, prin urmare, valoros.

lectură înrudită: Aflați cum API-ul mainframe Sola al Akana oferă clienților un proces rapid și ușor de expunere a aplicațiilor mainframe ca servicii web sigure și permite aplicațiilor mainframe să consume servicii web.

înregistrați

Ok, deci aveți unul sau mai multe servicii disponibile în întreprinderea dvs. Acum ce?

pentru ca un serviciu să fie utilizat, cu atât mai puțin reutilizat, arhitecții și dezvoltatorii de aplicații care ar putea beneficia de acest serviciu trebuie să știe că există. Aici intervine un registru. La nivelul său cel mai simplu, un registru nu este altceva decât un index de bibliotecă care ajută potențialii utilizatori de servicii să găsească servicii de care ar putea fi interesați. Registrul ar trebui să ofere atât interfețe de căutare, cât și de navigare și ar trebui organizat logic pentru a facilita descoperirea rapidă și precisă a serviciilor.

în SOA de astăzi, standardul acceptat pentru serviciile de registru de bază este UDDI (Universal Discover, Description and Integration). Specificația UDDI oferă un model de date și un set de interfețe (toate serviciile Web în sine) pentru publicarea și descoperirea serviciilor, precum și un set suplimentar de interfețe pentru gestionarea serverului de registru în sine.

mulți furnizori de registru au dus conceptul original de registru destul de mult și folosesc tehnologiile de registru ca bază pentru un depozit mai complet. Furnizorii de registre adaugă, de asemenea, filtre bazate pe” politici „la instrumentele lor de publicare și oferă”soluții de guvernare în timp de proiectare”.

Akana consideră că registrul este un element fundamental al SOA. Toate produsele noastre folosesc UDDI ca un singur magazin central pentru informații autoritare despre serviciile dintr-un SOA. Produsele pot funcționa cu orice registru compatibil UDDI, iar Akana include propriul server de registru UDDIv3 cu produsul său Service Manager pentru companiile care nu au deja un registru. În acest sens, Registrul îndeplinește rolul SOA pe care LDAP l-a ocupat pentru soluții de gestionare a identității și accesului.

produsele Akana se concentrează pe guvernanța run-time și folosesc Registrul ca un loc central pentru a găsi politici run-time pentru a implementa și a pune în aplicare. Desigur, Registrul încorporat este pe deplin funcțional UDDIv3 server și astfel face, de asemenea, un depozit ideal de servicii de proiectare-Timp.

Beyond registry este întregul concept de servicii de politici și metadate care oferă depozite complete pentru toate artefactele de proiectare și execuție pentru serviciile din SOA. Acest concept este acoperit mai detaliat în Cartea albă Akana modelul de referință al infrastructurii SOA.

Secure

lumea SOA și servicii Web nu este tot vin și trandafiri. Presupunând că ați finalizat acum pașii unu și pas, faceți un pas înapoi și luați în considerare ceea ce ați făcut. Presupunând că veți obține o valoare maximă a afacerii, este posibil să fi luat aplicații critice pentru misiune, să le împărțiți în bucăți de funcționalitate cu granulație grosieră, să expuneți această funcționalitate ca servicii și apoi să publicați aceste servicii într-un registru universal accesibil.

toate acestea pot părea un lucru bun și, în cele mai multe cazuri, este un lucru minunat, dar este posibil să fi creat din greșeală niște găuri de securitate în organizația dvs. și să fi expus informații sensibile sau tranzacții de mare valoare oricui are abilități rudimentare de servicii Web. Asigurarea securității serviciilor înseamnă construirea unui nivel de aplicare a securității la furnizorii de servicii și a unui nivel de implementare a securității la consumatorii de servicii.

o modalitate bună de a înțelege riscurile de securitate cu serviciile Web este să vă gândiți la aplicațiile tradiționale mainframe cu ecran verde. Singura securitate cerută de aceste aplicații a fost securitatea de conectare, dacă ați putea accesa aplicația, ați fost înăuntru. Aceste aplicații conțineau aceleași piese de bază ca o aplicație modernă (interfață, logică de afaceri, servicii de date), dar numai interfața era accesibilă în afara aplicației. În lumea serviciilor Web, este probabil ca unele dintre serviciile de date de bază să fie expuse ca servicii, o parte din logica de afaceri cu siguranță ar trebui expusă, iar aplicația nu a fost scrisă având în vedere niciunul dintre aceste puncte de acces. Aceasta înseamnă că este esențial să securizați serviciile pe care le expuneți individual, nu vă puteți baza pe componentele interne ale aplicației pentru a vă asigura propria securitate.

deci, ce înseamnă să securizezi un serviciu Web? Aceleași 5 principii de securitate care se aplică altor aplicații se aplică și serviciilor Web:

• autentificare-asigurați-vă că cunoașteți identitatea solicitantului de servicii (și, de asemenea, asigurați-vă că solicitantul cunoaște identitatea serviciului pe care îl contactează). Există mai multe standarde diferite de servicii Web pentru autentificarea cererilor, variind de la abordări simple, cum ar fi autentificarea de bază http, până la mecanisme mai complexe, cum ar fi semnătura SAML sau X. 509. Un bun instrument de securitate Servicii Web ar trebui să sprijine toate aceste opțiuni diferite.
• autorizare-asigurați-vă că solicitantul este autorizat să acceseze serviciul sau operațiunea pe care o solicită. Autorizarea este o problemă complexă și există un număr de diferite produse de decizie politică disponibile. Majoritatea întreprinderilor mari vor avea o soluție existentă pentru autorizare (ca SiteMinder, IBM tam etc.), iar o soluție bună de securitate a serviciilor Web ar trebui să se poată integra cu acestea, precum și să ofere propriile capacități de autorizare.
• Confidențialitate – asigurați-vă că mesajele de solicitare și răspuns nu pot fi citite de părțile neautorizate 3rd. Acesta este locul în care standardele precum criptarea XML intră în propriile lor, dar pentru a utiliza cu succes criptarea XML, soluția de securitate a serviciilor Web trebuie să ofere capacități eficiente de gestionare și distribuție a cheilor și certificatelor și, în mod ideal, unele instrumente din partea clientului pentru a ajuta dezvoltatorii consumatorilor.
• Non-repudiere-asigurați-vă că solicitantul nu poate refuza trimiterea unei cereri și asigurați-vă că serviciul nu poate refuza trimiterea răspunsului său. Acesta este rolul semnăturii XML, cu aceeași dispoziție de gestionare și distribuție a cheilor ca și pentru confidențialitate.
• audit-asigurați-vă că sistemul poate menține o înregistrare corectă și în timp util a solicitărilor și răspunsurilor, după cum este necesar.

o întrebare interesantă și un punct de dezbatere care apare în jurul securității serviciilor Web este locul în care ar trebui aplicată această securitate. Unii furnizori vor argumenta că securitatea ar trebui să fie o funcție centrală aplicată printr-un grup de proxy-uri implementate central, în timp ce alții vor argumenta că ar trebui să fie exclusiv domeniul furnizorului de servicii sau al containerului. Realitatea este, desigur, undeva între aceste două poziții. Există cu siguranță un rol important pentru un proxy (sau un grup de proxy-uri) în furnizarea de servicii de autentificare și detectare a amenințărilor la marginea rețelei pentru a proteja împotriva amenințărilor externe. Există, de asemenea, un rol la fel de important pentru securitatea bazată pe furnizor sau container pentru a asigura securitatea serviciului până la ultima milă.

multe companii tind să treacă cu vederea cercetările care arată că majoritatea amenințărilor de securitate sunt interne pentru întreprindere, nu externe și, prin urmare, deleagă securitatea unui tip de soluție firewall. Akana oferă un proxy de înaltă performanță care efectuează funcții de securitate centralizate sau de rețea și o gamă largă de agenți de containere pentru a asigura securitatea ultimei mile a serviciilor implementate.

asigurarea serviciilor Web necesită:

• implementați agenți complet funcționali în containere pentru a asigura securitatea ultimei mile și pentru a distribui sarcina operațiunilor criptografice
• implementați intermediari de rețea de înaltă performanță pentru rutare și aplicarea securității de margine a rețelei
• oferiți o gestionare și o distribuție cuprinzătoare a cheilor și certificatelor pentru a vă asigura că furnizorii de servicii și dezvoltatorii de consumatori pot implementa cu succes politicile de securitate necesare
• furnizați seturi de instrumente pentru dezvoltatori de consum dezvoltatorilor abstracți din complexitatea descoperirii și implementării securității întreprinderii politici

lectură înrudită: Aflați mai multe despre cele mai bune practici de securitate API.

gestionați

trei pași în abordarea în 7 pași a SOA și începem să facem unele progrese către obținerea unei valori reale din SOA pentru întreprinderi. Avem unele servicii, acestea sunt publicate într-un registru și pot fi descoperite de către potențialii utilizatori, și ne-am asigurat că acestea sunt sigure. Ce altceva am putea avea nevoie?

pentru a răspunde la această întrebare, ar trebui să analizăm mai întâi un potențial scenariu de dezastru. Ce se întâmplă când serviciile mele devin victime ale propriului succes? Adică. un serviciu a devenit atât de popular încât există mai multe (zeci, sute sau mii) aplicații diferite care îl consumă și începe să se îndoaie sub sarcină. Dintr-o dată avem zeci, sute sau mii de aplicații care eșuează sau au performanțe slabe și nu știm de ce sau cum să o oprim.

trebuie să ne monitorizăm serviciile astfel încât să știm dacă acestea funcționează în parametrii normali de funcționare și astfel să vedem potențiale probleme înainte de a apărea prin implementarea modelelor de planificare a capacității.

soluția de monitorizare pe care o implementăm ar trebui să poată monitoriza Serviciile pentru disponibilitatea de bază, performanță (timp de răspuns), randament și chiar să se extindă la conținut și monitorizare bazată pe utilizatori. Ar trebui să poată monitoriza și alerta cu privire la anumite praguri SLA și ar trebui să poată aplica sla diferite utilizatorilor diferiți ai aceluiași serviciu sau operațiune.

mulți furnizori definesc această categorie de produse ca o soluție de gestionare a serviciilor Web, deși mulți analiști sunt de acord că managementul este mult mai larg decât o soluție simplă de monitorizare și ar trebui să includă o mare parte din funcționalitatea descrisă în pasul următor.

în mod ideal, desigur, nu ar trebui să implementăm soluții separate pentru securitate și monitorizare, deoarece de fiecare dată când interceptăm mesaje și agent sau intermediar adăugăm un alt blocaj de performanță. Acesta este motivul pentru care managerul de servicii Akana se combină cu Network Director pentru a oferi o platformă cuprinzătoare de securitate, Monitorizare și gestionare SOA într-o singură soluție, de înaltă performanță, ușor de implementat.

unii furnizori de gestionare a serviciilor Web (monitorizare) își poziționează soluțiile ca platforme de monitorizare a activității de afaceri (BAM), deși BAM este o soluție complexă care necesită integrare cu multe sisteme și baze de date back – și front-office. Monitorizarea interacțiunilor serviciilor Web pentru conținut nu ar trebui considerată o alternativă la o soluție BAM de întreprindere.

Lectură Înrudită: Aflați mai multe despre soluția de gestionare API end-to-End a Akana.

5. Mediați și virtualizați

în acest moment s-ar părea că SOA-ul nostru este pregătit pentru primetime. Și așa este, cel puțin pentru o vreme…

următorul set de provocări apare pe măsură ce SOA-ul tău se maturizează. Trebuie să introduceți noi versiuni de servicii sau să creșteți capacitatea unui serviciu rulând mai multe instanțe ale acestuia, trebuie să furnizați aplicații pentru a utiliza instanțe specifice de servicii și trebuie să oferiți servicii care expun o gamă mai largă de tipuri de interfețe diferite.

aici intervine virtualizarea serviciilor. Virtualizarea pare complexă, dar realitatea este destul de simplă. Un serviciu virtual este un serviciu complet nou, definit de propriul WSDL, cu propria adresă de rețea și parametrii de transport. Nu implementează nicio logică de afaceri; acționează pur și simplu ca un proxy pentru unul sau mai multe servicii fizice, rutare, echilibrare a încărcării, transformare și mediere între diferite tipuri și standarde de mesaje de solicitare.

în timp ce simplu la suprafață, conceptul de virtualizare este extrem de puternic. Acesta oferă posibilitatea de a abstractiza pe deplin consumatorii de servicii de la orice cunoaștere directă a serviciului fizic. De exemplu, printr-un serviciu virtual, un client.net care utilizează o implementare Microsoft a unui protocol de mesagerie fiabil cu SOAP peste http ar putea consuma un serviciu XML simplu vechi expus prin seria IBM WebSphere MQ dintr-o aplicație mainframe. Clientul. net ar crede că a fost comunicarea cu un serviciu http care a susținut protocolul său de mesagerie fiabil, în timp ce aplicația mainframe ar crede că a fost interogată de o altă aplicație nativă din seria mq.

serviciile virtuale oferă o gamă largă de funcționalități:

• aceștia pot utiliza tehnologii de transformare XML pentru a permite consumatorilor să continue să utilizeze o versiune veche a unui serviciu care nu mai există prin transformarea mesajelor de solicitare și răspuns între versiunea veche și noua versiune care a fost implementată.
• pot selecta operațiuni specifice din mai multe servicii diferite și le pot combina într-un singur WSDL funcțional pentru o anumită clasă de aplicații consumatoare.
• acestea pot furniza cerințe de politică diferite pentru diferite clase de utilizatori (adică. un set de politici și o altă implementare a serviciului care impune un set de politici diferit pentru consumatorii externi).
• acestea pot furniza legături de transport pentru servicii și consumatori pe transporturi incompatibile (de exemplu, http și JMS). * Ele pot media între diferite standarde de punere în aplicare sau chiar versiuni ale standardelor.
• ele pot media între diferite stiluri de mesagerie – RSS, SOAP, REST, POX (plain old XML).
• pot oferi rutare puternică bazată pe conținut sau context pentru a oferi capacități avansate de echilibrare a încărcării și disponibilitate ridicată.

linia de jos cu servicii virtuale este că acestea sunt necesare pentru orice rutare sau alte servicii web avansate, și va deveni rapid o parte esențială a oricărei întreprinderi SOA.

Govern

cu 5 din 7 etape finalizate, SOA întreprindere este destul de mult gata pentru a merge. Acum aveți servicii sigure, gestionate, care sunt disponibile pentru un public larg într-un mod fiabil, echilibrat de încărcare și sunt ușor de descoperit.

următorul pas este de a lega împreună toate capacitățile livrate prin primii 5 pași cu un cadru de guvernanță. Guvernarea este o muncă suprautilizată și mult abuzată, așa că haideți să analizăm pe scurt o definiție a guvernanței. Din nou de la Wikipedia:

termenul de guvernare se referă la procesele și sistemele prin care operează o organizație sau o societate. Frecvent se înființează un guvern care să administreze aceste procese și sisteme.

punctul cheie care trebuie luat din această definiție este că guvernanța se referă la procese și sisteme. În cazul guvernării SOA, discutăm procese organizaționale precum un consiliu de revizuire a arhitecturii și sisteme precum Registrul, securitatea și tehnologiile de management discutate în acest blog.

guvernanța pentru SOA este adesea împărțită în două părți separate, guvernanța timpului de proiectare și guvernanța timpului de execuție. La momentul proiectării, organizațiile doresc să controleze (guverneze) tipurile de servicii care pot fi publicate, cine le poate publica, ce tipuri de scheme și mesaje pot accepta aceste servicii și o serie de alte reguli despre servicii. În timpul rulării, organizațiile trebuie să asigure securitatea, fiabilitatea și performanța serviciilor lor și trebuie să se asigure că serviciile respectă politicile definite ale întreprinderii. Guvernarea timpului de proiectare este interesantă și ajută la asigurarea unui SOA organizat, bine conceput, dar devine nesemnificativ în comparație cu controlul activ al SOA în timpul rulării.

managerul de servicii Akana este cea mai importantă platformă de guvernare a timpului de rulare din industrie, oferind o soluție cuprinzătoare pentru securitate, monitorizare, management, mediere și registru. Guvernanța în timpul rulării oferă, în esență, un cadru unic pentru controlul și monitorizarea aplicării diferitelor etape ale SOA descrise în acest document. Acesta oferă o singură soluție globală furnizarea de supraveghere în registru serviciu, Securitate, management, și mediere. O soluție bună de guvernanță în timpul rulării se va manifesta ca o formă de banc de lucru care oferă instrumente pentru toți participanții activi la un SOA.

• Dezvoltator De Servicii: instrumente pentru publicarea, clasificarea, definirea meta-datelor, descărcarea „agentului”, virtualizarea, versiunea, alegerea politicii, alegerea vizibilității/drepturilor de acces, participarea la planificarea capacității și accesul la fluxul de lucru
• serviciul consumator: instrumente pentru facilitarea descoperirii, selecției și accesului la fluxul de lucru
• operațiuni personal: instrumente pentru monitorizarea performanței serviciului, depanarea problemelor, monitorizarea dependențelor, servicii de versiune, virtualizare, gestionare proxy
• personalul de securitate: instrumente pentru gestionarea politicilor, raportarea politicilor, verificarea conformității, auditarea securității
• arhitect întreprindere: Instrumente pentru monitorizarea aplicațiilor, gestionarea relațiilor, validarea și definirea politicilor de proiectare, gestionarea versiunilor de servicii, atribuirea serviciului către proxy, virtualizarea serviciilor
• Enterprise IT Management: reutilizarea managementului metric, metricile de reutilizare a serviciilor, Statisticile SOA

integrarea SOA cu ESB

Privind înapoi la rezultatele ultimilor 6 pași către un SOA, ne-am întrebat ce altceva poate exista. Până acum avem un set de servicii care sunt publicate într-un registru, sigur, gestionat, fiabil și cuplat slab, toate înfășurate într-un design solid și o soluție de guvernare în timp de rulare.

ultimul pas pentru unele întreprinderi este implementarea uneia sau mai multor implementări Enterprise Services Bus (ESB) pentru a integra serviciile în servicii compozite sau orchestrate de nivel superior. Aceste ESB-uri vor fi adesea livrate ca parte a unei suite de aplicații mai largi, cum ar fi Oracle eBusiness applications sau SAP. Unele ESB specializate pot fi utilizate pentru a crea servicii complexe compozite și se vor extinde în domeniul managementului proceselor de afaceri (BPM).

lectură înrudită:Aflați mai multe despre soluțiile de integrare Akana.

Enterprise Service Bus (ESB) este un concept din ce în ce mai popular. Conceput inițial ca evoluția atât a soluțiilor middleware orientate spre mesaje, cât și a soluțiilor EAI (enterprise application integration), ESB înseamnă lucruri foarte diferite pentru diferite organizații. Pe măsură ce analiștii, vânzătorii și clienții se împacă cu ideea unui ESB, se pare că un ESB încapsulează 3 concepte funcționale; adaptoare preluate dintr-un instrument eai pentru a asigura conectivitatea cu aplicațiile vechi, servicii de mesagerie preluate dintr-o platformă middleware orientată spre mesaje pentru a asigura livrarea fiabilă și orchestrarea proceselor pentru a construi aplicații agile.

consensul dintre analiști este că majoritatea organizațiilor vor ajunge cu mai multe platforme ESB de la mai mulți furnizori, oferind servicii în propriul context. În acest mediu, este esențial ca ESB să utilizeze o infrastructură SOA centrală pentru a asigura respectarea consecventă a politicilor de securitate și mesagerie pentru serviciile pe care le expun și le consumă.

produsele managerului de servicii și directorului de rețea Akana se combină pentru a oferi o soluție completă pentru guvernanța și medierea între mai multe instanțe ESB dintr-o întreprindere.

acum, că știți mai multe despre ceea ce înseamnă SOA și pașii cheie SOA, verificați Akana în acțiune!

Începeți Procesul