EDA and Incremental ETL
Jul 17th, 2011 | By raja shankar kolluru | Category: architecture, design, FeaturedEvent Driven Architecture (EDA) is a paradigm that I became familiar with when I was coding the earliest GUI components. The user interaction with a GUI application is modeled as a series of events that the application responds to. There is an “infinite loop” of events which can potentially be engendered by user interactions with a graphical application. The user responds to an application by potentially typing on the keyboard, clicking on certain segments of a GUI (such as a button for instance) with his mouse, hovering over certain regions etc. Individual GUI components respond to these events as they deem fit and perform various actions. Each c0mponent took charge of maintaining its own events and was able to invoke common services in response to them.
A Segue – Enterprise Architecture & Systems of Records
Let us consider a different problem. Let us think about an enterprise with a large number of applications.
As the enterprise started fanning out to envelope multiple enterprise applications, it becomes imperative to reckon with a large number of different databases of information often called as systems of records.
For instance, let us take the example of a large enterprise that has thousands of employees.
There would be an employee system of record that stores details about the employees. There would be multiple applications that the enterprise might have to use to discharge its day to day activities. These applications might all require access to the employee database for both validation and other purposes. Ex: The accounting application might want to add an employee as an “owner” to each account.
SOA & The Enterprise
How do these applications access employee information? One option is to use SOA and hide the employees data behind a service. The Employee Service is responsible for maintaining employees and facilitating updates to the central Employee System of Record. This approach is great but can have a few drawbacks:
- If there is a batch process (such as a scheduled job) that iterates over multiple records in the database and for each record needs to obtain employee information, then this might suffer from the (n+1) selects problem that is mentioned elsewhere in this blog.
- It is hard to enforce reference integrity constraints between an entity in a local database and an employee since the employee information is only available via SOA. Ex: How do we ensure that all accounts owners are valid employees?
Replicated Data & ETL
EDA & Real time Incremental ETL
No related posts.


Technorati
Picasa
Twitter
LinkedIn
Facebook
Flickr
Delicious
Excellant explanation and example. Found this material to be more juicy than some of the material that I have read in books and other sites like theserverside.com.
Thanks Adit.