Follow Us on Twitter

Integratie van SOA met Oracle Event Processing in 12c

November 2014 - Het zogenaamde Internet of Things komt er aan. Steeds meer apparaten en sensoren worden verbonden en gaan online. Ook andere kanalen zoals  (bestaande) bedrijfsapplicaties kunnen veel waardevolle datastromen genereren. Deze data wordt steeds belangrijker en dient steeds sneller te worden geanalyseerd. “Fast Data” -  de verzamelnaam voor gegevens uit datastromen, zoals websitegebruik, financiële transacties of sensoren - wordt steeds waardevoller voor de bestaande bedrijfsprocessen. Het wordt ook steeds vaker verwerkt en geïntegreerd in de normale bedrijfsvoering. Om dit te ondersteunen zijn er veel softwarepakketten in de markt. Natuurlijk heeft Oracle ook een product: Oracle Event Processing (OEP).

In dit Whitebook kijken we naar de 12c editie van Oracle Event Processing en de vernieuwde integratie met de SOA Suite van Oracle. We zullen kijken hoe de service-georiënteerde architectuur eenvoudig kan worden verweven met een Event Driven architectuur door gebruik te maken van de standaard componenten die met de 12c editie meekomen. Hoe kan de oude vertouwde SOA Suite onderdeel worden van de Fast Data stromen die Oracle Event Processing verwerkt. We zullen aan de hand van een eenvoudig voorbeeld laten zien hoe we het Event Delivery Netwerk events uit de SOA Suite gebruiken in Oracle Event Processing.

Oracle Event Processing als onderdeel van de SOA Suite 12c

Figuur 1: Oracle Event Processing als onderdeel van de SOA Suite 12c

Oracle Event Processing 12c

Oracle Event Processing 12c (kortweg OEP) is een nieuwe naam voor wat we voorheen nog kenden als Oracle Complex Event Processing. Dit product is enige tijd geleden al eens de revue gepasseerd in het Whitebook "Leid datastromen in goede banen met Complex Event Processing van Oracle".

OEP is een product waarmee realtime datastromen worden geanalyseerd.  Deze datastromen worden ook wel streams genoemd. De bronnen van deze datastromen zijn adapters die events genereren. Deze events kunnen worden geanalyseerd. De uitkomst van de analyse kan vervolgens worden afgeleverd aan andere (externe) systemen, wederom met behulp van adapters.

Het koppelen en verwerken van event streams gebeurt in OEP-applicaties. Deze applicaties worden Event Processing Networks (EPNs) genoemd. Zoals de naam al doet vermoeden bestaan deze applicaties uit een aaneenschakeling van diverse componenten.

OEP is een lichtgewicht product en dus in staat zeer grote hoeveelheden events te verwerken.  Uiteindelijk worden alle componenten onder water vertaald naar eenvoudige Java object classes die op een lichtgewicht stand-alone server, of op de Oracle WebLogic Server kunnen draaien.

Anders dan de voorgaande versie, is OEP nu onderdeel van de SOA Suite 12c. Het ontwikkelen van OEP-applicaties gebeurt nu in JDeveloper, waar dat voorheen met Eclipse gebeurde. Verder kan OEP nu overweg met het Event Delivery Framework, kan het werken met Big Data en heeft het out-of-the-box templates voor de werkpaarden uit het EPN: de Processors.

voorbeeld van een EPN

Figuur 2: voorbeeld van een EPN

Een EPN bestaat dus uit een aaneenschakeling van verschillende componenten zoals Figuur 1 laat zien. In dit figuur zijn inbound adapters aan de linkerkant te zien, een outbound adapter aan het einde van de flow en de Processor in het midden die de uiteindelijke analyse doet.
De componenten waaruit een EPN bestaat zijn onder te verdelen in verschillende smaken. Uiteindelijk zijn alle componenten onder water Java classes. Een EPN kan daarom eenvoudig worden uitgebreid met eigen Java programmatuur. Deze componenten zijn:

Adapters en extensions

Dit component zorgt voor de ontvangst en verzending van events en streams. Net zoals we gewend zijn uit de SOA Suite zijn er adapters voor verschillende protocollen en systemen. Zo zijn er adapters voor JMS queues, Remote Method Invocation (RMI), HTTP, File (CVS), Database (relational en NoSQL), EDN (voor de SOA Suite), maar ook voor Hadoop.

voorbeeld van een adapter

Figuur 3: voorbeeld van een adapter

Channels

Streams binnen de EPN worden in de juiste banen geleid door de Channels. De channels fungeren als queues tussen de diverse componenten waaruit het EPN bestaat. Een channel ontvangt de events uit de voorgaande stap en zorgt dat deze bij de volgende stap worden afgeleverd. Het zorgt er dus ook voor dat de ontvangende stap niet wordt overspoeld met aangeleverde events.

een Channel

Figuur 4: een Channel

Processors en CQL

Het verwerken van events wordt gedaan in de zogenaamde Processors.  Deze componenten maken gebruik van de Continuous Query Language (CQL) om streams te analyseren.

CQL is een query-taal die enigszins lijkt op SQL. In tegenstelling tot SQL wordt CQL niet gebruikt om tabellen te raadplegen. CQL werkt op streams. Dit is een fundamenteel verschil. Waar SQL -op het moment van de uitvoer van de query- een vaste dataset benadert, moet CQL het doen met een continue stroom data.

Omdat CQL dus een continue datastroom als input heeft, beschikt het over een hele set aan features om deze datastroom te partitioneren.  Streams kunnen worden gepartitioneerd in een sliding tijdswindow, per tijdseenheid, per aantal events e.d.. Anders dan in de klassieke SQL kan je dus in CQL bijvoorbeeld een sliding window over de datastroom leggen zodat je bijvoorbeeld alleen de events van de laatste 5 minuten bekijkt (zie Oracle CQL Language Reference for Oracle Event Processing).

Verderop in dit Whitebook zullen we een eenvoudig voorbeeld zien van een CQL query.

Caches

Binnen je EPN kan het soms nodig zijn bepaalde data even op te slaan of te bevragen. Bij grote datastromen die constant dezelfde dataset moeten benaderen is een in-memory cache een goede en snelle oplossing om dit te bewerkstelligen. De Cache component kan gebruikt worden in een EPN om een cache te implementeren. Dit kan met Oracle’s Coherence in-memory cache en ook met een eigen, in Java geschreven, cache.

Java Beans

Uiteraard is niet alle benodigde functionaliteit te vatten in de standaard componenten.Geavanceerde logica kan worden geïmplementeerd in een EPN met Java Beans. Deze beans zijn te koppelen aan channels net als alle andere componenten.

Runtime omgeving

OEP kan worden geïnstalleerd in haar eigen lichtgewicht server of op de WebLogic server. De runtime omgeving komt met een uitgebreide interface, de "Event Processing Visualizer". Via de browser vormt deze visualizer een uitgebreid dashboard op de OEP server en de applicaties die er gedeployed zijn.

Event Processing Visuallizer

Figuur 5: Event Processing Visualizer

In dit dashboard kan ook in detail de gedeployde EPNs worden bekeken. De CQL statements van de Processors  kunnen zelfs worden veranderd in een grafische omgeving.

grafisch CQL editor

Figuur 6: grafisch CQL editor

De Event Processing Visualizer heeft daarnaast uitgebreide dashboards om datastromen te bekijken. Deze interface is het gezicht van OEP, en bevat alle gebruikelijke lifecycle functionaliteit wat van een “enterprise” product mag worden verwacht.

Integratie met SOA Suite

Oracle Event Processing 12c is onderdeel van de SOA Suite 12c. Deze editie bevat dan ook een betere integratie met de rest van de SOA Suite.  Niet alleen zijn EPNs nu te ontwikkelen in de JDeveloper (de SOA Suite 12c ontwikkelomgeving), het is nu tevens mogelijk om gebruik te maken van het Event Delivery Network.

Event Delivery Network

Een belangrijke nieuwe feature in OEP 12c is de introductie van de EDN adapter. EDN, het Event Delivery Network, bestaat sinds SOA Suite 11g. EDN is een technologie om van te voren gedefinieerde events te versturen en ontvangen. EDN events zijn gedefinieerd in de Event Definition Language. Hiermee wordt het event, en het bijbehorende XML schema gedefinieerd.

voorbeeld van het out of the box HumanTaskEvent EDL

Figuur 7: voorbeeld van het out of the box HumanTaskEvent EDL

SOA Suite componenten zoals Mediator, BPEL en BPM kunnen eenvoudig acteren op, en werken met deze events.  Het werkt als een publish-subscribe model. SOA componenten kunnen events het EDN op sturen zonder te weten wat het event oppakt en wanneer dat gebeurt. Andersom kunnen SOA componenten zich abonneren op events op het EDN.

voorbeeld van een SOA mediator component dat luistert naar een event op EDN

Figuur 8: voorbeeld van een SOA mediator component dat luistert naar een event op EDN

de SOA composite met de Mediator die het EDN publiceert

Figuur 9: de SOA composite met de Mediator die het EDN publiceert

Hoewel de Service Bus - ook onderdeel van de SOA Suite - niet out-of-the-box EDN ondersteunt, is dit wel eenvoudig te realiseren door de onderliggende JMS queue van EDN direct aan te spreken (zie Publish EDN from Java & OSB). Daarnaast is EDN ook vanuit Java te gebruiken zodat het binnen de SOA Suite een interoperabel event netwerk is.

Een simpel voorbeeld

Zoals eerder genoemd willen we kijken hoe we de SOA Suite eenvoudig onderdeel kunnen laten worden van de Fast datastromen die door OEP vliegen. Door gebruik te maken van EDN kunnen we deze koppeling realiseren.

We nemen een simpel voorbeeld, waarin we een EDN definiëren met daarin twee events die worden vergeleken met elkaar en de uitkomst wordt doorgestuurd naar een JMS queue. Stel een asynchrone webservice bevat een workflow waar een mens aan te pas komt die een belangrijke order moet goedkeuren. Een requirement kan zijn dat het management automatisch wil inzien welke goedkeuringen binnen 10 minuten plaatsvinden. We kunnen hiervoor twee events definiëren. De twee events zijn: onEvent en onStop. Het onEvent is een event dat in de SOA Suite wordt gegenereerd wanneer de asynchrone webservice wordt aangeroepen. Wanneer de verwerking klaar is wordt er een onStop event gegenereerd. In dit simpele voorbeeld zullen we OEP gebruiken om de aanroepen te detecteren die binnen 10 minuten klaar zijn.

De EDN-events "onEvent" en "onStop" zijn als volgt gedefinieerd:

<?xml version = '1.0' encoding = 'UTF-8'?>
<definitions xmlns="http://schemas.oracle.com/events/edl" targetNamespace="http://www.whitehorses.nl/lvdstarre/event/v1/whitebook/oep-edl">
   <schema-import location="whitebook-event-xsd.xsd" namespace="http://www.whitehorses.nl/lvdstarre/event/v1/whitebook/oep"/>
   <event-definition name="onEvent">
      <content xmlns:ns1="http://www.whitehorses.nl/lvdstarre/event/v1/whitebook/oep" element="ns1:event"/>
   </event-definition>
   <event-definition name="onStop">
      <content xmlns:ns1="http://www.whitehorses.nl/lvdstarre/event/v1/whitebook/oep" element="ns1:event"/>
   </event-definition>
</definitions>

voorbeeld EDL

Figuur 10: voorbeeld EDL

De XML definitie voor de events bestaat uit twee elementen, de integer "Id" en de string waarde "type":

<?xml version="1.0" encoding="windows-1252" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:wh="http://www.whitehorses.nl/lvdstarre/event/v1/whitebook/oep"
            targetNamespace="http://www.whitehorses.nl/lvdstarre/event/v1/whitebook/oep" elementFormDefault="qualified">
  <xsd:element name="event">
    <xsd:annotation>
      <xsd:documentation>A sample element</xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="id" type="xsd:int"/>
        <xsd:element name="type" type="xsd:string"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

XSD is grafische weergave

Figuur 11: XSD is grafische weergave

Deze events kunnen we in OEP 12c laden in de EDN adapter:

inladen van een EDN event in OEP

Figuur 12: inladen van een EDN event in OEP.

De EDN adapter van OEP verbindt via het T3-protocol direct met de SOA infrastructuur. T3 het efficiënte protocol dat binnen WebLogic wordt gebuikt. Verder moet de event definitie worden aangegeven in de vorm van de EDL file zoals we gewend zijn uit de SOA Suite. Voor een efficiënte verwerking kan worden aangegeven de payload van het event (de XML) te converteren naar Java in plaats van pure XML. Als er wordt gekozen voor Java, dan wordt het event naar JAXB Java-classes geconverteerd, en genereert OEP Java code op basis van de XML Schema definitie die bij het event hoort, met alle bijbehorende get- en set-methods om de data elementen uit te lezen of te zetten.  Deze Java classes zijn direct benaderbaar in de datastromen van de EPN, en kunnen worden gebruikt in de CQL queries van een Processor. Een kanttekening hierbij is dat JAXB zich wel eens verslikt in complexe en grote XSDs. In dit geval zal handmatig Java moeten worden geschreven, iets wat een foutgevoelige aangelegenheid kan zijn.

Door deze EDN Adapters, een Processor en een outbound Adapter te koppelen, krijgen we het volgende EPN:

een simpel EPN

Figuur 13: een simpel EPN.

In OEP kan je nu eenvoudig analyseren welke onEvent events uit onze EDN definitie binnen 10 minuten worden gevolgd door een onStop event. Dit doen we door een CQL statement te schrijven die beide streams met een sliding window van 10 minuten inleest, en de events daarin matcht o.b.v. het ID. Als er een match is, dan is de uitkomst van de query een nieuw Event.

ISTREAM(
  SELECT
	Event(cast@java(onEvent.javaContent, nl.whitehorses.oep.Event.class).getId(), "Stopped Event") as javaContent
  FROM
   	onEventStream [RANGE 10 MINUTES] AS onEvent,
	onStopStream [RANGE 10 MINUTES] AS onStop
  WHERE cast@java(onEvent.javaContent, nl.whitehorses.oep.Event.class).getId() = cast@java(onStop.javaContent, nl.whitehorses.oep.Event.class).getId()
)

In het bovenstaande voorbeeld is duidelijk te zien dat we de events uit de beide datastromen onEventStream en onStopStream benaderen via de gegenereerde JAXB methods.  Er is een sliding window toegepast op beide datastromen zodat we over een periode van 10 minuten de events analyseren. De uitkomst van deze CQL query wordt vervolgens weer als een stream (ISTREAM-method) doorgegeven gebaseerd op het Event zoals in ons EDL is gedefinieerd. Nu wordt alleen wel het type “Stopped event” gezet. Natuurlijk kunnen we ook een compleet nieuw event gebruiken, zolang deze maar is gedefinieerd in het project. In eventuele vervolgstappen kan dit event weer worden geanalyseerd door Processors, of worden uitgestuurd via een adapter. In dit simpele voorbeeld zetten we het gewoon op een JMS queue. Een (extern) systeem kan zich abonneren op deze queue en kan dit event weer verder verwerken.

Ook de JMS adapter is eenvoudig te configureren op basis van standaard JMS connectie parameters die we kennen uit JMS verbindingen. Wel moeten we expliciet aangeven welk event type we op de queue gaan zetten. In dit geval dus het event dat de uitkomst is van de Processor: het onEvent-event.

JMS configuratie

Figuur 14: JMS configuratie

In het bovenstaande hoofdstuk hebben we een eenvoudig voorbeeld gezien van een EPN. Dit EPN zal luisteren naar EDN events die vanuit de SOA Suite kunnen worden gegenereerd.

OEP en de business gebruiker

In de Event Processing Visualizer is het mogelijk om in een grafische omgeving de CQL statements te construeren. Net zoals bij business rules binnen de SOA Suite is er sterk de behoefte om de business gebruiker, de niet-techneut, de mogelijkheid te geven dit op een intuïtieve wijze zelf te kunnen. Op Oracle Open World 2014 is hierover een tipje van de sluier opgelicht: Oracle StreamXplorer is de tool die een niet-techneut in staat gaat stellen OEP datastromen te analyseren zonder dat diepgaande kennis van CQL vereist is.

vrijgegeven schermprint van StreamXplorer op Open World

Figuur 15: vrijgegeven schermprint van StreamXplorer op Open World.

Conclusie

Oracle Event Processing kenden we al in de hoedanigheid van Complex Event Processing. De 12c editie is nu echter onderdeel van de SOA stack van Oracle en heeft als groot verbeterpunt dat het beter integreert met de SOA Suite. Het Event Delivery Network dat we kennen uit de SOA Suite is nu direct te gebruiken in OEP. We hebben gezien aan de hand van een eenvoudig voorbeeld dat de EDN events in OEP tot leven kunnen komen als datastromen en in CQL queries kunnen worden geanalyseerd. Vooral omdat EDN events zeer eenvoudig vanuit de SOA Suite zijn te genereren geeft dit vele mogelijkheden.

OEP 12c is nu onderdeel van SOA Suite, en is te ontwikkelen in JDeveloper. De integratie op technologisch vlak met de EDN adapter is daar, maar in de ontwikkelomgeving voelt het nog wel als een los product. SOA-ontwikkelaars zullen merken dat “standaard” functionaliteit uit het SOA-ontwikkeltraject zoals het gebruik van de MDS metadata repository, de IDE connections (nog) niet aanwezig zijn. Dit zal ongetwijfeld meer naar elkaar toegroeien in de verdere evolutie van het product.

Met de komst van StreamXplorer zal ook de niet-techneut uiteindelijk een uitgebreide toolkit tot zijn beschikking hebben om fast data te analyseren en te processen.

Referenties:

  1. Leid datastromen in goede banen met Complex Event Processing van Oracle
    http://www.whitehorses.nl/whitebooks/2012/leid-datastromen-goede-banen-met-oracle-complex-event-processing-oep-cep
  2. Oracle CQL Language Reference for Oracle Event Processing
    http://docs.oracle.com/middleware/1213/eventprocessing/CQLLR/cql-statements.htm
  3. Oracle Open World 2014 presentation CON7736 "Service Integration Product Strategy: Oracle SOA Suite 12c, the Cloud, and API Management".
  4. Publish EDN from Java & OSB.
    http://biemond.blogspot.nl/2011/06/publish-to-edn-from-java-osb-with-jms.html

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.