Service-Oriented Architecture: Event Web Building Block
This article is the second in a series about the Event Web (EW), Event Driven Architecture (EDA), and Sense and Respond (S&R) systems. The first article, "The Event Web: Sense and Respond to Critical Conditions," introduced these concepts. This article discusses software architectures in general and service-oriented architecture (SOA) in particular. The Event Web is based as much on SOA as on EDA, so this discussion offers a review of SOA. The next article will describe EDA in greater detail.
Review of Fundamental Concepts
S&R systems amplify human capability to respond to threats and opportunities. They monitor events both outside and inside an organization, create the changing big picture by integrating information from multiple sources of events, identify new opportunities and threats as the big picture changes, and respond by invoking applications and sending alerts to devices. The EW is a S&R utility that helps people respond to critical conditions in their environments. EDA is the architecture that allows for the systematic structuring of S&R applications. EDA components monitor the environment, process events, and respond to changing conditions continuously.
SOA supports composition of services. SOA is the culmination of a development, over many decades, of modular program construction based on function (or procedure) calls. Procedural composition, object-oriented programming, client/server structures, and SOA are compositional software structures based primarily on request/response calls: synchronous requests to components that reply to each request with a response. The components are quiescent until they receive a request. By contrast, EDA continuously senses and responds to the environment.
You probably are familiar with software architecture (see Figure 1), but a refresher on the subject will help set the stage for the comparison of SOA and EDA to follow.
Figure 1: Architecture Definition and Schema
As Figure 2 shows, architectures are composed of the following:
- Components: The elements that form a system. For example, the components of a bridge are beams, cables, and trusses.
- Compositional operators: The mechanisms for plugging components together to get other components. For example, smaller trusses can be welded together to form larger trusses.
- Contracts: The specifications for what users of components can expect from them. For example, a contract for a truss specifies its ability to handle compression without buckling, its tensile strength, and its ability to withstand corrosion.
Figure 2: Bridge Architecture Example
Associated with a composition operator are rules that help designers demonstrate the correctness of a component that was built by plugging components together with the compositional operator. Bridge designers use these rules to verify that a truss satisfies a contract, given the construction of the truss using compositional operators (for example, welds) on other components (for example, beams) and the contracts of the components.
Business networks facilitate the development of systems. The components of these business networks are providers, consumers, and brokers of systems (see Figure 3). For example, steel companies are providers of beams, construction companies are consumers of beams and providers of bridges, and brokers help in connecting beam suppliers and consumers.
Figure 3: Business Network Trinity: Bridge
To help clarify the distinctions between the terms SOA and EDA, this series begins by defining each rigidly. The definitions will become broader with time, but keeping them rigid at the start highlights the differences between EDA and SOA. Note that the comparison is between SOA and EDA, not Web services and EDA. Web services, defined broadly, has many features of EDA—indeed, the Event Web is based entirely on Web services—but this article and the one to follow merely set the stage for a detailed study of EDA and the Event Web.
How SOA Works
A service is quiescent awaiting requests; when a request is received, the service responds with an appropriate reply. The coupling between caller and called components is "tight" in function calls in programming languages but "loose" in Web services in the following sense. A function call in C is made by one function written in C to another function written in C within the same program running within the same process. A call to a Web service can be made by a process written in one programming language on one machine to a service offered by a process implemented in a different language on another machine. A Web service can be registered in a directory at one point in time, and then discovered, bound, and invoked later.
During the past 50 years, programmers have been given access to procedural composition structures that are increasingly loosely coupled. All of these compositional structures—function calls, procedure calls, method calls, remote procedure calls, and service calls—have a common ancestry, which is the strength of service-oriented architectures (see Figure 4). The familiarity that programmers have with synchronous request/reply calls ensures that SOA is here to stay.
Figure 4: What Service-Oriented Architecture Looks Like
Page 1 of 3