Follow Us on Twitter

Ver-servicen van Oracle database-applicaties

Mei 2013 – Met behulp van een SOA-architectuur kunnen IT-oplossingen sneller, beter en goedkoper worden gerealiseerd. Dit wordt onder meer bereikt doordat bestaande functionaliteit met behulp van SOA gemakkelijker kan worden hergebruikt door deze als services aan te bieden. Het is dan niet nodig om de bestaande IT-voorziening volledig te vervangen, zodat nog steeds profijt kan worden getrokken van vroeger gedane investeringen.

Bij veel bedrijven is bestaande functionaliteit geïmplementeerd in Oracle-databaseapplicaties. Dit zijn doorgaans applicaties met Oracle Forms-schermen op een Oracle-database.

In dit Whitebook laat ik zien hoe de functionaliteit in Oracle-databaseapplicaties met behulp van services kan worden ontsloten voor hergebruik. Oftewel in “goed Nederlands”, hoe Oracle-databaseapplicaties kunnen worden “verserviced”.

Ik ga daarbij eerst in op hoe applicaties in het algemeen op een servicebus kunnen worden aangesloten, hetgeen typisch wordt beschreven in een SOA-referentiearchitectuur. Vervolgens werk ik dit specifiek verder uit voor het aansluiten van een Oracle-databaseapplicatie op OSB.

SOA-referentiearchitectuur

In mijn vorige Whitebook “Invoering van SOA onder governance” heb ik toegelicht op welke wijze applicaties in het algemeen op een servicebus kunnen worden aangesloten. Dit wordt typisch beschreven in een SOA-referentiearchitectuur; een aantal belangrijke punten daaruit wordt hieronder kort aangestipt. Zie verder mijn vorige Whitebook voor meer uitleg over deze punten.

SOA-modellen

In een SOA logisch model worden de servicelagen/servicetypen onderkend en beschreven, bijvoorbeeld:

  • Processervices.
  • Businessservices.
  • Connectorservices.
  • Utilityservices.

Het aansluiten van applicaties op een servicebus wordt met name beschreven door het zogenaamde SOA-busmodel. Hierbij spelen concepten als “CDM” (canoniek datamodel; zie ook lijst met afkortingen achteraan) en “Functioneel domein” een belangrijke rol. Een functioneel domein is samenhangend geheel van businessfunctionaliteit binnen een bedrijf zoals “HRM” en “Order Management”. Het zijn namelijk functionele domeinen en hun ondersteunende applicaties die van elkaar worden ontkoppeld met behulp van services, CDM en servicebus. Dit wordt schematisch weergegeven in de volgende figuur.

SOA bus-model

Implementatie van canonieke businessservices op OSB (Oracle Service Bus)

In onderstaande figuur wordt aangegeven hoe een canonieke businessservice in het algemeen wordt geïmplementeerd op OSB conform bovenstaand SOA-busmodel.

Businessservice op bus

Een canonieke businessservice wordt dus geïmplementeerd als OSB proxy service en de bijbehorende applicatieconnectorservice(s) worden geïmplementeerd als OSB business service(s). Hij kan dan door andere domeinapplicaties worden aangeroepen via zogenaamde requesterservices, die ook als OSB proxy services worden geïmplementeerd.

In de rest van dit Whitebook ga ik het aansluiten van een Oracle-databaseapplicatie op OSB verder uitwerken. Dit is een speciaal geval van de hierboven beschreven algemene aanpak.

Aansluiten van een Oracle-databaseapplicatie op OSB

Een Oracle-databaseapplicatie is een applicatie met schermen (bijv. Oracle Forms) en rapporten (bijv. Oracle Reports) op een Oracle-database. De database bevat de tabellen, views, sequences, e.d. en businesslogica in de vorm van PL/SQL program units.

Het idee is nu om de database van een Oracle-databaseapplicatie op de OSB aan te sluiten met behulp van databaseadapters en zo de bestaande databasefunctionaliteit te ontsluiten.

Applicatieschema en SOA API-schema

De databaseobjecten van een applicatie zijn meestal ondergebracht in één databaseschema: het zogenaamde applicatieschema. Het is echter onder meer om de volgende redenen niet verstandig om het applicatieschema rechtstreeks door databaseadapters te laten benaderen:

  • Het is onduidelijk welke functionaliteit precies beschikbaar mag worden gesteld op OSB als het hele applicatieschema benaderbaar is.
  • De services op OSB zijn dan erg gevoelig voor wijzigingen in databaseobjecten van het applicatieschema omdat deze rechtstreeks worden benaderd door de services. Bovendien is vaak niet duidelijk welke services van welke databaseobjecten gebruik maken.
  • Bij Oracle-databaseadapters kan het beste gebruik worden gemaakt van Oracle SQL-objecttypes. Dergelijke objecttypes ten behoeve van SOA zijn echter doorgaans niet gedefinieerd in (legacy) applicatieschema’s.
  • Bij gekochte applicatiepakketten is het vaak niet mogelijk of toegestaan om het applicatieschema aan te passen ten behoeve van SOA.

In plaats daarvan kan beter een apart schema worden gemaakt dat alleen databaseobjecten bevat ten behoeve van ontsluiting van de functionaliteit in het applicatieschema. De extra inspanning hiervoor wordt gemakkelijk terug verdiend door aanzienlijk eenvoudiger onderhoud van de services op OSB, zoals hierboven aangegeven.

Het aparte schema vormt als het ware de interface naar de applicatie ten behoeve van SOA-services; het schema noemen we daarom het SOA API-schema. Dit schema wordt benaderd door OSB-services, zoals geschetst in de volgende figuur.

SOA API-schema

Deze figuur is een verdere uitwerking van de voorgaande figuur. Een ACS (applicatieconnectorservice) is geïmplementeerd als OSB business service die op een databaseadapter is gebaseerd. De databaseadapter benadert een stored procedure in het SOA API-schema, die op zijn beurt een of meer databaseobjecten van het applicatieschema benaderd. De ACS kan worden aangeroepen door een CBS (canonieke businessservice) geïmplementeerd als OSB proxy service. In deze OSB proxy service vindt onder meer de transformatie plaats tussen canoniek en applicatiespecifiek formaat.

Op deze manier wordt bestaande applicatiefunctionaliteit in het applicatieschema dus ontsloten als een set canonieke businessservices op de OSB.

Inhoud van SOA API-schema

Een SOA API-schema bevat typisch de volgende databaseobjecten:

  • PL/SQL-packages.
  • SQL-objecttypes.
  • Objectviews.

PL/SQL-package

Een PL/SQL-package bevat een aantal functioneel bij elkaar horende PL/SQL-procedures en PL/SQL-functies (stored procedures en functions). Een SOA API-package bevat bijvoorbeeld de procedures die de CRUD-operaties (Create, Read, Update, Delete) voor een bepaald businessobject als “Persoon” of “Order” bieden. Deze procedures benaderen op hun beurt databaseobjecten in het applicatieschema die de CRUD-operaties daadwerkelijk implementeren.

SQL-objecttype

Een SOA API-procedure heeft businessobjecten als inputparameters en/of als outputparameters. Bijvoorbeeld een HAALOP_MEDEWERKER-procedure heeft als outputparameter een MEDEWERKER-object. Dit object wordt in het SOA API-schema gedefinieerd met behulp van een SQL-objecttype. Kortom, SQL-objecttypes worden gebruikt voor input- en outputparameters van SOA API-procedures. Oracle-databaseadapters kunnen hier goed mee omgaan, beter dan met bijvoorbeeld PL/SQL-recordtypes.

Objectview

In een SOA API-procedure worden vaak query’s op relationele tabellen en views van het applicatieschema uitgevoerd. Het resultaat van deze query’s moet dan worden overgezet naar een outputparameter van een bepaald SQL-objecttype. Het is echter ook mogelijk om gebruik te maken van zogenaamde objectviews op de relationele tabellen en views van het applicatieschema. Hierdoor blijkt de SOA API-procedure aanzienlijk eenvoudiger te worden.

Bovenstaande wordt hieronder verder toegelicht aan de hand van een voorbeeld.

Voorbeeld: Medewerker-service op bestaande Oracle-database

Stel dat een HRM-applicatie is geïmplementeerd als Oracle-databaseapplicatie en dat we functionaliteit rond medewerkers beschikbaar willen stellen aan andere applicaties. In onderstaande figuur wordt aangegeven welke componenten nodig zijn in de verschillende lagen om bijvoorbeeld CRUD-operaties voor businessobject “Medewerker” beschikbaar te stellen op OSB.

Overzicht componenten in OSB en database

De componenten in de figuur worden hieronder kort besproken.

Applicatietabellen “HRM_MEDEWERKERS”, “HRM_ADRESSEN”, etc.

Het HRM-applicatieschema bevat de bestaande functionaliteit rond medewerkers. Tabel HRM_MEDEWERKERS bevat de kerngegevens van medewerkers. Meestal hoort hier nog een aantal tabellen bij die aan medewerkers gerelateerde gegevens bevatten, bijvoorbeeld tabel HRM_ADRESSEN. Ook kan een aantal PL/SQL-packages aanwezig zijn die medewerker-gerelateerde functionaliteit implementeren.

De bestaande functionaliteit in de medewerker-gerelateerde tabellen, views en packages wordt via het HRMSOA API-schema beschikbaar gesteld op OSB.

Canoniek objecttype “MedewerkerCOT”

MedewerkerCOT bevat de canonieke definitie van businessobject “Medewerker” en is onderdeel van het CDM. De attributen van een canoniek objecttype kunnen ook zijn gebaseerd op een canoniek objecttype of canoniek datatype (CDT), zoals geschetst in het volgende plaatje.

Canonieke objecttype

De attributen van onderliggende canonieke datatypes kunnen op hun beurt weer zijn gebaseerd op canonieke datatypes, zodat een complexe hiërarchische definitie kan ontstaan. MedewerkerCOT en onderliggende CDT’s worden “geïmplementeerd” als XSD.

Canonieke businessservice “MedewerkerCBS”

MedewerkerCBS is de canonieke businessservice die de CRUD-operaties voor businessobject “Medewerker” beschikbaar stelt op OSB. Deze service heeft een aantal serviceoperaties die de CRUD-operaties implementeren zoals haalopMedewerker (R) en voeropMedewerker (C). MedewerkerCBS wordt geïmplementeerd als OSB proxy service.

De serviceoperaties maken gebruik van MedewerkerCOT voor hun input- en outputobjecten, zoals bijvoorbeeld hieronder geschetst voor serviceoperatie haalopMedewerker van service MedewerkerCBS:

MedewerkerCBS.haalopMedewerker Objectnaam Datatype
Inputobject medewerkerId string
Outputobject medewerker MedewerkerCOT

Op implementatieniveau betekent dit dat MedewerkerCOT.xsd wordt geïmporteerd in MedewerkerCBS.wsdl.

Applicatieconnectorservice “HRMhaalopMedewerker”

Voor elke serviceoperatie van MedewerkerCBS is een applicatieconnectorservice nodig voor de connectie naar de HRM-applicatie om daarin de juiste functionaliteit te benaderen. Voor bijvoorbeeld serviceoperatie haalopMedewerker is applicatieconnectorservice HRMhaalopMedewerker nodig.

HRMhaalopMedewerker wordt geïmplementeerd als OSB business service, die wordt gegenereerd op basis van een databaseadapter. Deze databaseadapter benadert packaged procedure HRMSOA_MDW.HAALOP_MEDEWERKER in het HRMSOA API-schema.

SQL-objecttype “HRMSOA_MEDEWERKER_OT”

HRMSOA_MEDEWERKER_OT bevat de definitie van businessobject “Medewerker” in het HRMSOA API-schema. Voor SOA API-objecttypes wordt aangeraden om de definitie zoveel mogelijk 1-op-1 over te nemen van de canonieke definitie van het gerelateerde businessobject in het CDM. Dit bespaart ontwerptijd en beperkt de transformaties tussen canoniek en applicatiespecifiek formaat tot een minimum.

Dit betekent dat HRMSOA_MEDEWERKER_OT zoveel mogelijk 1-op-1 wordt overgenomen van MedewerkerCOT. Voor eventuele onderliggende canonieke datatypes worden dan ook corresponderende SQL-objecttypes gedefinieerd, zoals bijvoorbeeld hieronder geschetst.

create or replace type hrmsoa_medewerker_ot as object
( id     varchar2(10)
, naam   varchar2(100)
, adres  hrmsoa_adres_ot
, ...
)

create or replace type hrmsoa_adres_ot as object
( straat      varchar2(10)
, huisnummer  varchar2(25)
, postcode    varchar2(25)
, ...
)

PL/SQL-package “HRMSOA_MDW”

PL/SQL-package HRMSOA_MDW is het package dat de CRUD-operaties voor businessobject “Medewerker” beschikbaar stelt in het HRMSOA API-schema. Dit package bevat een aantal procedures die de CRUD-operaties implementeren zoals HAALOP_MEDEWERKER (R) en VOEROP_MEDEWERKER (C). Deze packaged procedures corresponderen met de serviceoperaties van MedewerkerCBS op OSB.

De packaged procedures maken gebruik van HRMSOA_MEDEWERKER_OT voor hun input- en outputparameters, zoals bijvoorbeeld hieronder geschetst voor procedure HAALOP_MEDEWERKER van package HRMSOA_MDW:

HRMSOA_MDW.HAALOP_MEDEWERKER Objectnaam Datatype
Inputparameter P_MEDEWERKER_ID VARCHAR2
Outputparameter P_MEDEWERKER HRMSOA_MEDEWERKER_OT

Objectview “HRMSOA_MEDEWERKERS_OV”

In de procedurebody van HRMSOA_MDW.HAALOP_MEDEWERKER worden de medewerkergegevens opgehaald. Hiervoor kan handig gebruik worden gemaakt van een objectview. Het resultaat van een query van een objectview is namelijk een verzameling objecten van een SQL-objecttype. Daardoor kan dit resultaat veel gemakkelijker worden toegekend aan de outputparameter van de procedure, die immers ook van een SQL-objecttype is.

Hieronder staat een fragment van de definitie van objectview HRMSOA_MEDEWERKERS_OV.

create or replace view hrmsoa_medewerkers_ov
of                     hrmsoa_medewerker_ot
with object identifier (id)
as
select mdw.id
,      mdw.naam
,      hrmsoa_adres_ot -- woonadres
          ( adr.straat
          , adr.huisnummer
          , adr.postcode
          , ...
          )
, ...
from   hrm_medewerkers  mdw
,      hrm_adressen     adr
,      ...
where  mdw.id = adr.mdw_id
and    adr.adres_type = ‘WOONADRES’
and    ...

Hieronder wordt geschetst hoe in de procedurebody van HRMSOA_MDW.HAALOP_MEDEWERKER van deze objectview gebruik kan worden gemaakt.

select value( mdw )
into   p_medewerker
from   hrmsoa_medewerkers_ov  mdw
where  mdw.id = p_medewerker_id

Het resultaat van de query van objectview HRMSOA_MEDEWERKERS_OV is een object van objecttype HRMSOA_MEDEWERKER_OT. Dit resultaat kan direct worden toegekend aan outputparameter p_medewerker omdat deze van hetzelfde objecttype is. In feite implementeert de objectview een object-relationele mapping tussen objecttypes en relationele tabellen/views.

Door gebruik te maken van objectviews hoeft de complexiteit van de object-relationele mapping maar één keer te worden geïmplementeerd. De objectview kan vervolgens op eenvoudige wijze worden hergebruikt in meerdere SOA API-procedures.

Conclusie

Met behulp van SOA kan bestaande functionaliteit worden hergebruikt door deze als services aan te bieden. Bij veel bedrijven is bestaande functionaliteit geïmplementeerd in Oracle-databaseapplicaties. In dit Whitebook heb ik laten zien hoe dergelijke applicaties kunnen worden “verserviced”, zodat nog steeds profijt kan worden getrokken van vroeger gedane investeringen in die applicaties.

Bij het verservicen kan een strakke aanpak worden gevolgd, waarbij de volgende, sterk aan elkaar gerelateerde componenten een rol spelen:

  • Applicatieschema met bestaande functionaliteit. Als herbruikbare businesslogica overigens nog in Oracle Forms is geïmplementeerd, wordt aangeraden deze naar het applicatieschema te verplaatsen.
  • SOA API-schema voor ontsluiting van functionaliteit in het applicatieschema op OSB; bevat onder meer PL/SQL-packages, SQL-objecttypes en objectviews.
  • OSB proxy services en OSB business services die canonieke businessservices en applicatieconnectorservices op OSB implementeren.
  • XSD’s van canonieke objecttypes en canonieke datatypes die door canonieke businessservices op OSB worden gebruikt.

Het volgen van een dergelijke standaard aanpak geeft niet alleen duidelijkheid over wat er moet gebeuren, het maakt het ook gemakkelijker om in te schatten hoeveel tijd, geld en mensen hiervoor nodig zijn. We hebben dit onlangs succesvol toegepast bij een van onze klanten, waar we bestaande functionaliteit in een grote Oracle-databaseapplicatie hebben ontsloten met behulp van services op OSB.

Referenties

Gebruikte afkortingen

  • ACS: Applicatieconnectorservice
  • API: Application Programming Interface
  • CBS: Canonieke businessservice
  • CDM: Canoniek datamodel
  • CDT: Canoniek datatype
  • CRUD: Create Read Update Delete
  • COT: Canoniek objecttype
Waardering:
 

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.