Jan and John Green

lancelotlinc

 
cd
Event Driven SOA

Event-driven Service Oriented Architecture is an approach to distributed SOA design that promotes the use of smaller, more finite Web Services that can be combined into applications and driven by events that occur in the application. While some human data input may be used to initiate events, the character and quality of the application is known by its automated focus on processing events, without human intervention.

 

The Enterprise Service Bus is the heart of the Service Oriented Architecture and is a software pattern. Some companies produce products that can be used to create and host the ESB pattern. Techniques described and promoted in this wiki work with all products, including IBM WebSphere Message Broker, FUSE/ServiceMix, and Oracle Service Bus/OpenESB. Of these three offerings, IBM WMB is the most advanced and sophisticated. WMB has a toolkit that is used to graphically assemble ESB patterns called Message Flows using drag-and-drop nodes, whereas the other two (ServiceMix and OpenESB) rely on the programmer to construct viable service flows through plain-text Java Business Integration (JBI). JBI has the disadvantage of relying on custom code or open-source parsers whereas WMB's cornerstone advantage is the exemplary work on the XMLNSC and DFDL parsing technology.

 

The most important aspect of any Service Oriented Architecture is the design of data. Because legacy systems must remain operational and in-place, their data formats cannot be changed to improve their efficiency. Application A designed and implemented in the 1980s represents a customer much differently than Application B which was implemented in the 1990s. When the company acquired a competitor in the 2000s, still other data structures defined the customer still differently. Thus the need for the Data Warehouse and several Data Marts, which are central parts of any SOA implementation.

 

Connecting Application A to the Data Warehouse can involve extensive data transformation. Usually, this transformation takes place inside the Enterprise Service Bus. Application A's code was debugged a long time ago, and business stakeholders do not want to change what works: code that has already been refined and tested. Therefore, to use a customer data structure from Application A that was written so long ago, the Application A legacy customer data structure is sent to a central location (Data Mart) through the ESB which transforms the Application A customer data structure into the common representation of a customer that is the new standard as stored in the Data Warehouse.

 

Some companies track changes to customer data for various reasons: for example, to know who changed what when. Data history tracking creates what is known as bi-temporal data. Bi-temporal data is very useful to a company when, for example, the company needs supporting data for a lawsuit or other administrative action. Insurance companies use bi-temporal data in many ways, one of the chief uses is to discover insurance fraud or drive changes to other risk management initiatives. The Enterprise Service Bus performs a unique role in creating such records in an efficient way. Insurance company underwriting processes consume bi-temporal data to adjust the rate structure of a particular product. This is an example of how events within a SOA application trigger automatically intelligent responses to protect the company from undue losses. Other examples are energy companies: electric, natural gas, oil and coal producers use bi-temporal event-driven SOA applications to adjust rates of products moment-by-moment.

 

Within this wiki site, there are source code examples that you can use to build a robust Event-Driven SOA architecture. The source code examples are written so that they can run in cooperation with any ESB pattern and any product that implements the ESB pattern. Professional services are available to help you and your company get pointed in the right direction adopting, implementing, and promoting the good direction. lancelotlinc at gmail dot com (785) 260-0150.