samenvatting service oriented architecture...samenvatting service oriented architecture 1...

Samenvatting service oriented architecture 1

Samenvatting Service Oriented Architecture

Wat is architectuur?

Architecture is a term that lots of people try to define, with little agreement. There are two common

elements: One is the highest-level breakdown of a system into its parts; the other, decisions that are

hard to change.

(Martin Fowler in Patterns of Enterprise Application Architecture)

Wat is een software service

A service is a means of delivering value to customers by facilitating outcomes the customers want

to achieve without ownership of specific costs or risks

(Service definitie in ITIL)

• Altijd minstens twee partijen

• Software service

◦ beide partijen zijn software

◦ Meestal over een netwerk

◦ Geautomatiseerde contracten

◦ contract = wat doet de service (tegen welke voorwaarden)

Software services worden gebruikt in Enterprise applications

• Veel gebruikers

• grote applicaties

• Communicatie met andere applicaties in de onderneming en met externen

• KISS principe (Keep it simple stupid): eenvoudige algoritmen, eenvoudige datastructuren,

maar ook eenvoudige hoofdstructuur

• Lange levensduur van data (ten opzichte van technologie)

• Flexibel

• Business driven

• Herbruikbare bouwstenen

• Veel stakeholders: politieke beslissingen

Entropie stijgt in een gesloten systeem

• Applicatie ondergaat wijzigingen

• Oorspronkelijke design principes worden uit het oog verloren of workarounds

• Applicaties worden minder en minder beheerbaar

• Business architect moet hiervoor tegengas bieden

Business architect

• Entropie van een systeem onder controle houden

• Applicaties kaderen in strategie


• Afwegen van niet-ideale oplossingen

• Refactoring: applicatie aanpassen zonder de functionaliteit te wijzigen (bijvoorbeeld interne

structuur aanpassen)

• Typische cyclus: aanpassen => refactoring => aanpassen => refactoring ...

• Incrementele optimalisatie (Service Oriented Architecture geschikt hiervoor)

“Officiële” definities van SOA

A service-oriented architecture provides the flexibility to treat elements of business-processes and

the underlying IT infrastructure as secure, standardized components (services) that can be reused

and combined to address changing business priorities. (IBM)

• Services vormen componenten of bouwstenen

• Services kunnen herbruikt worden op business niveau

• Doordat services ook de technologie afschermen, kunnen we verschillende technologiën met

elkaar combineren (.NET applicatie die via een service met een CICS backend werkt)

• Services zijn “loosely-coupled”

OASIS

SOA is a paradigm for organizing and utilizing distributed capabilities that may be under the control

of different owners and domains. It provides a uniform means to offer and discover, interact with

and use the capabilities to produce desired effects consistently.

Andere definitie

SOA is about connecting customer requirements with enterprise capabilities, regardless of

technology landscape or arbitrary organizational boundaries.

SOA: drie termen

• Operations: (software) methodes die één welomschreven taak uitvoeren, bijvoorbeeld

SchrijfGeldOver(rekening1, rekening2, bedrag)

• Service: logische groepering van operations, bijvoorbeeld een bankrekening service

• Business process: (meestal) langdurige opeenvolging van activiteiten die gebruikt maakt van

services. Een business process is bursty en stateful. Dat wil zeggen dat het proces een

belangrijk deel van de tijd niets doet (staat te wachten) en ondertussen onthoudt wat er al

gebeurd is. Een facturatieproces begint met de melding dat er mag gefactureerd worden. De

factuur wordt verstuurd en men wacht op betaling. Wanneer de klant niet op tijd betaalt

moet er een herinnering verstuurd worden. Wanneer er betaald wordt, moet de betaling

afgeboekt worden in de boekhouding.

Waar ligt de oorsprong van SOA

• Drie evoluties:

◦ Programmeertalen

▪ assembler: machinecode afschermen van programmeur via mnemonics

▪ COBOL: programmeerstructuren (iteratie, selectie) herbruiken door ze te definiëren

in een hogere taal

▪ Werken met functies (functionaliteit herbruiken)


▪ Componenten: modules (verzameling van functies die samenhoren herbruiken)

▪ OO-talen: mogelijkheid om functionaliteit te herbruiken via overerving (inheritance)

▪ OO-talen: “program to an interface, not to an implementation”. Scheiding van

interface (lijst van methodes + argumenten) en implementatie (de code die echt iets

doet) => we kunnen de implementatie wijzigen zonder de intgerface te wijzigen.

Daardoor zullen wijzigingen in de applicatie meer gelokaliseerd worden.

◦ Distributed computing

▪ Terminals (VT100 van Digital Equipment Corporation) => mainframe

▪ UNIX: besturingssysteem waarbij networking ingebouwd is in het besturingssysteem

▪ UNIX: via Network File System de bestanden op een andere machine in het netwerk

aanspreken (maakt gebruik van Remote Procedure Calls)

▪ CORBA: Common Object Request Broker Architecture: objecten aanspreken via het

netwerk (niet alleen procedures aanroepen, maar ook creatie en delete van objecten)

▪ World Wide Web: standaardisatie van de client applicatie (web browser met HTML

en javascript). Je kunt vanop een Windows client surfen naar een UNIX server

▪ Enterprise Javabeans: Applicatie server waarin componenten worden geïnstalleerd.

De application server is verantwoordelijk voor toegang tot databanken, logging,

beheer van transacties en security

▪ SOAP: Simple Object Access Protocol om remote procedure calls uit te voeren via

het web (HTTP protocol) en XML (webservice)

▪ WSDL: Webservice definition language. Gestandardiseerde beschrijving van de

mogelijkheden van een interface zodat ontwikkelaars de code die nodig is om via het

netwerk een webservice aan te spreken automatisch kunnen laten genereren(eigenlijk

geautomatiseerd contract)

◦ Business computing

▪ Centrale mainframe waar alles opstaat (monolithische applicaties)

▪ Via batch programma's bepaalde taken uitvoeren (vertraging op resultaat aangezien

batch programma's op bepaalde tijdstippen worden uitgevoerd en niet continu)

▪ Databanken: aparte applicaties om met data te werken. De databank kan ondervraagd

worden via de taal SQL. Tegenwoordig wordt SQL gebruikt door ontwikkelaars.

Oorspronkelijk is het ontwikkeld als een taal voor business mensen

▪ SAP R/2: gestandardiseerde software voor Enterprise Resource Planning. Real time

processing van financiële data (<=> batch programma's)

▪ goedkope IBM PC zorgde ervoor dat er gemakkelijk client programma's naar de

gebruiker konden worden gebracht. (client-server applicaties)

▪ Enterprise Application Integration: verschillende applicaties met elkaar integreren

(ERP en Customer Relationship Management bijvoorbeeld)

▪ Business process Modeling: proces definiëren via een grafische interface (en

uitvoerbaar maken)

▪ Model Driven Architecture: software genereren op basis van een model

SOA en Business Process Management(BPM)

De (Business) bedoeling van SOA is flexibeler te kunnen omgaan met verandering in


business processen

Business Process Management vindt zijn oorsprong in de management technieken van de

Japanse maak-industrie (kaizen): continuous improvement

Business Process Management Cycle: Design-Model-Implement-Execute-Monitor-Improve-

Design-Model-…

SOA: 9 onderdelen

• 4 hoofdbestanddelen: Application front end, service repository, service, service bus.

• Application front end stuurt het proces (eigenlijk de gebruiker van de application front end.)

application frontends komen overeen met UI-layer van three tier. Maar opgelet: services

komen niet overeen met de lagere lagen

• Services geven structuur aan de SOA (application front end kan regelmatig veranderen,

services blijven grotendeels hetzelfde)

• Services omvatten een high level business concept.

◦ Contract: informele beschrijving van doel, functionaliteit, beperkingen (constraints) en

gebruik van de service. Kan ook een formele definitie bevatten onder de vorm van IDL

of WSDL, maar dit is altijd maar een deel van het contract

◦ Interface: deel van de service dat van buiten kan worden aangesproken. de beschrijving

van de interface is deel van het contract. De implementatie van de interface gebeurt via

proxies of stubs in de client van de service

◦ Implementatie: bevat business logica en data (programma's, configuratiebestanden +

databanken)

◦ Business logic: deel van de implementatie dat business rules bevat

◦ Data: gegevens waarmee de service werkt, vooral bij data-centric service

• Service is een vertical slicing (geen horizontale zoals bij three tier layers) die een volledig

business concept bevat.

• Service repository: om services terug te vinden. Hoeft niet via technologie geïmplementeerd

te zijn. (een klasseur met documenten). Wordt gebruikt door operations maar ook door

business analysten en programmeurs.Kan de volgende items bevatten:

◦ WSDL en XSD schema's

◦ Service owner: business level (vragen en change requests voor functional level),

development level (technische vragen en change requests), operational level (beste

manier om een service aan te spreken of operationele problemen)

◦ info over toegangsrechten

◦ Informatie over verwachte performantie en scalability. Kan via een SLA agreement

◦ Transactionele eigenschappen van de service.

• Service bus: verbindt alle deelnemers: services en application frontends. Lijkt op software

bus van CORBA. Maar kan bijvoorbeeld uit verschillende technologieën bestaan.

◦ Connectivity: verbindt alle deelnemers

◦ heterogene technologieën: verschillende programmeertalen, operating systems moeten


met elkaar verbonden kunnen worden.

◦ Heterogene communicatie: zowel synchrone als asynchrone communicatie

◦ technische services: logging, auditing, security, transacties...

Soms spreekt men ook over de Process manager. Die bestaat uit de service repository, de business

process orchestration manager(stuurt de services aan) en de service broker(zorgt voor de

communicatie tussen de services)

Service-oriented architecture: 8 principes

• Een gestandardiseerd service contract: alle services in de repository volgen dezelfde contract

design standards

• Service loose coupling: service contracten leggen geen zware koppeling op met de

consumers en services zijn zelf los gekoppeld aan hun omgeving

• Service abstraction: service contracten bevatten alleen essentiële informatie en informatie

over services is beperkt tot wat er in het service contract staat

• Service reusability: services kunnen herbruikt worden

• Service autonomy: services kunnen hun taak uitvoeren zonder al te veel hulp van buitenaf

• Service statelessness: services houden zo weinig mogelijk “state” bij

• Service discoverability: services bevatten voldoende meta informatie (informatie over de

service) om gemakkelijk gevonden te worden

• Service composability: services kunnen gemakkelijk deel uitmaken van een groter geheel

Service-oriented architecture: 4 karakteristieken

• Business driven: in het verleden speelde software vooral in op tactische(=korte termijn)

business vereisten. SOA moet zich meer richten naar lange termijn (strategische) plannen.

=> business en technologie groeien uit elkaar

• Vendor neutral: SOA moet de algemene principes volgen van de huidige SOA oplossingen,

zonder afhankelijk te zijn van specifieke implementaties. => vendor (dus SOA) drijft

business processen

• Enterprise centric: alle oplossingen moeten kaderen in het grotere geheel => geen software

silos (=bijvoorbeeld eigen oplossing in Access of Excel) => alle software moet ontworpen

zijn om gedeeld te worden.

• Composition centric: service moeten gemakkelijk deel kunnen uitmaken van een groter

geheel(zelfs al zijn ze daar oorspronkelijk niet voor bedoeld)

Communicatie tussen services

• Communicatie middleware: RPC, Corba(soms zonder object beheer, waardoor het eigenlijk

RPC wordt), Message oriented middleware

• Transaction monitors en application servers

• synchrone vs asynchrone communicatie

• interface <=> payload semantics

• tight <=> loose coupling

◦ physical: direct verbonden of via een intermediary (MOM)

◦ communicatie stijl: synchroon vs asynchroon


◦ type systeem: interface vs payload

◦ interactie: OO (corba) vs self contained messages

◦ control of process logic: central vs distributed

◦ service discovery and binding: statically bound services vs dynamically bound services

(twee soorten runtime binding)

◦ development time binding: gemakkelijkste en meest gebruikte. Bij het ontwikkelen van

de client is geweten met welke service men een connectie wil maken en deze informatie

zit vast in de code (interface)

◦ runtime binding: veel moeilijker

▪ runtime service lookup by name: meest gebruikt, service definitie is gekend tijdens

development, service lokatie wordt opgezocht at runtime via de naam van de service

▪ runtime service lookup by properties: idem, maar niet gezocht op naam, maar op

eigenschappen: zoek een print service op de tweede verdieping die postscript kan

afdrukken (VERDIEPING=2, LANGUAGE=POSTSCRIPT)

▪ runtime service discovery via reflection: in tegenstelling tot bij de twee vorige is de

interface niet gekend bij developing. Via reflection wordt de interface opgevraagd.

Weinig gebruikt want veel te ingewikkeld.

Remote procedure call

• Remote procedure kan worden aangesproken zoals een gewone procedure via een client

stub. Dit is een methode die er hetzelfde uitziet als de echte methode (die op de server staat),

maar met behulp van de RPC library de connectie verzorgt over het netwerk.

• Aan de server kant vertaalt de server stub de netwerk aanroep naar een gewone functie

aanroep

Distributed objects(CORBA)

• Hier kunnen niet alleen methodes of procedures worden opgeroepen, maar er kunnen ook

objecten worden gemaakt, gezocht en verwijderd.

• Een client kan een verwijzing opvragen naar een object op de server (client proxy object).

Via dat object kan men methodes via de client oproepen die op de server zullen worden

uitgevoerd.

• Soms worden de Create, find en delete mogelijkheden niet gebruikt. In feite wordt CORBA

dan RPC.

• In tegenstelling tot bij SOA zijn de methodes die worden opgeroepen fine-grained. Ze

komen meestal niet overeen met business methodes.

Message oriented middleware

• Geen rechtstreekse communicatie tussen beide partijen

• Verloopt via een “tussenpersoon”.

• Opdracht wordt als message verstuurd naar een queue (of een topic)


• Message bestaat uit een header en een payload.

• Header is algemeen voor elke applicatie die de MOM gebruikt. Bevat onder meer informatie

naar welke queue de message moet worden gestuurd

• payload is applicatie specifiek en bevat business data (en opdrachten), dikwijls in XML

formaat.

• Een queue is een plaats waar messages worden achtergelaten

• Voorbeeld van een Message Oriented Middleware is e-mail

• Twee soorten: Point-to-point (één-op-één communicatie) en publish-subscribe (één-op-veel

of veel-op-veel communicatie)

• De eerste soort (Point-to-point) noemt men een queue. De tweede soort (publish-subscribe)

noemt men een topic.

Transaction monitors

• Duizenden gebruikers

• Computer resources verdelen onder gebruikers (multiplexing)

• Beheer van CPU, database transacties, sessions,

• opslag, …

• Ook distributed applicaties

• Voorbeelden: CICS, IMS, Tuxedo

• CICS al meer dan 20 jaar oud. Wordt aangesproken via External Call Interface (ECI)

• ECI bevat library voor RPC aanroepen

• CICS transaction gateway bevat een object georiënteerde interface voor Java

• IMS werkt met MQSeries (MOM)

Application servers

• Tussen webserver en backend systeem(bijv. Databank)

• Verzamelt informatie uit de backend en zet die om naar HTML code

• Componenten beheren, toegang tot datasources beheren, verschillende user interfaces

ondersteunen

• Microsoft: Internet information server + .NET

• Java: JBoss, Websphere, Tomcat, …: J2EE (of Java EE)

• Java EE bevat vele standaarden: Java Servlets, Java Server Pages, Java Server Faces,

Enterprise JavaBeans, Java EE Connector Architecture, Java Naming and Directory

Interface (JNDI), Java Management Extensions, Java Transaction API, CORBA, Java

Messaging Service (JMS)

Synchrone/asynchrone communicatie

• Bij synchrone communicatie moet de client wachten tot de server klaar is.

• De client blijft dus geblokkeerd. Wanneer een gebruiker gegevens opvraagt via een


Windows applicatie en de opvraging gebeurt synchroon, zal de applicatie geblokkeerd

blijven tot alle gegevens zijn overgehaald (tenzij de client met verschillende threads werkt)

• Meestal RPC-communicatie.

• Synchrone communicatie kan men vergelijken met een telefoongesprek.

• Bij asynchrone communicatie kan de client verderwerken vanaf het moment dat de opdracht

verstuurd is. Er wordt niet gewacht op de server. (vergelijk met e-mail, de meeste mensen

wachten niet op een antwoord)

• MOM kan ook gebruikt worden voor synchrone communicatie via een apart framework

boven de message queue. Achter de schermen worden er twee queues gebruikt.

◦ De client verstuurt een bericht naar het framework. Dat plaatst het bericht in queue1.

◦ Het framework wacht op een antwoord in queue2

◦ De server ontvangt het bericht en plaatst het antwoord in queue2

◦ Vanaf het moment dat het antwoord in queue2 is ontvangen door het framework, stuurt

dat het antwoord naar de client

◦ Voor de client is het net of er een synchrone communicatie is geweest

• RPC kan ook gebruikt worden op een asynchrone manier via callbacks:

◦ client stuurt en request naar de server

◦ die geeft de controle direct terug aan de client (heel korte methode), eventueel na een

bevestiging

◦ De server verwerkt de request

◦ Wanneer de server klaar is wisselen de twee om van taak. De server wordt client en roept

een callback methode op de oude client (nu dus de server) op

◦ Wanneer het niet mogelijk is om de oorspronkelijke client terug op te roepen( firewall)

kan de client ook regelmatig “pollen” naar een antwoord

Interface/payload semantics

• Interface semantics wil zeggen dat er voor elke aanroep een verschillende methode is,

bijvoorbeeld getCustomer(int id)

• Bij payload semantics gebruiken alle aanroepen dezelfde methode (sendMessage). Wat de

server juist moet doen staat in de message.

• Interface semantics zijn voor de ontwikkelaars gemakkelijker te gebruiken. Ze hebben een

lijst met methodes en hun argumenten die ze kunnen oproepen. Wanneer de naam van

methodes goed gekozen is, is het ook duidelijk wat de methode doet.

• Maar wanneer de parameters van de methode veranderen omdat er andere informatie moet

worden meegestuurd (interface verandert), moeten alle applicaties die de interface

gebruiken, worden verandert (zelfs al gebruiken ze de methode niet)

• Bij payload semantics kan men bijkomende messages definiëren, zonder dat de client over

moet worden aangepast.

• In de tekeningen wordt gesuggereerd dat interface semantics bij RPC horen en payload


semantics bij MOM. Dit hoeft niet. In RPC kan men ook een methode Execute (Message)

hebben.

• SOAP is een voorbeeld van payload semantics. We noemen dit ook dpcument centric

messages. Het volledige commando staat in een XML document.

Tight vs Loose coupling

Laag Tight coupling Loose coupling

Physical coupling Directe fysieke link nodig Tussenpersoon

Communicatie stijl

Synchroon Asynchroon

Types

Interface semantics Payload semantics

Interactie patroon

Object trees Self contained messages

Control of process logic Central control Distributed logic

Service discovery &

binding

Statically bound Dynamically bound

Platform afhankelijkheid Sterk OS en programmeertaal

afhankelijk

OS en programmeertaal onafhankelijk


Services

• Bouwstenen van een Service-oriented architecture

• Coarse grained (Business driven): de functionaliteit wordt gedefinieerd op het business

niveau, niet op het technische niveau

• We definiëren een aantal namen om gemakkelijker over services te kunnen praten

• Soorten:

◦ Application frontends: eigenlijk geen service, maar wel een onderdeel van een SOA.

◦ Basic services: business logic centric, data centric

◦ Intermediary services: “hulp services”

◦ Process centric services: beheren een proces

◦ Public enterprise services: toegankelijk voor externen

Application frontends

• De client applicaties of batch processen. Ze starten de business processen en ontvangen ook

de resultaten.

• Communiceren met de services over het netwerk

Basic services: business logic services

• Business logic centric services: implementeren de business rules, bijvoorbeeld een service

die de “kennis” bevat over de producten die door een verzekeringsmaatschappij worden

verkocht. Deze service kan premies berekenen, betalingen verwerken en terugbetalingen,

aanvragen beoordelen, offertes maken en allerlei simulaties uitvoeren

• Deze functionaliteit behoort standaard tot het backoffice systeem. Alleen iemand van de

backoffice kan dan wettelijk bindende overeenkomsten afsluiten.

• Front office gebruikers hadden geen toegang tot die functionaliteit en moesten het vroeger

doen met bijvoorbeeld niet bindende simulaties. Dit is niet klant-vriendelijk (“dit is onze

aanbieding, maar alleen het hoofdkantoor kan een definitieve offerte maken”)

• Een alternatief is die functionaliteit kopiëren naar de PC's van de front office. Maar dat is

niet zo eenvoudig (werkt een COBOL programma op die PC, hoe zorg ik ervoor dat alle

front office clients de laatste wijzigingen hebben)

• Een derde mogelijkheid is de front office gebruikers rechtstreeks toegang te geven tot de

backoffice. Dit is ogenschijnlijk de beste oplossing. Maar in de praktijk ligt het niet zo voor

de hand dat een (externe) agent toegang heeft tot de interne applicaties.

• Een aparte service kan door alle betrokkenen worden aangesproken. We kunnen aparte

interfaces voorzien voor externe gebruikers zodat ze slechts toegang krijgen tot een beperkte

functionaliteit (gecombineerd met security)

• Opgelet: we zeggen hier niets over de implementatie van de service (aparte Java applicatie,

toegang via CICS, tekst uitwisselen via een terminal simulatie, ...)

Basic services: data centric services

• Data centric services werken met persistente (bewaarde) data

• Die data kan bewaard worden in een relationele databank, het bestandssysteem of zelfs een


tape library

• Data centric services lijken sterk op de data access layer in klassieke applicaties (DAL).

• Het grote verschil is dat in klassieke applicaties de volledige applicatie toegang had tot de

volledige databank (via de DAL)

• Data centric services werken volgens het principe van de vertical layering: één service

beheert één business entity.

• Wanneer een andere service data nodig heeft, moet de data centric service daarvoor worden

gebruikt.

• Nadeel: in een klassieke applicatie is er maar één datastore. Dat is gemakkelijk voor

bijvoorbeeld transacties. In een SOA applicatie zijn er meerdere datastores. Wie is er

“eigenaar” van welke data? Hoe kunnen we transacties over meerdere data centric services

gebruiken?

Intermediary service: technology gateway

• Bijvoorbeeld:

◦ business rules van een legacy applicatie zijn nodig in een moderne (windows user

interface) applicatie

◦ We zijn van plan om die legacy applicatie “ooit” eens te herschrijven (re-engineering)

◦ Een nieuw project kan daar niet op wachten (“ooit” in de informatica = “onverwijld” in

de politiek)

◦ we willen niet dat de legacy technology het nieuwe project “besmet” (we zouden een

windows applicatie kunnen ontwikkelen die via terminal streams gegevens uitwisselt

met de legacy applicatie)

◦ De technology gateway wordt tussen de legacy applicatie en de moderne windows client

gezet. De windows client spreekt de technology gateway aan via webservices. De

technology gateway vertaalt dit naar terminal streams en stuurt dit door naar de legacy

applicatie

◦ Opgelet: in een service-oriented architecture zullen we niet één service voorzien voor de

gehele legacy applicatie, maar een reeks services. Dat heeft als bijkomend voordeel dat

we het re-engineering process ook in stapjes kunnen opdelen. => eerst de application

front ends service-oriented maken.

Intermediary services: adapter

• Technology gateway vertaalde de ene technologie naar de andere

• adapter vertaalt de ene interface naar de andere.

• Bijvoorbeeld: de merger van twee firma's

◦ beide hebben al een SOA architectuur

◦ maar de interfaces van de services verschillen

◦ Om de application frontends (of services) van firma B te laten werken met de customer

data van firma A, gebruiken we een adapter die de aanvragen vertaalt van de ene

interface naar de andere

Intermediary services: facade

• Brengt verschillende services tezamen onder één interface


• Maar groot gevaar dat men de herbruikbaarheid in gevaar brengt. Door alle services te laten

aanspreken via een Common Access server layer introduceren we een groot blok dat altijd in

zijn geheel gebruikt moet worden

• Facades ontwikkelt men best voor één project zodat men de herbruikbaar van de services

eronder voor ogen houdt.

• Facades zijn dikwijls tegelijkertijd ook technology gateways of adapters

Intermediary services: functionality adding service

• Functionaliteit toevoegen aan een bestaande service

• Het is moeilijk om de bestaande service aan te passen( in de toekomst wordt de bestaande

service toch vervangen, de bestaande service is een product van een andere producent)

• Functionality adding service kan een stap zijn in een evolutie van het ene systeem naar het

andere

Process centric service

• Process staat op een hoger niveau dan een service

• processen maken gebruik van services en sturen ze aan. De verschillende proces stappen

maken gebruik van services.

• Proces moet ook toestand bijhouden (waar zit ik ergens in het proces)

◦ extra complexiteit (toestand van het proces) kan in een aparte service worden beheerd

◦ load balancing: we kunnen dezelfde service op meer machines zetten. De state kan dan

niet meer op die machines worden bijgehouden => bijhouden in process centric service

◦ multi channel applicaties: co-browsing twee browser sessies met elkaar samenwerken

◦ process logic afschermen van busines logic (in servies) en dialog control (in de

application front end)

• Process centric services worden soms “vergeten”. De proces control zit mee in de basic

services of (nog meer voorkomend) in de application front end.

• Process centric services zijn meestal project specifiek en kunnen moeilijk gedeeld worden

tussen verschillende projecten.

• Vormen een brug tussen SOA en Business Process Modeling

• We maken hier een verschil tussen de proces control logic (in het Business Process

Management System) en de business logic (in de basic layer)


• Business logic is stabieler dan Proces control.

Public enterprise services

• Vorige services waren voor intern gebruik

• public enterprise services worden gebruikt door externen (klanten, leveranciers/partners, …)

• “Business documenten” uitwisselen. Bevat alle informatie die nodig is om de dienst te

leveren (of om het resultaat terug te sturen). Dit is geen echt document, maar eerder een

message (vgl MOM)

• grote decoupling => asynchrone communicatie en payload semantics

• niet iedereen mag die service (gratis) gebruiken: aanmelden (authenticatie)

• Informatie wordt over een publiek netwerk verstuurt: encryptie

• facturatie: voor het gebruik van de service kan een fee gevraagd worden => registratie van

gebruik en integratie met facturatie systeem

• Service Level Agreements als “verzekering” voor externen

SOA roadmap

• Men zal SOA niet ineens invoeren

• Fundamental => network => process-enabled SOA

• Process logica zit mee in de enterprise layer

• We hebben eventueel ook de mogelijkheid om data te delen (door een services te delen) =>

geen data uitwisseling meer tussen applicaties via bijvoorbeeld batch processen

• In een green field (nieuwe situatie) gemakkelijk te implementeren.

• Networked SOA voegt een intermediary laag toe via bijvoorbeeld facades (vereenvoudigen

van het aanroepen van de operaties) of technology gateways (om legacy applicaties te

gebruiken.

• Door een facade te maken, wordt het aanroepen van Boekingen en facturatie eenvoudiger

Basic layer

Intermediary layer

Proces

layer

Business Process Management System => voert model uit


(bijvoorbeeld één methode om zowel de boeking als de facturatie te doen)

• Process enabled SOA's zorgen ervoor dat de process control uit de application frontend

verdwijnt.

• Process centric services zijn 'stateful'. Ze onthouden waar de client ergens in het proces zit

(welke processtap)

• Application frontend wordt nog eenvoudiger

• uitbreiden met intermediary services om bijvoorbeeld technologie af te schermen.

• Scheiding tussen business logica (in de basic services), process logica (in de process layer)

en dialog control (in de application frontend waar de dialog boxen in de user interface

bepalen welke processen gestart worden en hoe de informatie die de processen nodig hebben

wordt verzameld)

Andere view

Level 1:

Ad-hoc

Level 2:

Defined

Level 3:

Standardized

Level 4:

Managed

Level 5:

Agile

Business Ad hoc

Business state

Defined

Business state

Standardized

Business state

Managed

Business state

Agile

Business state

Organization Ad hoc

Organization

state

Defined

Organization

state

Standardized

Organization

state

Managed

Organization

state

Agile

Organization

state

Program

Management

Ad hoc

program

management

state

Defined

program

management

state

Standardized

program

management

state

Managed

program

management

state

Agile program

management

state

Governance Ad hoc

governance

state

Defined

governance

state

Standardized

governance

state

Managed

governance

state

Agile

governance state

Technology Ad hoc

technology

state

Defined

technology

state

Standardized

technology state

Managed

technology

state

Agile technology

state

Operations

and

Management

Ad hoc

operations

and

management

state

Defined

operations and

management

state

Ad hoc

operations and

management

state

Managed

operations and

management

state

Agile operations

and management

state


Facturatieproces

1) Bestaat klant: nee => maak klant

2) Maak factuur

Klant: nr, naam, adres, geboortedatum

Factuur: Klantgegevens, factuurnr, Datum, 1 of meerdere factuurlijnen (product, eenheidsprijs,

aantal, subtotal), total, BTW

Services

Klant

o Lijst klanten <=FindKlant(zoekcriteria)

o Klnr<=CreateKlant(naam, adres, gebdatum)

Factuur

o Facnr<=CreateFactuur(klnr, naam, adres, facdatum, factuurlijnen)

Product

o Product <=FindProduct (productnr)

Bestelling(process centric)


Process integriteit

• Data/process integriteit: we willen geen slechte data in het systeem. Bijvoorbeeld wanneer

we een geboortedatum ingeven, mag die niet in de toekomst liggen. (voorbeeld van data

integriteit)

• Data integriteit kan dikwijls worden afgedwongen door de databank

• process integriteit is moeilijker te implementeren dan data integriteit. Stel dat we twee

systemen hebben: één systeem is verantwoordelijk voor de bestellingen, het tweede systeem

is verantwoordelijk voor de facturatie. Elke nacht worden de bestellingen via een batch

proces doorgestuurd naar het facturatie systeem. Bestelling en facturatie maken deel uit van

hetzelfde proces. Neem nu de volgende situatie:

◦ klant bestelt maandag een product

◦ nacht maandag-> dinsdag wordt de bestelling doorgestuurd naar het facturatiesysteem

◦ dinsdag annuleert de klant de bestelling

◦ systeem bevat een inconsistentie: er zit een bestelling in het facturatie systeem die niet

meer bestaat

• Hoe kunnen we processen integer/consistent houden? (gegeven dat een proces dikwijls uit

een mix van systemen bestaat die historisch gegroeid is)

Soorten fouten die gevolgen kunnen hebben voor de proces integriteit

• Technische fouten: databank crash, netwerkproblemen

◦ Technische problemen kunnen vaak opgelost worden door de technische omgeving

(database recover, transacties gebruiken, opnieuw proberen in geval van netwerk

problemen.

◦ Soms kan dit ingewikkelder zijn, bijvoorbeeld met netwerkproblemen kunnen we

omgaan door tijdelijk de data die moet worden doorgestuurd te stockeren.

• Business exceptions: vlucht boeken in het verleden (kan zelfs worden afgehandeld in de user

interface)

◦ moeilijkere gevallen: out of stock. Ga ik gewoon tegen de klant zeggen “niet meer in

voorraad”? Betere oplossing op tijd bij bestellen (maar dit is een veel ingewikkelder

oplossing: wanneer ga ik bijbestellen?)

• Speciale gevallen: afwijkingen van het “happy path”.

◦ Speciale gevallen vereisen veel meer programmeerwerk dan het happy path

◦ kunnen erg ingewikkeld worden: ga ik een vliegtuig/boot gewoon volboeken (veilig) of

een beetje overboeken (commercieel interessanter)

Oplossingen voor problemen

Logging en tracing

• wijzigingen bijhouden (en wie ze uitgevoerd heeft)

• Wanneer we weten wat er gebeurd is, kunnen we bepaalde stappen ongedaan maken.

• Dikwijls manueel oplossen van problemen op basis van gelogde gegevens. (manueel

oplossen is in eerste instantie soms goedkoper dan software te ontwikkelen die dit

automatisch kan doen)


• Probleem: mix van systemen, verschillende logs => hoe vind ik de log entries terug die bij

een bepaald proces horen (dikwijls alleen log entries met tijdsaanduiding)

• logging dikwijls in service bus

ACID transacties

• Transactie: unit of work in de databank (geld overschrijven is geld afhalen van de ene

rekening en storten op de andere rekening)

• ACID:

◦ Atomicity: ofwel gaan alle stappen in de transactie door, ofwel gaat er geen enkele stap

door

◦ Consistency: transacties brengen het systeem van de ene consistente toestand naar de

andere (geld overschrijven: de som van de rekeningen voor en na de overschrijving moet

hetzelfde zijn. Er mag nooit een toestand voorkomen dat er teveel of te weinig geld op

de rekeningen staat)

◦ Isolation: intern kan er altijd een toestand zijn die niet consistent is. Er is namelijk altijd

een moment dat de aanpassing al gebeurd is op de ene rekening maar niet op de andere.

Andere processen mogen deze toestand echter niet zien. Dat wordt opgelost via locking

◦ durability: Eenmaal dat de transactie is afgelopen moeten de data voorgoed

weggeschreven zijn in de databank.

Transaction monitors en 2 phase commit (2PC)

• ACID transacties werken alleen binnen één databank

• Wanneer een transactie moet gebeuren over twee verschillende databanken heen (geld van

databank 1 moet overgeschreven worden naar databank 2) => distributed transaction

coördinator

• 2 phase commit:

◦ elke databank moet zich in een toestand zetten zodat de aangepaste gegevens voorgoed

kunnen worden weggeschreven (nodige locks zijn gezet bijvoorbeeld) maar ook dat ze

niet weggeschreven kunnen worden

◦ Afhankelijk van de uitkomst van de vorige stap (elke databank geeft door of de update

zal kunnen lukken) zal de transaction coördinator doorgeven dat de wijzigingen

persistent moeten worden gemaakt (elke databank heeft doorgegeven dat het in orde is)

◦ Wanneer niet elke deelnemer heeft doorgegeven dat het in orde is, krijgt elke deelnemer

de opdracht om de wijzigingen ongedaan te maken.

• Problemen met 2PC en ACID transacties

◦ performantie: transacties vertragen het systeem (onder meer wegens de locks)

◦ transacties zijn ontworpen om gebruikt te worden voor een korte duur. (locks niet te lang

vasthouden) + proces “transacties” duren veel langer.

◦ Combinatie met legacy systemen en packaged applicaties (ERP, CMS): distributed

transacties worden niet altijd ondersteund door legacy systemen of door packaged

applicaties

◦ 2PC vereist een goede netwerk verbinding


Compensaties

• Bijhouden welke stappen er moeten worden gezet om de acties ongedaan te maken.

• (Rek1 – 500) en (Rek2 + 500) => compensaties (Rek1 + 500) en (Rek2 – 500)

• Dit is een business oplossing (geen ACID transactie) omdat andere processen in principe de

tussentoestand kunnen zien.

• Via een persistent queue kunnen we bijhouden wat er gebeurd is op een systeem. Elke stap

die wordt uitgevoerd, wordt uit een lijst (queue) gehaald en na het uitvoeren in een tweede

queue gestoken.

• De tweede queue bevat een lijst met alles wat er is uitgevoerd op de databank (in dit geval)

• (Hopelijk volstaat deze informatie om alle stappen ongedaan te maken)

Concurrency contol

• Zorgen dat we rekening houden met multi user systemen: verschillende processen kunnen

met dezelfde data proberen te werken

• twee oplossingen: optimistic en pessimistic concurrency control

• pessimistic

◦ locking van gegevens: zolang proces 1 met de data bezig is, kan niemand anders eraan

◦ niet aan te raden omdat dit grote gevolgen kan hebben voor de performantie

• optimistic

◦ proces 1 leest gegevens in

◦ proces 1 schrijft wijzigingen weg MAAR alleen wanneer ze ondertussen niet gewijzigd

zijn ('versie' is niet veranderd)

◦ optimistic concurrency veel minder gevolgen voor performantie

◦ onwerkbaar wanneer er processen dikwijls met dezelfde data werken

In een meer verfijnde vorm kunnen we proberen om de wijzigingen samen te voegen (merge) met

de nieuwe gegevens die aanwezig zijn in de data. We lezen bijvoorbeeld de volgende gegevens in:

Naam: Joske Vermeulen

Straat: Trammezandlei 122

We veranderen de naam in “Jos Vermeulen” en proberen de gegevens weg te schrijven. Dat lukt niet

want de gegevens zijn ondertussen gewijzigd. De nieuwe gegevens zijn:

Naam: Joske Vermeulen


Aangezien de aanpassing op twee verschillende plaatsen is gebeurd zouden we de gegevens kunnen


samenvoegen:

Naam: Jos Vermeulen


Pessimistic locking

We spreken hier niet over pessimistic locking op het niveau van de databank. Maar pessimistic

locking wordt geïmplementeerd door de applicatie.

Pessimistic locking zal gebruikt worden in plaats van optimistic locking wanneer er dikwijls

gelijktijdige write operaties gebeuren op dezelfde data. Optimistic locking is dan minder interessant

omdat de gebruiker die als tweede schrijft een foutmelding zal krijgen (begin maar terug opnieuw

want iemand anders heeft de data al gewijzigd)

Pesssimistic locking wordt op applicatie niveau geïmplementeerd door voor elke entity (klant,

factuur, product, factuur, …) een aparte eigenschap 'LOCKED BY' te voorzien. Wanneer een

gebruiker een wijziging wil aanbrengen, wordt er gekeken of het LOCKED BY attribuut is

ingevuld. Wanneer dat het geval is, krijgt de gebruiker de melding dat het item op dit moment niet

gewijzigd kan worden. Wanneer LOCKED BY niet is ingevuld, wordt het ingevuld met de ID van

de gebruiker. (wanneer een ander proces probeert het veld te wijzigen, zal dat proces nu de

foutmelding krijgen).

De gebruiker voert de aanpassingen uit en wanneer de nodige aanpassingen zijn gebeurd, wordt het

LOCKED BY veld terug leeg gemaakt.

Op het eerste zicht lijkt dit eenvoudig, maar:

• we moeten zorgen dat er bij elke aanpassing wordt gechecked of het item gelockt is door de

gebruiker zelf

• We moeten een beheertool voorzien waarmee locks kunnen worden veranderd (een item is

toegewezen aan een gebruiker en een andere gebruiker moet het afhandelen)

• We moeten ook rekening houden met het feit dat een lock soms niet meer wordt vrijgegeven

(bijvoorbeeld omdat de client is gecrasht). Via een management tool moeten dit soort van

locks kunnen vrijgegeven.

Idempotente operaties

• Stel dat ik een website heb om iets te bestellen

• De gebruiker vult gegevens in en drukt op de bestellen-knop

• Doordat het netwerk nogal traag is, heeft de gebruiker de indruk dat er niets gebeurt en drukt

hij/zij op 'vernieuwen' (F5)

• Wat gebeurt er? (in de praktijk niets omdat websites dit meestal zelf oplossen)

• Een idempotente operatie zorgt ervoor dat een client een operatie nooit meerdere keren kan

uitvoeren of dat het geen effect heeft wanneer de gebruiker een operatie meerdere keren zou

uitvoeren.

• Dit probleem komen we tegen bij Add/increment operaties. (verhoog het aantal bestellingen

met 1)

• Dit probleem treedt niet op bij set-operaties (verander de naam “Joske” in “Jos”)

• We zorgen er dus best voor dat operaties vooral set-operaties zijn.

• Een andere oplossing is gebruik maken van sequence nummers.

◦ Wanneer een client een operatie wil uitvoeren, vraagt hij een nummer aan de service


◦ Dat nummer wordt meegestuurd bij het uitvoeren van de operatie.

◦ De server controleert of de operatie met dat nummer al is uitgevoerd. Wanneer dit niet

het geval is, wordt de operatie niet uitgevoerd.


Services definiëren(Syllabus pag 45 e.v.)

– Herbruikbaarheid: services zijn bouwstenen. We moeten die kunnen hergebruiken in

verschillende processen(idealiter)

– information hiding: de interne implementatie (hoe werkt de service) moet verborgen blijven

voor de buitenwereld (andere services, application front end). De buitenwereld mag alleen

weten welke informatie een service nodig heeft en welke informatie een service teruggeeft.

– Low coupling, large cohesion: een (basic) service moet zoveel mogelijk op zichzelf staan en

mag in principe geen andere services nodig hebben.

– Stateless: we houden geen state bij in een service zelf. De enige state die wordt bijgehouden

door een service zit in een datasource of in de process service

– Granulariteit: De informatie die we uitwisselen met een service

"Bronnen" voor services

1. Business Process Model diagram

2. Enterprise architecture (bijvoorbeeld Zachmann diagram)

(vijf rijen: Scope , Business concepts, System logic, technology, Tools,

zes kolomen: waarom, hoe, wat, wie, waar, wanneer)(bron: wikipedia)

3. Object georienteerde analyse en ontwerp: pas op, de methodes die uit OOAD komen zijn te

fine-grained(setNaam, setAdres, setBTWnr, setTelefoon, …). De operaties in een service

zullen meer coarse-grained zijn.


Voorbeeld WSDL (contract first)

Omgevingen zoals .NET laten toe om op basis van OO-code een WSDL bestand te genereren. Het

probleem hiermee is dat we weinig controle hebben over het gegenereerde bestand. Deze aanpak

noemt men ook code first.

In een SOA omgeving is het meestal beter om gebruik te maken van een “contract first” aanpak.

Een WSDL bestand zou er als volgt kunnen uitzien:

<?xml version="1.0" encoding="utf-8" ?>

<definitions name="HelloService"

targetNamespace="http://www.examples.com/wsdl/HelloService.wsdl"

xmlns="http://schemas.xmlsoap.org/wsdl/"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:tns="http://www.examples.com/wsdl/HelloService.wsdl"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<message name="SayHelloRequest">

<part name="firstName" type="xsd:string"/>

</message>

<message name="SayHelloResponse">

<part name="greeting" type="xsd:string"/>

</message>

<portType name="Hello_PortType">

<operation name="sayHello">

<input message="tns:SayHelloRequest"/>

<output message="tns:SayHelloResponse"/>

</operation>

</portType>

<binding name="Hello_Binding" type="tns:Hello_PortType">

<soap:binding style="document"

transport="http://schemas.xmlsoap.org/soap/http"/>

<operation name="sayHello">

<soap:operation soapAction="sayHello"/>

<input>

<soap:body

use="literal"/>

</input>

<output>

<soap:body

use="literal"/>

</output>

</operation>

</binding>

<service name="Hello_Service">

<documentation>WSDL File for HelloService</documentation>

<port binding="tns:Hello_Binding" name="Hello_Port">

<soap:address location="http://localhost:52608/HelloService.svc" />

</port>

</service>

</definitions>

In .NET svcutil /sc /serializer:DataContractSerializer


Service bus

“An enterprise service bus (ESB) is a distributed infrastructure used for enterprise integration. It

consists of a set of service containers, which integrate various types of IT assets. The containers are

interconnected with a reliable messaging bus. Service containers adapt IT assets to a standard

servcies model, based on XML message exchange using standardized messages exchange patterns.

The ESB provides services for transforming and routing messages, as well as the ability to centrally

administer the distributed system”

(http://blogs.oracle.com/rtenhove/entry/what_is_enterprise_service_bus, 2006)

Andere definities:

"A Web-services-capable infrastructure that supports intelligently directed communication and

mediated relationships among loosely coupled and decoupled biz components."

–Gartner Group

"The ESB label simply implies that a product is some type of integration middleware product that

supports both MOM and Web services protocols."

–Burton Group

"A standards-based integration backbone, combining messaging, Web services, transformation, and

intelligent routing." –Sonic Software

"An enterprise platform that implements standardized interfaces for communication, connectivity,

transformation, and security." –Fiorano Software

"To put it bluntly: If you have WebSphere MQ and other WebSphere brokers and integration

servers, you have an ESB." –Bob Sutor, IBM

Praktische toepassing: execution containers

– dispatching en servicing: zorgen dat een service kan worden aangesproken (service aanroep

op de juiste manier doorsturen naar de juiste service)

– transaction management: beheer van transactions(data centric service, maar ook process

centric services)

– Security: authenticatie (wie bent u), authorizatie (wat mag u) en ook transport encryption

(het verkeer tussen services encrypteren zodat het onleesbaar wordt voor anderen)

– Logging: bijhouden wat er gebeurt + de mogelijkheid om een logging level te configureren

(DEBUG, INFO, WARNING, ERROR)

– Billing: informatie verzamelen om het gebruik van de service te kunnen aanrekenen

– System management: beheer van de service bus met bijvoorbeeld de mogelijkheid om een

service te stoppen en te starten. Maar ook statistische informatie (error reports, gemiddelde

processing tijd, resource gebruik, tijd online, ….)

– Message transformation: Enterprise Application Integration en B2B scenario's waarbij de

berichten die worden uitgewisseld tussen verschillende services eerst moeten worden

vertaald naar een ander formaat.

http://blogs.oracle.com/rtenhove/entry/what_is_enterprise_service_bus


– Web service integratie is niet strikt nodig, maar de meeste huidige producten ondersteunen

dit en men is al meer en meer van mening dat dit een essentieel onderdeel is van een

moderne Enterprise Service Bus.

Wat voegt SOA toe aan webservices?

Enabled by Web

services

Technology

neutral Endpoint platform independence.

Standardized Standards-based protocols. Consumable Enabling automated discovery and usage.

Enabled by SOA Reusable Use of Service, not reuse by copying of

code/implementation. Abstracted Service is abstracted from the implementation.

Published Precise, published specification functionality of service

interface, not implementation.

Formal Formal contract between endpoints places obligations on

provider and consumer.

Relevant Functionality presented at a granularity recognized by the

user as a meaningful service.


Essentie van services

• SOA is een reactie op de problemen met monolithische applicaties. Een monolithische

applicatie bevat alle functionaliteit in één applicatie. Tekstverwerking, spreadsheets, …

delen dezelfde persistentie laag. We kunnen hierbij ook van horizontal slicing spreken.

• In een service oriented omgeving zijn tekstverwerking, spreadsheets, … services die los

staan van elkaar. We kunnen nu de tekstverwerking ook apart gebruiken in een andere

applicatie. Dit is een voorbeeld van vertical slicing

• Dit is echter nog geen echte SOA. In een service oriented architecture willen we niet alleen

services hergebruiken in andere applicaties, we willen ook binnen de applicatie gemakkelijk

van service willen wisselen. Indien de tekstverwerker Microsoft Word niet meer voldoet,

moeten we die kunnen veranderen naar OpenOffice Writer bijvoorbeeld. Dat is niet zo

eenvoudig in de vorige tekening. De kans is groot dat de application front sterk gebonden is

aan de tekstverwerking service. We zullen een gemeenschappelijke toegang (interface1)

moeten afspreken voor alle tekstverwerkingsservices. Die toegang bevat de operaties die we

willen uitvoeren met een tekstverwerker.

Tekstverwerking

Application front end

Rekenblad Presentatie

Bestand Bestand Bestand

Documenten, berekeningen, tekeningen, … maken

User interface

Persistentielaag (bestanden of databank)


• En toch is dit ook nog geen echte SOA. We kunnen bij het bouwen van de applicatie kiezen

welke tekstverwerker (rekenblad, presentatiesoftware) we willen koppelen aan die

application front end. Maar we zouden die flexibiliteit ook graag hebben tijdens het

uitvoeren. Dat kunnen we doen door de verschillende onderdelen niet rechtstreeks met

elkaar te verbinden, maar ze via een tussenpersoon met elkaar te laten communiceren.

Die bus is een soort centrale verkeerwisselaar waarlangs alle verkeer verloopt.

• Om de services zo bruikbaar mogelijk te maken, moeten ze zoveel mogelijk onafhankelijk

Interface3

Application frontend

Interface4

Bus

Interface2 Interface1

Tekstverwerking

Bestand

Rekenblad

Bestand

Presentatie

Bestand

Tekstverwerking

Application frontend

Interface1 Interface2 Interface3

Presentatie Rekenblad

Bestand Bestand Bestand


zijn van elkaar. Ze moeten hun werk onafhankelijk van elkaar kunnen doen. We proberen

ook de communicatie zo coarse-grained mogelijk te maken. We willen eigenlijk maar één

opdracht geven aan de services en niet een reeks van vragen beantwoorden. Dit wordt

duidelijker met het volgende voorbeeld:

Service(coarse-grained) API(fine-grained)

Klant vraagt een formulier aan om een

hypotheek aan te vragen

Bank zendt het formulier

Klant vult het formulier in en stuurt het terug

Bank zegt “ja” of “neen” op basis van het

formulier

Klant belt bank

bank: hoe kan ik u helpen?

Klant: ik wil een hypotheek aanvragen

bank: wat is u naam?

Klant: <naam>

bank: wat is het adres?

Klant: <adres>

bank: wat is...

….

bank: u krijgt de details van uw hypotheek

lening doorgestuurd (of niet)

SOA Governance(https://www.opengroup.org/soa/source-book/gov/sgrm.htm)

Principe Beschrijving Waarom?

SOA governance must promote the alignment of business and IT

The SOA governance program should support the business and IT drivers. Business and IT stakehold-ers must participate in governing and enforcing the organization’s SOA pro-gram.

SOA is intended to drive flexibility and agility for the business and IT. Failing to govern to foster that align-ment will reduce the benefits of a ser-vice-oriented approach.

Conform to organization's govern-ance

SOA governance activities shall con-form to Business, IT, & EA govern-ance principles and standards.

The organization governance proce-dures are part of the strategy of the organization and should be a part of SOA governance as well.

An SOA Reference Architecture is re-quired

An SOA Reference Architecture pro-vides a set of architectural patterns, standards, and best practices for use in developing SOA solutions

Use of the approved architectural ar-

tifacts, from the SOA RA, will reduce

project risk and lower costs, by re-

ducing the number and complexity of

design activities in the project.

Organization reference architectures

may be based on standard SOA ref-

erence architectures or industry ref-

erence architectures.

All SOA solution architectures should

be created based on the organiza-

tion’s SOA Reference Architecture.

Provider & consumer contracts Contracts should exist between ser-

vice providers and consumers.

Contracts may be dictated by one

party.

To ensure the correct delivery of service.


Service metadata To enable decisions and descriptions relating to services and their contracts to be stored in a well-known location, including relationships among services and their associated artifacts.

Understanding of the purpose of the

service.

Business continuity impact analysis.

Root cause analysis.

Identified governance stakeholders Stakeholders shall be identified and accept responsibility for the governance process(es).

To ensure proper execution of gov-

ernance.

To communicate SOA governance

value.

To communicate appropriate SOA

governance processes and proce-

dures.

Tailor SOA governance processes SOA governance processes should be tailored based on objectives, project scope, and risk.

Only do as much governance as is

needed.

To prioritize SOA governance costs.

Automate SOA governance processes

It should be possible to automate the SOA governance processes.

Facilitates consistent and efficient

application.

Reduces personnel required to do

the work.

Reduces training of people.

More reliable and traceable govern-

ance.

Implement funding model All services and solutions should be covered by a funding model.

Ensure that an organization is willing

to develop and support a needed ser-

vice long-term, especially if services

may be used across organization

funding models.

Services developed on an ad hoc ba-

sis may not be officially supported for

defects, conformance, enhancement,

and performance

SOA implementeren

Er zijn al veel organisaties die SOA hebben geïmplementeerd (of hebben proberen te

implementeren). Uit deze ervaringen komen een aantal aanbevelingen naar boven:

• Zorg voor een “pilot success story”:

◦ voldoende budget (communiceer de overheadkosten)


◦ een zichtbaar pilootproject (wanneer het geïmplementeerd is moet het voor zoveel

mogelijk mensen duidelijk zijn dat het geïmplementeerd is), maar niet te prestigieus

(want dan begint iedereen zich te bemoeien).

◦ Goed SOA team

◦ backers: goede ondersteuning van top-management

• gebruik top-down benadering: vertrek vanuit de business view (logical view) en begin met

de algemene architectuur te bepalen

• leg de focus op services (hergebruik van functionaliteit en data) en niet op het uitwisselen

van data

• blijf vendor onafhankelijk en gebruik alleen open standaarden

• laat het proces niet alleen beheren door IT mensen, betrek de business mensen ook actief

• Herbruikbaarheid voorzien van services is een probleem:

◦ men moet er rekening mee houden bij de ontwikkeling

◦ ontwikkeling van services duurt langer wanneer men herbruikbaarheid moet voorzien

◦ (Winterthur): maar één op de drie services wordt effectief herbuikt in verschillende

applicaties

◦ (Credit Suisse): de gemiddelde services wordt in 1.6 applicaties gebruikt maar sommige

services worden door 12 applicaties gebruikt. => soms tot 80% hergebruik in nieuwe

applicaties

◦ Herbruikbaarheid voorzien leidt ook tot meer fine-grained services. =>

performantieprobleem bij remote services (CORBA gebruiken in plaats van webservices

of facade met lokale aanroepen naar fine-grained services)

◦ Onderscheid maken tussen publieke(herbruikbaar) en private(niet herbruikbaar) services

• Besteed veel aandacht aan de repository. Repository is een betere vorm van documentatie

dan klassieke documentatie. Omdat de repository info zich beperkt tot de essentiële feiten

over de service die in een gestandaardiseerd formaat wordt gegoten, is de informatie veel

beter.

• (Credit Suisse) vier succesfactoren:

◦ Interfaces

◦ Processen

◦ Management commitment

◦ Solid technology

Waarom mislukt de introductie van SOA soms?

• SOA bekijken als een technologie (IT) project in plaats van een business project

• Niet incrementeel te werk gaan: teveel ineens willen waardoor de oplevering vertraagd

wordt (1 à 2 jaar is lang genoeg => SOA moet flexiebel kunnen inspelen op business

vereisten, na ). Beter om een kleiner piloot project te voorzien. Dit kan ook beter

geëvalueerd worden door de business

Waarom SOA?

• SOA bevordert“Agile” software development. Complexiteit zorgt ervoor dat de

ontwikkeling van enterprise applicaties soms te traag gaat. Complexiteit situeert zich op


verschillende niveau's:

◦ Complexiteit in technologie: IT oplossingen kunnen vrij complex zijn zeker wanneer er

'workarounds' worden gebruikt

◦ Complexiteit in business processen: de complexiteit van business processen is meestal

verborgen omdat men de processen niet goed kent. Maar wanneer men ze probeert te

modelleren, komt de complexiteit al snel naar voor

◦ Complexiteit in business functionaliteit: afzonderlijke business functionaliteit kan erg

eenvoudig zijn, maar de combinatie van functionaliteit kan leiden tot een complex

geheel

◦ Integratie: applicaties zijn niet altijd gebouwd om samen te werken. De integratie van

verschillende applicaties is soms een moeilijk proces

◦ Onderhoud: complexe applicaties zijn natuurlijk ook complex om te onderhouden

• SOA's pakken complexiteit aan op de volgende manieren:

◦ decomposition: het complexe systeem wordt opgedeeld in application front ends en

services

◦ Grote granulariteit: services geven niet te veel details vrij in hun interface waardoor ze

gemakkelijker te gebruiken/begrijpen zijn. (het is gemakkelijker geld af te halen aan het

loket van een bank dan zelf manueel alle handelingen te verrichten)

◦ Losgekoppeld van de technology: de beschrijvingen van services staan los de gebruikte

technologie. Men moet dus de technologie niet kennen

◦ Hergebruik: goede services kunnen herbruikt worden waardoor de ontwikkeling van

nieuwe applicaties gemakkelijker gaat

◦ Documentatie: documentatie wordt actief gebruikt via het service contract. Men kan dus

services gemakkelijker begrijpen

• SOA werk kostenbesparend

◦ op business niveau

▪ het wordt gemakkelijker om van leverancier te switchen wanneer een applicatie niet

half moet herschreven worden. Zo zal men eerder geneigd zijn om over te stappen

naar een goedkopere leverancier

▪ business processen wijzigen regelmatig. Door de flexibiliteit van services kunnen we

een business process gemakkelijk wijzigen

▪ live data kunnen gemakkelijker gedeeld worden tussen verschillende applicaties.

Hiervoor wordt rapportering (financiële rapportering) nauwkeuriger.

◦ Op IT niveau

▪ de introductie van SOA verhoogt te kost, maar eenmaal een SOA in gebruik is wordt

de implementatie van projecten gemakkelijker

▪ Men is niet verplicht om oude applicaties te vervangen, men kan ze integreren in een

SOA oplossing

▪ Het onderhoud wordt goedkoper doordat de architectuur eenvoudiger is.

• SOA bevordert hergebruik alhoewel men door een service herbruikbaar te willen maken de

ontwikkeltijd soms verhoogt (+ finer grained services krijgt)

• SOA architecturen zijn onafhankelijk van de technologie. Te dikwijls wordt de ontwikkeling

van een applicatie gestuurd door de technologie in plaats van door de business vereisten.


• SOA propageert een stap-voor-stap aanpak.

◦ Een Big Bang aanpak (applicatie A wordt vervangen door applicatie B) is een duur

proces omdat

▪ men problemen dikwijls pas opmerkt nadat applicatie B geïnstalleerd is

▪ men bijgevolg heel voorzichtig (en heel traag) is met het installeren van nieuwe

applicaties

▪ men moet key players en decision makers op één lijn krijgen. Dat is moeilijker bij

één grote applicatie (veel stakeholders) dan bij kleine aanpassingen.

◦ Nieuwe functionaliteit en aanpassingen gebeuren eigenlijk continu. In een SOA

architectuur kunnen we aanpassingen per service doen

• Laat feedback (en buy-in) toe op verschillende niveau's doordat services op verschillende

niveau's gedefinieerd zijn: zowel op business(interface) als op implementatie niveau

• vermindert het risico.

◦ Mogelijke risico's (Standish group):

▪ slechte specificaties

▪ slechte planning en inschatting

▪ slecht project management

▪ gebruik van nieuwe technologiën en onvoldoende ervaring

◦ SOA lost dit op:

▪ service documentatie helpt via de contracten de werking van services duidelijk te

maken voor Business mensen

▪ Business wordt veel nauwer betrokken

▪ Maakt het gemakkelijker om bestaande technologieën te integreren

▪ Vereenvoudigt ontwikkeling door complexe procedures af te schermen van de rest

van de applicatie


Gartner hype cycle: hoe is SOA geëvolueerd?

Referenties

1. http://msdn.microsoft.com/en-us/library/bb977471.aspx: overzicht van SOA volgens

Microsoft

2. http://www.microsoft.com/biztalk/en/us/soa.aspx: Microsoft implementatie van SOA via

Biztalk server

3. http://www.redbooks.ibm.com/abstracts/sg247240.html: SOA volgens IBM

4. http://publib-b.boulder.ibm.com/abstracts/sg247335.html: IBM redbook over Websphere

ESB

5. http://wiki.open-esb.java.net/Wiki.jsp?page=OpenESBIntroductionTutorial: OpenESB een

open source Enterprise Service Bus, oorspronkelijk ontwikkeld voor de Oracle Glassfish

application server

6. http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html. Artikel waarin

het einde van het buzzword SOA wordt verklaard, maar de essentie (services) nog steeds

verdedigd wordt.

http://msdn.microsoft.com/en-us/library/bb977471.aspx

http://www.microsoft.com/biztalk/en/us/soa.aspx

http://www.redbooks.ibm.com/abstracts/sg247240.html

http://publib-b.boulder.ibm.com/abstracts/sg247335.html

http://wiki.open-esb.java.net/Wiki.jsp?page=OpenESBIntroductionTutorial

http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html

samenvatting service oriented architecture...samenvatting service oriented architecture 1...

Documents