Wat is SOA? 7 SOA-stappen

deze blog beschrijft de SOA-stappen die een organisatie moet nemen voordat ze echt succesvol kan zijn in het realiseren van de kosten-en agiliteitsvoordelen die worden geboden door Enterprise service-oriented architecture. Het bespreekt waar SOA voor staat en de verschillende stadia van de invoering van SOA door de beschikbare technologieën, processen en best-practices te beschrijven om bedrijven te helpen succesvol te zijn in hun service oriented architecture initiatieven.

Wat Is SOA?

Service-oriented architecture (SOA) is een type architectuur dat wordt gebruikt in softwareontwerp dat service-oriëntatie ondersteunt, waarbij diensten worden geleverd aan andere componenten via een communicatieprotocol over een netwerk.

waar staat SOA voor?

de definitie van SOA, zoals verstrekt door Wikipedia:

Service-oriented architecture (SOA) is een stijl van softwareontwerp waarbij diensten aan de andere componenten worden geleverd door applicatiecomponenten, via een communicatieprotocol over een netwerk. De basisprincipes van servicegerichte architectuur zijn onafhankelijk van leveranciers, producten en technologieën. Een dienst is een discrete eenheid van functionaliteit die op afstand kan worden benaderd en onafhankelijk kan worden bediend en bijgewerkt, zoals het ophalen van een creditcardafschrift online.

een dienst heeft vier eigenschappen volgens een van de vele definities van SOA:

1. logischerwijs vertegenwoordigt het een bedrijfsactiviteit met een bepaald resultaat.
2. het is op zichzelf staand.
3. het is een zwarte doos voor zijn consumenten.
4. het kan bestaan uit andere onderliggende diensten.

verschillende diensten kunnen worden gebruikt in combinatie met de functionaliteit van een grote softwaretoepassing, een principe dat SOA deelt met modulair programmeren. Servicegerichte architectuur integreert gedistribueerde, afzonderlijk onderhouden en geà mplementeerde softwarecomponenten. Het wordt mogelijk gemaakt door technologieën en normen die de communicatie en samenwerking tussen componenten via een netwerk, met name via een IP-netwerk, vergemakkelijken.

dit geeft een beknopt antwoord op wat SOA betekent, maar het beschrijft niet de redenen waarom een organisatie zou willen overstappen naar service-georiënteerde architectuur, noch de voordelen van SOA.

ook uit Wikipedia over waar SOA voor staat:

sommige enterprise architects geloven dat SOA bedrijven kan helpen sneller en kosteneffectiever te reageren op veranderende marktomstandigheden.Deze stijl van architectuur bevordert hergebruik op macro (service) niveau in plaats van micro (klassen) niveau. Het kan ook de koppeling met—en het gebruik van—bestaande IT (legacy) activa vereenvoudigen.In sommige opzichten kan SOA worden beschouwd als een architectonische evolutie in plaats van als een revolutie. Het vangt veel van de best practices van eerdere softwarearchitecturen. In communicatiesystemen, bijvoorbeeld, is er weinig ontwikkeling van oplossingen die echt statische bindingen gebruiken om met andere apparatuur in het netwerk te praten. Door een SOA-aanpak te hanteren, kunnen dergelijke systemen het belang van goed gedefinieerde, zeer interoperabele interfaces benadrukken.In deze concepten kunnen we zien dat er een reeks basiscapaciteiten is die nodig zijn om de potentiële voordelen van SOA te bereiken. Wikipedia bespreekt een aantal van deze leidende principes, waaronder zijn:

• Reuse – the ability to encapsulate and expose grovere grained business functions as services
• Loose-coupling – ensuring that service consumers are sufficiently abstracted from the physical implementation of a service
• identificatie en categorisatie (vindbaarheid) – making sure that potential consumers can find the services they need

ongeacht welke SOA definitie u gebruikt, deze fundamentele principes leiden tot een natuurlijke volgorde van activiteiten die een organisatie moet voltooien om stapsgewijs de voordelen van servicegericht realiseren architectuur.

zie waarom Akana een sterke Performer is in het Forrester Wave™: API Management Solutions, Q3 2020 rapport.

Download rapport

Wat zijn de zeven SOA-stappen?

er zijn zeven SOA-stappen:

1. Create/Expose Services
2. Register Services
3. Secure Services
4. Manage (monitor) Services
5. Mediate and Virtualize Services
6. Governing the SOA
7. Soa Integration With ESB

SOA steps 2 t / m 6 beschrijf problemen tussen ondernemingen die moeten worden aangepakt met een centrale soa infrastructuur platform. De stappen 1 en 7 zijn gericht op specifieke behoeften en worden vaak geleverd als onderdeel van een bestaande enterprise application stack. Het volgen van deze stappen zal een organisatie leiden op de juiste weg naar het realiseren van de voordelen van SOA. Blijf lezen om dieper in elke SOA stap te gaan.

Create / Expose Services

de eerste stap in het verplaatsen van een organisatie naar SOA is duidelijk. Er kan geen SOA-applicatie zijn zonder services, dus de eerste stap moet zijn om services bloot te leggen of te creëren die gemakkelijk kunnen worden gebruikt door Web services enabled applicaties.

er zijn een aantal interessante beslissingen waarmee bedrijven worden geconfronteerd wanneer ze dit proces beginnen, niet in de laatste plaats de beslissing om bestaande applicaties opnieuw op te bouwen met behulp van een service-georiënteerd paradigma, of om bestaande applicatielogica als een reeks diensten bloot te leggen. Dit is natuurlijk geen binaire beslissing, en de meeste organisaties zullen nieuwe diensten vanaf nul bouwen, vaak met behulp van J2EE en / of.net, en zullen ook diensten blootstellen van bestaande mainframe en andere zakelijke toepassingen.

er is een breed scala aan verschillende oplossingen voor bedrijven die bestaande toepassingen als diensten willen blootstellen, waaronder Akana ‘ s toonaangevende SOLA, waardoor mainframe CICS-toepassingen betrouwbare, veilige en hoogwaardige diensten kunnen blootstellen en gebruiken.

elk bedrijf met een aanzienlijke (meer dan 1000 MIPS volgens Gartner) investering in mainframe zou moeten onderzoeken hoe de voordelen van dit platform beter kunnen worden benut, en zou webdiensten moeten gebruiken om hun mainframeapplicaties gemakkelijk te integreren met moderne systemen. Akana ‘ s SOLA is de productie-bewezen bij klanten als Merrill Lynch, waar het verwerkt meer dan 2 miljoen transacties per dag van meer dan 600 webservices. SOLA is het enige product dat mainframeprogrammeurs een eenvoudig te gebruiken, webgebaseerde interface biedt voor het blootstellen en consumeren van diensten van CICS-toepassingen. Het bevat ingebouwde ondersteuning voor geavanceerde Web services mogelijkheden zoals WS-Security, XML-encryptie, en XML-handtekening.

de meeste van de traditionele enterprise application integration (EAI) bedrijven leveren ook versies van hun adapters die webdiensten blootstellen in plaats van hun traditionele eigen protocollen. In feite zijn veel van deze EAI-platforms opnieuw in opkomst als Enterprise Service Bus-producten. De ESB behandelt meerdere verschillende problemen, een daarvan is de commodity data services type functionaliteit die wordt gebruikt om Web services interfaces van traditionele adapters bloot te leggen.

Wat is een webservice?

Van Wikipedia:In relatie tot W3C Web Services definieerde de W3C een webservice als: “een webservice is een softwaresysteem dat ontworpen is om interoperabele machine-to-machine interactie over een netwerk te ondersteunen. Het heeft een interface beschreven in een machinaal verwerkbaar formaat (specifiek WSDL). Andere systemen interageren met de webservice op een manier die wordt voorgeschreven door de beschrijving met behulp van SOAP-berichten, meestal overgebracht met behulp van HTTP met een XML-serialisatie in combinatie met andere web-gerelateerde normen.”

deze definitie is interessant vanuit een technisch perspectief, maar het raakt niet echt de kern van de waarde die kan worden afgeleid uit SOA en Web services. Een fundamenteel aspect van webservices is dat ze business logic via een op standaarden gebaseerde interface bloot moeten leggen. Een belangrijk aspect van het blootstellen of creëren van een dienst is de granulariteit. Er zijn veel verschillende denkrichtingen over wat een dienst is (zie hierboven), maar de meeste bedrijfsarchitecten zouden het ermee eens zijn dat om nuttig te zijn in een SOA, een dienst voldoende grof moet zijn om nuttig te zijn voor meerdere verschillende toepassingen.

Dit sluit uiteraard aan bij een van de basisprincipes van diensten in SOA – om een dienst te kunnen hergebruiken; deze dienst moet in het algemeen nuttig en bruikbaar zijn. Een voorbeeld van een over het algemeen nuttige dienst kan een “getCustomerInfo” dienst die gegevens over een klant van een klant identifier zal terugkeren. Een meer fijnkorrelige service die over het algemeen niet nuttig kan zijn, kan iets specifieks zijn voor een bepaalde toepassing, “setApplicationState” bijvoorbeeld.

het is belangrijk om granulariteit van diensten te overwegen, zowel bij het bouwen van nieuwe diensten als bij het blootleggen van bestaande business logic as a service. Het zou bijvoorbeeld gemakkelijk zijn om een CICS-transactie te nemen en meerdere verschillende diensten bloot te stellen en verschillende parameters te krijgen, terwijl de realiteit is dat een meer grove korrelige dienst die de hele transactie blootstelt als een enkele dienst veel meer in het algemeen nuttig en daarom waardevol zou kunnen zijn.

gerelateerd lezen: ontdek hoe Akana ‘ s SOLA Mainframe API klanten een snel en eenvoudig proces biedt om mainframe-toepassingen als veilige webservices bloot te stellen, en mainframe-toepassingen in staat stelt webservices te gebruiken.

Registreer

Ok, dus u hebt een of meer diensten beschikbaar in uw onderneming. Wat nu?

om een dienst te kunnen gebruiken, laat staan hergebruiken, moeten toepassingsarchitecten en-ontwikkelaars die van deze dienst kunnen profiteren, weten dat deze bestaat. Hier komt een register bij kijken. Op zijn eenvoudigste niveau is een register niets meer dan een bibliotheekindex die potentiële gebruikers van diensten helpt om diensten te vinden waarin ze misschien geïnteresseerd zijn. Het register moet zowel zoeken als bladeren interfaces bieden, en moet logisch worden georganiseerd om een snelle en nauwkeurige ontdekking van diensten te vergemakkelijken.

in de huidige SOA is UDDI (Universal Discover, Description, and Integration) de geaccepteerde standaard voor basisregisterdiensten. De UDDI-specificatie biedt een datamodel en een set interfaces (alle webservices zelf) voor het publiceren en ontdekken van services, evenals een verdere set interfaces voor het beheren van de registerserver zelf.

veel registerverkopers hebben het oorspronkelijke concept van registry een stuk verder gebracht en gebruiken registertechnologieën als basis voor een vollediger repository. Registry leveranciers zijn ook het toevoegen van “beleid” gebaseerde filters aan hun publishing tools, en het aanbieden van “design-time governance oplossingen”.

Akana beschouwt registratie als een fundamentele bouwsteen van SOA. Al onze producten maken gebruik van UDDI als één centrale opslag voor gezaghebbende informatie over de diensten in een SOA. De producten kunnen werken met elk UDDI compliant register, en Akana omvat zijn eigen UDDIv3 registry server met zijn Service Manager product voor bedrijven die nog geen register hebben. In dit opzicht vervult registry de rol van SOA die LDAP vervulde voor identiteits-en Toegangsbeheeroplossingen.

Akana ‘ s producten richten zich op run-time governance en maken gebruik van het register als een centrale plaats om run-time beleid te implementeren en te handhaven. Natuurlijk, de embedded register is volledig functionele UDDIv3 server en dus maakt ook een ideale design-time service repository.

buiten het register is het hele concept van beleids-en metagegevensdiensten die uitgebreide repositories bieden voor alle ontwerp-en runtime-artefacten voor de diensten in SOA. Dit concept wordt in meer detail behandeld in Akana ‘ s whitepaper het Soa Infrastructure Reference Model.

Secure

de wereld van SOA en webdiensten is niet alleen wijn en rozen. Ervan uitgaande dat je nu de stappen één en stap hebt voltooid, neem een stap terug en overweeg wat je hebt gedaan. Ervan uitgaande dat u gaat voor maximale bedrijfswaarde, bent u waarschijnlijk bedrijfskritische toepassingen hebben genomen, opgesplitst in Grove korrelige stukken van functionaliteit, blootgesteld deze functionaliteit als diensten, en vervolgens gepubliceerd deze diensten aan een universeel toegankelijk register.

dit lijkt allemaal een goede zaak, en in de meeste gevallen is het een geweldige zaak, maar u kunt per ongeluk een aantal gapende beveiligingslekken in uw organisatie hebben gecreëerd en gevoelige informatie, of hoogwaardige transacties hebben blootgelegd aan iedereen met rudimentaire Web Services vaardigheden. Het waarborgen van de veiligheid van diensten betekent het opbouwen van een laag voor de handhaving van de beveiliging bij de dienstverleners en een laag voor de implementatie van de beveiliging bij de serviceconsumenten.

een goede manier om de veiligheidsrisico ‘ s van webservices te begrijpen is om terug te denken aan traditionele mainframe-toepassingen met groen scherm. De enige beveiliging vereist door deze toepassingen was login beveiliging, als u toegang tot de toepassing, je was in. Deze applicaties bevatten dezelfde basisstukken als een moderne applicatie (interface, business logic, data services), maar alleen de interface was toegankelijk buiten de applicatie. In de wereld van Web services, is het waarschijnlijk dat een aantal van de core data services zal worden blootgesteld als diensten, een deel van de zakelijke logica zeker moet worden blootgesteld, en de applicatie is niet geschreven met een van deze access points in het achterhoofd. Dit betekent dat het van cruciaal belang is om de services die u individueel bloot te stellen, kunt u niet vertrouwen op de interne van de applicatie om zijn eigen veiligheid te waarborgen.

wat betekent het beveiligen van een webservice? Dezelfde 5 beveiligingsprincipes die van toepassing zijn op andere toepassingen zijn ook van toepassing op webservices:

• authenticatie-zorg ervoor dat u de identiteit van de service-aanvrager kent (en zorg er ook voor dat de aanvrager de identiteit kent van de service waarmee hij contact opneemt). Er zijn meerdere verschillende Web services standaarden voor het authenticeren van verzoeken, variërend van eenvoudige benaderingen zoals http basic authentication, tot meer complexe mechanismen zoals SAML of X. 509 signature. Een goede Web services security tool moet al deze verschillende opties te ondersteunen.
• autorisatie-zorg ervoor dat de aanvrager gemachtigd is om toegang te krijgen tot de dienst of operatie die hij aanvraagt. Autorisatie is een complexe kwestie en er zijn een aantal verschillende beleidsbeslissingsproducten beschikbaar. De meeste grote ondernemingen zullen een bestaande oplossing voor autorisatie hebben (ca SiteMinder, IBM TAM, enz.), en een goede Web services security oplossing zou hiermee moeten kunnen integreren en zijn eigen autorisatiemogelijkheden moeten bieden.
• Privacy-zorg ervoor dat verzoeken en antwoorden niet kunnen worden gelezen door niet-geautoriseerde derden. Dit is waar standaarden zoals XML-encryptie tot hun recht komen, maar om met succes XML-encryptie te gebruiken, moet de Web services security solution effectieve sleutel-en certificaatbeheer-en distributiemogelijkheden bieden, en idealiter wat client side tooling om consumentenontwikkelaars te helpen.
• niet-afwijzing-zorg ervoor dat de aanvrager het verzenden van een verzoek niet kan weigeren en zorg ervoor dat de dienst het verzenden van zijn antwoord niet kan weigeren. Dit is de rol van XML-handtekening, met dezelfde sleutelbeheer-en distributievoorziening als voor privacy.
• Auditing-zorg ervoor dat het systeem zo nodig een nauwkeurige en tijdige registratie van verzoeken en antwoorden kan bijhouden.

een interessante vraag, en punt van discussie, die rijst rond de beveiliging van Webdiensten is waar deze beveiliging moet worden toegepast. Sommige leveranciers zullen beweren dat beveiliging een centrale functie moet worden afgedwongen door middel van een cluster van Centraal geïmplementeerde proxies, terwijl anderen zullen beweren dat het uitsluitend het domein van de service provider of container moet zijn. De realiteit ligt natuurlijk ergens tussen deze twee standpunten. Er is zeker een belangrijke rol voor een proxy (of cluster van proxy ‘ s) bij het leveren van authenticatie-en dreigingsdetectiediensten aan de rand van het netwerk om te beschermen tegen externe bedreigingen. Er is ook een even belangrijke rol voor provider of container gebaseerde beveiliging om de veiligheid van de dienst tot de laatste mijl te waarborgen.

veel bedrijven hebben de neiging om het onderzoek dat aantoont dat de meeste veiligheidsbedreigingen intern zijn voor de onderneming, niet extern, over het hoofd te zien en daarom de beveiliging te delegeren aan een firewall-type oplossing. Akana biedt een high-performance proxy die gecentraliseerde of netwerk edge beveiligingsfuncties uitvoert, en een breed scala aan in container agents om de laatste mijl beveiliging van de geà mplementeerde diensten te garanderen.

beveiliging van webservices vereist:

• volledig functionele in-container-agenten inzetten om de laatste mijl beveiliging te garanderen en de lading cryptografische bewerkingen te distribueren
• netwerkintermediairs met hoge prestaties inzetten voor Routering en handhaving van netwerkrandbeveiliging
• uitgebreid sleutel-en certificaatbeheer en-distributie bieden om ervoor te zorgen dat serviceprovider en consumentenontwikkelaars het vereiste beveiligingsbeleid succesvol kunnen implementeren
• toolkits voor consumentenontwikkelaars leveren aan consumentenontwikkelaars abstract van de complexiteit van het ontdekken en implementeren van bedrijfsbeveiliging beleid

gerelateerd lezen: Lees meer over de beste praktijken voor API-beveiliging.

Beheer

drie stappen in de 7 stappen benadering van SOA en we beginnen enige vooruitgang te boeken in de richting van het bereiken van echte waarde van enterprise SOA. We hebben een aantal diensten, ze worden gepubliceerd in een register en kunnen worden ontdekt door potentiële gebruikers, en we hebben ervoor gezorgd dat ze veilig zijn. Wat kunnen we nog meer nodig hebben?

om deze vraag te beantwoorden moeten we eerst kijken naar een mogelijk rampenscenario. Wat gebeurt er als mijn diensten slachtoffer worden van hun eigen succes? Dat wil zeggen: een dienst is zo populair geworden dat er verschillende (tientallen, of honderden, of duizenden) verschillende toepassingen consumeren en het begint te gespen onder de belasting. We hebben plotseling tientallen, of honderden, of duizenden applicaties die falen of slecht presteren en we weten niet waarom, of hoe het te stoppen.

we moeten onze diensten controleren, zodat we weten of ze binnen de normale bedrijfsparameters functioneren, en zodat we potentiële problemen kunnen zien voordat ze zich voordoen door het implementeren van capaciteitsplanningsmodellen.

de monitoringoplossing die we implementeren moet in staat zijn om services te monitoren op basisbeschikbaarheid, prestaties (responstijd), doorvoer, en zelfs uit te breiden naar content en gebruikersgebaseerde monitoring. Het moet in staat zijn specifieke SLA-drempels te monitoren en te waarschuwen en verschillende SLA ‘ s toe te passen op verschillende gebruikers van dezelfde dienst of operatie.

veel leveranciers definiëren deze categorie van producten als een Web Services Management oplossing, hoewel veel analisten het erover eens zijn dat het beheer veel breder is dan een eenvoudige monitoring oplossing, en veel van de functionaliteit moet bevatten die in de volgende stap wordt beschreven.

idealiter zouden we natuurlijk geen afzonderlijke oplossingen voor beveiliging en monitoring hoeven te implementeren, omdat we telkens als we berichten onderscheppen via en agent of tussenpersoon, een andere prestatie-bottleneck toevoegen. Daarom combineert Akana ‘ s Service Manager met Network Director Om een uitgebreid soa-beveiligings -, monitoring-en managementplatform te bieden in één krachtige, eenvoudig te implementeren oplossing.

sommige Web services management (monitoring) Leveranciers positioneren hun oplossingen als Business Activity Monitoring (Bam) platforms, hoewel BAM een complexe oplossing is die integratie met vele back – en front-office systemen en databases vereist. Het monitoren van Web services interacties voor inhoud mag niet worden beschouwd als een alternatief voor een enterprise BAM-oplossing.

Gerelateerd Lezen: Meer informatie over Akana ‘ s End-to-End API Management oplossing.

5. Bemiddelen en virtualiseren

op dit moment lijkt het erop dat onze SOA klaar is voor primetime. En zo is het, tenminste voor een tijdje…

de volgende reeks uitdagingen vindt plaats naarmate uw SOA rijpt. U moet nieuwe versies van diensten introduceren, of de capaciteit van een dienst vergroten door meerdere exemplaren ervan uit te voeren, U moet toepassingen aanbieden om specifieke instanties van diensten te gebruiken en u moet diensten aanbieden die een breder scala aan verschillende interfacetypen blootstellen.

dit is waar service virtualisatie van pas komt. Virtualisatie lijkt complex, maar de realiteit is vrij eenvoudig. Een virtuele dienst is een geheel nieuwe dienst, gedefinieerd door zijn eigen WSDL, met zijn eigen netwerkadres en transportparameters. Het implementeert geen zakelijke logica; het fungeert gewoon als een proxy voor een of meer fysieke diensten, routing, load-balancing, transformeren en bemiddelen tussen verschillende soorten aanvraagberichten en standaarden.

hoewel virtualisatie eenvoudig is, is het concept van virtualisatie extreem krachtig. Het biedt de mogelijkheid om volledig abstracte dienst consumenten van elke directe kennis van de fysieke dienst. Bijvoorbeeld, door middel van een virtuele service, een.net client die gebruik maakt van een Microsoft implementatie van een betrouwbaar messaging protocol met SOAP via http kan verbruiken een gewone oude XML-service blootgesteld via IBM WebSphere MQ series vanuit een mainframe applicatie. De. Net-client zou geloven dat het communicatie was met een http-service die het betrouwbare messaging-protocol ondersteunde, terwijl de mainframe-applicatie zou geloven dat het werd opgevraagd door een andere native mq-serie-applicatie.

virtuele diensten bieden een breed scala aan functionaliteit:

• ze kunnen XML-transformatietechnologieën gebruiken om consumenten in staat te stellen een oude versie van een dienst te blijven gebruiken die niet meer bestaat door het transformeren van verzoeken en Antwoorden tussen de oude versie en de nieuwe versie die is geïmplementeerd.
• ze kunnen specifieke bewerkingen uit meerdere verschillende services selecteren en deze combineren tot één functionele WSDL voor een specifieke klasse van verbruikende toepassingen.
• ze kunnen verschillende beleidsvereisten bieden voor verschillende klassen van gebruikers (d.w.z. interne gebruikers met één beleidsset en een andere implementatie van de service die een ander beleidsset afdwingt voor externe consumenten).
• zij kunnen vervoer overbruggen voor diensten en consumenten op incompatibele transporten (bijvoorbeeld http en JMS). • Ze kunnen bemiddelen tussen verschillende normen implementatie of zelfs versies van normen.
• ze kunnen bemiddelen tussen verschillende berichtenstijlen – RSS, SOAP, REST, POX (gewoon oude XML).
• ze kunnen krachtige inhoud – of contextgebaseerde routering bieden om geavanceerde mogelijkheden voor taakverdeling en hoge beschikbaarheid te bieden.

de bottom-line met virtuele diensten is dat ze nodig zijn voor elke routing of andere geavanceerde webdiensten, en snel een essentieel onderdeel zullen worden van elke enterprise SOA.

Govern

met 5 van de 7 stappen voltooid, is de Enterprise SOA vrijwel klaar om te gaan. U beschikt nu over veilige, managed services die op een betrouwbare, load-balanced manier beschikbaar zijn voor een breed publiek en gemakkelijk te vinden zijn.

de volgende stap is om alle tijdens de eerste vijf stappen geleverde capaciteiten te koppelen aan een governancekader. Governance is een overgebruikt en veel misbruikt werk, dus laten we kort kijken naar een definitie van governance. Nogmaals uit Wikipedia:

de term governance gaat over de processen en systemen waarmee een organisatie of samenleving opereert. Vaak wordt een overheid opgericht om deze processen en systemen te beheren.

het belangrijkste punt uit deze definitie is dat governance draait om processen en systemen. In het geval van soa-governance bespreken we organisatorische processen zoals een architecture review board en systemen zoals de registry -, security-en managementtechnologieën die in deze blog worden besproken.

Governance voor SOA wordt vaak verdeeld in twee afzonderlijke delen, design-time governance en runtime governance. Op het moment van ontwerpen willen organisaties bepalen (regeren) welke soorten services kunnen worden gepubliceerd, wie ze kan publiceren, welke soorten schema ‘ s en berichten deze services kunnen accepteren, en een groot aantal andere regels over services. Tijdens runtime moeten organisaties de veiligheid, betrouwbaarheid en prestaties van hun diensten garanderen en ervoor zorgen dat de diensten voldoen aan gedefinieerd ondernemingsbeleid. Design-time governance is interessant en helpt zorgen voor een georganiseerde, goed ontworpen SOA, maar het verbleekt in onbeduidendheid in vergelijking met actieve controle van de SOA tijdens run-time.

Akana ‘ s Service Manager is het toonaangevende runtime governanceplatform in de sector en biedt een uitgebreide oplossing voor beveiliging, monitoring, beheer, bemiddeling en registratie. Run-time governance biedt in wezen een enkel kader voor het controleren en monitoren van de toepassing van de verschillende stappen op SOA beschreven in dit document. Het biedt een enkele overkoepelende oplossing die toezicht biedt op de registratie, beveiliging, beheer en bemiddeling in de dienst. Een goede runtime governance-oplossing zal zich manifesteren als een vorm van workbench die tools biedt voor alle actieve deelnemers aan een SOA.

• Serviceontwikkelaar: tools om te publiceren, te categoriseren, te definiëren meta-gegevens, het downloaden van “agent”, virtualiseren, versie, kies beleid, kiezen voor zichtbaarheid/toegangsrechten, deel te nemen in de planning van capaciteit en access workflow
• Service Consument: Hulpmiddelen te vergemakkelijken service discovery -, selectie-en access workflow
• Personeel: Instrumenten monitor service performance, oplossen van problemen, monitor afhankelijkheden, versie services, virtualisatie -, proxy-management
• Beveiliging Personeel: Hulpmiddelen voor het beleid van het management, beleid rapportage, controle op de naleving, het controleren van de beveiliging
• 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 statistieken

SOA integratie met ESB

Terugkijkend op de resultaten van de laatste 6 stappen naar een SOA, vragen we ons af wat er nog meer kan zijn. Inmiddels hebben we een set van diensten die zijn gepubliceerd in een register, veilig, beheerd, betrouwbaar en losjes gekoppeld, allemaal verpakt in een solide ontwerp en run-time governance-oplossing.

de laatste stap voor sommige ondernemingen is het implementeren van een of meer Enterprise Services Bus (ESB) implementaties om diensten te integreren in samengestelde of georkestreerde diensten op hoger niveau. Deze ESB ‘ s zullen vaak worden geleverd als onderdeel van een breder applicatiepakket, zoals Oracle eBusiness applications of SAP. Sommige gespecialiseerde ESBs kunnen worden gebruikt om complexe samengestelde diensten te creëren, en zal zich uitstrekken tot het domein van Business Process Management (BPM).

gerelateerd lezen: Lees meer over Akana ‘ s integratieoplossingen.Enterprise Service Bus (ESB) is een steeds populairder concept. Oorspronkelijk ontworpen als de evolutie van zowel message-oriented middleware en EAI (enterprise application integration) oplossingen, de ESB betekent heel verschillende dingen voor verschillende organisaties. Als analisten, leveranciers en klanten het idee van een ESB in het reine komen, lijkt het erop dat een ESB 3 functionele Concepten omvat; adapters uit een EAI-tool om connectiviteit met legacy-applicaties te garanderen, messaging-services uit een bericht-georiënteerd middleware-platform om betrouwbare levering te garanderen, en procesorstratie om agile applicaties te bouwen.

de consensus onder analisten is dat de meeste organisaties zullen eindigen met meerdere ESB-platforms van meerdere leveranciers, die diensten leveren in hun eigen context. In deze omgeving is het van cruciaal belang dat de ESBs een centrale SOA-infrastructuur gebruiken om te zorgen voor consistente naleving van het beveiligings-en berichtenbeleid voor de diensten die zij blootstellen en gebruiken.De producten van Akana ‘ s Service Manager en Network Director bieden samen een complete oplossing voor het beheer van en bemiddeling tussen meerdere ESB-instanties in een onderneming.

nu je meer weet over waar SOA voor staat en de belangrijkste SOA-stappen, bekijk Akana in action!

Start Onderzoek