http://www.developer.com/

Back to article

Service-Oriented Architecture: Event Web Building Block


February 10, 2005

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.

Software Architecture

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.



Click here for a larger image.

Figure 1: Architecture Definition and Schema

As Figure 2 shows, architectures are composed of the following:

  1. Components: The elements that form a system. For example, the components of a bridge are beams, cables, and trusses.
  2. Compositional operators: The mechanisms for plugging components together to get other components. For example, smaller trusses can be welded together to form larger trusses.
  3. 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.



Click here for a larger image.

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.



Click here for a larger image.

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.



Click here for a larger image.

Figure 4: What Service-Oriented Architecture Looks Like

The key component of SOA is the service, and the key compositional operator is the service call. Simple services are called and composed within programs to obtain more powerful services, just as simple functions are composed in procedural programming languages to get more powerful functions. The contract of a service call (see Figure 5) specifies the schema for a call to the service and the relationship among:

  1. the parameters passed by the call to the service,
  2. the state of the service prior to the call,
  3. the parameters returned by the service to the call, and
  4. the state of the service after the call.



Click here for a larger image.

Figure 5: What a Service Contract Looks Like

For example, consider a consumer's call to a producer to ship an item (see Figure 6): The call schema specifies the format of the request and reply. The parameters that the consumer's call pass to the producer include the consumer's ID, the ID of the item, the quantity, shipping information, and so forth. The parameters that the producer returns to the consumer include the date that the item will be delivered, the account number charged, and so on. The relation between states before and after the call is captured by the states of the warehouse and logistics systems: the warehouse has one fewer of the specified item and the logistics system has one more of the item after the call.



Click here for a larger image.

Figure 6: Service Contract Example: Ship Item from Warehouse

For decades, programmers have been developing programs that call functions; thus, the contracts and compositional structures for SOA are well understood.

Powerful services can be constructed in a systematic fashion by composing simpler services, and the validity of contracts for the composed services can be demonstrated from the contracts of the simpler services and the compositional structure. For example, a service that returns the value of a portfolio of currencies—say, in euros and yen—in dollar terms can be composed from simpler services such as a service that converts only euros to dollars, and another service that converts only yen to dollars. Programmers can demonstrate the validity of the contract for the portfolio-of-currencies service from the contracts of the euro/dollar and yen/dollar services and the compositional structure (see Figure 7).



Click here for a larger image.

Figure 7: Service Composition

Next, consider the architecture of the business network of SOA (see Figures 8 and 9). The components of the business network are processes and bindings where a process can be a service provider, a service consumer, or a service broker.



Click here for a larger image.

Figure 8: SOA of Business Networks



Click here for a larger image.

Figure 9: SOA Trinity

A process can be both a service provider and a service consumer. A service broker is a special type of service provider; it provides a brokering service (see Figure 10).



Click here for a larger image.

Figure 10: SOA UDDI as Service Broker

A producer can make a call on a broker to register a service with the broker. A consumer can make a call on a broker to find the address of a provider that offers a particular kind of service. For example, a consumer can make a service call on a brokering service to get addresses of providers that offer services to convert currencies (for example, from euros to dollars).

A consumer that uses a service type—say, converting currencies—binds to a producer of that service: the binding specifies which producer the consumer will employ for that service. A consumer invokes a service by making a call to the producer specified in the consumer's binding for that service, and the producer responds to the call with an appropriate reply.

The business network for SOA can be represented by a dynamic labeled, directed graph where the components (processes and bindings) of the business network are components (nodes and edges) of the graph. Nodes represent processes and the edges represent bindings (refer to Figure 9). An edge is directed from a consumer of a service to a producer of that service, and the label of the edge identifies the service. Since a process can be both a producer and a consumer, a node may have both incoming and outgoing edges. The graph is dynamic because over time bindings can change, new processes can be created, and processes may be deleted.

A compositional operator in the business network is the creation of a "service binding" between a consumer and a producer of a service. In terms of the graph, the creation of a binding creates a new edge. Other compositional operators include the creation and deletion of services. Executions of these compositional operators determine how the graph evolves over time.

More to Come

The next article will discuss components, composition operators, and contracts for EDA and its business network. Until then, consider the broad relationships between EDA and SOA elements in Figure 11.



Click here for a larger image.

Figure 11: SOA vs. EDA

We invite you to participate in The Event Web Community, a not-for-profit community organization where you can search, discover, and share information about the event web. Please visit Spy-Dir-Web.com for more details.

Acknowledgment: This research was supported in part by NSF Grant CCR-0312778 called "Information Infrastructures for Crisis Management."

Bibliography

Indigo: http://msdn.microsoft.com/Longhorn/understanding/pillars/Indigo/default.aspx

Architecture Center: http://msdn.microsoft.com/architecture/default.aspx

Web Services Training: www.quickstart.com [Course 2524]

Sense & Respond: www.ispheres.com

IBM SOA: http://www-130.ibm.com/developerworks/webservices/

W3C: www.w3c.org

About the Authors

K. Mani Chandy is the Simon Ramo Professor of Computer Science at the California Institute of Technology, where he has been a professor since 1989, twice holding the office of Executive Officer of the Computer Science Department. Dr. Chandy does research in distributed computing. He has published three books and over a hundred papers on distributed computing, verification of concurrent programs, parallel programming languages, and performance models of computing and communication systems.

Jonathan Lurie is a newly minted doctoral student at the California Institute of Technology, prior to which he toiled as a "professional software professional" whilst acquiring a bad case of acronym certification measles: MCT, MCSD, MCSE, MCDBA, MCAD.NET, MCSD.NET, MSF, Java Certified Developer, and IBM XML Certified Developer. He currently researches an area of Computer Science known as Sense & Respond at the Infospheres Research Group.

Robert Alexander is a creative graphic designer who delivered the images for this article. Robert can be reached at ralexander@codeconference.com.

All images are the property of Jonathan Lurie.

Sitemap | Contact Us

Thanks for your registration, follow us on our social networks to keep up-to-date