On flow oriented and component oriented development of EP applications Post: 302231488

Sponsored Content

Special Forums News, Links, Events and Announcements Complex Event Processing RSS News On flow oriented and component oriented development of EP applications Post 302231488 by Linux Bot on Tuesday 2nd of September 2008 12:00:05 PM

09-02-2008

Registered User

On flow oriented and component oriented development of EP applications

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

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...

Linux Bot

View Public Profile for Linux Bot

Find all posts by Linux Bot

4 More Discussions You Might Find Interesting

1. 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.

2. 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...

3. 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...

4. 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

LEARN ABOUT DEBIAN

mheard

MHEARD(1)						     Linux Programmer's Manual							 MHEARD(1)

NAME

       mheard - display AX.25 calls recently heard.

SYNOPSIS

       mheard [-d cmns] [-n] [-o cfpt] [-v] [port...]

DESCRIPTION

       Mheard  displays  information about most recently heard AX.25 callsigns, the interface upon which they were heard, the total packets heard,
       the time at which the last one was heard and other information.	Mheard displays different information, in different  orders  depending	on
       the settings of the arguments. Information on specific ports can be displayed by giving the port names as arguments.

OPTIONS

       -d cmns	    Sets the information that is displayed for each AX.25 callsign heard. The different arguments are:

		    c	 Display all the information with regard to callsigns, from-callsign, to-callsign, port name, and any digipeaters that may
			 be in use.

		    m	 Display miscellaneous information, the from-callsign, port name, no frames heard, the last  type  of  frames  heard,  and
			 which different PIDs have been heard from that station.

		    n	 Display the default information. This is the from-callsign, port name, no frames heard and the date and time last heard.

		    s	 Displays  statistics  about  the station heard, the from-callsign, port name, no I frames, no S frames, no U frames, time
			 first heard, and time last heard.

       -n	    Supress the displaying of titles.

       -o cfpt	    Sets the ordering of the information displayed. The meanings of the different arguments are:

		    c	 Sort list by from-callsign.

		    f	 Sort list by number of frames heard.

		    p	 Sort list by port name.

		    t	 Sort list by the time last heard, this is the default.

       -v	    Display the version.

FILES

       /var/ax25/mheard/mheard.dat
       /etc/ax25/axports

SEE ALSO

       ax25(4), mheardd(8).

AUTHOR

       Jonathan Naylor G4KLX <g4klx@g4klx.demon.co.uk>

Linux								  19 August 1996							 MHEARD(1)