Blog

/ Archive by category "Blog"
SCJP upgrade examen: Java 8

SCJP upgrade examen: Java 8


Dennis van Loon

Java bestaat ondertussen alweer twintig jaar. Sinds maart 2014 hebben we Java 8 en Java 9 staat voor volgend jaar op de agenda. Voor Java Developers zijn er verschillende certificaten die je kunt halen, deze zijn uiteraard gebonden aan een specifieke versie.

Zelf werk ik nu ongeveer 15 jaar met Java. In de eerste jaren heb ik twee Java certificaten behaald SCJP 1.4 (2003) en SCWCD xx (2004). In de jaren er na heb ik meerdere keren overwogen mijn SCJP (Sun Certified Java Programmer) te upgraden naar het huidige OCP (Oracle Certification Program) maar tot op heden was dat er niet van gekomen, er zijn tenslotte altijd voldoende redenen waarom het niet goed uitkomt. Bovendien zijn er nog zoveel andere onderwerpen waar je je ook voor kunt certificeren (bijv. Spring).

Voorbereiden op het Java 8 upgrade examen

Met de komst van Java 8 in 2014 vond ik dat het nu echt tijd was voor een upgrade. Java 8 bevat veel nieuwe concepten zoals functionele interfaces, lambdas en streams. Een goed moment om na ruim 10 jaar die upgrade toch echt te gaan doen. Met de komst van Java 9 in zicht besloot ik eind vorig jaar dat het nu tijd was. Maar hoe te beginnen als je nog geen enkel project met Java 8 hebt gedaan?

Op de website van Oracle is te zien dat er verschillende mogelijkheden zijn om OCP Java 8 te worden. Een daarvan is het upgrade examen vanaf Java 6 of eerder. Verder is te vinden wat de onderwerpen zijn die onder dit examen vallen. Je kunt natuurlijk op basis hiervan je studiemateriaal bij elkaar zoeken en van start gaan. Ik vind het makkelijker om een boek te pakken waarin alle onderwerpen worden behandeld.

Ik ben aan de slag gegaan met het boek ‘Oracle Certified Professional Java SE 8 Programmer II Study Guide’ van ‘Jeanne Boyarsky’. Primair is dit boek gericht op het huidige certificeringstraject waarbij je eerst OCA haalt en dan OCP. Het is echter ook bruikbaar voor dit upgrade examen. In het begin van het boek staat een tabel waarin per objective staat aangegeven in welke hoofdstuk dit wordt behandeld. Deze indeling is helaas vrij grof, er zijn geen specifieke paragrafen per onderwerp binnen de hoofdstukken.

Als je de tabel bekijkt zie je dat je voor het upgrade examen 1Z0-809 geldt dat:

  • Het eerste en laatste hoofdstuk niet relevant zijn (Advanced Class Design en JDBC).
  • Hoofdstuk 2 en 6 slechts één keer in de lijst voorkomen. Zelf heb ik er voor gekozen om hoofdstuk 2 wel te bestuderen en hoofdstuk 6 over te slaan.
  • Er een Appendix is met extra materieel die specifiek is voor dit upgrade examen. Heel vreemd maar deze appendix is echt relevant voor het examen.

Vervolgens ben ik in het boek gaan lezen, ieder hoofdstuk (behalve 1, 6, en 9) gevolgd voor de review vragen aan het eind. Daarna heb ik nog één keer alle review vragen van alle hoofdstukken geoefend.

Het examen

De volgende stap waren de online mock examens die bij het boek horen. Hier zitten uiteraard ook vragen bij van onderwerpen die buiten scope zijn voor het upgrade examen. Bovendien is het moeilijk in te schatten in hoeverre deze oefen examens een goed beeld geven van wat je kunt verwachten bij het upgrade examen.

Om een goed beeld te krijgen wat je echt kun verwachten op het examen zijn er verschillende mogelijkheden zoals whizlabs en enthuware waar je oefenexamens kunt kopen.

Zelf heb ik gekozen voor de Enthuware mocks die specifiek zijn voor dit examen. Voor een klein bedrag heb je dan 5 examens (300 vragen). Het bleek als snel dat de focus in deze mock examens toch een andere is dan in de mock examens van het boek. Deze enthuware mock examens blijken uiteindelijk veel meer op het echte examen te lijken. Wat bovendien een groot voordeel is dat er bij de vragen veel uitleg staat. Goed oefenen met deze vragen is een absolute must. Het is noodzakelijk dat je deze vragen goed begrijpt.

Eind november heb ik examen gedaan en geslaagd met een score van 80%. Ondanks een goede voorbereiding bleek het zeker geen makkelijk examen.

Welke onderwerpen bleken van belang?

Als ik achteraf naar de hoofdstukken in het boek kijk zou ik het volgende zeggen:

Hoofdstuk 2: Design Patterns and Principles
Zoals al aangegeven is dit hoofdstuk van beperkt belang. Wel kun je vragen tegen komen over de eerste paragrafen (tot aan ‘Working with Design Principles’).

Hoofdstuk 3: Generics and Collections
Generics en collections worden natuurlijk op vele punten binnen het examen gebruikt. Ik heb geen vragen gehad over de minder gebruikte types in de Collections API (Queue, NavigableSet). Ook het verschil tussen Comparable en Comparator kwam nauwelijks aan bod. Een onderdeel om goed te bestuderen is ‘Additions in Java 8’.

Hoofdstuk 4: Functional Programming
Dit hoofdstuk is van het begin tot het eind absoluut relevant. Eigenlijk kun je alles wat hier genoemd wordt wel verwachten op het examen. De oefenexamens van enthuware geven een goed beeld van het type vragen dat je kunt verwachten. Grondige kennis van dit hoofdstuk is absoluut noodzakelijk!

Hoofdstuk 5: Dates, String and Localization
Ook voor dit hoofdstuk geldt dat alles wat er in staat relevant is. Conceptueel is dit hoofdstuk ook wat makkelijker dan het voorgaande hoofdstuk.

Ik kreeg een aantal vragen over het gebruik van ResourceBundles in combinatie met Locale. Ook de manieren waarop je Locale objecten kunt maken, en het gebruik van NumberFormat en CurrencyFormat werd getest. Wat me wel opviel is dat ik geen vragen kreeg over de java variant van ResourceBundles.

Al met al kreeg ik over dit hoofdstuk wat minder vragen dan ik verwacht had. Toch is het zeker de moeite dit hoofdstuk goed te leren, het zijn relatief makkelijk te halen punten.

Hoofdstuk 6: Exceptions and Assertions
Dit hoofdstuk had ik in eerste instantie niet bestudeerd. Bij het oefenen met de mock examens bleek echter dat de volgende onderwerpen wel degelijk aan de orde komen:

  • Multi catch
  • Try with resources
  • Autoclosable

Uiteindelijk heb ik het hoofdstuk toch bestudeerd (tot aan Assertions). Dit bleek nuttig, ook op het examen kwamen de genoemde onderwerpen aan de orde.

Hoofdstuk 7: Concurrency
Dit hoofdstuk is conceptueel weer een wat lastiger hoofdstuk. In mijn geval geldt wel dat ik in de praktijk recentelijk weinig met dit onderwerp heb gedaan zodat ik het hele hoofdstuk grondig heb moeten bestuderen. Eigenlijk komen alle onderwerpen in dit hoofdstuk wel voor in het examen. Wel vond ik de vragen vaak redelijk oppervlakkig. Zo werd bij mij bij een Fork Join task alleen gevraagd wat er gebeurd als je de Fork en Join omdraait. Ook de CyclicBarrier kwam voor maar ook deze was niet al te moeilijk.

Hoofdstuk 8: IO
In het examen kwamen wel een aantal vragen terug over dit hoofdstuk, vaak in combinatie met exception handling. Uiteindelijk kreeg ik over dit onderwerp toch minder vragen dan ik verwacht had. Het stuk over het console aan het eind van het hoofdstuk kwam bijvoorbeeld niet aan bod.

Hoofdstuk 9: NIO.2
Dit is een belangrijk hoofdstuk waar op mijn examen behoorlijk wat vragen uit kwamen. Conceptueel is dit weer een makkelijker hoofdstuk, het bevat echter wel veel details waar naar gevraagd kan worden. Ook hier geldt weer dat de mock examens van enthuware een goed beeld gaven van wat je kunt verwachten.

Appendix C: Upgrading from Java 6 or earlier
Het lijkt vreemd maar Oracle heeft besloten dat in dit specifieke upgrade examen (xxx) een aantal onderwerpen zijn opgenomen die niet in het regulier OCP examen zitten. Deze onderwerpen staan beschreven in deze Appendix. Het bevat een aantal extra onderdelen voor Localization, Concurrency en NIO.2. Vergeet deze appendix niet, alle onderwerpen die hier worden behandeld kwamen bij mij ook echt voor op het examen.

Conclusie

Al met al is het upgrade examen zeker geen makkelijk examen. Ook als je al jaren met Java werkt moet je nog even goed moeten studeren alvorens het examen te doen. In mijn geval kwam daar nog bij dat ik geen Java 8 ervaring had.

Het boek is echter uitstekend als studiemateriaal. Zelf heb ik gebruik gemaakt van de digitale versie via iBooks. Op zich is dat makkelijk maar er waren wel wat dingen om rekening mee te houden:

  • Copy paste van tekst uit het boek is niet mogelijk. Dus stukjes code even in je IDE kopiëren is er niet bij.
  • Printen wordt niet ondersteund.
  • De antwoorden op de vragen bij een hoofdstuk staan achter in het boek. Bij de antwoorden staan de vragen echter niet herhaald. Dit levert veel onhandig heen en weer geblader op.

Gezien het feit dat dit upgrade examen al veel materie bevat is het denk ik aan te raden dit examen te doen en niet te wachten tot bijvoorbeeld Java 9. Java 9 zal ongetwijfeld ook weer het nodige toevoegen.

Ik heb me in ieder geval voorgenomen vanaf nu netjes per versie te upgraden.

Een introductie in Apache NiFi

Een introductie in Apache NiFi


Marcel-Jan Krijgsman

Voor een aantal Open Circle collega’s is Apache NiFi niet meer volledig nieuw maar omdat het een relatief nieuw product betreft dat nog in ontwikkeling is leek het me goed om er vanaf de basis in te duiken. Daarnaast komt NiFi steeds vaker naar voren bij opdrachtgevers. In deze blog neem ik je mee in mijn eerste ervaringen met Apache NiFi.

Er zijn erg veel data gerelateerde Apache producten beschikbaar en het is lastig om ze allemaal te volgen. Er zijn verschillende producten voor data “streaming” of “flowing”: Kafka, Storm, Flink en NiFi. Natuurlijk hebben al deze producten een documentatie maar voor een buitenstaander klinken de beschrijvingen als “enterprise schaalbare streaming oplossingen”, iets wat velen weinig zal zeggen.

DataWorks Summit München

Bij de DataWorks Summit in München afgelopen maand volgde ik een crash course in Apache NiFi en ik was behoorlijk onder de indruk. Vanuit mezelf ben ik meer van de command line maar deze grafische interface ziet er erg gelikt uit en het is fantastisch wat je allemaal kan doen om uit te vinden waar je data naartoe gaat met NiFi. Omdat ik zo onder de indruk was zal ik binnenkort ook een interne workshop geven voor mijn collega’s hier bij Open Circle Solutions.

Apache NiFi

Met NiFi kun je programmeren waar je data vandaan komt, wat ermee gebeurt en waar deze naartoe gezonden wordt. Bijvoorbeeld; er komt wat data binnen in JSON formaat vanaf IoT apparaten, mobiele apps sturen een XML, er zijn server logs en daarnaast importeer je Twitter data. Dit zijn dan je “data producenten” en je wil dat deze data naar verschillende “data consumenten”, zoals databases, Hadoop clusters en applicaties stroomt. Met NiFi kun je beschrijven waar data vandaan komt, geconverteerd wordt, gesplit wordt en hoe dit naar de consument gezonden wordt. Dit wordt de “data routing” genoemd.

Hieronder zie je hoe dit eruit ziet. Dit werkt met drag and drop processors om data te ontvangen, converteren en verzenden.

nifi_interface0

Er zijn vele soorten processors. Je kunt bestanden ontvangen, lezen van Twitter of Kafka, SQL op een database draaien, (un)compressen van bestanden, data verzenden via SFTP of bestanden verwijderen in Hadoop. Er zijn zelfs zoveel processors dat er een zoekveld is om deze snel te vinden. Hieronder zocht ik op “DB”.

nifi_interface2

Hieronder zie je een resultaat van een demo die ik gedaan heb. De grotere witte rechthoeken in de afbeelding zijn processors. De kleinere rechthoeken die met lijnen verbonden zijn in de processors beschrijven de connectie. Linksboven start mijn flow met een processor type genaamd “GetFile”, deze gebruik ik om een zip bestand te lezen. Dit maakt een connectie met een UnpackContent processor om de XML bestanden in deze zip bestanden uit te pakken.

nifi_interface1

Om ervoor te zorgen dat ik de rest van mijn systeem niet overbelast heb ik een ControlRate processor toegevoegd die de hoeveelheid bestanden of bytes dat verzonden wordt beperkt. Van daaruit lezen de blauwe onderdelen de XML en verkrijgen ze de attributen die ik wil en verzenden deze naar andere processors.

Een van de sterkste punten van NiFi is de debug informatie. Stel dat bepaalde data wel doorkomt maar niet correct verwerkt wordt, je kunt een processor dan inspecteren en “Data Provenance” kiezen.

nifi_interface3

Hier zie je al de recente “flow files” die doorkomen. Je hebt hier een zoekoptie om voor specifieke data te zoeken.

nifi_interface4

Stel dat ik bijvoorbeeld wil weten hoe deze data doorgekomen is. Met de pijltjes rechts in beeld kun je zien waar de data naartoe gegaan is. Dit heet de “data lineage”.

nifi_interface6

Hier kun je nog meer data verkrijgen over hoeveel tijd het gekost heeft of… welke attributen de data had.

Hier zag ik de URL die door een eerdere processor gevormd is en kon ik dus proberen of er iets mis mee was. Het bleek dat Google had gemeld dat ik mijn dagelijkse quotum voor de Google Places API bereikt had. Hierdoor werkte de rest van mijn flow niet correct.

nifi_interface7

Voor goede beveiliging is weten waar je data is het belangrijkste. Met NiFi kun je dit vrij goed inrichten, het is tenslotte door de NSA ontwikkeld! Ik heb nog geen ervaring met de performance of splitsing van taken wat betreft NiFi maar daar kom ik in een latere blogpost op terug.

Wil je zelf NiFi ook eens uitproberen? Dat kan! Bijvoorbeeld met de Hortonworks Data Platform sandbox (beschikbaar als VirtualBox, VMWare of Docker image) en de Apache NiFi crash course. Zelf ben ik een tiental uren bezig geweest met het volgen van de tutorials 0,1,2 en 3 maar met mijn nieuwe blog waarin ik je door deze tutorials leid lukt het je hopelijk in ongeveer 4uur!

Dataworks Summit München 2017

Dataworks Summit München 2017


Marcel-Jan Krijgsman

Afgelopen week is Open Circle Solutions met een aantal collega’s afgereisd naar München voor de Dataworks Summit. Voor onze Data Engineer Marcel-Jan was dit zijn eerste open source / big data summit. Op zijn eigen blog vind je de uitgebreide beschrijvingen van de dagen en alle sessies waar we aanwezig waren:
Dag 1
Dag 2
Een korte samenvatting van de dagen en de verschillende onderwerpen die voorbij kwamen:

Dag 1

Na een aantal keynotes was het tijd voor de breakout sessies. Een aantal topics van deze dag:

  • De snelheid en mogelijkheden van Apache Hive (data warehouse infrastructuur gebouwd op Hadoop)
  • Het big data avontuur en de optimalisatie van Klarna (Zweedse aanbieder van betalingsoplossingen voor de e-commerce)
  • De aankomende Hadoop 3.0 release, wat kunnen we hiervan verwachten?
  • De updates van YARN (een platform voor het beheren van resources)
  • Een live demo van Apache Ranger (securitymanagement tool)

Aan het eind van dag 1 kwamen wij tot onder andere de volgende conclusies:

  • Het waren vooral de ontwikkelaars aan het woord waardoor inhoudelijke vragen gesteld konden worden en duidelijk naar voren kwam dat input van gebruikers meegenomen is in de nieuwe updates.
  • We hebben vertrouwen in de mogelijkheden die zorgen dat Hadoop en je data ook in de toekomst veilig gehouden kan worden.
  • De argumenten van critici tegenover Hadoop zullen weggenomen worden door de nieuwe ontwikkelingen.

De dag werd traditioneel afgesloten met Beer Garten party als prettige afsluiting en ontspanningsmoment na een intensieve dag.

Dag 2

Na een aantal keynotes (waarin onder andere de droom geschetst werd dat Artificial Intelligence ons ooit het gevoel kan geven dat we de hele dag op het strand zitten) was het wederom tijd voor de breakout sessies. Een aantal topics van dag 2:

  • Marcel-Jan woonde een crash course Apache NiFi bij, een nog jong software project dat de data flow tussen o.a. apparaten, gebruikers, servers en systemen mogelijk maakt en de mogelijkheid biedt om de data te volgen.
  • Real-time analytics van security-events en machine learning voor een bank.
  • Best practices voor architectuur en deployment

De summit bevatte veel technische onderwerpen, teveel om allemaal bij elkaar in 1 blog te beschrijven. We zullen daarom in latere blogs dieper ingaan op een aantal van deze onderwerpen!

JBoss Data Virtualization: Het stapelen van constraints en hoe ze worden toegepast op de database

JBoss Data Virtualization: Het stapelen van constraints en hoe ze worden toegepast op de database

Het stapelen van constraints en hoe ze worden toegepast op de database
Bas Piepers

In een vorig blog artikel hebben we gezien hoe we de security modules van het JBoss Enterprise Application Platform (EAP) konden gebruiken voor het mappen van technische rollen die we konden gebruiken in de Virtuele Database (VDB) in JBoss Data Virtualization (JDV). In dit blog artikel gaan we een eigenschap van de engine in JDV behandelen die eenvoudig over het hoofd gezien wordt maar die toch erg belangrijk is als je VDB’s ontwikkeld voor klanten. We zullen zien wat het verschil in gedrag is wanneer je beperkingen op een tabel legt in hetzelfde view model en wanneer je dit doet op dezelfde tabel maar in verschillende view modellen.

Aangezien dit blog artikel zeer specifiek is gericht op JDV en de bijbehorende Teiid Designer wordt verwacht dat de lezer enige ervaring heeft met deze producten. Voor een introductie in deze producten kun je hier een kijkje nemen.

Gebruikte versies: JBoss Data Virtualization 6.3 Update 3 en JBoss Developer Studio versie 9 met Teiid Designer 10.0.2.Final. Het is, uiteraard, mogelijk om andere versies van de producten te gebruiken echter kan met name de interface van Teiid Designer er anders uit zien.

Voorbeeldschets

Voor dit voorbeeld hebben we een zeer eenvoudige VDB gemaakt die slechts één tabel bevat. De tabel bevat verkopen van gebouwen in Engeland en Wales en is opgeslagen in een PostgreSQL database. Deze tabel is vervolgens geïmporteerd in de VDB met de Teiid Designer.

Bij het ontwikkelen van VDBs voor klanten houd ik over het algemeen een drie-lagen ontwerp aan. Het is goed gebruik om view modellen te scheiden van source modellen en het geeft me de mogelijkheid om een abstractie laag aan te brengen tussen de source modellen, die eenvoudigweg imports zijn van de onderliggende datastructuren, en de bovenliggende view modellen. De view modellen bevatten de transformaties, joins, constraints en filters en bieden uiteindelijk een view aan zoals deze naar gebruikers wordt blootgesteld. Weet, overigens, dat de hoeveelheid modellen die je gebruikt om je VDB te modelleren geen invloed heeft op de prestatie of snelheid waarmee de queries worden uitgevoerd. Er is dus geen reden om niet meerdere modellen te gebruiken en we zullen in dit artikel ook zien dat het soms simpelweg nodig is om meerdere modellen te gebruiken voor dezelfde entiteiten.

Voor het voorbeeld van dit artikel hebben we ook het drie-lagen principe toegepast zodat we kunnen demonstreren wat het gedrag is van de engine wanneer we op eenzelfde tabel beperkingen opleggen maar in verschillende rollen. We hebben de volgende structuur gebruikt in Teiid Designer:

JBoss Data Virtualization 1

Er is één source model genaamd “psql_test_src” die we gebruiken om de tabel te importeren uit de PostgreSQL database. Vervolgens is er een model genaamd “properties_vbl” in “virtual-base-layer”. De virtual base layer bevat over het algemeen een één-op-één representatie van het onderliggende source model maar kan ook al transformaties, constraints en joins bevatten. In dit voorbeeld, echter, is het gewoon een import van “psql_test_src”. Tot slot hebben we nog het properties_edl model dat in ons geval ook slechts de property_sales tabel bevat zoals deze ook in de virtual base layer zit. We gebruiken de modellen in de enteprise-data-layer om naar gebruikers toe te ontsluiten.
De VDB ziet er nu als volgt uit:

JBoss Data Virtualization 2

Aan de VDB voegen we drie rollen toe: BROKER, ASSISTANT en JUNIOR. Zij representeren een fictieve situatie van een bedrijf dat op basis van deze rollen al dan niet beperkingen wil opleggen aan gebruikers. De drie rollen hebben allemaal leesrechten op de property_sale tabel in het properties_edl model. We zullen echter wel beperkingen (constraints) voor twee rollen toevoegen zoals we nu zullen laten zien.

Eerst voegen we de BROKER rol toe aan de VDB. We gebruiken hiervoor het JBoss Data Virtualization 3 icoon en geven het een naam. Verder zorgen we ervoor dat deze rol leesrechten heeft voor de property_sales tabel in het properties_edl model:

JBoss Data Virtualization 4

We mappen de bijbehorende enterprise rol in het tabblad “Mapped Enterprise Role or Group”:

JBoss Data Virtualization 5

We voegen verder geen beperkingen toe aan deze rol.
Vervolgens voegen we de ASSISTANT rol toe, koppelen deze aan de ASSISTANT enterprise rol en geven het leesrechten op dezelfde tabel uit hetzelfde model als de BROKER rol. Ditmaal, echter, voegen we ook een filter toe. We gebruiken hiervoor de “Row Filter” tab:

JBoss Data Virtualization 6

We willen dat deze rol enkel records ziet waarbij de kolom “Data Of Transfer” (dot) een waarde bevat die groter is dan 1 januari 2016. De constraint is dus als volgt:

dot >= PARSETIMESTAMP(‘2016-01-01 00:00:00’, ‘yyyy-MM-dd HH:mm:ss’)

Tot slot voegen we de JUNIOR rol toe, koppelen het aan de JUNIOR enterprise rol en geven het ook leesrechten op de property_sales tabel in het properties_edl model. We willen voor deze rol dat gebruikers enkel records zien uit het LONDON district. Daartoe voegen we de volgende beperking toe in de filters van deze rol:

JBoss Data Virtualization 7

De conditie heeft de volgende waarde:

district like ‘%LONDON%’

Aangezien we voor dit voorbeeld verder geen security modules gebruiken, gebruiken we de standaard inlog modules die worden geleverd bij het product. We voegden rollen toe aan het bestand: application-roles.properties. Verder maakten we een paar gebruikers aan zodat we de volgende gebruikers en rollen hebben in het hiervoor genoemde bestand:

Bas=BROKER
John=JUNIOR
Charly=JUNIOR,ASSISTANT
Ben=ASSISTANT

De rollen uit dit bestand corresponderen met de “Enterprise Roles” zoals we die voor onze VDB hebben gekoppeld.

Hoe de JDV engine de constraints interpreteert

Nu we alles gereed hebben voor ons voorbeeld kunnen we demonstreren wat er gebeurt als we verbinden met de VDB en queries uitvoeren. Omdat we verder geen wijzigingen hebben aangebracht aan de logging configuratie van JDV, vinden we de command logs in de standalone\logs directory in de locatie waar we JDV hebben geïnstalleerd. Het log bestand die we willen bestuderen heet:

teiid-command.log

Als we inloggen met gebruiker: “Bas”, kunnen we de property_sales records bekijken door de volgende query uit te voeren:

select * from properties_edl.property_sales;

Om te voorkomen dat we de hele tabel terugkrijgen in onze resultaat set hebben we de SQL cliënt die we gebruiken ingesteld met een limiet van 1000 records. De command log regels die we nu tegen komen als we bovenstaande query uitvoeren zijn als volgt (alleen relevante gedeelten worden getoond):

START USER COMMAND: (…) sql=select * from properties_edl.property_sales

START DATA SRC COMMAND: (…) sql=SELECT g_0.id AS c_0, g_0.tui AS c_1, g_0.price AS c_2, g_0.dot AS c_3, g_0.postcode AS c_4, g_0.ptype AS c_5, g_0.new1 AS c_6, g_0.duration AS c_7, g_0.paon AS c_8, g_0.saon AS c_9, g_0.street AS c_10, g_0.locality AS c_11, g_0.city AS c_12, g_0.district AS c_13, g_0.country AS c_14, g_0.ppd_cat AS c_15, g_0.record_status AS c_16 FROM psql_test_src.property_sales AS g_0 LIMIT 1000

SOURCE SRC COMMAND: (…) sourceCommand=[SELECT g_0.”id” AS c_0, g_0.”tui” AS c_1, g_0.”price” AS c_2, g_0.”dot” AS c_3, g_0.”postcode” AS c_4, g_0.”ptype” AS c_5, g_0.”new1″ AS c_6, g_0.”duration” AS c_7, g_0.”paon” AS c_8, g_0.”saon” AS c_9, g_0.”street” AS c_10, g_0.”locality” AS c_11, g_0.”city” AS c_12, g_0.”district” AS c_13, g_0.”country” AS c_14, g_0.”ppd_cat” AS c_15, g_0.”record_status” AS c_16 FROM “public”.”property_sales” AS g_0 LIMIT 1000]

END SRC COMMAND: (…)
END USER COMMAND: (…) finalRowCount=1000

De log statements beginnen met “START USER COMMAND”. Dit is de query zoals wij hem hebben ingegeven in de SQL client terwijl we ingelogd waren met gebruiker: “Bas”. De twee daar opvolgende regels zijn:

  • 1. Het “START DATA SRC COMMAND”: dit is de geoptimaliseerde query die zal worden gebruikt om de onderliggende database te bevragen.
  • 2. Het “SOURCE SRC COMMAND”: dit is de query zoals die daadwerkelijk naar de database gaat, in de syntax die wordt begrepen door de database.

In ons geval zijn de queries nagenoeg identiek aan elkaar omdat we verder geen constraints hebben toegevoegd in het model voor deze rol.

Als we hetzelfde doen voor de gebruikers John en Ben, dan zien we dat de engine de filters toevoegt die we voor de bijbehorende rollen hebben ingesteld. John is lid van de rol: JUNIOR en Ben is lid van de rol: ASSISTANT.
De command log regels van John:

START USER COMMAND: (…) sql=select * from properties_edl.property_sales

START DATA SRC COMMAND: (…) sql=SELECT g_0.id AS c_0, g_0.tui AS c_1, g_0.price AS c_2, g_0.dot AS c_3, g_0.postcode AS c_4, g_0.ptype AS c_5, g_0.new1 AS c_6, g_0.duration AS c_7, g_0.paon AS c_8, g_0.saon AS c_9, g_0.street AS c_10, g_0.locality AS c_11, g_0.city AS c_12, g_0.district AS c_13, g_0.country AS c_14, g_0.ppd_cat AS c_15, g_0.record_status AS c_16 FROM psql_test_src.property_sales AS g_0 WHERE g_0.district LIKE ‘%LONDON%’ LIMIT 1000

SOURCE SRC COMMAND: (…) sourceCommand=[SELECT g_0.”id” AS c_0, g_0.”tui” AS c_1, g_0.”price” AS c_2, g_0.”dot” AS c_3, g_0.”postcode” AS c_4, g_0.”ptype” AS c_5, g_0.”new1″ AS c_6, g_0.”duration” AS c_7, g_0.”paon” AS c_8, g_0.”saon” AS c_9, g_0.”street” AS c_10, g_0.”locality” AS c_11, g_0.”city” AS c_12, g_0.”district” AS c_13, g_0.”country” AS c_14, g_0.”ppd_cat” AS c_15, g_0.”record_status” AS c_16 FROM “public”.”property_sales” AS g_0 WHERE g_0.”district” LIKE ‘%LONDON%’ ESCAPE ” LIMIT 1000]

END SRC COMMAND: (…)
END USER COMMAND: (…) finalRowCount=1000

John’s query is aangepast: de engine heeft een WHERE-clausule toegevoegd met de filter die we hadden opgegeven voor zijn rol.
De command log van Ben:

START USER COMMAND: (…) sql=select * from properties_edl.property_sales

START DATA SRC COMMAND: sql=SELECT g_0.id AS c_0, g_0.tui AS c_1, g_0.price AS c_2, g_0.dot AS c_3, g_0.postcode AS c_4, g_0.ptype AS c_5, g_0.new1 AS c_6, g_0.duration AS c_7, g_0.paon AS c_8, g_0.saon AS c_9, g_0.street AS c_10, g_0.locality AS c_11, g_0.city AS c_12, g_0.district AS c_13, g_0.country AS c_14, g_0.ppd_cat AS c_15, g_0.record_status AS c_16 FROM psql_test_src.property_sales AS g_0 WHERE g_0.dot >= {ts’2016-01-01 00:00:00.0′} LIMIT 1000

SOURCE SRC COMMAND: (…) sourceCommand=[SELECT g_0.”id” AS c_0, g_0.”tui” AS c_1, g_0.”price” AS c_2, g_0.”dot” AS c_3, g_0.”postcode” AS c_4, g_0.”ptype” AS c_5, g_0.”new1″ AS c_6, g_0.”duration” AS c_7, g_0.”paon” AS c_8, g_0.”saon” AS c_9, g_0.”street” AS c_10, g_0.”locality” AS c_11, g_0.”city” AS c_12, g_0.”district” AS c_13, g_0.”country” AS c_14, g_0.”ppd_cat” AS c_15, g_0.”record_status” AS c_16 FROM “public”.”property_sales” AS g_0 WHERE g_0.”dot” >= ? LIMIT 1000]

END SRC COMMAND: (…)
END USER COMMAND: (…) finalRowCount=1000

Ook de query van Ben is aangepast: de WHERE-clausule bevat het filter van de rol waar Ben lid van is.
Gebruiker Charly is niet alleen lid van de JUNIOR rol, maar ook van de ASSISTANT rol. Als we inloggen als deze gebruiker en dezelfde query uitvoeren, resulteert dit in de volgende log regels:

START USER COMMAND: (…) sql=select * from properties_edl.property_sales

START DATA SRC COMMAND: (…) sql=SELECT g_0.id AS c_0, g_0.tui AS c_1, g_0.price AS c_2, g_0.dot AS c_3, g_0.postcode AS c_4, g_0.ptype AS c_5, g_0.new1 AS c_6, g_0.duration AS c_7, g_0.paon AS c_8, g_0.saon AS c_9, g_0.street AS c_10, g_0.locality AS c_11, g_0.city AS c_12, g_0.district AS c_13, g_0.country AS c_14, g_0.ppd_cat AS c_15, g_0.record_status AS c_16 FROM psql_test_src.property_sales AS g_0 WHERE (g_0.district LIKE ‘%LONDON%’) OR (g_0.dot >= {ts’2016-01-01 00:00:00.0′}) LIMIT 1000

SOURCE SRC COMMAND: (…) sourceCommand=[SELECT g_0.”id” AS c_0, g_0.”tui” AS c_1, g_0.”price” AS c_2, g_0.”dot” AS c_3, g_0.”postcode” AS c_4, g_0.”ptype” AS c_5, g_0.”new1″ AS c_6, g_0.”duration” AS c_7, g_0.”paon” AS c_8, g_0.”saon” AS c_9, g_0.”street” AS c_10, g_0.”locality” AS c_11, g_0.”city” AS c_12, g_0.”district” AS c_13, g_0.”country” AS c_14, g_0.”ppd_cat” AS c_15, g_0.”record_status” AS c_16 FROM “public”.”property_sales” AS g_0 WHERE g_0.”district” LIKE ‘%LONDON%’ ESCAPE ” OR g_0.”dot” >= ? LIMIT 1000]

END SRC COMMAND: (…)
END USER COMMAND: (…) finalRowCount=1000

Omdat Charly lid is van zowel de JUNIOR als ASSISTANT rol past de engine beide filters toe in de WHERE clausule. Merk echter op dat er tussen deze filters een OR-statement staat: de beperkingen worden dus niet opgeteld maar gescheiden van elkaar. Er zullen situaties zijn dat dit gedrag gewenst is. Bijvoorbeeld waar een gebruiker meer verantwoordelijkheden krijgt omdat er een aanvullende rol van toepassing is. In ons voorbeeld zou je kunnen stellen dat vanwege de ASSISTANT-rol de JUNIOR-rol overbodig is en dat Charly dus alleen de filter waar de “date of transfer” wordt gebruikt nodig heeft.

In de meeste situaties, echter, is dit gedrag juist ongewenst want het toevoegen van meerdere rollen waar constraints van toepassing zijn zou de hoeveelheid data die een gebruiker ziet juist meer moeten beperken in plaats van minder. Met andere woorden: als een gebruiker zowel de JUNIOR- als de ASSISTANT-rol heeft dan mag deze gebruiker enkel de verkopen uit het LONDON district zien én enkel verkopen van na 1 januari 2016. Om dit te bewerkstelligen moeten we de filter van één van de rollen toepassen op de property_sales tabel in een ander model.

In ons voorbeeld hebben we de target van de constraint aangepast zodat de JUNIOR rol verwijst naar properties_vbl.property_sales in plaats van naar properties_edl.property_sales:

JBoss Data Virtualization 8

Nu we de aanpassingen hebben doorgevoerd en de query opnieuw uitvoeren terwijl we zijn ingelogd als Charly ziet de logging er als volgt uit:

START USER COMMAND: (…) sql=select * from properties_edl.property_sales

START DATA SRC COMMAND: (…) sql=SELECT g_0.id AS c_0, g_0.tui AS c_1, g_0.price AS c_2, g_0.dot AS c_3, g_0.postcode AS c_4, g_0.ptype AS c_5, g_0.new1 AS c_6, g_0.duration AS c_7, g_0.paon AS c_8, g_0.saon AS c_9, g_0.street AS c_10, g_0.locality AS c_11, g_0.city AS c_12, g_0.district AS c_13, g_0.country AS c_14, g_0.ppd_cat AS c_15, g_0.record_status AS c_16 FROM psql_test_src.property_sales AS g_0 WHERE (g_0.district LIKE ‘%LONDON%’) AND (g_0.dot >= {ts’2016-01-01 00:00:00.0′}) LIMIT 1000

SOURCE SRC COMMAND: (…) sourceCommand=[SELECT g_0.”id” AS c_0, g_0.”tui” AS c_1, g_0.”price” AS c_2, g_0.”dot” AS c_3, g_0.”postcode” AS c_4, g_0.”ptype” AS c_5, g_0.”new1″ AS c_6, g_0.”duration” AS c_7, g_0.”paon” AS c_8, g_0.”saon” AS c_9, g_0.”street” AS c_10, g_0.”locality” AS c_11, g_0.”city” AS c_12, g_0.”district” AS c_13, g_0.”country” AS c_14, g_0.”ppd_cat” AS c_15, g_0.”record_status” AS c_16 FROM “public”.”property_sales” AS g_0 WHERE g_0.”district” LIKE ‘%LONDON%’ ESCAPE ” AND g_0.”dot” >= ? LIMIT 1000]

END SRC COMMAND: (…)
END USER COMMAND: (…) finalRowCount=204

De engine heeft de filters nu gescheiden door een AND-operator.

Conclusie

Dit blog artikel demonstreerde een klein maar belangrijk verschil in hoe JBoss Data Virtualization filters behandeld afhankelijk van waar deze worden gekoppeld in de modellen. Dit geeft weliswaar meer flexibiliteit maar maakt ook dat een ontwikkelaar zich bewust moet zijn van het gedrag van de engine. In veel gevallen zijn dergelijke verschillen helaas niet direct duidelijk en niet altijd goed gedocumenteerd.

Big Data en het wagenpark

Big Data en het wagenpark


Rens Priems

Steeds vaker verschijnen in het nieuws berichten over de ontwikkelingen van zelfrijdende auto’s door autofabrikanten en technologiebedrijven. Hoe verzamelen en gebruiken zij hiervoor big data, en wat kan big data voor u betekenen? Voor de nieuwsbrief van Riemersma Leasing legden we dit uit.

Er zijn meerdere typen gegevens over uw voertuig en rijgedrag te verzamelen. De technieken hiervoor zijn bovendien volop in ontwikkeling. Gegevens worden over een breed spectrum verzameld. Moderne auto’s, zoals bijvoorbeeld de modellen van Tesla, verzenden een enorme hoeveelheid aan informatie. Onder meer locatiegegevens (GPS), snelheid en acceleratie, en gegevens over de status van accu’s en elektromotoren. Meer recentere modellen verzamelen daarnaast radargegevens om op ieder moment een beeld van de wereld rondom de auto te vormen.

Sensoren en rijgedrag

Fabrikanten kunnen zulke sensoren in hun producten inbouwen om gegevens te verzamelen. Andere partijen hebben die mogelijkheid niet, en verzamelen op andere manieren gegevens. Verzekeraars bieden autoverzekeringen aan waar een klein blokje, vergelijkbaar met een usb-stick, in de OBD-poort (On-Board Diagnostics) van de auto gestoken moet worden om op basis van rijgedrag een eventuele korting op de premie te bepalen. De stick verzameld locatiegegevens en acceleratie, om zo het rijgedrag te scoren. Een rijstijl met veel hevige acceleraties en met regelmaat te hoge snelheden krijgt een lagere score dan een rustigere, behoudende bestuurder.

sensor

Deze gestructureerde en ongestructureerde data van auto’s wordt verzameld in data warehouses, bijvoorbeeld op basis van het Hadoop platform. Er zijn verschillende complete suites van tools voor de verzameling, opslag en bewerking van big data op basis van Hadoop, zoals bijvoorbeeld Hortonworks.

Gebruik van de verzamelde data

De verzamelde gegevens over voertuigen en het rijgedrag kunnen voor verschillende doeleinden worden gebruikt. Technologiebedrijven trainen en verifiëren hun Artifical Intelligence oplossingen voor autonoom rijden. Het is dan met name van belang om zoveel mogelijk gegevens over uiteenlopende omstandigheden te verzamelen, zodat de autonome systemen beter getraind kunnen worden. Op dit moment zijn er slechts enkele bedrijven die ook daadwerkelijk auto’s min of meer zelfstandig laten rijden. Meerdere andere bedrijven ontwikkelen hun technologieën nu nog achter gesloten deuren, om in de nabije toekomst ook zelfrijdende oplossingen aan te kunnen bieden. Verzekeraars zijn daarnaast aan het verkennen hoe ze met de voor hen beschikbare informatie, door middel van bijvoorbeeld incentives, een veiligere verkeerssituatie met minder schade kunnen creëren.

Ook voor zowel leasenemers als gevers kan big data een meerwaarde bieden. Bijvoorbeeld bij de optimalisatie van de samenstelling en benutting van het wagenpark, of door te anticiperen op verwacht noodzakelijk onderhoud. Daarnaast kan inzicht in persoonlijke statistieken gebruikers ertoe aanzetten hun rijgedrag te verbeteren, vergelijkbaar met de eerder genoemde verzekeraars. Samen levert dit een efficiencyslag op met minder schade, minder brandstofverbruik, minder noodzakelijk onderhoud, en een toegevoegde waarde aan de leaseovereenkomst voor beide partijen.

Blockchain, Revolutie of Evolutie? Deel 3

Blockchain, Revolutie of Evolutie? Deel 3

Blockchain: revolutie én evolutie.
Sander Kerkdijk     

Eerder behandelden we in deel 1 de BlockChain technologie in brede zin en in deel 2 waarom BlockChain anders is dan eerdere systemen en als betrouwbaar kan worden beschouwd. In dit derde en afsluitende deel gaan we specifiek in op de vraag: Is BlockChain een revolutie of evolutie?
Eerst zal er uitgelegd worden dat BlockChain in totaliteit revolutionair zou kunnen zijn door een evolutie van bestaande systemen te zijn. Daarnaast zal er een voorbeeld worden gegeven van een revolutie waarbij BlockChain een belangrijke rol kan spelen.

Een ketting van “blocks”

Veel technologieën, waaronder het reeds behandelde P2P principe zijn BlockChain voorgegaan en geadopteerd binnen deze standaard. Toch wijkt Block Chain hiervan af door gebruik te maken van een asynchrone leesbaarheid. Waar P2P nog inzicht gaf in alle datadelen kan BlockChain bepaalde data blocks alleen toegankelijk maken voor een select aantal afnemers. Tevens is BlockChain in tegenstelling tot P2P robuuster ingericht om te kunnen omgaan met zogenoemde Big Data. Een procedure die dit goed kan beschrijven zit al in de naam: BlockChain. Letterlijk een ketting van Blocks. Waar P2P de gehele data in vaste groottes opdeelt en niet flexibel toestaat dat er later nog data kan worden toegevoegd is dit binnen BlockChain wel het geval. Dit wordt gedaan aan de hand van een proces waarbij na een bepaald aantal transacties die zijn toegevoegd in de database de transacties samen worden gerepresenteerd als een block. Dit zorgt er ook voor dat indien er een verwerking of afhandeling plaatsvindt niet de gehele database moet worden bekeken maar een select aantal blocks. Deze ‘truc’ zorgt ervoor dat de data oneindig kan groeien, aangezien er altijd maar een deel hoeft te worden bevraagd indien er een verzoek binnenkomt.

The Internet of Things

Een ander gebied waar BlockChain een techniek is die goed toegepast kan worden is de Internet Of Things. Binnen Internet of Things gaan we ervan uit dat steeds meer alledaagse apparaten verbonden kunnen worden met slimme (digitale) verbindingsmogelijkheden. Een voorbeeld hiervan is een cola automaat dat zelf zijn bevoorrading verzorgt en inschat. Deze zou dan ook proactief communiceren met de frisdrankfabrikant om altijd in zijn bevoorrading te voorzien. De hoge mate van trust die is ingebouwd in BlockChain zorgt ervoor dat een fabrikant zonder een hoge kans op interceptie of afwijking deze communicatie kan overlaten aan alledaagse apparaten. Een bijkomend voordeel van BlockChain is de lage overhead van de gevraagde capaciteit van het netwerk. Aangezien alles lokaal wordt ingeladen is een snelle internetverbinding niet vereist. Dit zorgt ervoor dat op de centrale server van de frisdrankfabrikant geen bulk van aanvragen binnenkomt, maar alleen een enkel verzoek dat wordt beantwoord en niet een hoge mate van encryptie of fraud detection hoeft te kennen. Deze zogenoemde Low Latency en lightweight footprint maakt dat BlockChain een ‘enabler’ is voor de nu steeds populairder wordende microservices die wel gebruik moeten maken van een hoog volume van datadichtheid/ abstractie.

Revolutie of evolutie?

Na dit drieluik hoop ik dat er een globaal beeld is van waar alle opwinding rondom BlockChain vandaan komt. Daarnaast hoop ik dat er genoeg beargumenteert is dat BlockChain een revolutie voor de afhandeling van vertrouwenskwesties is. Deze vertrouwenskwesties zijn vanuit het bedrijfsleven vaak aangedragen als reden om een deel van hen dataset niet vrij te geven. Het gebruik van deze techniek heeft als gevolg dat meer en meer data vrij toegankelijk dan wel open wordt gemaakt. Dit zorgt voor een revolutie binnen het Big Data Landschap. Data gestuurde oplossingen die hedendaags worden geschreven door een DataScientist worden steeds meer gedreven door een honger naar veel en vooral gevarieerde open data. De verrijking komende uit het vrijgeven van gesloten datasets zorgt ervoor dat oplossingen die te vinden zijn binnen deze datamodellen steeds beter worden. Ook krijgt men hierdoor een meer universeel beeld van trends en verwachte bewegingen binnen een vakgebied. Hierbij is niet alleen de eigenaar van de data geholpen maar tevens kunnen we hiermee een efficiëntie slag als totale samenleving maken. Voorbeelden hiervan zullen worden beschreven in later volgende blogs.

Er kan dus als slot geconcludeerd worden dat BlockChain zelf een evolutie is van bestaande technieken samengevoegd maar dat dit als optelling een revolutie betekent voor de mogelijkheid om data die nu als bijvoorbeeld black of gesloten data (zie eerdere post) kan worden bestempeld toch vrij te kunnen geven in de vorm van Open Data.

Blockchain, Revolutie of Evolutie?  Deel 2

Blockchain, Revolutie of Evolutie? Deel 2

Blockchain: De achterliggende techniek.
Sander Kerkdijk     

Zoals in deel 1 is uitgelegd brengt BlockChain een nieuwe technologie op tafel die vooral een vernieuwing op het gebied van toegankelijkheid en betrouwbaarheid van informatie brengt. In deel twee zullen we dieper op de technologie ingaan om beter te onderbouwen waardoor het komt dat deze techniek als betrouwbaar kan worden beschouwd. Tevens zullen we door middel van praktische voorbeelden inzichtelijk maken hoe een proces van BlockChain verloopt. Omdat BlockChain op veel domeinen toepasbaar is hebben we gekozen om verder in dit artikel BitCoin als voorbeeld te nemen. Hiervoor is gekozen omdat BitCoin op dit moment het meest uitgekristalliseerd is.

“Bitcoin gives us, for the first time, a way for one Internet user to transfer a unique piece of our property to another Internet user, such that the transfer is guaranteed to be safe and secure, everyone knows that the transfer has taken place, and nobody can challenge the legitimacy of the transfer. The consequences of this breakthrough are hard to overstate.”
– Marc Andreessen

Wat is een bitcoin?

Om bij het begin te beginnen: wat is een BitCoin?
Een BitCoin is een enkel deel van een grotere valuta. Gelijkend aan elke andere valuta heeft het geen waarde van zichzelf, maar heeft het waarde omdat we onderling met elkaar hebben afgesproken dit een bepaalde waarde toe te dichten. Om overzicht te houden over de hoeveelheid BitCoins die in omloop zijn maken we gebruik van een ‘Ledger’. Een zogenoemde ledger is een bestand wat overzicht houdt over alle BitCoin Transacties. In plaats van bewaard te worden op een centrale server zoals in traditionele systemen, wordt deze ledger over de hele wereld gedistribueerd via een netwerk van losse entiteiten / computers. Deze entiteiten bewaren de data en verwerken de benodigde computaties. Elke entiteit kan als een ‘Node’ worden beschouwd en bestaat uit een lokale kopie van de ledger.

Voorbeeld:
Patrick wil een genoemd aantal BitCoins overmaken aan Jordan. Hiervoor propageert hij een bericht naar het gehele netwerk dat zegt: ‘Ik wil mijn account met 5 BitCoin verlagen, en Jordan’s account met 5 BitCoin verhogen”. Elke ‘Node” in het netwerk zal dit bericht ontvangen en doorzetten naar zijn kopie van de ‘ledger’ waarna deze mutatie lokaal zal worden uitgevoerd.

Om te zorgen dat er transacties tussen partijen mogelijk zijn heb je een zogenoemde ‘Wallet’ of ‘Vault’ nodig. Dit is een stuk software dat door middel van een crypto grafisch model dat met behulp van een uniek paar van verbonden sleutels (een privé en publieke sleutel) de data versleuteld. Alleen de eigenaar van de gekoppelde privé sleutel kan hierdoor het bericht decoderen en autoriseren. Echter kan elke ‘node’ aan de hand van de transactie aanvraag die wordt verzonden van een node met zijn eigen privé sleutel wel autoriseren dat dit een valide mutatie is.

Hoe werkt deze codering?

Als er een gecodeerde transactie aanvraag wordt gemaakt dan wordt er eerst een digitale handtekening gegenereerd om de bron en de authenticiteit van de transactie dubbel te controleren. Deze digitale handtekening is een rij van tekst die het resultaat is van een combinatie van de transactie aanvraag en de gebruikte privé sleutel. Hierdoor kan dezelfde handtekening niet worden gebruikt voor andere transacties. Doordat je de transactie pas verstuurd nadat deze is gecodeerd zal de privé sleutel nog openbaar worden gemaakt. Daarnaast houdt de node met een afgeschermde log bij wat er reeds voor handelingen door hem zijn uitgevoerd. Indien een aanvraag die van hem af kwam nogmaals wordt gedaan (al dan niet van een andere bron) wordt dit door hem opgemerkt en afgekeurd.

Hoe weet de node wat de balans van een specifieke andere node is?

De node houdt niet bij wat de balans van een andere node is. Het slaat alleen elke mutatie op die heeft plaatsgevonden. Indien je wilt weten wat de balans van jouw node is zal jouw node alle mutaties die er ooit zijn geweest moeten analyseren en verifiëren.

Er kan gesteld worden dat door middel van de tweetraps versleuteling en het decentraal maken van het mutatie archief BlockChain als veilig kan worden beschouwd. Door het delen van alle informatie met elkaar, maar ook door de versleuteling mutaties alleen inzichtelijk te maken voor een specifieke node dan wel nodes moet de data door iedereen worden gevalideerd voordat het wordt geaccepteerd. Dit gebeurt zonder iedereen toegang tot de daadwerkelijke inhoud te geven.

In deel drie bespreken we onder andere the Internet of Things en waar BlockChain zijn naam aan dankt.
Als afsluiting zal er gesteld worden of BlockChain meer een evolutie of revolutie betreft.

Blockchain, Revolutie of Evolutie?  Deel 1

Blockchain, Revolutie of Evolutie? Deel 1

Blockchain: decentraal, open en veilig.
Sander Kerkdijk     

Wie het afgelopen jaar een willekeurig middel tot groot bedrijf met een solide datalandschap instapte zal het woord Blockchain vast minstens een keer over de tafel hebben horen komen. Maar wat is het nou precies? En hoe kan blockchain bijdragen aan een hogere graad van data transparantie en vertrouwen? De aankomende weken gaan we proberen iedere geïnteresseerde mee te nemen in een beter begrip van deze opkomende technologie met als slotrede of Blockchain een Revolutie of Evolutie is.

Een goed voorbeeld van een analoog concept waarbij blockchain toepasbaar is, is een grootboek. Tegenwoordig is een grootboek gedigitaliseerd en noemen we het databases. Deze databases zijn tot nu toe voornamelijk gesitueerd op een centrale plek waarbij de toegang is afgesloten voor de buitenwereld. De reden om deze databases af te sluiten is vooral vanuit beveiligingsoverwegingen. Een nadeel van deze centraal afgesloten databases is dat ze daardoor lastiger aan te sluiten zijn op andere systemen zonder dat er afbreuk wordt gedaan aan de beveiliging van de database.

Een mogelijke oplossing om de systemen aan elkaar te verbinden zonder afbreuk te doen aan beveiliging is blockchain. Het karakter van blockchain is decentraal en open in essentie. Dit wil zeggen dat er niet één eigenaar van de data is. Sterker nog, niemand is daadwerkelijk eindeigenaar van alle data. Een zogenoemd Peer to Peer principe wat we kennen van BitTorrent of Napster deelt de datafile/database op in kleinere delen (chunks). Deze chunks worden over het netwerk gedeeld met andere gebruikers waarbij er continu onderling wordt gecontroleerd of alle beschikbare chunks nog met elkaar overeenkomen. Hierdoor kan een wijziging in het bestand gelijk worden gesignaleerd en worden gecorrigeerd indien het niet valide is. Dit is vergelijkbaar met de eerder gepubliceerde blog over wijsheid van de massa waar de meeste stemmen gelden. Indien één afwijkt zal hij zich conformeren naar de groep en zijn afwijkende chunk inwisselen voor degene van de grootste populatie in het netwerk.

Het toevoegen van nieuwe informatie gebeurt door middel van een wijziging die doorgezet wordt naar de andere gebruikers. Indien men als een valide auteur wordt aangemerkt zal deze wijziging met iedereen gedeeld worden. Aangezien deze lijst van auteurs ook wordt rondgestuurd in chunks en afhankelijk is van eerdere mutaties in de database wordt dit ten alle tijden gecontroleerd op validiteit. Dit zorgt ervoor dat het nagenoeg onmogelijk is om informatie te vervalsen of zonder sporen achter te laten eerdere mutaties te wijzigen.

Blockchain vs client server

Universeel vertrouwd

De conclusie is dat er door een techniek als Blockchain geen intermediairs meer nodig zijn om voor het benodigde vertrouwen te zorgen. Door het toepassen van universeel vertrouwde afhandeling door crypto grafische modellen die eerdere transacties gebruiken om te controleren of een mutatie valide is zorgt men dat het vertrouwen gedistribueerd wordt onder alle afnemers van de data.

Zoals hopelijk inzichtelijk is gemaakt biedt Blockchain een robuuste en betrouwbare manier om meer dan alleen een kopie over te dragen. Ook eigenaarschap van data kan tussen meerdere partijen worden verdeeld. Iedereen met toestemming kan de data inzien maar om een mutatie te kunnen uitvoeren moet men kunnen aantonen dat men de juiste rechten heeft. Aangezien de formule voor het berekenen van dit eigenaarschap diep verscholen zit in het systeem doormiddel van een crypto grafisch model dat onderling wordt gedeeld biedt het een hoge mate van bescherming tegen datafraude.

In het tweede deel van de blog zullen we dieper op de techniek ingaan en laten zien hoe de achterliggende cryptologie functioneert. Tevens zal er een inkijk in de techniek achter de onderlinge overdracht van chunks worden gegeven.

Wijsheid van de massa

Wijsheid van de massa

Data remodelleren door ‘wijsheid van de massa’ in te zetten
Sander Kerkdijk     

‘Wijsheid van de massa’ is een begrip vanuit de Sociologie. Het introduceert het idee dat de massa over meer informatie beschikt dan het individu. Een klassiek voorbeeld hiervan is het raden van het gewicht van een os:

Op een landbouwshow konden omstanders het slachtgewicht schatten van de os. Zo’n 800 omstanders vulden een gewicht in waarna de data werd onderzocht. De stem van het volk kwam verrassend dicht bij het werkelijke gewicht van de os.

Door dit concept kan een massa een redelijk precieze schatting samenstellen over onderwerpen waarvan ze niet precies weten wat de exacte uitkomst zou moeten zijn.

Een goed voorbeeld van een geslaagd project waarbij ‘wijsheid van de massa’ is toegepast betreft Wikipedia. Hier kan elk individu een verandering indienen wat door de massa kan worden goedgekeurd, afgekeurd of aangevuld. Door deze vorm van sociale cohesie wordt er een afwijking gevonden die naar vermoeden het dichtste bij de universele correctheid zal liggen.

De waarde van data vinden heeft binnen Data Science ook geen universeel antwoord. Door hiervoor het concept ‘wijsheid van de massa’ in te zetten kan er op een snelle en correcte manier ‘Big Data’ worden geclassificeerd en/of worden verrijkt.

2

‘Wijsheid van de massa’ in de praktijk

Binnen Data Science bestaan verschillende manieren om ‘wijsheid van de massa’ toe te passen. De meest gebruikte manier bij succesvolle bedrijven blijkt het A/B testen van microveranderingen te zijn. Een goed voorbeeld hiervan is Booking.com, aan de hand van de respons van gebruikers testen zij microveranderingen van de website. Denk hierbij aan een verandering in de tekst of een witte rand om knopjes heen, om zo te kijken of er dan meer op wordt geklikt. Door het gewenste of gemiddelde gedrag te onderzoeken wordt op een autonome manier bekeken of de verandering een goede keuze zou zijn.

Bij content geldt dat door een variatie op een tekst aan te bieden, er getoetst kan worden of de beschikbare informatie relevant bleek voor het (gewenste) einddoel. Dit gebeurt voornamelijk door markeerpunten in te bouwen op strategische plekken in het proces. Op deze manier kan er getest worden of de informatie daadwerkelijk is gebruikt. Uit onderzoek blijkt bijvoorbeeld dat een mens geneigd is om de muis van een computer te bewegen naar het punt waar de ogen zich focussen op het beeldscherm. Door te meten waar op de pagina de muis zich bevindt, weten we of een tekst is gebruikt. Zodoende kan er achterhaald worden of een bepaalde tekst daadwerkelijk relevant is voor het beoogde doel. Indien de data niet relevant genoeg bleek zal het in de uiteindelijke keuze om een dataveld mee te nemen in een predictie een lagere prioriteit krijgen.

Een optelling van output gegenereerd door ‘wijsheid van de massa’ zorgt ervoor dat je een gemiddelde vindt welke (indien de omvang van de invoer groot genoeg is in een significant aantal van de gevallen) de geoptimaliseerde uitkomst vindt zonder veel interventie van een specialist.

Een laatste voorbeeld over dit onderwerp is het monitoren van mensenmassa’s. Dit is een complex proces, omdat het voor de mens lastig te kwantificeren is wat de optimale karakteristieken zijn om mensenmassa’s zo nauwkeurig mogelijk te voorspellen. Hiervoor is een zelflerend systeem ingezet, welke video’s van mensenmassa’s analyseert. Daarna werden abnormale bewegingen in meer dan 80% van de gevallen door het systeem opgemerkt. Het systeem wist dit zelfs te signaleren voordat een specialist doorhad dat er iets aan de hand zou kunnen zijn.

Conclusie

Er kan gesteld worden dat ‘wijsheid van de massa’ een goede aanpak blijkt om complexe data-vraagstukken aan te pakken en verbanden tussen data te vinden. Gebruik maken van de kennis die al aanwezig is binnen de populatie, die deze data consumeert, blijkt een goede aanpak om tot een verbetering van data-begrip te komen. Dit kan zelfs zonder grondige domeinkennis van de data-specialist.

Wanneer we een datamodel gebruiken, die afhankelijk is van processen waarvoor het verloop niet kan worden voorspeld of een te brede abstractie kennen voor de mens, kan invoer van ‘wijsheid van de massa’ een goede aanpak zijn om een juiste data-benadering te vinden.

Jboss Data Virtualisatie – mappen van LDAP rollen naar VDB rollen

Jboss Data Virtualisatie – mappen van LDAP rollen naar VDB rollen

Hoe gebruik je de security modules om LDAP rollen te mappen naar rollen die we kunnen gebruiken in de VDB?
Bas Piepers     

JBoss Data Virtualization (JDV) geeft ons de mogelijkheid gegevens uit verschillende bronnen te ontsluiten via zogenaamde virtuele databases (VDBs). Doormiddel van tooling of door het samenstellen van een xml-bestand kunnen deze virtuele databases worden gemodelleerd aan de hand van de onderliggende datastructuren.

Naast de mogelijkheid om deze abstractielaag aan te brengen, tussen aan de ene kant bronnen van allerlei pluimage (databases, flat files, web services etc.) en aan de andere kant de eindgebruikers die van deze data gebruik maken, is beveiliging één van de belangrijkste aspecten van deze data. JDV kent een uitgebreide set aan mogelijkheden om de verschillende onderdelen in zo’n datamodel te beveiligen op basis van rollen. Men kan velden en functies al dan niet toestaan voor rollen, maar ook condities en maskeringen aanbrengen.

Gebruikers en rollen zijn dikwijls al buiten JDV opgeslagen, bijvoorbeeld in een LDAP oplossing. Aangezien JDV binnen JBoss Enterprise Application Platform (EAP) draait kunnen we gebruik maken van alle functionaliteiten die dit platform te bieden heeft.

In dit blogartikel laten we zien hoe we gebruik kunnen maken van standaard aanwezige security modules om gebruikers te authentiseren via LDAP. Daarnaast laten we het gebruik van een aanvullende security module zien, die zorgt voor het mappen van de LDAP rollen naar technische rollen binnen een VDB. Het mappen van de rollen die bekend zijn binnen LDAP naar rollen die zijn opgenomen in een bestand is handig wanneer er meerdere rollen binnen een VDB zijn die aparte autorisatie regels kennen. Of wanneer je rollen een duidelijkere betekenis wilt geven, omdat ze binnen een LDAP omgeving niet beschrijven wat de betekenis is binnen een virtuele database.

De vele mogelijkheden die JDV biedt voor het combineren van verschillende bronnen laten we in dit artikel buiten beschouwing. Mocht je een eerste indruk willen krijgen van JDV en de tooling daaromheen dan is de DV Workshop van RedHat een goed begin. In het blogartikel van mijn collega Dennis van Loon wordt hier ook over gesproken. Hier vind je de link naar de workshop.

Als bron voor de virtuele database in dit artikel gebruiken we een test database, die is opgebouwd met een deel van het script dat ook wordt gebruikt in de workshop. Dit script wordt alleen gebruikt als startpunt en om het onderscheid in rollen te demonstreren. Verder maken we gebruik van een gratis en voor iedereen te bereiken voorbeeld LDAP implementatie van Forumsys. De inhoud van deze LDAP server heeft ten opzichte van de inhoud van de voorbeeld database geen enkele relevantie. Zo bevat de voorbeeld LDAP server twee groepen: ‘mathematicians’ en ‘chemists’ en heeft de voorbeeld database account- en brokertabellen.

We maken in dit blogbericht gebruik van de JBoss Developer Studio versie 8.1.0 GA in combinatie met Teiid Designer 9.0.6.Final. Als server instantie gebruiken we JBoss Enterprise Application Platform 6.4, update 3 in combinatie met JBoss Data Virtualization 6.2 update 4.

De security domain configuratie

Het aanmaken van een security domain doe je in de configuratie van JBoss EAP. In het configuratie bestand van JBoss EAP maken we een security domain aan genaamd “ocs-com” met twee loginmodules:

  • De LdapLoginModule: deze module verzorgt de authenticatie van de gebruikers en zorgt ervoor dat een gebruiker wordt aangemaakt met de rollen die voor hem of haar zijn geconfigureerd
  • De RoleMappingLoginModule: deze module zorgt ervoor dat we op basis van een property file de rollen, die zijn toegekend aan de gebruiker in de LDAP omgeving, kunnen omzetten naar een technische rol die kan worden gebruikt in de applicatie. In dit geval gaat het om rollen die we in onze virtuele database willen gebruiken

De voorbeeld configuratie ziet er als volgt uit:

JBV 1

 

 

 

 

 

 

 

 

Voor de LdapLoginModule geldt dat de indeling van de LDAP omgeving leidend is. Met de attributen in deze module geef je instructies, zodat ze weet waar de gebruikers en de rollen staan. ‘principalDNPrefix’ en ‘principalDNSuffix’ geven aan waar deze module naar gebruikers moet zoeken; ‘rolesCtxDN’, ‘uidAttributeID’ en ‘roleAttributeID’ geven de informatie die de module gebruikt om de rollen van een gebruiker op te zoeken. De indeling van de voorbeeld LDAP van Forumsys ziet er als volgt uit:

JDV 2

 

 

 

 

 

 

 

 

 

 

 

Alle gebruikers en de rollen zitten in ‘dc=example,dc=com’. De gebruikersnamen zijn gekoppeld aan het ‘uid’-attribuut, de rollen staan achter het ‘ou’-attribuut. Als we in de rollen kijken dan zien we dat daar de gebruikers zijn opgesomd die lid zijn van die rol:

JDV 3

 

 

 

 

 

 

 

 

 

 

 

 

De gebruikers zijn met het attribuut ‘uniqueMember’ toegevoegd aan de rol. In bovenstaand voorbeeld zien we dat ‘pasteur’, ‘nobel’, ‘boyle’ en ‘curie’ lid zijn van de groep ‘chemists’. De rol ‘mathematicians’ heeft de gebruikers ‘test’, ‘gauss’, ‘euler’, ‘riemann’ en ‘euclid’ als lid:

JDV 4

 

 

 

 

 

 

 

 

 

 

We hebben de LdapLoginModule nu zodanig geconfigureerd dat deze overeen komt met onze LDAP omgeving.

De RoleMappingLoginModule heeft als configuratie de locatie van het bestand waar de rollen staan met de daarbij behorende mapping naar een technische rol (in ‘rolesProperties’). Met ‘replaceRole’ geven we vervolgens aan dat de rollen die de gebruiker op de LDAP omgeving kent moeten worden vervangen door de rollen uit het ‘rolesProperties’-bestand. Hieronder zie je twee regels met de rollen uit de LDAP-omgeving en daarachter de rol waarmee we de LDAP rol willen vervangen:

JDV 5We kunnen hier overigens ook meerdere rollen mappen, indien nodig hadden we, gescheiden door een komma, ook meerdere rollen achter ‘mathematicians’ of ‘chemists’ kunnen opnemen. In dit voorbeeld hebben we slechts één technische rol per LDAP-rol.

Beide loginmodules hebben de ‘flag’-attribuut op ‘required’ staan. Dit betekent dat indien één van de login modules faalt, de gebruiker niet kan inloggen. Dit is voor de LdapLoginModule cruciaal, aangezien deze module de authenticatie van de gebruiker voor zijn rekening neemt. Als het mappen van rollen in RoleMappingLoginModule niet lukt dan zal de gebruiker wel in kunnen loggen, maar worden de rollen niet aan de gebruiker toegekend. In die zin is het voor de RoleMappingLoginModule iets minder van belang of de ‘flag’ op ‘required’ staat.

De Virtual Database (VDB)

In de VDB hebben we door middel van de Teiid Designer de informatie van de voorbeeld database geïmporteerd in een source model:

JDV 6

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Bijbehorend view model is een 1-op-1 weerspiegeling van het source model en deze hebben we opgenomen in de VDB:

JDV 7

 

 

 

 

 

 

 

 

 

 

 

Zoals je ziet hebben we ervoor gezorgd dat enkel het view model voor gebruikers zichtbaar is (onder JDV loepje hebben we enkel test_edl.xml aangevinkt). Om het onderscheid in rollen aan te tonen maken we rollen aan in de VDB:

JDV 8

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Per rol moeten we dan nog aangeven naar welke ‘enterprise role’ ze verwijzen. Als we dubbelklikken op de rol of op JDV rol aanmaken klikken kunnen we in het tabblad ‘Mapped Enterprise Role or Group’ aangeven welke rol binnen het security domain overeenkomt met de rol binnen de VDB:

JDV 9

 

 

 

 

 

 

 

We hadden de rolnaam die binnen de VDB geldt een andere naam kunnen geven, maar om het niet te verwarrend te maken geven we hem dezelfde naam als de bijbehorende rol in ‘role-mapping.properties’.

In het ‘Permissions’-tabblad kunnen we vervolgens voor de rol de rechten toekennen. In dit geval geven we TESTROLE1 rechten om de tabellen ‘account’, ‘accountholdings’ en ‘customer’ te lezen. TESTROLE2 geven we rechten op de tabellen ‘brokercustomer’, ‘brokerinformation’ en ‘customer’:

JDV 10

 

 

 

 

 

 

JDV 11

 

 

 

 

 

We kunnen de VDB nu deployen op de applicatie server.

Het resultaat testen

Nu we de VDB hebben gedeployed op de applicatie server kunnen we met een eenvoudige SQL client testen wat het resultaat is. We gebruiken hiervoor een gratis SQL client genaamd ‘Squirrel’ en maken met behulp van de Teiid JDBC driver een alias aan, zodat we kunnen verbinden met de VDB. We loggen eerst in als gebruiker: ‘riemann’. Om te testen welke rol we hebben voeren we de volgende twee queries uit:

SELECT hasRole(‘TESTROLE1’)

SELECT hasRole(‘TESTROLE2’)

Op de eerste query zullen we ‘true’ als resultaat krijgen en op de tweede query ‘false’:

JDV 12

 

 

 

 

JDV 13

 

 

 

 

We kunnen daarnaast enkel een query uitvoeren op de tabellen die zijn toegekend aan deze rol. Een query uitvoeren op een tabel waar we geen rechten op hebben met deze gebruiker geeft de volgende foutmelding:

JDV 14

 

 

Inloggen met gebruiker ‘boyle’, die in de rol ‘chemists’ is ingedeeld op LDAP geeft het volgende resultaat:
JDV 15

 

 

 


JDV 16

 

 

 

Ook met deze gebruiker kunnen we enkel een query uitvoeren op de tabellen waar we rechten op hebben. Voeren we namelijk een query uit op een tabel waar we geen rechten op hebben, dan krijgen we de eerder getoonde foutmelding.

Via deze manier hebben we aangetoond dat we, gebruik makend van standaard beschikbare security modules, rollen uit een externe omgeving kunnen omzetten naar technische rollen die we binnen onze VDB kunnen gebruiken.

×