By now, you have a good general sense of what an EDA is, how it works, and what’s getting in the way of its realization. The good news is that help is on the way. Service-oriented architecture (SOA), the broad move toward the use of standards for system integration, offers a true path to the kind of dynamic, implicit EDA that we seek. If our current enterprise architecture is the spilled milk, SOA is the “mop.”

Of course, getting from here to there is not so easy. The whole subject of SOA brings to mind the classic joke about what you get when you cross a lawyer with a mob guy: someone who makes you an offer you can’t understand... Yes, SOA is truly a breakthrough in terms of its raw potential to put EDA on the map.

It was challenging to develop an effective sequence for the material in this book. At first, we wanted to lay out absolutely everything there was to tell about EDA, and then go into detail on SOA and the implementation of EDA. However, after some reflection, we decided for the sake of overall comprehension to define EDA first, then look at SOA, and then go back to more subtle issues of EDA. Having already outlined the basics of EDA and its essential components, including event producers, event listeners, event processors, and so on, in this chapter, we now look at SOA, the actual approach that can be used to design these components. Chapter 3, “Characteristics of EDA,” explores the characteristics of EDA, and Chapter 4, “The Potential of EDA,” returns to the topic of SOA and looks at how SOA makes EDA happen in pragmatic detail. If you are already an expert on SOA, you might want to skim this chapter.

Our basic premise is that there cannot be EDA—at least the kind we want—without SOA, as it becomes an industry standard for interoperation. Of course, there are plenty of differing opinions on this, but we are, at the very least, pragmatists about this. There are a number of ways to develop EDA that are better than the current technological trend known as SOA, but let’s be realistic: Those approaches are not getting the attention and installed base that SOA is getting. For this reason, we are going to work with the assumption that the EDA of the future will be built using SOA.

Years ago, everyone seems to have agreed that enterprise architecture should be flexible and cost effective to change and maintain. The exact approach to getting to this state was far from obvious, and a number of attempts were made, all of which failed. Then, around 2000, as tech companies and industry groups watched the rapid growth of the Web, which is a human-to-machine interface, people wondered, “Why can’t we do that for machine-to-machine interoperation as well?” The result was a remarkable agreement among a number of competing vendors to standardize on Extensible Markup Language (XML; and Simple Object Access Protocol [SOAP] XML in particular) for application integration. These were known as the Web services standards, the enablers of a service-oriented architecture.

Ignoring the hype, and there is plenty of that, SOA does provide the flexible, low-cost capability that we want in our enterprises, the architecture upon which we can build EDAs. SOA is based on the premise of universal interoperability among software components, regardless of operating system, programming language, or network proximity. As we move forward in this chapter, we look at how standards enable this universal interoperability, and the ways in which the standards pave the way for the creation of EDA components. To start, we first define what we mean by service, a concept that is poorly understood.

The SOA field is plagued with suboptimal name tags for simple technologies. Web service sounds suspiciously like an Internet service provider or Web site development tool. Service-oriented architecture gets muddled up with the “service economy” and service providers and consultants. It’s confusing enough without the ambiguous words. To help frame the subject of SOA, then, we want to go over two basic concepts before we get into the in-depth material. First, what do we mean by a service? And, what is the difference between service-orientation, which is an approach to development, and service-oriented architecture, which is a global paradigm for enterprises?

When we talk about services in SOA, we mean pieces of software functionality that will be used by other pieces of software when needed. Let’s use a real-world example to clarify the concept: Imagine that you have a thermometer outside your window, so you can see what temperature it is at any time of day or night. It’s your thermometer, and you enjoy it all by yourself. Then, let’s say that your friends want to know what temperature it is. They call you, and you look outside and tell them what the thermometer says. You have now become a temperature service to your friends. They don’t have to buy a thermometer because they can call you when they need to know the temperature.

In enterprise software, you might have financial accounting software that has a sales tax calculation function. The tax function returns the total sales tax amount when provided a dollar amount and zip code. However, you could make that sales tax calculator available to other pieces of software that need that functionality. For example, you might have an e-commerce application that needs to calculate sales tax. One approach to this requirement is to code, or buy, a sales tax calculator module right into the e-commerce application. Alternatively, you could enable the sales tax function to be requested as a service by the e-commerce application. In the same way that your neighbor might call you to find out the temperature so he doesn’t have to buy his own thermometer, the e-commerce application can leverage the financial application’s sales tax calculator service instead of its own sales tax calculator code.

In the simple example we have set up, the integration between the e-commerce application and the financial application is known as service-orientation, the rather simple act of exposing a service and allowing other applications to consume it. Service-orientation is often the first step toward the attainment of an SOA. However, the SOA is a much broader concept, one that posits that virtually all applications in an enterprise will take advantage of service-orientation for their functioning.

Connecting the idea of a service, and service-orientation through to the EDA, you should imagine that any component of an EDA could be a service. The event producer could be a service, as could the consumer, and so on. What’s significant about that is the potential of a service to be dynamic and implicit—free of tight connections to the EDA elements with which it needs to communicate. We explore this concept more and more as we move ahead.

Over the past few years, an increasing number of organizations have embraced the notion of service-based integration as a cheaper, non-product-specific alternative to the proprietary middleware suites of the past. For example, in Figure 2.1, which continues the phone company example from Chapter 1, “EDA: Opportunities and Obstacles,” the billing system consumes a SOAP Web service called CheckMinutes on the line management system. By exposing data and functionality as services to systems and users (choosing interoperability over traditional integration techniques), IT groups can meet business needs quickly and relatively painlessly. As a stepping stone to a fully realized SOA, or as a placeholder for an anticipated enterprise integration strategy, this is an excellent approach.

Figure 2.1 In service-based integration, a Web service consumer calls a Web service provider using a SOAP XML message over HTTP. The Web service processes the request and returns a SOAP response over HTTP.

There are drawbacks to this service-based integration because many such implementations are still point-to-point in nature, even if they are not case-specific. Federated management and governance of point-to-point services can be difficult to implement, and without a management mechanism, a service-based interoperability strategy will not scale with the needs of an enterprise. Unless you have a governance method in place, service-level objectives can slip (performance, reliability, scalability) without your knowledge, and your architecture can lose its agility.

Web services, as described by the Web Services Interoperability Organization (WS-I, www.ws-i.org/), play a significant role in modern SOA implementations. Though SOAs do not require the use of Web services, and there are many viable alternatives, Web services have become the de facto standard technology for realizing SOA. When we refer to SOA and Web services in this book, we mean the three basic WS-I specifications standards: SOAP, Web Services Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI; including standards such as Web Ontology Language [OWL-S]). In a nutshell, Web services accept requests and send responses in SOAP format. Service characteristics are described by a WSDL document, and advertised using a registry services application programming interface (API) such as UDDI or other “registry, discovery, and dynamic invocation” standards like OWL-S. The following sections provide high-level descriptions of each specification, for your information. For the latest and most complete specification information, and for press releases related to emerging related specifications, refer to the WS-I Web site mentioned earlier.

It’s important at this point to clarify the difference between a service and a Web service. Whereas a Web service uses Hypertext Transfer Protocol (HTTP) as a transport protocol and SOAP as a message formatting standard, both of these qualities are actually optional for the implementation of an SOA. Several technologies allow exposing services over Transmission Control Protocol/Internet Protocol (TCP/IP), Simple Mail Transfer Protocol (SMTP), or other transport protocols (e.g., Windows Communication Foundation). For the sake of simplicity in this book, we most often use the example of Web services.

Simple Object Access Protocol (SOAP)

At its core, a Web service is a means of processing and returning SOAP messages. SOAP defines a format for XML that includes a transport-independent enveloping mechanism. The SOAP envelope contains a body element and optional header and fault elements. The SOAP body holds the message itself and is distinguished from the header element by a namespace prefix. In general, a message sent to a remote component through the invocation of a Web service causes a method to run on the remote object. The response is the result of the method invocation, also formatted in a SOAP message. Such an implementation is called a remote procedure call (RPC) style of SOAP message. The SOAP specification also allows for the exchange of XML documents using what is called the Document Literal style of SOAP message. The style attribute of the SOAP protocol binding determines which style is in use and tells the client of the Web service whether to use RPC conventions.

(For further reading on Document Literal, see http://msdn2.microsoft.com/en-us/library/ms996466.aspx.)

RPC style services are not loosely coupled, so they pose serious interoperability concerns. This has caused many to push for removal of RPC from the WS-I Basic profile. In the interoperable spirit of this book, we do not recommend using RPC style Web services.

The SOAP header can hold security information (tokens, usernames, etc.), routing information, reliability indicators, conversation identifiers, and anything else you might find useful to embed in the header. Many emerging specifications define standard ways of using the SOAP header for these sorts of things. The great thing about putting information of interest in the SOAP header (as opposed to the transport message header) is that it can pass unchanged and unexamined through various layers of security, both physical and logical. Examples of these SOAP extensions include WS-Addressing (standards for specifying routes), WS-Security (standards for exchanging credentials and encryption), WS-Attachments (a standard way of attaching documents to the SOAP message), and the like. Figure 2.2 shows a schematic of a SOAP message.

Figure 2.2 A SOAP message consists of an envelope, header, and body formatted in XML using the SOAP standard format.

The following is an example of a SOAP message. Note the envelope, header, and body sections. The SOAP envelope establishes the beginning and end of the SOAP message. The header contains message-level content, such as where the message came from. The body contains the payload of data or procedural instructions. Pay attention especially to the line of code in the body section that reads <w:GetSecretIdentity xmlns:w=“http://www.wrox.com/heroes/”>. This line is a procedure call that invokes a Web service called GetSecretIdentity, which is located at the URL www.wrox.com/heroes/. We point this out to show you how Web services put software functionality in reach of applications by publishing them to the Web, literally. GetSecretIdentity has its own URL, which can be coded into the Web service consumer. The SOAP specification can be viewed at the W3C site: www.w3c.org.

Throughout the book, lines of code that are too long to fit on one printed line have been manually broken and the continuation preceded with a code-continuation arrow ().

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/”
  SOAP-ENV:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”/>
   <SOAP-ENV:Body>

       <e:Book>
          <title>My Life and Work</title>
          <firstauthor href=“#Person-1”/>
          <secondauthor href=“#Person-2”/>
       </e:Book>
       <e:Person id=“Person-1”>
          <name>Henry Ford</name>
          <address xsi:type=“m:Electronic-address”>
              <email>mailto:[email protected]</email>
              <web>http://www.henryford.com</web>
          </address>
       </e:Person>
       <e:Person id=“Person-2”>
          <name>Samuel Crowther</name>
          <address xsi:type=“n:Street-address”>
              <street>Martin Luther King Rd</street>
              <city>Raleigh</city>
              <state>North Carolina</state>
          </address>
       </e:Person>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Source: www.W3C.org XML Protocols (www.w3.org/2000/03/29-XML-protocol-matrix)

Note about the preceding example: The SOAP 1.2 specification recommends that all SOAP body child elements be namespace qualified. That is recommended for an EDA deployment.

It might be in the best interest of your organization or infrastructure to build policies around acceptable SOAP messages. For example, SOAP messages can be Document Literal or RPC encoded. Some organizations prohibit RPC-encoded SOAP messages because of interoperability concerns. This is the sort of policy that can be applied programmatically to the service description (WSDL; see the following section) at design time (predeployment) as part of your governance cycle. Industry- or company-specific SOAP conventions should be part of the research and definitions produced by your SOA-related initiatives.

SOA is a flexible method of structuring and managing component-based systems. Components in an SOA-based environment might be software or hardware based, might perform a generic business function (transfer funds, for example) or an enterprise function (security, policy application, routing, or logging, for example), or might be an application-specific function. Components in an SOA might also include frameworks for interactive applications (portals) or event management systems (pub/sub, event correlation). All of these units of work are services in an SOA and must be managed and monitored in a uniform way. We often refer to the whole as a service network.

In an SOA, services (typically Web services) are the preferred unit of work. We talk about services being loosely coupled and featuring standard interfaces with messages sharing common identifiers, formats, and protocols. The formats are network-ready; the protocols are concern-based and composeable.

Services can be combined in various ways to create multiple applications.

The diagram in Figure 2.3 illustrates how a full-featured SOA might be constructed. Note that this diagram has logical representations of components that in reality could be distributed physically. Figure 2.3 also illustrates the use of intermediaries to execute the functionality of shared cross-cutting concerns. One of the most significant characteristics of an SOA is the abstraction of nonfunctional concerns from business functions or applications. This means that the remedies for reliability, security, transactionality, adaptability, synchrony, and all of the other *ilities are refactored out of business services and into the service network as service intermediaries. Many runtime governance frameworks provide support for intermediaries and their configuration with declarative policy assertions.

Figure 2.3 In this service-oriented architecture phone company example, there are six Web services exposed on two systems. Through intermediaries, two separate composite applications can be developed that use the functionality of the Web services without requiring any new coding to achieve the functionality that they deliver.

As we have discussed, EDAs work best when there is a low level of constraint on EDA components to communicate. If there are tight restrictions on how the event listeners can communicate with the event producers, the EDA will be inflexible and limited in scope. To put this idea in SOA terms, we now discuss the concept of coupling.

Beyond the simple exposure of data and functionality as services, SOA reinforces the notion of loosely coupled, component-based, distributed systems. The very existence of an EDA requires an SOA to be loosely coupled. Loose coupling of components means that each component need not—and should not—know anything about its counterparts or about its environment in general. In the situation used in Figure 2.1, the line management system that provides a minutes balance in response to a request from the billing system should not have any awareness of the line management system. That is, for the coupling between the two systems to be “loose,” the less specific information about the line management system that the billing system needs to have to process the request for the minutes balance, the better. The more information it needs, the more “tight” the coupling. The coupling is directly tied to the amount of preconceived information required to engage another software component. As you decrease the coupling (preconception), you increase the ability to evolve and change unencumbered. This is the true essence of SOA.

One of the reasons SOAs are achievable today is the remarkable cooperation of the major enterprise technology vendors and their participation in the Web Services Interoperability (WS-I) group. The vendors in this group coordinate their usage of versions of the applicable standards in the latest versions of their software. That acceptance by the vendors has created a cohesive standard for integration never before accomplished. The broad acceptance has allowed loose coupling to exist where it would have been difficult before. Indeed, SOA is omnipresent in the IT landscape. Every major player has their version of it. Microsoft’s SOA is based on their .NET framework, BEA has Aqualogic, IBM has the WebSphere SOA Stack, Oracle has Fusion Middleware, SAP has NetWeaver, and so on.