Follow Us on Twitter

Service Data Objects

September 2008 - De meeste applicaties verwerken gegevens. Meestal komen deze gegevens uit relationele databases, maar dit is lang niet altijd het geval. Gegevens kunnen ook voortkomen uit web services, object databases of andere systemen. Om toegang te krijgen tot die gegevens bestaan veel verschillende oplossingen. Alleen al voor relationele databases is er volop keuze: JDBC, Hibernate, JPA, Toplink, BC4J, etcetera. Elk hulpprogramma gebruikt een eigen programmeermodel.Slechts enkele raamwerken lenen zich voor toepassing in een servicegeoriënteerde architectuur. De juiste keuze maken is vaak lastig. Wil een programmeur effectief kunnen werken, dan moet hij kennis hebben van veel verschillende programmeerinterfaces. 

Je kunt je afvragen waarom deze programmeermodellen zo uiteenlopen. Het zou toch eigenlijk niet uit mogen maken waar de informatie vandaan komt. Ontwikkelen van software kan een stuk eenvoudiger indien er één programmeerinterface alle gegevensbronnen kan bedienen. Om dit probleem op te lossen is Service Data Objects (SDO) bedacht. SDO is voortgekomen uit een samenwerkingsverband tussen IBM en BEA met als doel tot een eenvoudig en eenduidig programmeermodel te komen voor verschillende types gegevensbronnen. Bovendien moet dit programmeermodel gebruikt kunnen worden in een servicegeoriënteerde architectuur. De specificaties van het programmeermodel en de programmeerinterfaces zijn gedeponeerd bij het open standaarden consortium OASIS. Er is ook een Java Specification Request (JSR 235) ingediend bij het Java Community Process om SDO onderdeel te maken van de Java programmeertaal. De behandelstatus van deze JSR is op dit moment ‘in progress’. Omdat SDO een open specificatie is kan het door iedereen geïmplementeerd worden. Momenteel is er een aantal implementaties van SDO beschikbaar, waarvan Apache Tuscany uit de open source hoek komt.

Het programmeermodel van SDO

Bij SDO is de programmeerinterface onafhankelijk van de gegevensbron. In principe kunnen alle mogelijke gegevensbronnen worden ondersteund. Het maakt dus niet uit of de gegevens komen uit een relationele database, web services, XML databases, object databases of EJB.

Het model van SDO bestaat uit een zogenaamde ‘data graph’. Dit object lijkt op een boomstructuur waarin de verschillende data objecten hangen. De data objecten bevatten de eigenlijke gegevens. Hierin kunnen ook referenties staan die verwijzen naar andere data objecten. Daarnaast bestaat er een wijzigingshistorie object (de zogenaamde ‘change summary’): alle mutaties op de dataobjecten worden hierin vastgelegd. Verder bevat de data graph meta gegevens. Deze is nodig om de eigenschappen in de verschillende data objecten te beschrijven zodat met behulp van XPath de eigenschappen zijn uit te lezen of te wijzigen.


Figuur 1: SDO data graph en data objecten

SDO streeft naar eenvoud in gebruik. In SDO kan op twee manieren worden geprogrammeerd. De eerste manier gaat uit van een dynamische interface: de typeringen van de eigenschappen en de structuur van de data objecten zijn van tevoren onbekend. Dit lijkt op het ophalen van gegevens middels een JDBC RowSet.

//ophalen van een property middels de dynamische   interface
book.getString(“title”);

Ook statische interfaces worden ondersteund. Hiervoor moeten van tevoren Java klassen worden gegenereerd. Dit is vergelijkbaar met de JAXB manier van programmeren. Statische interfaces zijn behulpzaam tijdens het programmeren (door middel van ‘code completion’). Een ander voordeel van statische interfaces is het kunnen controleren op juiste typering tijdens het compileren van de programmacode (‘type checking’).

//ophalen van een property middels de statische   interface
book.getTitle();

Een Data Access Service (DAS) is een programmeerinterface om gegevens op te halen en weg te schrijven. Hiervoor kunnen zoekopdrachten worden gedefinieerd. Nadat een data graph is gewijzigd kan deze via de DAS terug aan de gegevensbron worden aangeboden. Voor elk type gegevensbron bestaat een aparte implementatie:

  • EJB Data Access Service – ontsluiting van stateless session beans
  • Relational Data Access Service – koppeling met relationele databases
  • Virtual Data Access Service – combinatie van verschillende DAS services
  • Elke andere gegevensbron. Als er voor een bepaalde gegevensbron nog geen programmeerinterface bestaat kan hiervoor een implementatie geschreven worden.

Na het ophalen van de gegevens wordt de verbinding met de gegevensbron verbroken. Dit maakt SDO bij uitstek geschikt voor toepassing in een servicegeoriënteerde omgeving. Een data graph kan omgezet worden naar XML zodat via verschillende transportprotocollen verstuurd kan worden. De data graph fungeert dus als een soort transfer object. Na wijziging van de gegevens kunnen deze weer worden aangeboden aan de DAS. Om met de gegevensbron te synchroniseren wordt optimistische locking gehanteerd. Dit wil zeggen dat de wijziging wordt geweigerd als er een andere gebruiker is voor geweest. In dat geval dient de implementatie van de DAS deze conflicten afhandelen.

Hieronder een code fragment waarin met behulp van een DAS een object uit een database wordt gehaald, gewijzigd en vervolgens wordt teruggeplaatst.

public void testDataAccessService() throws SQLException, IOException{
	  //creëer een Data Access Service a.d.h.v. een SQL DataSource connection
	  DAS das = DAS.FACTORY.createDAS(getConnection());

	//voer een lees commando   uit op de database 
	Command readBook = das.createCommand("SELECT ISBN, TITLE,    
          PUBLISHED FROM BOOK WHERE ID = 355");
	DataObject rootObject =   readBook.executeQuery();

	//controleer of het juiste object is opgehaald
	  DataObject book = rootObject.getDataObject("BOOK[1]");
	assertEquals("0201835959",   book.getString("ISBN"));

	//wijzig de titel en plaats het terug in de   database
	book.setString("TITLE", "The Mythical Man-Month");
	  das.applyChanges(rootObject);
}

Bijzonder aan SDO is dat applicaties kunnen omgaan met verschillende versies van een data object. Zo zal een applicatie dat ontwikkeld is aan de hand van een oude versie van het data object informatie dat hij niet herkent negeren. Andersom kan ook: applicaties kunnen met een oudere versie van een data object werken.

  Programmeermodel Programmeerinterface Gegevensbron
  Connected Disconnected Statisch Dynamisch Relationele DB XML Object DB
JDBC RowSet X     X X    
JDBC CachedRowSet   X   X X    
JPA / Hibernate X   X   X    
JDO X   X   X   X
DOM / SAX       X   X  
JAXB / JAX-RPC     X     X  
SDO   X X X X X X

Tabel 1: Vergelijking tussen verschillende technologieën

 

Oracle's visie op SDO

Volgens een White Paper van Oracle getiteld ‘Programming Loosely Coupled Data Oriented Systems in Java’ uit oktober 2006 is Oracle van plan om een volledige implementatie van SDO uit te brengen. Inmiddels zijn we twee jaar verder en is hiervan nog weinig zichtbaar. De technology preview van SOA Suite 11g maakt het mogelijk om SDO services gebruiken in een SCA composiet. Een SDO service kan gemaakt worden door een web service laag te creëren op ADF Business Components via een Application Module. Dit is waarschijnlijk slechts het begin. Door de recente overname van BEA beschikt Oracle nu over een behoorlijk complete implementatie. Te verwachten is dat Oracle de meeste BEA features, waaronder de DAS implementaties, zal opnemen in JDeveloper 11g. 


Figuur 2: SCA in combinatie met SDO

Conclusie

Met SDO krijgen we er weer een keuzemogelijkheid bij voor het ontsluiten van gegevensbronnen. Maar het is er wel één die andere overbodig maakt. Hoewel onder water technologieën als JAXB en ADF-BC nog steeds zullen worden gebruikt, zal het voor ontwikkelaars niet meer nodig zijn om kennis over deze en andere technologieën te hebben. Doordat alle gegevensbronnen op dezelfde manier geprogrammeerd kan worden zal het ontwikkelen software een stuk eenvoudiger worden.

En daarmee komen we meteen bij een nadeel. Dat er zo veel mogelijkheden zijn heeft een reden. Elk raamwerk biedt een oplossing voor een specifiek probleem in een bepaald toepassingsgebied. Zo levert Hibernate naast de object-relational mapping ook lazy loading, uitgebreide zoekmogelijkheden en validatie. Als in een applicatie deze dingen echt nodig zijn en er is geen behoefte aan flexibiliteit om van gegevensbron te kunnen veranderen dan is SDO niet de juiste keuze. De extra interface laag en features zal een negatieve invloed hebben op de performance.
Een andere tekortkoming van SDO is dat het alleen informatie bevat. Volgens de benadering van het objectgeoriënteerde programmeren moet elk object naast informatie ook gedrag hebben. Vaak heeft een applicatie een domein laag voor de bedrijfslogica: validatie, bedrijfsregels, eventing. SDO data graphs zullen voor toepassing in een domein laag vertaald moeten worden naar domein objecten. Een dergelijke vertaling kan bij complexe objecten zeer ingewikkeld zijn.

Toch is het in veel situaties een goed idee om SDO te gebruiken. Door een applicatie onafhankelijk te maken van de gegevensbron zal deze beter onderhoudbaar zijn. Als men besluit om in een bestaand systeem van gegevensbron te veranderen (bijvoorbeeld door de relationele database te vervangen door een web service) zal er zonder een ontkoppeling de programmacode grondig moeten wijzigen. Het maakt namelijk nogal wat uit of je te maken hebt met JDBC code of moet uitgaan van JAXB objecten. Bij SDO moet er alleen een andere DAS implementatie gekozen worden. Verder maakt de ingebouwde functionaliteit om wijzigingen te registreren samen met de onafhankelijkheid van gegevensbron SDO uitermate geschikt voor toepassing in een servicegeoriënteerde omgeving.

Referenties

Over de auteur
Jos Nieuwenhuis is werkzaam als Java / SOA Software Architect. Hij combineert ruime ervaring op het gebied van enterprise Java met uitgebreide kennis van integratie en SOA architecturen en oplossingen.

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.