Tim Bass
Mon, 02 Jun 2008 08:43:56 +0000

In antwoord op * Paul Vincent's post CEP is een dienst of een proces?* I posted CEP is een dienst of een proces? Reloaded.* Dit bericht is een follow-up van mijn dialoog met Paul en de CEP gemeenschap als geheel.
Enkele van de meer opmerkelijke kritische opmerkingen over het boek "De Kracht van Evenementen" was dat het boek niet (voor het grootste deel) * bespreken architectuur .*
Zoals we allemaal weten, zijn er vele definities van "de architectuur;" echter een definitie * dat gemakkelijk is te bespreken, in deze context, is dat een IT-systemen * "architectuur" staat voor de componenten van een IT * * *-systeem en de relaties tussen de verschillende componenten * in de architectuur .*
Een architectuur kan worden "technische" of "functionele" of "operationele" of * "data" centric .* Zo kan een architectuur zijn gebaseerd op een orkestratie van * service-onderdelen, zoals een SOA .* In een ander voorbeeld, een architectuur kan worden vertegenwoordigd door de semantiek van de gegevens .* In nog een ander voorbeeld, kan een architectuur worden vertegenwoordigd door de functionaliteit van de componenten.
Omdat boek van David op CEP geen architectuur te pakken, zijn mensen vrij om een "tool" of "techniek" ze willen, en noemen het "CEP" .** Mijn focus gebruik is op de totale CEP functionaliteit en de referentie-architecturen die beelden van deze functionaliteit voor het oplossen van CEP klassen van problemen.
Dit was een van de eerste onderwerpen (issues) * met * CEP we werden een paar jaar geleden, en * is de reden waarom wij, met inbegrip van * me op mijn dag * * goeie ouwe 'op TIBCO tot nu toe, creëerde een functionele referentie-architectuur voor CEP (ook in dit blog en de TIBCO CEP blog).
In dat functionele referentie-architectuur, hebben we gesproken over * hoe * en geïllustreerd CEP moet functioneren als een coöperatieve (gedistribueerde) functionele referentie-architectuur voor de meeste "echte" CEP klassen oplossen van problemen.
Daarom moet * CEP niet worden in het algemeen * beschouwd als een "proces" of een "dienst", * per se, want ** * CEP, als een * functionele referentie architectuur, de methodologieën (functionaility) die nodig zijn om op te lossen beeldt complexe detectie-georiënteerde problemen .* Deze abstracte vergunningen CEP te hebben betekenis in een brede context van de aanvragen evenement verwerking.
Uiteraard kan een functionele referentie-architectuur worden beschouwd als een "dienst" als alle componenten in de architectuur samenwerken om een probleem op te lossen en zijn ingekapseld als een dienst .* Daarnaast kan een functionele referentie-architectuur worden beschouwd als een "proces" wanneer het oplossen van problemen in een specifiek domein .* Dus, een 'proces', in dit geval is een voorbeeld van de functionele referentie-architectuur, en als de instantie is verpakt als een oplossing, kan deze oplossing worden ingekapseld als een service.
Dus, misleidend is, althans naar mijn mening, te verminderen * CEP naar een "proces" of een "dienst" tenzij we een specifieke oplossing bespreken van een domein probleem binnen een (functionele) referentie-architectuur (functionele context).
Deze verwarring ook * manifesteert zich in de levendig debat tussen Mark Palmer en de blogosfeer met betrekking tot de looptijd van CEP .** Mark en anderen hebben een voorbeeld van het evenement verwerking in de kapitaalmarkten en noemen het "CEP," wanneer je in feite wat ze doen is COTS algo de handel en het gebruik van een of meer functionele componenten van CEP aan het realiseren van hun oplossing.
Het is een belangrijk onderscheid, in mijn mening.



Bron ...