Sponsored Content
Special Forums News, Links, Events and Announcements Complex Event Processing RSS News CEP is to Architecture as SOA is to Architecture Post 302218576 by Linux Bot on Friday 25th of July 2008 03:10:05 PM
Old 07-25-2008
CEP is to Architecture as SOA is to Architecture

Tim Bass
07-25-2008 11:38 AM
I am often asked pointed questions (mostly from the stream processing crowd) like, ” What product does CEP?”* Sometime it seems my answer determines the fate of that relationship, as my feet are grilled over the CEP-fire to be beat of jungle drums!* The amount of money I have lost in deals that did not go through because I refused to sprinkle holy water on a vendor’s product and call it “CEP” is staggering, quite frankly.

CEP describes an architecture, just like SOA describes an architecture and just like EDA describes an architecture.

For example, you do not buy an SOA. * An SOA describes an architectural style of programming via components that are involved as services in a distributed network architecture - a service-oriented, or service-based architecture.

The concept of CEP does not have “the A-word” like SOA and EDA, but none-the-less, CEP describes an architecture, not a product.** Do not make the mistake of thinking in terms of “buying CEP”, just like you do not buy an SOA or an EDA.* You think, plan and design in terms of CEP, just like you should do in an SOA or EDA.* These are constructs, not products.

In other words, for “true CEP” you need a number of components, some of the components might be in the architectural style of SOA, others might be in the architectural style of EDA.** Your solution architecture for solving a complex event processing problem might have request-reply transactions, or it might have fire-and-forget messages.* You might have a Neural Networking component for analytics and a rules component for filtering, mediation and scheduling.* You might even have a stream processing component performing as a high performance filter and pattern matcher on streaming data where the output is forwarded to a Bayesian Classifer for further processing.

My key message in this post is that CEP requires a number of technologies to solve complex distributed computing problems.** Do not be fooled into thinking that a single product is “CEP” no more than a single product is SOA or EDA.



Source...
 

3 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

A question about Unix Architecture.

I want to know the memory capacity and types of memories, processor and more... What kind of aplications this OS attends? Archicture/system classification (Hybrid, monolithic, multitasking, micro-kernel, layered, Another..? Explain it to me... I really need to understand and know that. Any... (3 Replies)
Discussion started by: AlissonManson
3 Replies

2. Ubuntu

Dpkg architecture

I noticed dpkg reporting architecture as AMD64, but the h/w is Intel, see below: ~$ uname -a Linux XXX 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux ~$ lshw | grep -i xeon WARNING: you should run this program as super-user. PCI (sysfs) ... (2 Replies)
Discussion started by: migurus
2 Replies

3. Shell Programming and Scripting

64-32 architecture checker also OS version

hello is it possible to check systsme architecture and also system OS versions? like 32 bit centos 5 64 bit centos 6 how about cpu versions? (6 Replies)
Discussion started by: nimafire
6 Replies
cdtoc(4)							   File Formats 							  cdtoc(4)

NAME
cdtoc - CD-ROM table of contents file DESCRIPTION
The table of contents file, .cdtoc, is an ASCII file that describes the contents of a CD-ROM or other software distribution media. It resides in the top-level directory of the file system on a slice of a CD-ROM. It is independent of file system format, that is, the file system on the slice can be either UFS or HSFS. Each entry in the .cdtoc file is a line that establishes the value of a parameter in the following form: PARAM=value Blank lines and comments (lines preceded by a pound-sign, ``#'') are also allowed in the file. Parameters are grouped by product, with the beginning of a product defined by a line of the form: PRODNAME=value Each product is expected to consist of one or more software packages that are stored together in a subdirectory on the distribution media. There can be any number of products described within the file. There is no required order in which the parameters must be specified, except that the parameters must be grouped by product and the PRODNAME parameter must appear first in the list of parameters for each product specified. Each parameter is described below. All of the parameters are required for each product. PRODNAME The full name of the product. This must be unique within the .cdtoc file and is preferably unique across all possi- ble products. This value may contain white space. The length of this value is limited to 256 ASCII characters; other restrictions may apply (see below). PRODVERS The version of the product. The value can contain any combination of letters, numbers, or other characters. This value may contain white space. The length of this value is limited to 256 ASCII characters; other restrictions may apply (see below). PRODDIR The name of the top-level directory containing the product. This name should be relative to the top-level directory of the distribution media, for example, Solaris_2.6/Product. The number of path components in the name is limited only by the system's maximum path name length, which is 1024 ASCII characters. Any single component is limited to 256 ASCII characters. This value cannot contain white space. The lengths of the values of PRODNAME and PRODVERS are further constrained by the fact that the initial install programs concatenate these values to produce the full product name. For unbundled products the combined length of the values of PRODNAME and PRODVERS must not exceed 256 ASCII characters. When you install OS services with Solstice Host Manager, directories for diskless clients are created by constructing names derived from a concatenation of the values of PRODNAME, PRODVERS, and client architecture, for example, /export/exec/Solaris_2.x_sparc.all/usr/platform. The length of the component containing the product name and version must not exceed 256 ASCII characters. Thus, for products corresponding to bundled OS releases (for example, Solaris 2.4), the values of PRODNAME and PRODVERS are effectively restricted to lengths much less than 256. The initial install programs use the value of the PRODDIR macro in the .cdtoc file to indicate where packages can be found. EXAMPLES
Example 1: Sample of .cdtoc file. Here is a sample .cdtoc file: # # .cdtoc file -- Online product family CD # PRODNAME=Online DiskSuite PRODVERS=2.0 PRODDIR=Online_DiskSuite_2.0 # PRODNAME=Online Backup PRODVERS=2.0 PRODDIR=Online_Backup_2.0 This example corresponds to the following directory layout on a CD-ROM partition: /.cdtoc /Online_DiskSuite_2.0 ./SUNWmddr.c ./SUNWmddr.m ./SUNWmddu /Online_Backup_2.0 ./SUNWhsm The bundled release of Solaris 2.6 includes the following .cdtoc file: PRODNAME=Solaris PRODVERS=2.6 PRODDIR=Solaris_2.6/Product This file corresponds to the following directory layout on slice 0 of the Solaris 2.6 product CD: /.cdtoc /Solaris_2.6/Product ./SUNWaccr ./SUNWaccu ./SUNWadmap . . . ./SUNWutool SEE ALSO
clustertoc(4), packagetoc(4), pkginfo(4) SunOS 5.10 14 Sept 2004 cdtoc(4)
All times are GMT -4. The time now is 09:05 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy