On flow oriented and component oriented development of EP applications


 
Thread Tools Search this Thread
Special Forums News, Links, Events and Announcements Complex Event Processing RSS News On flow oriented and component oriented development of EP applications
# 1  
Old 09-02-2008
On flow oriented and component oriented development of EP applications

2008-09-02T16:13:00.005+03:00
Image



I got an invitation for some company I have not heard about for a kickoff of a product in the area of "seating in front of computers", I don't have time to go - but since they have also attached a picture of their product, I have copied it - I wonder if this is the current trend in ergonomy...


Anyway, today, some thoughts following a recent discussions here about development tools for event processing applications.

There are two possible ways, from the developer's point of view, to build an event processing network.
  • The first, which I'll call "component oriented" (may be there is a better name?), in which the developer defines the different components (patterns, rules, queries - use your favorite language style), each of them individually, and then some compilation process build the network implicitly. This is a kind of "bottom up" approach.
  • The second, which I'll call "flow oriented" , in which the developer has some graphical representation of the flow, and when building the flow, one can put some boxes inside the flow, and zoom to each box to define the component. This is a kind of "top down" approach.
It seems that each of them has benefits for other assumptions - if the application is dynamic and mainly subscription based, then the first approach is probably better, since the notion of flow is not a stable one; if the application is relatively static, then there is a benefit to use the second approach, since it can provide more visibility into what the application as a whole is doing, and help in the validation, since the "decoupling" principle may bring to the developments' feeling of chaos (this is indeed one of the barriers of the use of event processing...). As said, the "flow oriented" approach can ease the validation of event processing application, there are also some tools that help validating "implicit" flow, but the validation issue deserves discussion by its own right. More - later.



Source...
Login or Register to Ask a Question

Previous Thread | Next Thread

4 More Discussions You Might Find Interesting

1. Shell Programming and Scripting

How to use JavaScript in Perl Object Oriented

i am new to Perl CGI Object oriented. I want to use some java script in my Perl CGI but i am not able to do that. I am using Submit button then via param() i am getting all field parameters. But i want to validate all fields first then i want to move. But Use of Java script, i don't know (1 Reply)
Discussion started by: Navrattan Bansa
1 Replies

2. News, Links, Events and Announcements

ARM Based Community oriented to Job

Hi everybody, I write this small news in order to inform you an ARM network has been created around job opportunities and Vocational TRaining for student. This open group is coming together design, hardware software domains on ARM RISC Architecture. With more than 1,500 users from great... (0 Replies)
Discussion started by: ARMBasedGroup
0 Replies

3. Shell Programming and Scripting

Perl + object-oriented programming help

Currently Im trying to write a program that manipulates a class-based object as part of its functionality. However, the perl compiler is complaining that the class's respective package is not returning a true value. I have done the following a) Created a new package containing the body of the... (1 Reply)
Discussion started by: JamesGoh
1 Replies

4. Shell Programming and Scripting

A screen oriented command!!

Does a screen-oriented commands require you to specify an exact location or address for a particular operation ? Y or N cuz im having a debate right now in the office. (1 Reply)
Discussion started by: kprescod4158
1 Replies
Login or Register to Ask a Question