Book Image

Service Oriented Architecture: An Integration Blueprint

Book Image

Service Oriented Architecture: An Integration Blueprint

Overview of this book

Service Oriented Architecture (SOA) refers to building systems that offer applications as a set of independent services that communicate and inter-operate with each other effectively. Such applications may originate from different vendor, platform, and programming language backgrounds, making successful integration a challenging task. This book enables you to integrate application systems effectively, using the Trivadis Integration Architecture Blueprint, which is supported by real-world scenarios in which this Integration Blueprint has proved a success.This book will enable you to grasp all of the intricacies of the Trivadis Architecture Blueprint, including detailed descriptions of each layer and component. It is a detailed theoretical guide that shows you how to implement your own integration architectures in practice, using the Trivadis Integration Architecture Blueprint. The main focus is on explaining and visualizing the blueprint, including comprehensive descriptions of all of its layers and components. It also covers the more basic features of integration concepts for less experienced specialists, as well as shedding light on the future of integration technologies, such as XTP and Grid Computing. You will learn about EII and EAI, OGSi, as well as base technologies related to the implementation of solutions based on the Blueprint, such as JCA, JBI, SCA and SDO.The book begins by covering fundamental integration for those less familiar with the concepts and terminology, and then dives deep into explaining the different architecture variants and the future of integration technologies. Base technologies like JCA and SCA will be explored along the way, and the structure of the Trivadis Integration Architecture Blueprint will be described in detail, as will the intricacies of each component and layer. Other content includes discovering and comparing traditional and modern SOA driven integration solutions, implementing transaction strategies and process modeling, and getting to grips with EDA developments in SOA. Finally, the book considers how to map software from vendors like Oracle and IBM to the blueprint in order to compare the solutions, and ultimately integrate your own projects successfully.
Table of Contents (11 chapters)
Service-Oriented Architecture: An Integration Blueprint
About the Authors

Event-driven architecture

Event-driven architecture (EDA) is one of the hot topics of the industry. These architectures are often wrongly referred to as the successors to SOAs (Mühl et al. 2006). In fact, the concepts involved in EDA are as old as IT itself. In addition, EDAs are growing rapidly in popularity, together with the integration architectures of SOA. However, both types of architecture can be used completely independently of one another, and can be combined orthogonally. From the perspective of integration, two aspects of EDA are of particular interest:

  • The symbiosis between EDA and SOA that has already been referred to, which allows SOA domains to be linked/integrated together on an event-driven basis.

  • The technology offered by EDA which enables events from one or more event streams on the data integration level to be consolidated into new information.

Introducing EDA

According to a study by Gartner (Gartner 2006), the success of companies such as Dell and Google is due to the fact that these organizations are able to identify market factors or market events in the global marketplace at an early stage, and follow them up consistently and quickly. Both examples are very close to the picture drawn by Gartner of an ideal organization: the real-time enterprise (RTE). An RTE is characterized by its highly-automated business processes and the shortest possible process runtimes (Nussdorfer, Martin 2003).

While SOA concepts within IT structures form the basis for the automation of business processes, the second step, which relates to the ideal image of the RTE, involves processing more fine-grained information about changes in the state of these business processes. The complexity of these state changes is increasing noticeably, in the same way that the number of reaction interfaces in the business processes is. This is where the significance of EDA lies, because the observable changes in the state of the business processes can be modeled as events. Classic integration architectures, such as OLTP (Online Transaction Processing) ) or OLAP (Online Analytical Processing) are no longer able to meet the requirements for rapid and consistent action on the basis of event analyses (Zeidler 2007).

The above diagram illustrates the symbiosis between EDA and SOA, which is often referred to as SOA 2.0 (Carter 2007) or Next Generation SOA (Luckham 2002). An SOA or an SOA domain provides the technical services, independently of consumers. These services can be combined or orchestrated, and they form the building blocks for the business processes. If a service of this kind triggers an event, for example because of a change in its state, an orthogonal EDA extension can activate a new SOA domain. As a result, a service becomes an event-producing building block in an EDA. In contrast to the typical producer/consumer patterns of an SOA, the EDA largely uses a publish/subscribe mechanism. An event processor processes the events as they occur, and publishes the processed results via an event channel, which triggers the services of other SOA domains. Various types of event processor are used depending on the type of event processing required. These include Complex Event Processors (CEP), for example, which are described later in this chapter.

The SOA domains (to be integrated) should ideally be defined in such a way that they represent reusable services which can be used several times in business process chains of any length. The principle of loose coupling for the formation of such flexible business process chains is of decisive importance in the EDA, in the same way as it is in the SOA.

Event processing

The second aspect of integration that we want to highlight is of a more technical nature. It concerns the possibilities for event processing within an EDA concept, as shown in the following figure:

Event-processing technologies have been in day-to-day use in many industries for several years. Examples include algorithmic trading in stock markets and Radio Frequency Identification (RFID) in road charging systems.

There are three fundamental types of event processing:

  • Simple Event Processing (SEP)

  • Event Stream Processing (ESP)

  • Complex Event Processing (CEP)

Simple Event Processing (SEP)

Events occur either individually, or in streams. Single events can be regarded as an important change in state in a message source and, in particular, in a business event. Events of this kind typically trigger processes in the systems which receive the message. This form of event processing corresponds exactly with the specification of the Java Messaging Service (JMS). Therefore, a typical example of SEP is JMS.

Event Stream Processing (ESP)

ESP involves processing streams of incoming messages or events. Typical ESP systems have sensors which channel a large number of events, and use filters and other processing methods to influence the stream of messages or events. Individual events are less important, and instead the focus is on the event stream. Well-known examples include the systems which track stock market prices: one single fluctuation in prices is generally not particularly significant. A more informative overall trend can only be determined from several events.

Complex Event Processing (CEP)

The third form of event processing is Complex Event Processing, which is part of ESP. In CEP there is a strong focus on identifying patterns in a large number of events and their (message) contents, which may be distributed across different data streams.

The CEP funnel model is illustrated in the following figure:

The CEP funnel model illustrates the process of compressing (large) volumes of events to produce compressed information. The source of the events includes business events (Viehmann 2008). One of the classic uses of CEP is in tracing credit card fraud. In the case of two transactions using the same credit card, which were made within a short period of time, in locations a long distance apart, this type of geographical and chronological pattern indicating the possibility of fraud, can easily be applied to the model. Systems of this kind, which correlate thousands of events in order to filter out the few cases of fraud or misbehavior, are more and more frequently in use.