Event-driven SOA

Last updated

Event-driven SOA is a form of service-oriented architecture (SOA), combining the intelligence and proactiveness of event-driven architecture with the organizational capabilities found in service offerings. Before event-driven SOA, the typical SOA platform orchestrated services centrally, through pre-defined business processes, assuming that what should have already been triggered is defined in a business process. This older approach (sometimes called SOA 1.0) does not account for events that occur across, or outside of, specific business processes. Thus complex events, in which a pattern of activities—both non-scheduled and scheduled—should trigger a set of services is not accounted for in traditional SOA 1.0 architecture.

Contents

SOA 2.0

SOA 2.0 architecture, ("event-driven SOA"), lets business users monitor, analyze, and enrich events to make the connections among disparate events that do not at first appear to be intuitively obvious. This makes these enriched events visible to others, especially business analysts or marketing directors, and also allows the SOA 2.0 system to possibly automate actions to take to address some unique pattern. [1]

SOA 2.0 is the ability to create high-level business events from numerous low-level system events. Events are created by filtering real-time data (from middleware, applications, databases, and Web services, for example) and infusing it with defining detail such as dependencies or causal relationships discovered by correlating other events.

If it's clear, through the enriched events that are produced by an SOA 2.0 environment, that customer shopping cart abandonment rate has escalated in the last few days, a notification to the marketing department could initiate research into what competitors have done to cause customers to buy products elsewhere. Was there a common product in most shopping carts? If so, what are the prices that are being offered by the competition?

In practice, this relationship of streamed events is processed through a causal vector engine, which performs a lookup based on recently viewed events and assigns a causal vector to an event if a relationship is discovered. If A causes B, the causal vector engine checks if B’s causal vector rule index contains a reference to A. The engine may handle events for different transactions simultaneously, perhaps in a different order than they occurred.

Unlike sequential or procedural systems (in which clients must poll for change requests), event-driven SOA allows systems and components to respond dynamically, in real time, as events occur. SOA 2.0 complements and extends SOA 1.0 by introducing long-running processing capabilities.

Long running processing capability enables the architecture to collect various asynchronous events over a long period of time and correlate these events into causal relationships. SOA 2.0 event patterns can be designed and implemented to look for event relationships that span days, weeks, or months; and when certain criteria are met, trigger a business process to address the event pattern.

SOA 2.0 event-driven programming is structured around the concept of decoupled relationships between event producers and event consumers: an event consumer doesn't care where or why an event occurs; rather, it's concerned that it will be invoked when the event has occurred. Systems and applications that separate event producers from event consumers typically rely on an event dispatcher, or channel. This channel contains an event queue that acts as an intermediary between event producers and event handlers.

Prototypical SOA 2.0 paradigm

The prototypical SOA 2.0 paradigm contains four essential elements:

  1. multiple low-level system events that, separately, do not appear to have any relationship, but through pattern detection by comparing these many events some unusual or less obvious correlation becomes clear;
  2. some amount of data enrichment by infusion of related information to each event to more clearly illustrate how the many events are related;
  3. a trigger condition which when not met, the business-level event is not created, but when the trigger condition is met, the higher-level business event is created;
  4. some human or automated process that is invoked when the trigger event is reached.

SOA 2.0 Web Services can be composed in two ways: orchestration and choreography. In orchestration, a central process takes control over the involved web services and coordinates the execution of different operations on the web services involved in the operation. The involved SOA 2.0 services do not know (and do not need to know) that they are part of a composition or a higher business process. Only the central coordinator of the orchestration knows this, so the orchestration is centralized with explicit definitions of operations and the order of invocation of SOA 2.0 services.

Choreography on the other hand does not rely on a central coordinator. Rather, each SOA 2.0 service involved in the choreography knows exactly when to execute its operations (based on defined trigger criteria) and whom to interact with. Choreography is a collaborative effort focused on exchange of messages. All participants of the choreography need to be aware of the business process, operations to execute, messages to exchange, and the timing of message exchanges.

BPEL follows the orchestration paradigm. Choreography is covered by other standards, such as WSCI (Web Services Choreography Interface) and WS-CDL (Web Services Choreography Description Language).

Multiple low-level system events

Causal relationships are inherent in the world around us and are intrinsic to our decision making. The human intelligence processes and gathers these relationships faster than current artificial computational capability can. One of the fundamental obstacles in artificial intelligence is the absence of an automated ability to relate events together as when a human uses human intuition.

Using a Causal Vector Engine, the perception of causality can be enhanced under appropriate spatiotemporal conditions based on structural and temporal rules written into the engine. Perception of complex causal semantics, such as additive, mediated, and bidirectional causalities need to be coded so that the engine can distinguish between events that are related and those that only appear to be related but, in fact, are not.

The engine uses preponderant causal vector rate-of-change propagation to code the relationship among the events and establishes a partial order in which it validates the causality perceived between multiple occurrences. The engine plays and replays the event sequence in different temporal order to infer what could be related topological connections and compares these replays to rules preprogrammed by an analyst.

Multiple low-level system events are processed by the Causal Vector Engine and compared against these rules to trigger higher-level Business Events. It does this through a Causality Vector Engine (CVE) console application which displays events in real-time to business analysts. Where streams of events can be observed as they occur, much like a stock ticker, the CVE console app has several windows that list the same events in different contexts, so the business analysts can see what the CVE is doing with the relationships between them.

The Sequential window shows events in date-timestamp order, one or more other windows in various orders as the CVE works through the list of rules and creates implied relationships between the events. Various buttons and controls exist in the console application that enable the business analysts to create relationships between events on-the-fly and define rules that respond to these relationships.

Business analysts can infuse additional defining detail through an SQL query statement attached to a rule or event context. The CVE app works much like a modern-day stock trading application that mutual funds managers use to manage risk. An example of a CVE application and engine can be seen in SILK. [2]

Data enrichment

Most enterprise service bus (ESB) implementations contain a facility called "mediation". For example, mediation flows are part of the WebSphere enterprise service bus intercept. Mule also supports mediation flows. Mediation flows modify messages that are passed between existing services and clients that use those services. A mediation flow mediates or intervenes to provide functions, such as message logging, data transformation, and routing, typically the functions can be implemented using the Interception Design Pattern. [3]

As messages pass through the ESB, the ESB enriches the messages destined for a channel that is monitoring for a high-level business event. That is, for each message, the ESB may query a database to obtain additional information about some data entity within the message. For example, based on Customer ID, the ESB mediation flow could get the zip code that the customer resides in. Or, based on IP address of the originating request by the end-user, the ESB mediation flow could lookup what country, state or county that IP address is in.

These examples represent data enrichment, the concept of adding additional value to existing data, based on the intent of the high-level business event to eventually be triggered.

Mediation flows

An ESB mediation flow is one of the component types in a Service Component Architecture (SCA). Like any SCA component, the program accesses a mediation flow through exports that it provides, and the mediation flow forwards messages to other external services via imports. Special kinds of imports and exports for JMS, called JMS bindings, enable developers to specify the binding configuration and write data handling code. The mediation flow consists of a series of mediation primitives that manipulate messages as they flow through the bus.

Once the developers have coded the custom binding for both export and import, they can start to focus on the mediation flow component. In the WebSphere Integration Developer assembly editor, this is done by the JMS Custom Binding Mediation Component where each operation on the flow component's interface is represented by a request and a response.

Service Data Objects (SDO) framework provides a unified framework for data application development. With SDO, developers do not need to be familiar with any specific API in order to access and utilize data. Through SDO, developers simply work with data from multiple data sources, such as relational databases, entity EJB components, XML pages, Web services, the Service Component Architecture, and JavaServer Pages pages.

Mediation flows are entirely independent from the bindings that are used in the imports and exports. In fact, the purpose of having a conversion into an SDO DataObject instance outside of the flow implementation is because mediation flows can then be built without knowledge of the protocol and format with which messages are sent to and from the mediation module.

Business-level trigger condition

A business-level trigger condition enables the SOA 2.0 architecture to establish real-time customer intelligence, marketing automation and customer loyalty solutions, among other features. Business objects model real-world entities in the architecture such as customers, accounts, loans, and travel itineraries. When the state of one of these objects changes, and a monitoring agent notices this change is significant (when compared to the list of criteria to monitor), an event is created and passed to other monitoring agents.

For example, the detection of an actual business problem or opportunity could lead to increased revenue. If a customer cancels an order, extra manufacturing capacity could reduce the profitability of the production run. A SOA 2.0 event could notify marketing department to create a special sales campaign that would resell the excess capacity, thereby recapturing the original profitable cost-per-unit.

Automatic monitoring of events in operational business process activities as processes execute to see if any immediate action needs to be taken either inside or outside the enterprise. These monitoring agents continually test for specific business conditions and changes in business operations. If necessary, the agents alert people, make recommendations, send messages to other applications or invoke whole business processes when such conditions or changes occur..

Resulting business process

A triggered business process should directly support revenue growth with cost containment, responsiveness to business conditions, or ability to pursue new market opportunities. Resulting business processes could also measure operational progress toward achieving goals, control operational costs by communicating just what is needed to just who needs to know, or report performance status of key processes to key decision makers.

SOA 2.0 conceptual examples

Abandoned shopping cart

For example, you could construct a CRM event from an "abandoned shopping cart" message (parsing the transaction, customer ID, and time), using other filters to extract the value of goods in the cart and tapping the correlation capabilities of the system to add causal indicators such as whether the commerce site was suffering performance problems. Your CRM event might also include customer value or rank from the customer database...

Engineering defect

For another example, based on the types of independent service calls received, the SOA 2.0 platform could identify a product defect by detecting the underlying pattern of the separate complaints, then triggering an alert to engineering or production of the possible defect.

SOA 2.0 implementations

One mechanism that can be used from most SOA 1.0 Enterprise Service Bus implementations is the publish/subscribe facility. By implementing ESB functionality as Pub/Sub messages, no advanced knowledge of system events is needed to create SOA 2.0 message patterns. After an enterprise has implemented many Publish functions, SOA middleware analysts can set about the task of strategizing which of the available Publish messages could be assembled into a unique pattern to detect an SOA 2.0-enriched trigger.

Causal Vector Engine (CVE) mechanics are implemented simply, with an expandable view of SQL constructs written in stored procedures. [4] If A causes B, and causality must occur within N number of transactions, then SQL ORDER BY timestamp clause creates a result set that increments a counter of all transactions that occurred within a timeframe, N number of matching B to occurrence A transactions. The creation of additional stored procedures is accomplished through the CVE console application or by using any standard database developer's toolkit. [5]

Medical applications

Domain algorithms, such as fever/flu/infection domain logic in the cited reference, are used to derive SQL code that applies the selected business rules to the use case. Using CVEs in SOA environments improve business agility because the application of SOA 2.0 principles identify business opportunities that would have otherwise been missed or identified much later. [6]

Functional magnetic resonance imaging (fMRI) using Granger causality analysis (GCA) detects causal effects among brain regions. The results of one sample test demonstrated positive causal effect between rFIC and the dorsal anterior cingulate cortex (dACC). [7]

Oracle Business Intelligence

The Oracle CVE Analytical Engine uses a set of theoretical models, each of which evaluates some or all of the data. When a business analyst configures causal factors, he/she specifies criteria indicating which models should consider which causal factor. [8]

See also

Related Research Articles

Middleware in the context of distributed applications is software that provides services beyond those provided by the operating system to enable the various components of a distributed system to communicate and manage data. Middleware supports and simplifies complex distributed applications. It includes web servers, application servers, messaging and similar tools that support application development and delivery. Middleware is especially integral to modern information technology based on XML, SOAP, Web services, and service-oriented architecture.

<span class="mw-page-title-main">BEA Systems</span> Defunct American software corporation

BEA Systems, Inc. was a company that specialized in enterprise infrastructure software products, which was wholly acquired by Oracle Corporation on April 29, 2008.

Software AG is a German multinational software corporation that develops enterprise software for business process management, integration, and big data analytics. Founded in 1969, the company is headquartered in Darmstadt, Germany, and has offices worldwide.

In software engineering, service-oriented architecture (SOA) is an architectural style that focuses on discrete services instead of a monolithic design. By consequence, it is also applied in the field of software design where services are provided to the other components by application components, through a communication protocol over a network. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.

<span class="mw-page-title-main">Enterprise service bus</span> Communication system in a service-oriented architecture

An enterprise service bus (ESB) implements a communication system between mutually interacting software applications in a service-oriented architecture (SOA). It represents a software architecture for distributed computing, and is a special variant of the more general client-server model, wherein any application may behave as server or client. ESB promotes agility and flexibility with regard to high-level protocol communication between applications. Its primary use is in enterprise application integration (EAI) of heterogeneous and complex service landscapes.

In computing and systems design, a loosely coupled system is one

  1. in which components are weakly associated with each other, and thus changes in one component least affect existence or performance of another component.
  2. in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components. Subareas include the coupling of classes, interfaces, data, and services. Loose coupling is the opposite of tight coupling.

A business rules engine is a software system that executes one or more business rules in a runtime production environment. The rules might come from legal regulation, company policy, or other sources. A business rule system enables these company policies and other operational decisions to be defined, tested, executed and maintained separately from application code.

A mashup, in web development, is a web page or web application that uses content from more than one source to create a single new service displayed in a single graphical interface. For example, a user could combine the addresses and photographs of their library branches with a Google map to create a map mashup. The term implies easy, fast integration, frequently using open application programming interfaces and data sources to produce enriched results that were not necessarily the original reason for producing the raw source data. The term mashup originally comes from creating something by combining elements from two or more sources.

Java Business Integration (JBI) is a specification developed under the Java Community Process (JCP) for an approach to implementing a service-oriented architecture (SOA). The JCP reference is JSR 208 for JBI 1.0 and JSR 312 for JBI 2.0. JSR 312 was removed from the JCP balloting process on 17 Dec, 2010 by the submitters without being accepted.

A service delivery platform (SDP) is a set of components that provides a service(s) delivery architecture for a type of service delivered to consumer, whether it be a customer or other system. Although it is commonly used in the context of telecommunications, it can apply to any system that provides a service. Although the TM Forum (TMF) is working on defining specifications in this area, there is no standard definition of SDP in industry and different players define its components, breadth, and depth in slightly different ways.

Mule is a lightweight enterprise service bus (ESB) and integration framework provided by MuleSoft. The platform is Java-based but, can broker interactions between other platforms such as .NET using web services or sockets.

Event-driven architecture (EDA) is a software architecture paradigm promoting the production, detection, consumption of, and reaction to events.

IBM App Connect Enterprise is IBM's premier integration software offering, allowing business information to flow between disparate applications across multiple hardware and software platforms. Rules can be applied to the data flowing through user-authored integrations to route and transform the information. The product can be used as an Enterprise Service Bus supplying a communication channel between applications and services in a service-oriented architecture.

OpenESB is a Java-based open-source enterprise service bus. It can be used as a platform for both enterprise application integration and service-oriented architecture. OpenESB allows developers to integrate legacy systems, external and internal partners and new development in business processes. It supports a multitude of integration technologies including standard JBI, XML with support for XML Schemas, WSDL, and BPEL with the aim of simplicity, efficiency, long-term durability, and low TCO.

Service-oriented architectures (SOA) are based on the notion of software services, which are high-level software components that include web services. Implementation of an SOA requires tools as well as run-time infrastructure software. This is collectively referred to as a service-oriented architecture implementation framework or (SOAIF). The SOAIF envisions a comprehensive framework that provides all the technology that an enterprise might need to build and run an SOA. An SOAIF includes both design-time and run-time capabilities as well as all the software functionality an enterprise needs to build and operate an SOA, including service-oriented:

Oracle Enterprise Service Bus, a fundamental component of Oracle's Services-Oriented Architecture suite of products, provides integration of data and enterprise applications within an organisation and their connected enterprises.

Java Composite Application Platform Suite (Java CAPS) is a standards-based enterprise service bus software suite from Oracle Corporation. The suite has several components that help to integrate existing applications and deliver new business services in a service-oriented architecture environment. It is a Java EE compliant platform and provides application-to-application integration, business-to-business integration, business process management along with integrated human workflow, an Enterprise Information Portal, extract transform and load (ETL), business activity monitoring and composite application development.

Middleware analysts are computer software engineers with a specialization in products that connect two different computer systems together. These products can be open-source or proprietary. As the term implies, the software, tools, and technologies used by Middleware analysts sit "in-the-middle", between two or more systems; the purpose being to enable two systems to communicate and share information.

The JBoss Enterprise SOA Platform is free software/open-source Java EE-based service-oriented architecture (SOA) software. The JBoss Enterprise SOA Platform is part of the JBoss Enterprise Middleware portfolio of software. The JBoss Enterprise SOA Platform enables enterprises to integrate services, handle business events, and automate business processes, linking IT resources, data, services and applications. Because it is Java-based, the JBoss application server operates cross-platform: usable on any operating system that supports Java. The JBoss SOA Platform was developed by JBoss, now a division of Red Hat.

Business-oriented architecture is an enterprise architecture approach for designing and implementing strategically aligned business models.

References

  1. "Make way for SOA 2.0". 17 May 2006.
  2. http://silk.semwebcentral.org/gui-ruleml-2010.pdf Archived 2013-05-21 at the Wayback Machine Causal Vector Engine GUI as Eclipse plug-in.
  3. "E. Curry, D. Chambers, and G. Lyons, "Extending Message-Oriented Middleware using Interception", presented at Third International Workshop on Distributed Event-Based Systems (DEBS '04), ICSE '04, Edinburgh, Scotland, UK, 2004" (PDF). Archived from the original (PDF) on 2011-07-26. Retrieved 2011-08-09.
  4. http://bicep.dei.uc.pt/images/5/58/FINCoS_DEBS2008.pdf Causal Vector Engine design.
  5. http://people.cis.ksu.edu/~bbp9857/bbp_hicss05.pdf Causal Vector Engine algorithmic toolkit.
  6. http://people.cis.ksu.edu/~bbp9857/bbp_hicss05.pdf Causal Vector Engine medical domain logic.
  7. Zang, ZX; Yan, CG; Dong, ZY; Huang, J; Zang, YF (2012). "Granger causality analysis implementation on MATLAB: a graphic user interface toolkit for fMRI data processing". J. Neurosci. Methods. 203 (2): 418–26. doi:10.1016/j.jneumeth.2011.10.006. PMID   22020117. S2CID   44845757.
  8. http://docs.oracle.com/cd/E18727_01/doc.121/e05136/T485796T488110.htm Oracle Business Intelligence engine makes extensive use of temporal data in historical and future time buckets.