Login or Register for Dates, Times and to Reply

Thread Tools Search this Thread
# 1  

Tim Bass
Tue, 25 Sep 2007 01:37:13 +0000
The marketing folks and their friends are buzzing with hype.* Well intended, they want to convince the marketplace that EDA is really a type of SOA, or that EDA is an evolution of SOA. Unfortunately for the end user, they are mostly off target.
Normally, I agree with Dr. David Luckham regarding CEP and event processing, but I must admit I do not agree with his certain parts of his recently postings on SOA and EDA. On this topic, I tend to agree with Dr. Mani Chandi.
Mani gave an excellent talk at the recent Gartner Event Processing Symposium titled, Evaluating Costs and Benefits of Event-Driven Applications. In his keynote presentation, Dr. Chandi did not make any marketing statements about EDA (and events) somehow being the “magic” missing from SOA.* Instead, he focused his keynote on the differences between SOA (request-reply) and EDA (proactive event push) and how to determine the best architectural pattern (EDA, SOA or both) when designing an application.
I was really pleased to listen to a CEP presentation based on sound design principles and not on the “EDA piggybacks on SOA market share” story to promote CEP and EDA. Most, if not all, good network engineers know that orchestrated request-reply is quite different than asynchronous event processing.* Only marketing folks would convince us otherwise, hoping to somehow get the CEP “camel’s nose” under the “SOA tent”!
Baa Humbug!
There is a downside (more than one!) to trying to put the CEP nose under the SOA tent. First of all, SOA, while a great idea, suffers from over hype and the increasing weight of it’s less-than-successful status, even after years of over marketing.* Secondly, EDA and CEP actually have a chance of success.* SOA has seen such a lack of progress that the analysts continue to redefine it, so it will eventually fit somewhere!
If you fly high enough, the snow bears, the igloos and the snow all look white - and we are seeing folks flying snow blind in the EDA and SOA space.
Network engineers have been dealing with events and EDA in the form of SNMP traps for many years, and SOA in the form of polling devices for information for the same amount of time.* Experienced engineers don’t debate which is better, SNMP traps or SNMP polling, they use the appropriate pattern based on solid design principals and engineering tradeoffs, just like Dr. Chandi discussed in his recent presentation.EDA is not SOA. SOA is not EDA.
Let’s don’t send CEP on an ill-fated flight to the future of event processing with a large SOA stone around it’s neck.

Login or Register for Dates, Times and to Reply

Previous Thread | Next Thread
Thread Tools Search this Thread
Search this Thread:
Advanced Search

Test Your Knowledge in Computers #56
Difficulty: Easy
A flip-flop circuit stores 1 bit of data.
True or False?
named-xfer(8)						      System Manager's Manual						     named-xfer(8)

named-xfer - Pulls BIND zones from another server SYNOPSIS
/usr/sbin/named-xfer -z zone_to_transfer -f db_file -s serial_no [-d debug_level] [-l debug_log_file] [-t trace_file] [-p port] [-S] servers... OPTIONS
Specifies the name of the BIND zone for the named-xfer daemon to transfer, for example, dec.com. This option is required to pull a zone. Specifies the name of the file into which the pulled zone information is placed. This option is required to pull a zone. Specifies the current serial number of the SOA record for the zone zone_to_transfer. If serial_no is set to 0, the zone is always pulled. This option is required to pull a zone. Sets the debug level and determines the amount of debug information to be displayed. Specifies the file that will contain any debug messages from the zone pull. Specifies the file that will contain a trace from the zone pull. Specifies the port that will be used instead of the default name server port listed in /etc/services. Performs a restricted transfer of only the SOA, NS records and glue A records for the zone. The SOA record is not loaded by named, but is used to determine when to verify the NS records. See named(8) for more information. Specifies a list of Internet addresses, in dotted-quad format, from which to pull a zone. If the first host cannot be reached, the named transfer daemon tries to pull the zone from the next host listed. DESCRIPTION
The named transfer daemon, /usr/sbin/named-xfer, is a server that is usually run by the named daemon, /usr/sbin/named, but it can also be run manually with the given arguments. The named transfer daemon runs on a BIND secondary server and pulls BIND zones from a primary server. This daemon is not run by default, nor can it be started up from inetd(8). SEE ALSO
Commands: named(8) Files: resolver(4), services(4) named-xfer(8)

Featured Tech Videos