The Virtual Company: A Case Study in Networked Software-Architecture Design
Summary: Operational qualities of distributed applications are affected most by application-layer decisions, not by the design of the network. (6 printed pages)
"Let's go out tomorrow."
"I've outsourced my scheduling process, and we can't integrate you into the system in time."
Twenty years ago, this dialogue would have not made sense to me. But, as most of us already know, companies increasingly view themselves as dynamically structured businesses. New partnerships are frequently formed, and new acquisitions are commonplace. These activities, as well as the outsourcing of business functions, have forced architects to place much more design focus on distributed, highly dynamic, flexible software systems that are intrinsically dependent on networking infrastructures. Many books have been written about how to design and scale network infrastructures; but, over time, it has become clear that while choosing the low-level network protocols and hardware elements of a networked application constitute a series of important decisions, these choices often have a lesser impact than the design of the distributed applications that will run on the resulting architecture.
Not long ago, a project came my way that had a less-than-stellar success rate—the kind of project that becomes a money pit, with no working code ever produced. (You might have experienced one directly, or observed one from afar.) This particular beast was ambitious and, at one time, had had a goal that included boiling an ocean. My company needed an asset-management system, and, because that was already a large effort, they figured that we might as well revamp the ordering and supplies inventory systems while we were at it. When my manager came to me with this project, my response to her was, "It would be far kinder to shoot me if you don't like me."
She laughed and said that she gave it to me because she had so much confidence that I would manage to disentangle the factions and scope the project into something that was doable. She said that the executives had finally recognized that the asset-management system in itself was an ambitious-enough goal.
I was seriously considering taking home some of my personal books from the office—just in case I was going to be another casualty in the march of the many brave souls who had fallen before me.
When the project architect team met to begin the design of the Asset Management System (AMS), we listed on a whiteboard a statement of principles to which we wanted to adhere. Chief among these was that we had to create an application that would interoperate in the future. The project had failed over several years to produce a workable solution, because too many applications were being tackled at once. It was obvious that, while we had learned that the scope of the project had to be smaller and more clearly targeted, whatever system resulted from the effort was going to have to integrate with other applications, such as registration systems, network-access controls systems, and HR systems. A second, very important principle for us was that the application had to be easily evolved to accommodate changes in asset-management policies, new asset types, and new legislation and regulations regarding corporate auditing of equipment assets.
Increasingly, design decisions about distributed applications cluster around issues such as how to generalize a problem enough so that the resulting application can be reused by other applications (this is called composition, in SOA terminology). While the design of the network infrastructure—that is, the placement of routers, switches, load balancers, caches, and proxies—is critically important, especially from the standpoint of security concerns, it is rare to encounter a network "green field." More commonly, a distributed application is deployed into a mature network infrastructure that has been architected to accommodate growth by using well-understood design principles. Operational qualities of distributed applications are impacted far more by the application-level decisions that are being made. These days, most of the action occurs at Layer 7 of the ISO model.
Choices regarding the use of SOAP, JMS, or both; synchronous or asynchronous message-exchange patterns (MEPs); transaction semantics; and so forth now govern many "network"-design decisions—and so they did ours. We were designing with crosscutting concerns in mind; in other words, we were designing by taking into account potential future applications that would access the one that we were building today.
The core of our design was to create an Enterprise Service Bus (ESB), which would provide an integration "fiber" that included the management of physical destinations as abstract endpoints, message-transformation services, and message routing (via content or headers). In addition, the ESB, which is the basis for a SOA, separates the higher-level applications (or services) from the details of the underlying protocols.
Also, by employing an ESB, we embarked on a course that would allow us to publish our "asset-management" services to the rest of the enterprise in a structured and well-defined manner while, at the same time, allowing us the flexibility to add elements and attributes to our interfaces without affecting our service consumers.
Our ESB would support mainly JMS and HTTP/SOAP messaging. We already had a well-established JMS provider, and many applications that would later become services that were available through our ESB would need to be supported. Therefore, we would need to consider carefully the MEP requirements of our applications to ensure that request-response—and other messaging requirements, such as persistence and durability—were supported and architected correctly.
In other words, by deciding to use JMS, we had to keep in mind the following:
· JMS is not a wire-level protocol. All JMS applications must access the same JMS provider.
· JMS resources require an extra level of administration (for the JMS provider software).
· In general, message-based designs do not easily support the concepts of synchronous request-response.
So, what would our ESB look like at a high level? Conceptually, we decided upon something very similar to that of Figure 1.
Figure 1. Conceptual-level depiction of an ESB
During our review of vendors and products for our supporting technologies, we became aware that many of the "best-of-breed" offerings did not interoperate all that well. During our "Proofs of Concept" (POC), we discovered many issues—from lack of interoperability to software bugs and missing features. Similarly, when we considered the single-vendor solutions, we found that some of our critical requirements would not be met without having to introduce additional products or write substantial amounts of infrastructure code ourselves.
Suffice it to say that the selection of a portfolio of products for our ESB was critical. The ESB was the infrastructure that would run all of our services, moving forward. Therefore, we spent as much time as was necessary to evaluate each alternative. Our experience eventually taught us that the time that we spent up front not only prepared us for the unexpected, but also acted as a training period for the project team and me.
Each of our POCs evaluated operational requirements: performance, scalability, monitoring, alerting, administration, and reporting capabilities. Each POC that was conducted was documented as an artifact. Included in the document was a fit/gap analysis of the product against our requirements. Not only were these artifacts helpful when the time came to justify our decisions to our management team, but they became invaluable tools that we would reuse again and again.
I'd like to say that crafting an ESB in a legacy-laden environment was simple. But, unless you are fortunate enough to be able to buy an off-the-shelf product that will meet all of your needs, you will find that substantial effort must go into architecting the right design for your company. The maturity of the products that now support a standards-based ESB is increasing, and it is getting easier to put together a solid SOA infrastructure than it was during the period of my project (which was during the first quarter of 2004). So, one of the first problems that we tackled for ourselves was to clarify our semantics. We adopted the semantics that many vendors used, which is that an ESB is a bus; that is, it is one or more federated hubs working together and using protocol gateways, bridges, and adapters to connect clients to the protocols and message types that are supported by the bus. The diagrams in Figure 2 show the relationship between hubs and buses.
Figure 2. An ESB bus can be composed of federated hubs.
A Word About Additional Elements Composing a SOA
Soon after we had created our ESB for the AMS and we started to define our asset-management services, our internal customer organizations began to ask for information on how to access our service from their own applications. It was around this time that we began to understand a little more about the role that a service directory and repository played within an SOA.
We wanted not only to publish, but also to allow other programmers to search for and discover information about what services were available for reuse. Thus, we added to our ESB a discovery service with a metadata repository that would allow partner organizations to search and reuse our services by using Web browsers. Note that, in order to do this job, we called upon our data-mining experts, because defining metadata for searching purposes requires expertise. Think about what it takes to create data for search engines to scan through service descriptions in a meaningful way. This was the problem that the AMS project faced and had to resolve.
Even later, as more services came online and our AMS project was already deployed, new requirements brought with them the need to be able to create more sophisticated services by composing (and reusing) other services (for example, calling them in a specific order, or in parallel as part of a new service). This choreography of services made it possible to support not only more sophisticated services, but also more sophisticated human processes around these services. In order to realize this requirement, we had to add a business-process choreography engine as part of our SOA. In this manner, an enterprise-wide choreography platform became part of our infrastructure.
Note that, when choreographing (or composing) services, you might have the possibility of the failure of some services that provide services to yours. In such cases, the architect must consider whether transaction semantics are needed. (For example, do you need "ACID" capabilities?) Assume that an AMS provides a service that allows an HR Employee Separation Service to invoke an asset-service operation. Perhaps the operation indicates that equipment has been returned to the company before separation. How should the HR system behave if it is unable, for some reason, to complete its separation processing, because the asset-management system has returned a fault on the service operation that was invoked?
· What operational requirements does a service directory satisfy?
· Should JMS services have WSDL definitions? If so, why?
· What is the difference between orchestration and choreography?
· When you are choreographing services, will you need to add transaction semantics (for example, rollback)?
· Chappell, David A. Enterprise Service Bus. Sebastopol, CA: O'Reilly Media, Inc., 2004.
· Fielding, Roy T. Architectural Styles and the Design of Network-Based Software Architectures. Thesis (Ph.D., Information and Computer Science): University of California, Irvine, 2000.
· Krafzig, Dirk, Karl Banke, and Dirk Slama. Enterprise SOA: Service-Oriented Architecture Best Practices. Indianapolis, IN: Prentice Hall PTR, 2005.
· Weerawarana, Sanjiva, Francisco Curbera, Frank Leymann, Tony Storey, and Donald F. Ferguson. Web Services Platform Architecture. Upper Saddle River, NJ: Prentice Hall PTR, 2005.
About the author
Maureen Lecuona has over 27 years of IT industry experience, which spans employment in more than three major technology companies. She is an IBM-certified IT Architect, and is currently a practicing enterprise architect for a large financial information firm. Maureen holds an MS in CS from NJIT, a BA in Mathematics from Rutgers, and a BA in English Literature from Rutgers, too. She can be reached at firstname.lastname@example.org, when she isn't skydiving.
This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.