The time has come to get real. Having familiarized ourselves with the definition of event-driven architecture (EDA), the characteristics of its components, its potential, and the essential makeup of Web services, the likely building blocks of EDA, we are finally ready to delve into the “how-to” of EDA. For the purpose of this book, we focus on building an EDA using a service-oriented architecture (SOA) as the foundation. Although there are many other ways to create an EDA, keeping the focus on SOA gives you insight into a real-world approach to EDA that is being practiced today. In fact, building an EDA in this fashion could be viewed as a specialized, mature form of SOA because many of the building parts and concepts are shared between the two concepts.
This chapter establishes the SOA-EDA connection and lays out the specific ways in which SOA powers the EDA. Although simple in concept, the realities of bending the raw Simple Object Access Protocol (SOAP) Web services into a functioning EDA are quite challenging and complex. In particular, we look at the ways in which Web services can serve as event producers, event listeners, and event processors. We examine the ways in which SOA messaging constructs, such as the enterprise service bus (ESB), enable EDA.
From now on, when we talk about events, we mean SOAP-encoded data. To be precise, an event is a piece of SOAP XML that carries some data about the event that has occurred. The event data can then be relayed to a Web service that acts as an event listener or other EDA component. Let’s call this type of EDA Web service an event service. An event service can be created in two ways: organic development or adaptation of an existing event data source. In the organic development mode, a developer uses a software development tool, such as Visual Studio, to create a SOAP Web service that transmits and receives SOAP XML to indicate that an event has occurred. For example, you might develop a Web service that generates a one-way SOAP message every time someone logs in to a Web site. Each login would trigger the event service that, in turn, sends out the SOAP XML message saying—hypothetically—the time and date of the login. Such a Web service might be developed to sit on the Web server that manages the Web site. This event service is an event producer that transmits the event data to the event bus for receipt by the event listeners. In reality, this kind of wholly new event service might function as both the event producer and the event listener. It produces the event data and publishes it at the same time. However, the discrete functionality of generating the data and publishing it might be separate methods within the single event service.
An adaptation approach to creating an event service involves using a SOAP Web service development tool to transform data that originates in another application into SOAP XML and publishes it directly to the event bus. For example, there are extensive arrays of legacy applications that manage the trading in the stock market. These applications generate all kinds of data about stocks and the overall market. You could create an event service that functions as a generator of an event stream of stock data. This Web service would be an event producer, adapting the data it receives from the stock trading systems. It converts the stream of data in the legacy format into SOAP XML, which it can then publish for event consumption. Figure 5.1 diagrams what this kind of Web service EDA would look like.
As Figure 5.1 shows, the event listeners can also be Web services that communicate with the messaging hub and the event processors using SOAP. Keeping with our premise that the EDA of the future will consist of Web service and SOA components, every piece of the EDA shown in Figure 5.1 is based on Web services standards, including the message hub.
For practical purposes, the message hub that we refer to is an enterprise service bus (ESB), though there are, of course, alternatives in use. To keep things simple, though, let’s stay focused on ESB. The ESB is a messaging technology that enables Web service consumers and providers to connect. The ESB is the hub of the SOA and the EDA as well. Event Web services publish event data to the ESB. Event listeners subscribe to event services (event producers) through the ESB, and forward event data to event processors. The ESB (or groups of ESBs) is the message bone that facilitates the pub/sub structure of the EDA. Other applications, beyond the scope of the EDA, also tap into the ESB to connect with the underlying Web services, which expose the functionality of the trading applications as SOAP XML.
The technology used to implement an EDA bus varies widely, from vendor products to native language constructs. You can do the following:
Leverage an enterprise-class vendor product from Microsoft, IBM, Oracle, SOA Software, or the like.
Wrap IBM’s WebSphereMQ with the Java Messaging Standard (JMS) for an enterprise-class reliable transport.
Use a lightweight and inexpensive enterprise service bus (ESB).
Use a lightweight JMS provider or the JMS service provided by a J2EE server.
Grow your own backbone using MDBs, JINI, JVM Channels, or .NET functionality.
Leverage an XML-based network appliance either as a lightweight ESB or as a gateway to a heavier-weight ESB (potentially eliminating some XML transformation, security, and schema validation that are much more expensive in general-purpose hardware, where a traditional ESB runs).
Any of these would be fine technologies for the main EDA service bus. Your selection will depend upon a number of inputs, as always: constraints of budget, capability, or time, scope of the implementation and long-term road map, and so on. Generally speaking, moving away from a mainstream vendor solution should be done with some caution—particularly as the vendor solutions mature and become more interoperable.
Figure 5.1 provides the high-level view of the EDA’s fit with an SOA. Let’s look closer at the implementation of an SOA, which is the first practical step toward building the EDA. To get started on the subject of SOA adoption, we would like to introduce a way of viewing the SOA that can help cut through the complexity and keep you focused on the pragmatic reality of what is going on. Meet the service network.
A service network is a specific form of SOA that includes Web service providers, Web service consumers, service intermediaries, and ESBs all working in concert in a unified network. Figure 5.2 presents a very simplistic service network that contains these core elements. In the service network view of SOA, any application can be both a consumer and provider of Web services. In reality, this means that the applications that connect to the service network have separate Web service consumers and Web service providers. In Figure 5.2, we show just one or two of each for the applications, though in real life there might be thousands of Web service providers and Web service consumers.
The service network connects Web service consumers with Web service providers, which are also known as service endpoints. Though this might be a little confusing, we use this terminology to reinforce the notion that the Web service itself is at the endpoint of a chain of messaging that originates with the Web service consumer and terminates with the Web service itself, or at the very least, with a proxy for that Web service. For this reason, we sometimes refer to Web services as endpoints.
The Web services, or endpoints, themselves might represent a variety of processing functions. They might be event Web services (or event services) that feed event data to event listeners and event processors. Or, the Web services might be business services that handle business-specific logical processing.
In the service network, there might be more than one ESB implementation. The ESBs, and related intermediaries, route the SOAP messages from consumer to endpoint, handling routing, transformation, and so on. In fact, one of the great challenges of designing and implementing a service network is working through the mediation necessary to get multiple ESBs to operate together simply. In a service network, some of the Web services themselves might be deployed to help the service network with its own functioning. Such Web services are not involved in business processes, but rather in the management and administration of the service network itself. These are known as enterprise services.
Thinking of your SOA service network in terms of network design and management is an appropriate first step in understanding the undertaking of SOA adoption. In network management and design, network devices provide specific functions. Some functions are case specific and some are generic. Some nodes handle routing, some handle security, some serve only certain types of traffic, some are interactive in nature, and some are self-healing in that they adjust their behavior and alliances based on events or on the state of the network. All can be managed and monitored using a single tool or suite of tools. Design of a network includes many considerations—performance requirements, service-level requirements, organizational structure and support models, and even funding models. As you think about your SOA, you must consider the same. In network architecture, devices (nodes) and their scope are typically vendor-produced and well defined. In SOA design, service identification, scoping, and granularity are defined by you, and in most cases, services are built by you. SOA definition requires a level of sophistication typically underestimated by most corporate IT shops today. Take, as an example, the capacity planning discipline required to implement and maintain an SOA environment. The shared service nature of an SOA coupled with being oriented entirely around agility means that capacity planning is critical. These concerns are only amplified by the computational complexity of XML parsing because it has to happen for every message. Thinking about an SOA as a service network can accelerate understanding of SOA concerns, and the following paragraphs outline many of the characteristics of a service network.
Service networks provide several common capabilities, an important one being service-oriented legacy enablement. When we talk about SOA, we often concentrate on the notion of composing applications from a variety of services like the ones mentioned earlier in this chapter (business services, enterprise services, intermediaries, etc.). This might lead you to believe that SOA only works with new applications built with new components. It’s true that if we consider all noncomposite applications as black box, all existing applications are legacy applications. Service networks actually allow for the incorporation of legacy (black-box) applications just as they allow for the incorporation of brand-new, vendor-produced commodity applications that we might bring into our infrastructure. In some cases, bringing a legacy or black-box application into the service network is as simple as providing service wrappers into the application. In other cases, this approach is inappropriate, and classic integration mechanisms must be employed. In the case studies outlined later in this book, we see examples of both.
Service networks allow for event-driven composition and business-level integration. This is the big promise—the future (and in some cases the present) of SOA. Because elements in a service network present their capabilities through virtualized service abstractions, they promote distributed creation, execution, and evolution—facilitated by federated governance. In plain English: Because the functions provided by the “nodes” in your service network are being described in a uniform way, and the descriptions should be made available in a uniform way, services can be consumed dynamically by evolving composite applications, and services can be maintained, versioned, and retired without impact.
Disparities in service granularity and interface semantics can be significant barriers to interoperability and reuse, so in addition to common interface description and availability of service registries, enterprises need to be careful of variations in granularity and semantics.
The elements of a service network focus on specialization. Servers host services and specialize in specific areas of computing, such as routing, persistence, formatting, authenticating, orchestrating, and so on. These services often leverage each other in a symbiotic way, thereby providing a consistent underlying computing fabric. In essence, our old monolithic applications are being broken into smaller components that can be easily recombined via a linked model. By doing this, we facilitate reuse and enable a rapid development/rapid change model.
The last decade has taught us that change is continuous and evolution must be tolerant across time and space. System faults must be assumed. SOA is about creating a network application platform where manageability and programmability scale economically—operationally and organizationally—to unprecedented levels.
This style of software solution enables cost-effective business and IT alignment through protocol-based interoperability and composeability of shared cross-cutting concerns. So what to consider as you build out your service network? First, identify the types of services/components/nodes. This should include vendor-provided black-box systems, legacy or core systems, data sources, frameworks, enterprise services, business services, externally hosted functions or services, data or network feeds from external sources, and integration infrastructure and event services infrastructure. SOA specific items should include service registries and repositories and runtime governance mechanisms (typically in support of intermediaries). These last items are described later in this chapter, and sample usage is provided in the case study section of this book. The design of your SOA includes these service network components; how the components are structured, managed, and monitored; how traffic and transactions across the environment are managed; what policies are enforced at design time and runtime; and the nature of the enforcement, and these should be optimized for your case. Considerations include not only the technical landscape of your product or enterprise, but also your organizational structure and funding model. We get more into these items later in the book.
Service-oriented architectures can evolve over time; one seductive characteristic of this type of architecture is that it can be built incrementally without a large initial investment. For example, a common approach is to start by exposing existing components as Web services before entering them in a registry or building in a management platform.
Although there is some value in supporting a uniform way to consume functions/services in your network, there is a major drawback associated with simply service-enabling existing components without registry services or runtime governance. First, you are propagating a point-to-point integration approach. This means that you will have versioning and compatibility issues as services explicitly invoked by the consuming application change. It also means that you will have little or no visibility into transactions that rely on multiple serial service requests, making troubleshooting very costly.
That being said, if you choose to take any incremental approach, it’s important that you define your long-term strategy and best practices up front, so that the design of your Web services is in line with your long-term goals. If multiple application teams will be developing these early Web service interfaces, keeping an eye on the long-term will require immediate process changes to include, at a minimum, a review of the proposed services.
This point is important enough to reiterate: A successful SOA requires a long-term strategy to be in place before incremental work begins. Ensure that your long-term architectural plans are in line with your strategic business objectives, and be prepared to make a case to your senior management. Understand how you will show your SOA to be profitable, and show how you will calculate your return on investment (ROI). The case studies in this book illustrate useful methods for these tasks.
Ideally, you will have the opportunity to build your SOA from the top down. To do this, you should have an enterprise-level architecture team in place. This team should be made up of highly skilled architects—technologists and strategists with an overarching view of your enterprise, including a deep understanding of the existing technological landscape and an appreciation of the strategic business goals of your organization.
The ideal size of the architecture team depends on the size of your organization and the scale and complexity of the service implementation at hand; in some cases, two or three members will suffice, and in some cases, two dozen members could be necessary. The size is not important so much as the skill set and authority levels of the members.
The success of your SOA will hinge on the work of your architecture team. The responsibilities of this team should include the following:
Define your long-term SOA strategy such that it is aligned with your organization’s long-term business goals.
Incorporate a plan for meeting short-term business goals as part of your SOA strategy.
Define best practices and policies for Web services, deployment, governance, and so on.
Identify common services or components to be leveraged cross-functionally and deployed early in the process.
Communicate the SOA road map to management, development, and support teams.
Adjust the existing software development and deployment process to fit your new architectural requirements—this should include governance activities such as reviews, advertising available services, and so on—and be prepared to constantly reevaluate and adjust this process.
Create a collaboration vehicle for the constant review of service implementations and priority levels.
Select and incorporate the technology required for brokering and managing services, including service discovery through registries or service invocation through brokers.
Select and incorporate the technology necessary to meet requirements for monitoring, auditing, change control, and so on.
Calculate profitability of the architecture and show ROI to senior management.
Is that all? Probably not—but the preceding list gives you some idea of what it means to define an SOA strategy or road map. All of these items must be defined at some point, and some of it must be complete before even an incremental approach to SOA development can be undertaken with a reasonable hope of long-term success.
Unfortunately for many of us, we might not have a strong enterprise-level architecture team in place, nor can we spare the resources with the appropriate skills to create one. So if the tasks in the preceding list must be completed as part of an SOA definition, what’s next?
Step One: Create a project. Get a project manager, or project management body (PMO), to take ownership of tracking the deliverables associated with defining an SOA. Start with what we call Phase 1 tasks. These tasks on your plan should include the identification of short-term and long-term goals, followed by tasks associated with the definition of a road map.
Step Two: Staff the project with existing resources currently assigned elsewhere—ask for one day per week, or 20% of their time, to dedicate to your SOA initiative. If you are lucky enough to have received funding for your project, allow these resources to charge their time to it. Alternatively, identifying an existing project as a “strategic initiative” and creating a subteam associated with that project to address SOA-related concerns is often a good way to organize around the build-out of the first increment of your service network.
Step Three: Socialize the findings of your ad hoc or subteam—presumably, your team was made up of cross-functional representatives, domain experts, senior technologists, and senior strategists. The credibility of your team will lend credibility to its findings, and these findings and recommendations can be taken back to your funding committee for what we call Phase 2 of the SOA project. Perhaps, in addition to a blessing, you’ll receive funding and even full-time resources for Phase 2.
Step Four: Begin Phase 2, and start defining best practices and policies. Perhaps the organization and funding of common services or components can begin, either as part of your team’s deliverables or as part of another ongoing project. Your team should start working with all implementation teams (assuming an incremental approach to SOA implementation) and socializing best practices and the road map. Perhaps you have achieved some organizational authority by Phase 2 and can start using your proposed governance model and reference architecture.
No need to walk through the many potential iterations and tasking combinations therein. Suffice it to say that by placing the tasks associated with building an SOA into buckets, or iterations, and reconciling yourself to working within resource and time constraints of your organization, you will have a better chance of success than if you walked in to your senior management with a proposal for significant investment in what might be perceived to be either unproven technology or ivory tower architecture. Taking into consideration our natural aversion to change, not to mention the backlash IT departments have experienced as a result of enthusiastic adoption of any new technology in the “boom” years, we must be willing to prove that an SOA can be profitable for our organizations. The proof might only be achievable through multiple iterations, as described previously, and that’s something to consider as you start to sketch out your road map.
That being said, many organizations, both enterprise IT organizations and product development groups, have fully embraced SOA as it is defined by the industry today. A quick Web search will produce no shortage of case studies to be used as anecdotal evidence and planning aids for successful SOA implementation. Some of the case studies outlined in this book are based on many such successful implementations in the real world, and our hope is that you will benefit from seeing the approach taken and lessons learned.
Before going through the aforementioned cases, you should understand the technology on which modern service-oriented architecture is based. This technology includes Web services, registries, service buses, message brokers, management platforms, and the like. First, let us consider Web services.
Now that we understand the scope of a service-oriented architecture, the steps associated with creating an SOA, and a bit about the building blocks of an SOA, let’s talk about design.
The most common driver for SOA development (and a key component of ROI calculation) is the immediate and future interoperability advantage it presents. Designing for the future, so to speak, has a number of obvious implications: You must define and embrace new development practices and standards, you must define and implement a governance model, you must be able to track and recalculate your profitability or ROI, and so on. Let’s talk about each one of these concerns.
Your design practices for services must adapt to provide the greatest potential for service reuse. When we talk about service design as it relates to interoperability and reuse, the internal implementation details of a service are not generally of interest. The part we care about is the interface exposed by the service and the messages it sends and to which it responds.
In Chapter 3, “Characteristics of EDA,” where we talked about loose coupling, we learned that protecting service consumers from knowing anything about the implementation specifics of a service promotes long-term flexibility and interoperability. In the case diagramed in Figure 5.2, we could substitute another service for this one, and as long as the same requests can be answered, the consumer does not need to know about the change. Because Web services are truly autonomous in nature, they perform tasks in response to messages. As long as the requests can be honored, the underlying data or objects are not of interest to the consumer.
A number of patterns can be used to achieve this sort of abstraction, including the Façade, the Mediator, or even the Delegation pattern. The consumption of the service can be further abstracted through the use of a proxy or agent.
A more sophisticated loose coupling of services would allow for the dynamic consumption of services through the explicit or implicit querying of a service registry (Universal Description, Discovery, and Integration [UDDI]). This would allow for almost a complete decoupling of services in that the consumer queries for the type of service required rather than explicitly invoking a service.
Many people believe that in order for services to be loosely coupled, they must be stateless. There is some truth to that; however, it is not always necessary for services to be completely decoupled. We are typically concerned with degrees of coupling and striving for as loose as possible to achieve maximum reuse potential. In the case where your service must participate in a conversation with its consumers, you are more likely to be bound to your consumers than otherwise.
Creating services with reuse in mind means not only allowing for generic coupling, but also means exposing both fine- and coarse-grained services. The granularity of a service refers to its scope of functionality. A fine-grained service could return a single value in response to a request for data, for example, whereas a coarse-grained service would expose the result of a business process, typically composed of multiple functions and objects, abstracted by a service. There are many shades of granularity, of course, but the coarser grained your services are, the more business value they can offer, supporting reuse. Coarsely grained services are of great use in building composite applications (a major benefit of an SOA).
Business value should be a major factor when designing your services. Ideally, services in an SOA should be understandable to the business community in your organization so that they can be used in the definition of new processes, and eventually in the creation of composite applications. To this end, your published service interface should include not only technical particulars for consuming the service, but also some description of the business functions they perform.
In some large organizations, enterprise business services are divided in two segments: finely grained business services and coarsely grained business services. The latter are used by composite applications and are themselves composites of the former. The former, finely grained business services, might not be Web services at all, but rather native constructs (such as Enterprise Java Beans [EJBs], and so on).
Publishing meaningful descriptions of your services is essential to create a robust SOA environment. A contract is consumable programmatically (machine-readable) and should include the messages your service sends and receives, any policies to be enforced (security, requirements, etc.), and a description of the business functions they perform.
A contract or description of a Web service is in the form of a Web Services Description Language (WSDL) document, as mentioned in Chapter 2, “SOA: The Building Blocks of EDA.” Many mainstream development tools expect to have access to a service’s WSDL at development time, and can generate code that corresponds to the functionality of the service (the bindings are generated). Management tools use the WSDL to govern adherence to policies and best practices, and to monitor the operation of the service in production. Of course, if your WSDL is available in a registry, a requesting application can create a binding to your service at runtime, presumably after ascertaining your service provides the optimal functionality for a particular case.
Many Integrated Development Environments (IDEs; Visual Studio .NET, WebLogic Workshop, etc.) allow you to wrap a procedure in a Web service with the click of a button, and the associated service description (WSDL) is generated by the IDE. There are some pitfalls associated with WSDL generation—one of them being that the default type of SOAP message is typically RPC-encoded, potentially leading to interoperability issues (and potentially failing the design-time, policy-based assertion application that might be part of your governance process).
The messages sent and received as part of your Web service are described in the WSDL. One design issue introduced by SOAP messages is the notion of applying different characteristics to different parts of a message. So in a single message, some aspects might be visible to all consumers while other parts are encrypted and visible only to a trusted group of consumers. Still other parts of the same message might be signed. The SOAP specification and the corresponding WS-* specifications provide the rules for this sort of adaptability.
The term enterprise service bus (ESB) is one of the more confusing parts of an SOA definition, primarily because of the disparate definitions of ESBs provided by the vendor community at large. Thus far in this book, we have not explicitly mentioned the need for an enterprise service bus. We have said that we need a uniform way to support discovery of services, routing of messages, monitoring of services, policy application to messages/services, and other nonfunctional concerns such as transformation, logging, and so on. The industry adopted the use of the term ESB to describe a mechanism for providing service access and management as described previously, before the notion of a service network or fabric was propagated by the SOA industry leaders of today. The two terms are not inherently in conflict, but many ESB offerings look more like old-school enterprise application integration (EAI) stacks than the sophisticated management fabrics discussed by industry thought-leaders today.
One reason for this is that leading EAI vendors, like IBM and BEA, have packaged their integration offerings as ESBs. This means that their products can be used to provide access to data and functionality hosted by systems plugged into the bus, and nonfunctional concerns like the ones mentioned previously will be remedied by the functions provided by their product stack. This is a fine approach to SOA support and management as long as your enterprise feels comfortable with your vendor of choice and doesn’t mind the potentially enormous costs associated with scaling the product stack out to support all of the traffic in your enterprise. Think about the costs associated with your EAI platform today—then imagine that all traffic between all components in your service network flows through the platform. The combinatorial consequence is significant. Many popular J2EE-based integration platforms require that the entire stack be deployed everywhere any part of it is to be leveraged, and many rely heavily on compiled code versus declarative artifacts (as supported by some SOA vendors). The ESB model defines a distributed solution with what amounts to a container deployed in the environments of interest (hence the “lightweight” characterization of ESBs and management fabrics). That being said, there is value in having a single-vendor platform for interoperability and integration, and if you can stand the price tag and vendor dependence, it might be the safest way to go, given the complexity of designing an SOA.
Other vendors produced products not part of an EAI stack that provide similar capability, and they are also billed as ESBs. These ESBs provide a number of container-based mechanisms, abstracting things like life cycle management and thread pooling from an application implementation. Such a mechanism would remove the need for service consumers to be aware of a service location, although as mentioned previously it’s typically a good idea for routing decisions to occur at distributed nodes as opposed to a centralized hub. It supports rule-based routing, data transformation, and business process orchestration.
For the purpose of this chapter, let us refer to the runtime governance of services as a management fabric. A management fabric might be billed as an ESB implementation or not. Runtime governance of services can be managed by a single, standards-based solution (from a vendor or perhaps from the open source community), or it can be a composition of utilities of your choice. The management fabric should be available across an enterprise environment, regardless of organizational silos or technical disparity of systems, but can be leveraged for narrow, localized integration solutions as well.
A management fabric, like traditional heavyweight integration products, may support J2EE-based technology like JCA (J2EE Connector Architecture) or JMS (Java Message Service) to interact with an application, or it could use traditional application programming interfaces (APIs), or SOAP-based Web services. Fabrics can provide data transformation capabilities (leveraging XSLT, XQuery, and the like), and may support routing of requests to appropriate services at runtime. This is often implemented in the form of a message broker, where messages are routed based on a set of rules applied at runtime, may be event-driven, and may be exchanged using a publish/subscribe model. Facilities for transaction management and security services should be handled by the management fabric.
A quick note of caution: Do not think of an SOA management fabric (or ESB) as a standard heavyweight integration platform, even though many of the popular integration platform vendors purport to provide ESBs in their products. Although it should provide enterprise-class stability, your service infrastructure, by nature, should be lightweight—it should have a small footprint, is typically distributed, and must be inexpensive to deploy. Some use JMS (Java Message Service) or Jini MQ, a JMX (Java Management Extensions) backbone, JNDI (Java Naming and Directory Interface) directory, and one of the open source cluster frameworks (like those used in JBoss, JoNaS, and others). Although it’s not necessary that a runtime governance fabric or ESB implementation be based on Java technology, it often works out that way.
Another important point of clarification is that a fabric (as its name implies) should not feature a hub-and-spoke architecture (many integration brokers are hub-and-spoke). It should support deployment of distributed components (containers or intermediaries) that support the capabilities necessary for each case. Ideally, the components will have a configurable footprint, and will be managed remotely and independently from other components.
These characteristics also differentiate a fabric from a message bus. A message bus can provide access to multiple disparate systems, and it’s certainly lightweight, but management functions are typically centralized, not distributed, and it does not support the nonfunctional concerns (the *ilities) typically supported by a management fabric.
Designing an SOA around an industry-leading management fabric in support of your long-term SOA strategy is the most straightforward way to go. Leveraging a management fabric allows you to build your SOA incrementally, as is often preferable. This means that you can introduce a management fabric into a local architecture and leverage it to integrate globally later; the pitfall of such an approach is that it might be tempting to solve the local problem without an eye to the global architecture. As with any SOA definition, keep the greater goals in mind at all times.
By now, we have learned that a management fabric is an integral part of your service infrastructure and fills a major role in an SOA. It can act as a distributed broker for synchronous or asynchronous Web services, with all consumers invoking services through the management fabric, with dynamic routing at runtime. It facilitates abstraction of services, dynamic discovery, centralized management of utilities, decentralized runtime control of services, and the like.
Because management fabrics support the complete decoupling of a service from other applications or services in your environment, its structure is particularly important when your SOA becomes event-driven. As mentioned earlier, an event-driven architecture (EDA) is an extension of the SOA model. In an EDA, business processes can be kicked off and managed in response to a particular event. A request to a service could be received, acknowledged, split into multiple corresponding requests, and finally answered with multiple responses according to the process in work.
Your management fabric should support (or work in conjunction with) event service and correlation. This allows for complex business process flow management; of course, its sophistication depends upon its support for orchestration language standards (Business Process Execution Language/BPEL or Business Process Execution Language for Web Services/BPEL4WS). Business process orchestration standards typically define a variety of process flow constructs that can be used to abstract the process flow from the logical or physical infrastructure of participating applications. We talk more about business process modeling and management later in this book.
If you are taking an incremental approach to building out the service infrastructure of your SOA, you might find yourself relying on a (typically homegrown) service broker. In some cases, for one reason or another, the advantages offered by a management fabric are considered not worth the cost of the effort to implement in the early stages of an SOA build-out (this is akin to selecting against using J2EE containers for a Java application, by the way, so be careful when adopting this approach). As shown in Figure 5.3, a service broker is simply an abstraction layer between Web service endpoints. Implementing a service broker gets you part of the way toward achieving the loose coupling that is so important in any SOA implementation, and provides a single layer to use for simple monitoring and routing of Web services at a local level.
Figure 5.3 Diagram of service broker, both flow and logical, which is part of the J2EE core patterns.
(Source: CoreJ2EEPatterns.com)
Let’s say that you have designed an SOA with multiple, geographically distributed, technically disparate applications. You are planning to support dynamic discovery and routing of services, and you have decided to build (or assemble) a management fabric (or ESB) as a backbone. Now ask yourself: How are you going to manage security, deployment, and operational activities? Let’s say that you are prepared to expect the components (services, containers, etc.) of your SOA to provide Java Managed Extensions Managed Beans (JMX MBeans) or Simple Network Management Protocol Management Information Bases (SNMP MIBs). Will this put you a step closer to a management solution? Perhaps. How will you handle business process management (BPM)?
Ideally, your management solution will have become evident during the design process of your SOA. In the case of an incrementally built SOA where design was solidified over multiple iterations, you might be trying to retrofit a management solution with much of your SOA already in place.
Your options for SOA management are as follows (good, bad, and ugly, in no particular order):
Provide no SOA management and let each application rely on its own monitoring tools and be managed, deployed, and secured individually.
Create a “patchwork quilt” of existing management solutions with homegrown management functionality sewn in based on emerging standards.
Leverage the centralized management offered by a heavyweight integration platform.
Select a vendor-based SOA management solution.
Let’s talk about each option. The first option is the default—if you don’t have an SOA management solution, each application or component must rely on its native management tools for security, deployment, versioning, monitoring, and the like. The problems with this option are manyfold: no end-to-end security, no business process modeling, no automated versioning, no uniform management tie-in with the development cycle for each component, no centralized monitoring of areas of interest in an SOA, no centralized measurement tools for monitoring service-level objectives, and so on. Long-running transactions that span multiple services will not be managed as a single transaction, but as multiple hops across decoupled services.
The second option is not pretty—you could layer multiple management solutions that are not SOA-specific to meet your immediate management requirements. For example, you could use an existing application monitoring product that leverages agents to report basic health information back to a central server, host a separate business process management or workflow tool, and implement a homegrown deployment and versioning scheme for your SOA. You could even use your knowledge of emerging management specifications like Web Services Distributed Management (WSDM) to build Web-service-based communication between your management applications, manage the relationships between the components and underlying resources supporting your SOA, and even monitor end-to-end business process flow if based on Business Process Execution Language (BPEL). Of course, WSDM is still an emerging specification from the Organization for the Advancement of Structured Information Standards (OASIS), but in theory, it could be used in conjunction with existing management tools to grow your own SOA management solution. That being said, the justification for constructing such a solution would have to be the belief that a homegrown solution would offer some sort of competitive differentiation (typically not the case for infrastructure management solutions). More often, logs from multiple management solutions would be consolidated and parsed for meaningful notations in this patchwork-quilt style of management.
The third option is to leverage the management functionality that comes with a large, heavyweight integration server. To do this, you must have decided to use the server in question, of course. The advantages of adopting an integration platform are significant. BEA’s offering as well as IBM’s offer so-called ESB functions: asynchronous messaging backbone, data transformation, content-based routing, connectivity to multiple technologies and platforms, and full support for Web services and many WS-* standards. Full-blown EAI (enterprise application integration) platforms also offer many of the EAI functions you’d expect, including BPM, integrated development tools, adapters to major enterprise applications, and the like. They offer robust, centralized management mechanisms that can meet needs you didn’t know you had.
Why is this option suboptimal? Depending on your case, it might not be. We do know it breaks a couple of key ideals of a management fabric: First, it’s an integration broker—everything related to integration is centralized in a proprietary stack. One of the neat things about a management fabric (in fact, its distinguishing characteristic) is that you can rely on configurable, distributed components for many of the functions an integration broker would provide centrally. For example, data transformation services can be deployed as part of the service network, allowing messages to be converted in-flight from one format to another. Specialized monitoring functions can also be deployed as part of the service network, as would security functions and other nonfunctional remedies. As long as these functions are deployed as services, you can essentially “plug and play” these integration tools anywhere management fabric can reach. This allows for very precise scaling and tuning and versioning, despite the distributed nature of the services. Alternatively, an EAI platform centralizes the integration services as part of its server functionality. It’s a different, heavier, and significantly more expensive model. Is an SOA based on an EAI product really an SOA? Of course—you’re just betting the farm on a vendor product, service levels, pricing, and on your ability to pay to play as you need to scale up.
The fourth option is to leverage one of the specialized SOA management platforms on the market today. Before we talk about what these management platforms offer, it’s important to understand the nature of the market and what drives each flavor of SOA management implementation. Simply stated, the Web service management tool market is overloaded. Each management platform vendor is taking a different approach to distinguish itself from the rest. Some are competing in ease-of-use and reporting, others are offering adaptive monitoring of service levels, and many have incorporated WSDM-based functions into their platforms.
In an SOA or Web services management platform, you can typically expect to see some or all of the following key features:
Built-in registry solution for publishing and discovering services, as well as the ability to plug in to any compliant registry solution
Policy definition and enforcement
Service mediation and routing
Metadata transformation
Dashboard-style interface
Logging, auditing, and monitoring (and billing options)
Security options and enforcement (often through application of policies)
Service discovery, provisioning, configuration, versioning
If the management platform offers a fabric, many of the preceding features would be distributed and configurable across the network. Management platforms (either heavy- or lightweight offerings) will provide the data for calculating return on investment (ROI). As you evaluate your management platform options, keep in mind your goals for your chosen method for ROI tracking.
Figure 5.4 shows a possible reference architecture for an SOA that embodies a complete infrastructure for governance and management.
Web service management and governance platform vendors in the market today include AmberPoint, WebLayers, Actional (+WestBridge), SOA Software, Oracle, and Infravio, to name a few. Many of the Web service management functions provided by these vendors today are compatible with generic application management platforms. We know that existing application management approaches are insufficient for full-scale management of an SOA, but when paired with an SOA-specific management toolset, mainstream management platforms can still offer a unified vision into your system.
Estimating the return on investment (ROI) or profitability of your architecture is one of the more esoteric tasks associated with our work. Estimating the ROI for an SOA implementation and building the associated business case is no less difficult—but we can follow some basic rules for estimating how profitable our SOA can be.
In any sort of enterprise ROI calculation, you must have some knowledge of your anticipated total cost of ownership (TCO). This is a figure not measured on a yearly basis—this is a single figure corresponding to the total cost of owning a service infrastructure. Then you must consider three inputs: anticipated cost savings (this requires an understanding of your existing cost structure), opportunity costs, and anticipated revenue (this requires an understanding of your business and the benefits of agility).
Cost savings can be calculated by starting with the advantages of supporting common components. In this case, your implementation costs associated with building common business logic into every application or product is replaced with the anticipated costs of simply consuming a business service. The difference is the first part of the savings (difference * estimated reuse opportunities = projected savings). Support costs for common components versus multiple implementations are similar enough to leave out of our calculations. This calculation assumes you have an understanding of how much it costs to build and support blocks of business logic today.
Cost savings associated with common components include reduced interface development costs. Having common interfaces is estimated in general to reduce interface development costs by 60%–70%. Think of the costs associated with not only development, but also testing, SLA negotiation between endpoint owners, and the like. The interface development that is still required is streamlined through a common practice for development, testing, monitoring, service exposure, and governance. Take a look at your last project that exposed a function to multiple consumers. This will give you some idea how much savings is available to you in building out a service network with common business services.
There is cost savings associated with the management and governance of a service network (or network architecture), but it is not as simple to calculate. There is quantifiable value in providing a uniform method of addressing nonfunctional concerns and enterprise policies (rather than having every application figure out how to implement security, transformations, etc.). Management of system resources, visibility into long-running transactions, and governance of activity is all streamlined through the use of common mechanisms across the service network. The savings model is similar to that of the common components, described previously, in that the savings is realized through the sharing of common mechanisms and standardized approaches (development, testing, monitoring, support) as well as the reduced number of implementations. Again, calculating the savings requires an understanding of the cost structure for your existing enterprise support model. Because many large organizations distribute responsibility for these items organizationally, this might be more difficult to accurately quantify.
Maintenance costs can also be reduced in an SOA environment. An SOA framework allows you to target maintenance-related items for outsourcing, for example, and this can reduce your costs significantly, particularly if you are already planning to go to an outsourced model.
If regulatory compliance is an issue in your organization, the service network nature of an SOA offers the uniformity in system management and governance that simplifies monitoring and logging efforts for auditing purposes. An SOA offers a uniform implementation of data access methods, and corresponding rules and logging mechanisms support data integrity (lineage) and reporting. Given the planned costs associated with your regulatory compliance efforts, and depending on your existing infrastructure, this can be a significant savings category for you (of course, fear is often the motivator for regulatory compliance efforts, not costs).
The value of agility can be calculated if you understand your business growth mode. High growth organizations require extreme responsiveness from an IT department, and a typical problem in such organizations is the proliferation of disparate, suboptimal implementations developed without regard to the environmental strategy. Most large organizations have pockets of high growth and stagnation, leading to a generally constrained product management organization. In such organizations, most business owners have calculated the benefit of being first to market with a new product or service, as well as the costs of being second, third, or last. These figures can help you quantify the revenue opportunities associated with providing an SOA.
Consider the cost of your SOA implementation over some time period. Then subtract the savings calculated for common components and the like over the same period of time, then subtract the average gain associated with agility (time to market) multiplied by the planned number of product offerings over the same time period, and you will have some notion of the costs/savings associated with an SOA approach. You might also want to factor in the cost savings associated with reduced rework for retrofitting suboptimal solutions that were delivered fast at the expense of quality.
To better understand lost opportunity costs, you can invite your business community members to talk about the following in the context of an SOA: customer relationship, information, and access management. Imagine a single approach for case-specific security application across multiple customer repositories and rule sets and events triggered based on changes in customer status, completely decoupled from the application layer. Depending on your current solution state, this might be another potential win.
An SOA contributes to competitive advantage directly in support of business process management. Business processes can be defined and managed at the enterprise layer—this allows you to eliminate redundant, conflicting, or overlapping business process definitions across the enterprise. The underlying business components would be commonly support, consumed, and monitored as part of the service network.
A business case for SOA might include the following: current cost of managing enterprise infrastructure (HW/SW and projected growth based on replicated business processes and case-specific implementations, management tools associated with multiple environments, security infrastructure, cost of maintaining and monitoring interfaces across the enterprise, etc.), current cost of application development (costs to build business components under the current model, average number and cost of new interfaces required per application, costs associated with supporting multiple redundant applications, maintenance costs, etc.), anticipated cost savings (common components, common interfaces, management and governance savings, regulatory compliance, business process management, etc.), and anticipated revenue opportunities (speed to market, customer information and activity monitoring value, etc.).
You might also want to consider the potential cost savings of streamlining your organizational structure and dependencies based on the SOA-based development, management, and governance model, both inside and outside of IT. You will want to consider automation opportunities and associated cost savings in your governance process. You will need to keep an eye on the point at which this model is unsupportable (for whatever reason) within an acceptable cost model, and the points at which this model is most likely to fail in your organization.
All that being said, if your goal is to simply estimate how long it will take you to recover your investment, your task might be fairly straightforward.
Although there are many different, equally valid approaches to creating an EDA, from this point on in the book we work under the assumption that SOA and the use of SOAP XML Web services will be the building blocks of the EDA.
Events are produced by event Web services and listened for, and processed by, Web services. Like all Web services, event services can be created from scratch using a development tool or they can be exposed from existing applications using specialized tools.
We work under the assumption that the message backbone for the EDA will be an enterprise service bus (ESB). Event Web services publish event data to the ESB, and event listening Web services subscribe to event data through the ESB.
The event Web services, the ESB(s) used to connect them, and all the other moving parts in the EDA can be described as a service network that provides connectivity for any set of event Web services, listeners, and processors through the ESB(s). Creating a service network requires a high level of governance and mediation among all the separate components to function securely and effectively.
EDA exists on top of SOA, so to have an EDA, you should ideally first have developed a good SOA infrastructure. Before starting the EDA process, you should have established the business rationale for the SOA, allocated the personnel and resources to its development, standardized on a security and governance framework for the SOA, and deployed the core messaging infrastructure, such as ESBs, to make it all work properly.