Agile Infrastructure 2002 Technical White Paper

Document1

1.

INTRODUCTION................................................................................................................. 1 1.1. LESSONS LEARNED .......................................................................................................... 1 1.2. E-BUSINESS AND BUSINESS CONVERGENCE ..................................................................... 1 1.3. E-BUSINESS STRATEGY = USING THE INTERNET TO DYNAMICALLY ADAPT THROUGH INNOVATION ................................................................................................................................ 2 1.4. ADOPT INTERNET STANDARDS, CULTURE, AND TIME ...................................................... 2 1.5. ACHIEVING E-BUSINESS INFRASTRUCTURE AGILITY ....................................................... 3 1.6. THE SCOPE OF THE WHITE PAPER .................................................................................... 4

2. CURRENT INFRASTRUCTURE CHALLENGES: THE LIMITS OF COMPLEXITY ............................................................................................................................. 4 2.1. 2.2. 3. 3.1. 3.2. 4. AGILITY AT THE COMPONENT LEVEL ............................................................................... 4 UNWIELDY COMPLEXITY END-TO-END ........................................................................... 5 NEW DESIGN PRINCIPLES ................................................................................................. 7 PARADIGM SPANNING LAYERS: THE INTERNET AND THE WEB ........................................ 7

BUILDING SPANNING LAYERS ..................................................................................... 6

AGILE INFRASTRUCTURE: WEB SERVICES NETWORK ARCHITECTURE..... 9 4.1. FROM COMPOSABLE BUSINESS OBJECTS TO COMPOSABLE INFRASTRUCTURE ............... 10 4.2. COMPOSABLE = INTEROPERABLE + PROTOCOL-BASED + DYNAMICALLY-BOUND + WELL FACTORED ................................................................................................................................. 12 4.2.1. Interoperable......................................................................................................... 12 4.2.2. Protocol-Based ..................................................................................................... 12 4.2.3. Dynamically Bound ............................................................................................... 15 4.2.4. Well-factored......................................................................................................... 16 4.3. BUSINESS IMPACT .......................................................................................................... 17

5.

AGILE INFRASTRUCTURE: SPANNING LAYER REFERENCE MODEL ........... 19 5.1. RECURSIVE COMPOSITION OF SERVICES: THE SPANNING LAYER REFERENCE MODEL .. 19 5.1.1. The Internet SLRM ................................................................................................ 20 5.1.2. Comparing Spanning Layers ................................................................................ 20 5.2. SERVICE MODEL ............................................................................................................ 21 5.2.1. The WSDL Service Model ..................................................................................... 21 5.3. COMPOSITION MODEL.................................................................................................... 22 5.3.1. The SOAP Composition Model ............................................................................. 24 5.3.2. The WSFL Composition Model ............................................................................. 26 5.4. GLOBAL MODEL ............................................................................................................ 27 5.4.1. The End-to-End Argument .................................................................................... 27 5.5. WSNA SPANNING LAYER SUMMARY ............................................................................ 29 5.6. BUSINESS IMPACT .......................................................................................................... 29

6.

AGILE INFRASTRUCTURE: WSNA OPERATIONAL ISSUES .............................. 31 6.1. 6.2. 6.3. SECURITY....................................................................................................................... 31 MANAGEMENT ............................................................................................................... 31 LIFECYCLE ..................................................................................................................... 32

Document1

6.3.1. 6.3.2. 6.3.3. 7. 7.1. 7.2. 7.3. 7.4. 7.5. 7.6. 8.

Lifecycle Framework ............................................................................................ 33 Dynamic Lifecycle Phases .................................................................................... 34 Dynamic Interfaces ............................................................................................... 35

AGILE INFRASTRUCTURE: FUTURE IMPLICATIONS ......................................... 37 COMPONENT FRAMEWORKS ........................................................................................... 37 ACTIVE NETWORKS ........................................................................................................ 38 GRID COMPUTING........................................................................................................... 38 MODEL DRIVEN ARCHITECTURE .................................................................................... 39 COMPOSABLE HARDWARE: FROM PLATFORMS TO NETWORKS ...................................... 41 AGILE SOFTWARE DEVELOPMENT ................................................................................. 41

CONCLUSION ................................................................................................................... 42

ii

Document1

1. Introduction
With the recent burst of the dot-com bubble, 2002 is a good time to step back and see how far e-business infrastructure has come in the past five years and where it is going over the next five years.

1.1.

Lessons Learned

Perhaps the most important lesson to be drawn from the last five years is that the eand the business in e-business are both essential and must be deeply interrelated. The conventional wisdom is that the dot-com debacle was caused by too much emphasis on e-, without a solid business model based on profitability the infamous URL strategy: Ubiquity now, Revenue Later. But a deeper analysis reveals exactly the opposite: dot-coms were not really ebusinesses. Most of the dot-coms that went under did so because their revenue, which often was substantial, could not cover their even more substantial fixed costs in infrastructure. Yes, some blew their money on wasteful expenses like Super Bowl ads, but most poured their money into infrastructure: people, buildings, servers, storage, software, etc. Thus, when the economy slowed, the dot-coms could not dial down their infrastructure rapidly enough to survive. Although dot-coms sold a vision of how an e-business infrastructure enabled rapid response to dynamic markets, they failed to implement such a vision themselves. They followed a grow or die strategy by building out so much infrastructure capacity in advance of business. What they should have followed was a change or die strategy that would have enabled them to dynamically shed infrastructure capacity during the economic downturn. Thus, the dot-com debacle was essentially an infrastructure strategy failure. Dot-coms were done in because they didn't follow their own advice they were not truly e-businesses.

1.2.

e-Business and Business Convergence

Every so often, a disruptive innovation transforms the nature of markets and businesses, e.g., the industrial revolution, electricity, telephone, automobile, computer, etc. Most successful new businesses emerge as a result of a disruptive technology change: AT&T and the telephone, IBM and the computer, FedEx and air transportation/shipping deregulation. Today, the disruptive innovation is the Internet. e-Business was born of the Internet, and the standards, culture, and economics of the Internet (collectively, the Internet way) continue to shape e-business strategy. The Internet standards successfully spanned different server technologies, different network technologies, and amazingly, different organizations and different nations, all without any one organization making it happen. Of course, the telephone network had done this decades before, in order to provide a global telephone inter-network. However, unlike the telephone inter-network, which basically provided only voice service and took many decades to build out, what was most revolutionary about the Internet way was that it

Document1

also spanned a wide variety of collaborative applications: remote access, file transfer, email, etc, in a relatively short time. Going forward, e- strategy is all about expanding the span of the Internet way in three dimensions: 1. Higher into the business processes of the enterprise: How can e- automate or transform my business processes? 2. Deeper into the IT infrastructure of the enterprise: How can e- improve or transform IT as a business? 3. Broader in the lifecycle scope of products and services across the entire value chain: How can e- apply beyond browse and buy throughout the entire lifecycle of a product or service? At some point in this expansion, every enterprise will have discovered that its e-business strategy and its business strategy are the same thing. (And then we can drop the annoying e- in front of everything.)

1.3. e-Business strategy = Using the Internet to Dynamically Adapt Through Innovation
Although it is almost impossible to distill all aspects of e-business strategy into a single definition, the following addresses those that are most fundamental from an infrastructure perspective: An e-business strategy drives continuous business innovation by automating new forms of collaboration and resource sharing based on the universal span of the Internet to dynamically adapt products, services, processes, relationships, technologies, organizations, and markets to a constantly changing competitive environment. (Note: Compare to IBM's definition from 1998: e-business is what happens when you combine the broad reach of the Internet with the vast resources of traditional information technology systems. It is dynamic and interactive. Cite: http://web.archive.org/web/19980211184949/www.ibm.com/e-business/what/)

1.4.

Adopt Internet Standards, Culture, and Time

Essentially, an e-business strategy is a strategy for thriving during times of change, whether those changes are good or bad, technologic or economic. It's not grow or die, it's change or die. In order to thrive on change, businesses must transform themselves through automated collaborative innovation and resource sharing with their customers, partners, and suppliers, all enabled by a new form of infrastructure: the Internet. Accordingly, from the highest levels of corporate strategy to the lowest levels of

Document1

technology configuration, the unifying e-business theme must be to foster the ability to dynamically adapt by continuously innovating via Internet-enabled automation.

1.5.

Achieving e-Business Infrastructure Agility

The ability to dynamically adapt through innovation while maintaining stability is agility. Infrastructure such as the Internet enables agility to the degree it provides a layer of stability that decouples the business processes and applications above it from the technologies below it, so that each can evolve independently as rapidly as possible. The Internet's ability to foster innovation both at the application level above it, as well as at the technology level below it, is astounding. It is the result of a subtle but tremendously important insight by the designers of the Internet: The Internet as we now know it embodies a key underlying technical idea, namely that of open architecture networking. In this approach, the choice of any individual network technology was not dictated by a particular network architecture but rather could be selected freely by a provider and made to interwork with the other networks through a meta-level "Internetworking Architecture". [emphasis added] In an open-architecture network, the individual networks may be separately designed and developed and each may have its own unique interface which it may offer to users and/or other providers[,] including other Internet providers. Each network can be designed in accordance with the specific environment and user requirements of that network. There are generally no constraints on the types of network that can be included or on their geographic scope, although certain pragmatic considerations will dictate what makes sense to offer. [A Brief History of the Internet] To put it succinctly: The Internet is not a technology it is an architecture. This metalevel internetworking architecture is embodied solely in unified protocols (TCP/IP) whose fundamental purpose is to span heterogeneous underlying network technologies. Thus the stable infrastructure of the Internet is the set of abstract (aka meta-level, virtual, logical) inter-network protocols that operate over a set of concrete (aka particular, actual, physical) layer-two network protocols (e.g., Ethernet, X.25, ATM, Token Ring, FDDI, SONET, Frame Relay). This is what has enabled the technologies below the Internet to rapidly evolve. As we shall see, an agile infrastructure is a virtual infrastructure, built out of standard abstract service protocols that are dynamically bound to heterogeneous concrete service protocols. But just as important as the standard Internet protocols is the culture that created and sustained the myriad innovations we now think of as the Internet. e-Business strategy is just as much about the Internet way (the culture, principles, processes, economics, and organizations that created and sustain the Internet), as it is about Internet standards. e-Businesses must adopt both to continuously adapt to a constantly changing competitive environment.

Document1

Hence, as businesses build out the next generation of agile e-business infrastructure, it is critical that each new layer integrate the strengths of the Internet, and avoid its weakness.

1.6.

The Scope of the White Paper

This paper will discuss the current challenges facing e-business infrastructure agility, how Internet architecture (especially Web services) and the Internet way can be applied to meet these challenges over the next three to five years, and how to go beyond the current limitations of the Internet over the next five to ten years. The central focus of this white paper is to understand how virtual model-driven infrastructure enables agility above and below, as well as how to reinvent infrastructure interfaces, so that they too are agile.

2. Current Infrastructure Challenges: The Limits of Complexity

The impact of e-business has been an unrelenting demand for: More application package integration than ever before More scalability and availability than ever before More ability to cope with volatility in demand for services than ever before (HTTP storms) More continuous access from greater numbers of more diverse client devices at more locations than ever before (pervasive computing) More sharing of any resource, any time, anywhere, via any device, in always changing ways, than ever before

As a result, the complexity of high-end e-business infrastructure (e.g., high-volume web sites) has reached the breaking point. We can't keep up the pace, and we can't stabilize what we already have. And it's only getting worse.

2.1.

Agility at the Component Level

The problem is not at the infrastructure component level. Each of the components (CPU, Disk, Network Interface) is agile, in fact too agile. No other industry has innovated at such a rapid and sustained pace in so many dimensions as Information Technology. The sustained rapid improvement in component technologies over the last several decades has given rise to the so-called Laws of IT: Computation (Moore's Law): Processing price/performance doubles every 18 months Communication (Gilder's Law): Bandwidth grows at least three times faster than computing power Storage (Shugart's Law): The price per bit of magnetic storage halves every 18 months

Document1

Together, the Laws drive what is known as the Information Technology Curve of ever improving price performance. The implication of the IT Curve is that any competitor that can continuously innovate using the latest information technology will have a sustainable price/performance advantage over rivals. Accordingly, business strategy is changing from we must create barriers to innovative competitors to we must innovate faster than competitors. Nowhere is this more evident than the reinvention of Microsoft and IBM as leading proponents of open standards.

2.2.

Unwieldy Complexity End-to-End

The complexity problem is at the infrastructure system level: How does one integrate end-to-end across all components to create agile infrastructure services? The root problem is that each interface between components couples those components in ways that make it difficult to change one component without at least coordinating the change with the other component, and at worst changing the other component. The more components one adds to a system, the more interdependencies arise, eventually creating an infrastructure so brittle that innovation grinds to a halt. Consequently, once a complex infrastructure is in operation, each IT organization (ITO) repeatedly makes some version of the following tradeoff: either it emphasizes stability by refusing to upgrade or glacially upgrading tightly-coupled components, thereby sacrificing innovation by not keeping up with the IT Curve at the component level. Or the ITO emphasizes innovation by immediately upgrading components to the latest technology, thereby sacrificing the stability of the infrastructure. In either case, the infrastructure has sacrificed agility (innovation with stability). Given the growing number (N) of new business applications and the growing number (M) of new technologies, e-business N infrastructure currently faces a combinatorial explosion of complexity (NxM). The wrong answer is to eliminate heterogeneity by buying everything (applications and technology) from one NxM N+M vendor. Doing so would sacrifice innovation, since no one vendor can keep up with the IT Curve across all products only the market can. M The right answer is to turn combinatoFigure 1 rial explosion in complexity (NxM) into linear growth (N+M). This requires an architectural abstraction layer (defined by a set of standards) that insulates applications from technology, so that each can innovate independently, without requiring coordinated changes or downtime. See Figure 1. From a business perspective, the goal is to reap the benefits of technological innovation without being subjected to the costly changes generated by technology churn, while from an ITO perspective, the goal is to quickly provide the services required by the business without being subjected to the costly changes generated by business process churn.

Document1

Imagine if innovation at the end-to-end application level or the business-process level kept pace with IT Curve innovation at the component level, e.g., double the performance for the same price every eighteen months? That would truly create an ebusiness revolution.

3. Building Spanning Layers

Although the architectural principle of using an abstraction layer to reduce NxM to N+M is so old that the origin of the phrase has vanished into history, the term spanning layer was coined by David Clark, former chair of the Internet Architecture Board, to refer specifically to a set of standards forming an abstraction layer that is designed to provide interoperability across M different enabling technologies (below the layer) for use by N different types of applications (above the layer). A good spanning layer has the shape of an hourglass. Clark's paradigm, of course, was the Internet. See Figure 2. According to Clark, a spanning layer is characterized by three key attributes, which define the degree of interoperation it supports: 1. The span of infrastructure options over which the interoperation occurs [the width of the bottom of the hourglass]; 2. The range of higher-level applications the spanning layer supports [the width of the top of the hourglass]; and 3. The degree of symmetry in the services of the spanning layer and its interfaces [the network effect of adding a peer-to-peer application vs. a client/server application]. To this list, two more attributes should be added:
App2 App1 App3 App7 App5 App6 App4

Spanning Layer
Tech1 Tech3 Tech4 Tech2 Tech4 Tech5

4. The abstraction distance from the infrastructure options to the spanning layer Figure 2 [the height of the bottom of the hourglass]; and 5. The abstraction distance from the higher-level applications to the spanning layer [the height of the top of the hourglass]. The usefulness of this model of standards is that it enables intuitive comparison of key issues such as the number of uses (and therefore users) of a spanning layer and the number of technologies (and therefore vendors) supporting a spanning layer. This is essential for assessing the value of a spanning layer. The value of a standard increases with the number of vendors supporting a standard and the number of users using the standard. In economics, this is known as the network effect, because the increase in value comes not from the product embodying the standard (or the economies of scale of its production), but from the value of the standards-based service that spans the network of users and providers. (This is also known within the IT community as Metcalf's Law: The value of the network grows by the

Document1

square of the number of users.) Classic examples are fax machines and VCRs. Fax machines are based on fax communication standards that enable a fax service network that grows in value with each additional person or organization that can fax. VCRs are based on the VHS recording format that spans a tape purchase, rental, and sharing network (market) that grows in value with each new user and vendor. (Note that VHS displaced the BETA standard by spanning more vendors Sony vs. JVC and all its licensees.) The ultimate goal of any standard is not to achieve technical elegance in itself, but only as a means to maximizing its network effect. The key to maximizing the network effect of any standard is to maximize the width of both the top and bottom of the hourglass while minimizing the width of the waist (a few simple standards). The symmetry of the standard enhances the network effect, since every new node is both a subscriber and provider. The benefit of the spanning layer concept and its hourglass visual metaphor is that it provides an intuitive framework for assessing such vague and politicized terms as interoperability and openness.

3.1.

New Design Principles

However, the right approach to creating this spanning layer is not to throw more traditional software layers or Application Programming Interfaces (APIs) at the problem; so far, that has just exacerbated the problem. Instead we must begin rethinking infrastructure design by applying successful approaches in new ways. One of the most successful solutions to the NxM problem is the Internet. End-to-end, the number of technologies and applications that are composed by the Internet is astounding. Yet, changes to the technology components of the Internet are largely transparent to applications (and higher-level components). For example, Worldcom can upgrade a backbone router to take advantage of the latest innovations in optical technology without any Internet application in operation missing a beat. To expand the successful design of the Internet, we must design an architecture that can accommodate greater heterogeneity and faster change from the network up through middleware, all the way to the business applications and processes themselves. The primary design objective at all levels must be to enable innovation by enabling heterogeneity and change.

3.2. Paradigm Spanning Layers: The Internet and the Web

The Internet, and in particular the Internet Protocol (IP) is a revolutionary spanning layer because of the vast array of applications (N) it enables over diverse networks (M). However, the Internet revolution took twenty years and traversed three distinct architectural generations, each of which had the same primary design principle span heterogeneity:

Document1

1st Generation: ARAPANET enable diverse resource sharing spanning heterogeneous host computers 2nd Generation: Internet extend ARPANET to enable inter-networking spanning heterogeneous networks 3rd Generation: Web extend Internet to enable GUI (Graphical User Interface) access spanning heterogeneous resources

The first generation architecture was the ARAPANET. The primary reason why the Internet supports such a wide variety of applications (large N) is that the fundamental purpose of the ARPANET, which was inherited by the Internet, was not to provide a data network (i.e., a bit pipe), it was to create a general-purpose resource-sharing network: The principal goal of all resource-sharing computer networks, including the now international ARPA Network (the ARPANET), is to usefully interconnect geographically distributed hardware, software, and human resources. Achieving this goal requires the design and implementation of various levels of support software within each constituent computer, and the specification of network-wide "protocols" (that is, conventions regarding the format and the relative timing of network messages) governing their interaction. [RFC 707 dated Jan. 14, 1976] This emphasis on resource sharing led to the early creation of a rich set of collaborative applications: email (SMTP), remote access (TELNET), file transfer (FTP), etc. This early focus on collaborative applications was no doubt due in part to the fact that the Internet was originally built by computer scientists for computer scientists, so that they could share resources (papers, data, timesharing). In understanding the Internet way, it is important not to overlook the fact that it was computer scientists with a background in software architecture that designed the Internet protocols, not network engineers. In fact, in the early days of the Internet, its unreliable packet-switching approach was derided by many of the network engineers of the day, who espoused a reliable circuit switching architecture, based on the most successful inter-network of that time the telephone network. The second generation was the Internet, itself. The Internet grew out of the ARPANET by redesigning the ARPANET protocols to interoperate over a wide array of heterogeneous networks (M). IP enables the global scope of the Internet, as well as its ubiquity across every possible type of network hardware. The third generation spanning layer was the World Wide Web. The three core formats and protocols of the Web HTTP (HyperText Transfer Protocol), HTML (HyperText Markup Language), and URI (Uniform Resource Identifier) were designed by Tim Berners-Lee as a spanning layer enabling a wide variety of applications (Browsing, Audio, Video, Searching) based on visual presentation of and access to documents, images, and other media (i.e., a GUI spanning layer). As a result of these successive generations of architecture fundamentally focused on accommodating diverse uses and diverse technologies, the Internet is the most agile

Document1

architecture today. It's not the most reliable; it's not the most scalable; but it's arguably the most adaptive. Although the Internet and Web have enabled a wide array of collaborative and presentation applications based on a core set of enabling protocols (TELNET, SMTP, FTP, HTTP, HTML, etc.), the Internet has not yet produced a successful applicationlevel spanning layer for integrating or distributing applications. All prior attempts to create such a ubiquitous distributed-computing spanning layer atop the Internet have ended in failure: RPC, DCE, CORBA, DCOM, RMI. (Although each has achieved a fair degree of success in particular industries, e.g., CORBA in telecom and embedded systems.) To succeed where past attempts have failed, a revolutionary approach is required. The emerging Web services standards represent the fourth generation of the Internet, whose goal is to create a revolutionary XML-based, distributed network computing spanning layer enabling a wide variety of applications beyond the Web GUI (vastly expanding N). (For those who are skeptical of revolutions, keep in mind that until HTML/HTTP revolutionized the distributed-GUI market, it too was strewn with failed attempts to create a GUI spanning layer.)

4. Agile Infrastructure: Web Services Network Architecture

Imagine a world in which a vast array of applications (vast N) is intuitively described by a business-modeling framework annotated with Quality-of-Service (QoS) requirements. This modeling framework is supported as widely as the Web framework is supported today. Businesses use these QoS-annotated application models to find and bind to a wide range of infrastructure providers on the fly while the application is in operation. Infrastructure resources from these service providers (computational, storage, communication, and user device) would be added to the application in potentially massive quantities (vast M) on demand to meet QoS requirements: throughput, response time, number of users, increased security, increased availability. These resources would be freed as service demands decreased. In such a world, businesses and their applications could choose among service providers continuously, while in operation, with minimal switching costs. Although, at first glance, this world might seem like science fiction, consider how quickly the Web created an analogous world of dynamic GUI access to vast amounts of information and services. The goal is to expand the Internet and Web architecture and culture to realize such a vision to create a dynamically composable, application-level inter-networkable, service-oriented architecture (SOA) that provides unified access to heterogeneous computational resources (J2EE, .Net, legacy), storage resources (NAS and SAN), and user-device resources (desktop, phone, PDA) on a massive scale. It will be massive both in terms of functionalities (offering myriad features and functions) and in terms of -ilities (enabling massive scalability and high availability). The resources will be spanned in a fairly coarse grained manner (a file, a message, a presentation page, a business

Document1

process). Fine-grained spanning (thread, task, block, packet) will continue to require more traditional architecture for some time (although one that is agile as well). The approach is to overlay the Internet with an application-level active network architecture based on composable XML-based Web services protocols a Web Services Network Architecture (WSNA). Standards for addressing, routing, message processing, security, reliability, and scalability must be defined independently to enable independent rates of innovation. Yet the standards must each be composable into concrete application-level networks. To actually achieve this goal when others have failed, requires a paradigm shift in thinking about what needs to be composable and how to do composition.

4.1. From Composable Business Objects to Composable Infrastructure

Just as component-modeling and -development approaches have benefited business applications, it is becoming increasing clear that they will benefit, if not revolutionize, the technical infrastructure at both the software and hardware layers. Technical infrastructure, not just business applications, must be composable to deal with the NxM problem. The goal is to combine lessons learned from component- and object-oriented software architectures (OOAs) with lessons learned from the Internet way to take the next step towards the ur-vision of universal resource sharing among interconnected users and systems, which dates back to the earliest days of computing. Just as the Internet has gone through three generations prior to the WSNA, so too has software architecture, which grew up along side the Internet. First was the generation of hardware plus operating system. The belief was that a centralized computing utility based on a single OS with massive hardware scalability was the key to such resource sharing. The units of composition were hardware units (e.g., CPUs, memory systems, I/O subsystems) as well as OS units (e.g., programs, processes, libraries). Paradigm: Multics. Second was the generation of ad hoc middleware (muddleware?). The belief was that centralized homogeneous HW/OS was never going to happen, so the answer must be distributed, homogeneous, middleware unifying heterogeneous HW/OS. This led to a dog's breakfast of point-to-point middleware solutions: ODBC, MOM, RPC, etc. Paradigm: Client/Server. The third generation is the current component-based, distributed-OOA approach, which enables resource sharing among users and systems via components at the business level (e.g., invoice, PO, part, supplier) by building on top of a homogeneous distributedsoftware framework. Each such framework enables interoperability and composability of business components built within the framework, but the framework itself is not composable. For example, one can't use the CORBA security service from one vendor with the CORBA transaction service from another. Even worse, there is limited interoperability between frameworks (e.g., COM does not work well with CORBA), so

10

Document1

each vendor camp pushed the vision that someday its particular framework will become the universal framework. Paradigm: CORBA. Meanwhile, the only successful example of universal resource sharing among interconnected users and systems the Internet was taken for granted as just a pipe. That is, until the Web was born. Since then, architects, developers, vendors, etc. have begun studying and adopting the principles and practices that enabled the Internet and the Web to go beyond the limited successes of the HW/OS, middleware, and distributed-OOA generations. Perhaps the most profound but subtle principle guiding the design and architecture of the Internet is that all its services are specified entirely by layered protocols. The standards defining IP (RFC 701), TCP (RFC 793), HTTP (RFC 2616), etc. all describe protocols, not hardware interfaces, nor APIs. Although hardware and software are obviously required to implement the protocols, they are treated as implementation details, not architectural ones. To put it more bluntly: Hardware interfaces and APIs don't belong in agile architectural standards, they only belong in implementation standards. The only limitation of the Internet protocol standards is that they are focused primarily on communication resources, not computational, storage, or business-level resources. The Web (HTML and HTTP) changed that. It showed how an Internet-oriented, protocol-based architecture could enable universal GUI presentation, navigation and access to resources by users. Web services are much more than the current acronym soup used to define them: XML + SOAP + WSDL + UDDI. They represent the first step towards expanding the Internet and Web protocols beyond just communication resources to all IT resources and beyond just user access of resources to universal resource-sharing among interconnected users and systems. Thus Web services will enable systems to surf, access, and interact with other systems, just as people do today. The next generation of software architecture is a recursively-composable applicationlevel network of protocol-based services providing the spanning layer for a wide variety of applications dynamically sharing a broad array of Internet-accessible resources on a massive scale. This next generation is a convergence generation, in which OOA will fully converge with Internet and Web architecture to create an SOA we call the Web Services Network Architecture (WSNA). The WSNA's small set of well-factored, dynamically-bound, composable services represents the next leap toward the vision of universal resource sharing among interconnected users and systems. The WSNA is the architecture required for agile infrastructure providing a new foundation of stable formats and protocols enabling both the agility of the applications and business processes above it, as well the agility of in the technologies below it.

11

Document1

4.2. Composable = Interoperable + Protocol-Based + Dynamically-Bound + Well Factored

For the Web Services Network Architecture to succeed where distributed OOA has failed, it must offer a composable framework that is truly universal (i.e., every vendor supports it) and is composable all the way down (i.e., does not assume a monolithic foundation somewhere down in the stack). Such an architecture must be: Interoperable: supported by all vendors; Protocol-based: defined by composition based on distributed protocols instead of distributed software; Dynamically bound: able to substitute one implementation for another while in operation; and Well-factored: formal separation of concerns at a useable level of abstraction that applies to a wide variety of resources and makes those resources usable in a wide variety of ways.

4.2.1.

Interoperable

There are very few standards supported by all vendors: ASCII, UNICODE, SQL, TCP/IP, and HTML/HTTP. And all of them, uncoincidentally, are paradigm examples of spanning layers. The baseline WSNA protocols (SOAP, UDDI, WSDL) have rapidly achieved the same level of commitment by all vendors committed to Internet standards. Furthermore, interoperability testing of these baseline protocols is well under way. For example, the primary mandate of the recently formed Web Services Interoperability organization (www.ws-i.org) is to promote interoperability by publishing test suites for various scenarios. However, interoperability is not enough. If it were all that was required to build an agile infrastructure, they would be common today, since most significant infrastructure technologies are fairly interoperable at some level. No, much more is required. Not only must protocol implementations from many vendors actually be compatible, the protocols themselves must become the unit of composition.

4.2.2.

Protocol-Based

The problem with OOA is that the unit of composition is an object or a component. This implies an actual software component be used to represent the object, which then requires a standard execution environment for containing such objects. OOA has also led to battles over composition techniques such as inheritance, delegation, etc. The solution emerging via the WSNA is that the correct unit of composition for a service is not defined in terms of a software component with an API, which both exposes lots of unnecessary details about particular programming issues and hides necessary details about network behavior. Rather, the unit of composition is defined solely in terms of the pattern of interactions between the provider and subscriber (i.e., the behavior) and the information exchanged with each interaction. The abstract definition of a behavior is called a protocol, and the abstract definition of information is called a format.

12

Document1

Accordingly, the interface between two systems (i.e., endpoints) is simply the set of formats and protocols (aka FAPs) that define the interactions between them. (Note that while strictly speaking an interface is always between two systems, we will refer to the interface of a single system when focusing on the behavioral properties of that system. Also, we will use the terms FAP and protocol interchangeably, except where the distinction is relevant.) This is exactly how Internet services are defined IP, TCP, TELNET, FTP, HTTP. Internet architects have always thought of the Internet as a set of layered protocols, NOT a set of layered software components. Unfortunately, this distinction between layered protocols and layered APIs did not gain currency outside of the network-centric Internet culture until now. The WSNA represents a powerful expansion of the Internet way. WSNA interfaces are XML definitions that specify only the abstract protocols that define the interactions between two systems. The power of this is approach is that a Web service (technically a Web service protocol) can be defined abstractly to minimize the coupling between the provider and the service. Then, this abstract protocol (defined in XML) can be realized by a concrete protocol (also defined in XML) via a binding, which is yet another XML definition that simply specifies how to translate between the two. For example, in WSDL, an abstract service interface is called a port type. It is composed of an abstract endpoint and an abstract protocol for exchanging information with that endpoint. It is realized by a concrete interface called a port, which is simply a binding of the abstract endpoint onto an actual URI and the binding of the abstract protocol onto a concrete protocol, e.g., SOAP. SOAP itself is an abstract protocol that is realized by a binding to a concrete protocol, e.g., HTTP. At each level, each protocol and binding is represented in XML. If these levels of protocol were simply designed to be implemented by distinct runtime software layers (one Abstract Protocol SOAP for WSDL, one for SOAP, and one for HTTP), then the distinction between Abstract Protocol SOAP Representation Representation protocol-based and API-based would be at Binding Binding best a subtle conceptual distinction Concrete Protocol HTTP (albeit an important Concrete Protocol HTTP Representation Representation one).
(a) (b) But these XML protocols are not Web Services Interface Engine intended to be simply Figure 3 realized by software components via APIs. Rather, the actual work of realizing an abstract XML protocol by a concrete XML protocol via an explicit XML binding is done by a general-purpose Web Services Interface Engine (WSIE). See Figure 3.

13

Document1

4.2.2.1. Protocol-Driven Infrastructure

This approach eliminates the traditional layered software API stack, with each component layer acting as a black box interface engine (mapping a higher-level protocol onto a lower-level one represented in software), and replaces it with a virtual protocol stack driven by a single WSIE. The WSNA is all about extending the proven success of the Web user interface (WUI) conceptual architecture (based on the HTML/HTTP protocol) beyond mere user access. The WUI replaced the traditional client/server approach of distributing a different set of GUI software components for each application deployed to each desktop (NxM), with a single (N+M) WUI spanning layer. The WUI spanning layer deploys a distributed HTML-transformation engine in the form of a desktop-based HTML-rendering engine (i.e., the web browser) and a server-based HTML-generating engine (i.e., the web server). The rendering engine primarily renders by transforming HTML, not by executing downloaded code (e.g., applets and plug-ins). In two to three years, organizations will begin deploying a single WSIE per desktop, device, or server. Eventually replacing the client/server HTML-transformation engine, this WSIE will both generate/render WUIs and also expose/access Web services interfaces (WSIs) by transforming XML representations, not executing code performing by transforming. To get an idea of how WUI composition will converge with the WSI composition, see IBM's Web Services eXperience Language (WSXL). Essentially, the WSNA enables a protocol driven infrastructure (PDI). As we move towards protocol-driven infrastructure, XML transformation engines become the primary computational engines, e.g., DOM (Document Object Model) and SAX (Simple API for XML) are to XML as JVM is to Java although these XML parsing technologies will be evolving rapidly as well. Although this may sound revolutionary, it is just the latest inflection point in a long trend known as data-driven or declarative programming. The basic concept is to create a declarative language that states what result is desired, not how to achieve that result, and then create an engine that inputs a description as data and transforms it into the desired result. Common examples include SQL, Query By Example, spreadsheets, mail merging, workflow, Postscript, LaTex, SGML, HTML, and XML. A similar concept is being explored by IBM's NextWeb Interfaces Group.

4.2.2.2. Protocol-Driven Infrastructure Advantages

As an SOA, the WSNA defines a type of service only in terms of its behavior (protocol) and the information exchanged via such behavior (format). Besides minimizing design coupling at the architectural level, this protocol-driven approach has several infrastructure-engineering advantages: Because the binding from one protocol to another is more explicit, it is easier to test for correctness. Because only one WSIE is required per platform, it is less prone to software bugs than N distinct software layers.

14

Document1

It minimizes deployment of service-specific software to service subscribers. Changes in the design of a lower-level service require only the redeployment of an XML binding definition, instead of a software component. The fact that each Web service provider is actually invoked via an Internet transport, dramatically reduces coupling issues between subscriber software and server software, and makes complex composition possible. The only coupling issue is protocol traffic interference (e.g., a bursty event-driven protocol interfering with high throughput batch protocol).

The only potentially substantial architectural disadvantage is that conventional wisdom promotes insulating a higher-level protocol from changes in lower-level protocols by using an intervening software layer with an API that masks changes in the lower-level protocols from changes in the higher-level protocols. The WSNA approach of direct and explicit binding seems to contradict such wisdom. However, the WSNA approach actually provides a greater degree of insulation, in the form of the XML binding definition. The binding explicitly describes precisely which aspects of the lower-level protocol directly impact the higher-level protocol. This makes clear which aspects of the lower-level protocol can change without impacting the higherlevel protocol.

4.2.3.

Dynamically Bound

While defining services in terms of bindable protocols makes possible design and deployment of new services on an Internet scale, the WSNA must also enable such deployment to take place while the applications using such services are still in production. Thus the architecture must provide a service that enables an application to dynamically define, discover, and bind any required service while in operation. Universal Description Discovery and Integration (UDDI) is just such a service. UDDI makes it possible for a subscriber of a type of service to bind to a specific published service provider based on an open-ended set of criteria (known as tModels) that describe the service. UDDI is somewhat of a misnomer, because although it provides specific capabilities for publishing and finding, it does not actually integrate the subscriber with the service. Instead, it provides the subscriber with sufficient binding information to enable it to bind to the provider. The nature of the binding information and when in the subscriber lifecycle it is applied (design time, build time, deploy time, boot time, run time) is left open. UDDI should be thought of as UDDB: Universal Description, Discovery, and Binding. However, certain UDDI usage patterns enabling fully automated run-time binding are already emerging. For example, a private UDDI registry could be established by an enterprise to contain entries for both internal applications and trusted business partner applications, and these entries could be required to provide WSDL service definitions. Then dynamic binding would be a three-step process: 1. At initialization time, the subscriber uses UDDI to find a service provider for a service defined by WSDL. 2. Then the subscriber binds to the WSDL service provider.

15

Document1

3. When invoking a service at run time, if the service provider is unavailable (signaled by a fault), repeat step one to find a possible change to the current service provider address, or to find an alternative service transport to the current provider, or to find an alternative service provider (in that order). Another set of usage patterns is emerging to fully automate self-publishing of a service into UDDI as part of the service's self-provisioning process. As a set of general engineering principles for keeping the service subscriber and provider as loosely coupled as possible, the interface logic actually coded into the subscriber (and provider) should have the following characteristics: Minimal: The subscriber mechanism for invoking the service should be as simple and general purpose as possible, e.g., just the abstract service definition. Standard/Stable: This is currently a WSNA weakness, since its defining standards are still in flux. Bootstrappable: UDDIs find/bind mechanism and WSDL should be used to dynamically bind the abstract service definition to the concrete service.

It is important to remember that in all of this dynamic binding activity, XML definitions of service behaviors (protocols) are moving back and forth over a network, not code. This again minimizes the implicit coupling between service providers and subscribers. This distinction is a fundamental engineering difference between an SOA like the WSNA and an OOA like COM, J2EE, or CORBA. Although the latter have always stressed the importance of logical separation between interface and implementation, the fact that the component implementing the interface is physically incorporated into the application means that to substitute one implementation for another entails rebuilding (recompiling or at least relinking) the application. This effectively prevents the components implementation from ever being changed once the application is in production. Dynamic linking (e.g., DLLs) lessens the rebuilding issue to some degree, but since the DLL is still physically accessed from the computer containing the application, the owner of the computer still has to retain control of changes to the DLL (e.g., installing new DLLs). Thus, the WSNA effectively decouples the use of a service and its implementation by physically separating the two over a network. This is why the WSNA (or other SOA) is inherently a network-oriented architecture.

4.2.4.

Well-factored

Of course even with powerful models and mechanisms for enabling services, it is always possible to design services that are poorly factored. The art of service design lies largely in the insight required to decompose complex systems into simple protocolbased services that can be dynamically assembled into more complex functions with a bundle of QoS and security capabilities. The goal is to compose a relatively small number of general-purpose (generic) services rather than either:

16

Document1

A large number of special-purpose (custom) services that favors innovation over stability and results in a nightmare of a continuously semi-stable integration of custom best-of-breed services; or A single multipurpose service framework that favors stability over innovation and results in instant legacy.
App2 App4 App1 App5 App3 App6 App7 App1 App2 App3 Tech1

Tech1 Tech2 Tech3 Tech4 Tech4 Tech 5

Tech1 Tech2 Tech3 Tech4 Tech4 Tech 5

Tech1 Tech2 Tech3 Tech4 Tech4 Tech 5

Figure 4

In terms of the spanning layer concept, the first alternative looks like a series of inverted funnels. See Figure 4. At the apex of each pyramid is the custom application service, while at the base are all the heterogeneous implementations it can be mapped to. For example, consider the proliferation of web protocols for things like streaming audio, video, instant messaging, animation, etc. The second alternative looks like a funnel. The narrow bottom represents one multipurpose service, while the broad top represents a variety of application services. For example, consider all of the monolithic component frameworks of the 1990's: DCE, CORBA, COM, J2EE. The key is to design a small set of composable services that creates an hourglass shape and then to repeat this process recursively all the way up and down the stack (from infrastructure, through application, through business processes, to business organization) until the entire stovepipe stack has been refactored into a compositional multi-level network of processes and services. For example, the WSNA is already refactoring the middleware layer into composable transport (HTTP), routing (SOAP), marshalling (WSDL), and binding (XSLT), services. One can also see a similar refactoring in storage and server architecture. Storage virtualization represents the refactoring of the traditional storage stack into a storage network of composable services (instant copy, remote mirroring, etc.). Scale-out architectures like Infiniband and server farms represent the refactoring of the traditional server box into a composable server network.

4.3.

Business Impact

Before moving on to a more detailed discussion of such refactoring in the context of the WSNA, a brief discussion of the business impact of the WSNA may better motivate its principle of composition without components.

17

Document1

From a business perspective, WSNA might be translated as Work with Services, Not Assets. In other words, the value of the software is in the service it provides, not in the software asset itself. Accordingly, businesses should think more in terms of providing and using fee-based services, and less in terms of buying or selling the software and hardware that enable such services. Examples of such thinking abound: Anti-Virus: McAfee and Symantec. Given the rate of change in virus signatures, anti-virus software is useless without a signature-update service. (Anti-virus software companies should expand the potential size of the market by commodifying the subscriber software let MSFT bundle it and then compete on their update services.) Online Services: AOL, MSN. Both give away the subscriber software and sell the service (and even subsidize the PC itself through rebates). Mobile voice: Sprint, AT&T, Verizon, Cingular, etc. give away (bundle) the phone with the service and compete on their services. Amateur photography: Kodak, Fuji. Disposable cameras are an interesting variation of give away the hardware and charge for the service, in that a disposable camera is not tied to a particular processing service. Disposable cameras open up a new market for pictures that wouldn't have been taken with non-disposable cameras. Film vendors sell into this market hoping to gain some share of this market expansion.

The more the WSNA achieves the status of a ubiquitous spanning layer the more it will make possible the delivery of services with minimal service-specific subscriber software and the less valuable the client software market becomes. From a business perspective, the essential difference between a product and a service is not whether or not an asset or set of assets is involved; rather it is which rights and obligations concerning the assets are transferred in the transaction concerning the assets. Transaction cost economics analyzes many factors that determine the product buy vs. service lease issue. But from the perspective of this white paper enabling continuous business innovation via infrastructure agility two factors are critical. First, is the degree to which the service offered by the asset is standardized. As various business assets become more standardized, there is less need to own the asset. This is happening across a wide variety of assets: office space, retail space (the dominance of the mall), factories (contract manufacturing), warehouse space, etc. Second, is the degree to which the business using the asset values continuous innovation in the continuous improvement of the quality and price of the service provided by the asset. If the business values continuous improvement, it should use a service that enables the provider to innovate and improve the asset independently. If it doesn't value improvement of the asset's service, it should buy the asset and use and maintain it, as is, for the life of the asset. The IT infrastructure market is unique in its demand for highly standardized yet rapidly improving products/services. Normally, standardization of an infrastructure product/service signals the end of substantial improvement and the beginning of pure

18

Document1

commodification. The IT Curve ensures that this will not happen in the IT infrastructure market any time soon. Thus, in a marketplace of standard and stable product and service interfaces, the best strategy for locking in users is to innovate in improving the service quality and price of the product or service. A service-centric strategy based on sustained innovation and IT experience is exactly the strategy of Intel, Dell, HP, Microsoft, and more recently, IBM's Linux, J2EE, and open source strategies.

5. Agile Infrastructure: Spanning Layer Reference Model

Having glimpsed how the WSNA will impact business, let us return to the central issue of how to factor the WSNA into a small set of recursively composable protocols. The art of spanning layer design is making the waist of the hourglass as narrow as possible. To achieve this, one must offer a small number of average capabilities, each of which possesses above average agility (e.g., composability, extensibility, dynamic binding). Over the long run, average architecture with above average adaptability will displace best of breed architecture with average adaptability. That is the lesson of the IT Curve and the commodification it drives. The Internet architecture has never best of breed; neither has the Intel architecture or Ethernet architecture; nor the SCSI architecture. But each has proven to be incredibly adaptable and successful at displacing competitors.

5.1. Recursive Composition of Services: The Spanning Layer Reference Model

For insight into how to design well-factored services that will expand the power and simplicity of the Internet spanning-layer hourglass beyond the basic protocols (IP and TCP), the best place to begin looking is inside the underlying structure of the Internet spanning layer itself. Only by understanding how the Internet successfully factored and cleanly separated the requirements for composing diverse applications based on diverse technologies, can we hope to repeat its success elsewhere. The design principles underlying the protocol layering of the Internet can be generalized as a three-level spanning layer reference model (SLRM): Service Model: the protocol for accessing the functional and operational (QoS) capabilities of basic (atomic) services. Composition Model: the protocol for composing basic services into a composite process. Global Model: the protocol for augmenting the operational capabilities of the composition model and exposing it as a composite service.

The three levels of the SLRM can be repeated recursively, with a lower-level global model binding to a higher-level service model.

19

Document1

5.1.1.

The Internet SLRM

In the case of the Internet, the service model, although never formally defined, corresponds to the minimal requirements for each of the heterogeneous networks (Ethernet, X.25, ATM, dialup) that the Internet overlays. In the case of the Internet the requirements are minimal indeed: The basic assumption is that [an underlying] network can transport a packet or datagram. The packet must be of reasonable size, perhaps 100 bytes minimum, and should be delivered with reasonable but not perfect reliability. [The Design Philosophy of the DARPA Internet Protocols] The composition model corresponds to the IP protocol, which specifies the minimum information required to route a packet from a source address to a destination address. In essence, it composes a set of point-to-point links across heterogeneous networks (each defined by the service model) into a route from the source to the destination. The global model corresponds to the TCP protocol, which exposes the IP service to processes on each host computer and which augments the reliability of the IP subnet with end-to-end protocols for packet ordering and reliable delivery. Based on these three models, the Internet spanning layer provided a diverse set of applications a reliable byte stream over a global inter-network of heterogeneous network technologies and changed the world. Moving one level up to the Web, we see this spanning-layer revolution repeated. The composition model is HTTP, which enables the composition of a set of intermediaries (caches, proxies, firewalls, load balancers) to route the HTTP operation (GET, POST, etc.) from source to destination. As with IP, the service model on which HTTP is built is not formally defined except for the mapping of HTTP onto TCP (although the standard does say other transports can be used). The global model is HTML, which composes a set HTTP-based hyperlinks into a hypertext document. (It might be more accurate to think of the web browser/server distributed HTML-transformation engine, modeled as part of the HTML v1.1 specification [RFC2616], as the global model.) The Web Services Network Architecture represents yet another revolutionary spanning layer based on this SLRM, as we will see below.

5.1.2.

Comparing Spanning Layers

The SLRM provides an invaluable tool for analyzing the current explosion of XML standards by identifying which have better hourglass shapes than others. For example, the Value Chain Markup Language (VCML) is basically a straightforward translation of EDI formats into XML. While useful, the shape of such an abstraction is narrow at the top (useful for EDI-type applications only) and the bottom (EDI-centric technologies). A more interesting example is the shape of the ebXML spanning layer vs. the shape of the WSNA spanning layer. Although they arguably have comparably shaped lower halves (given that the ebXML messaging specification is based on SOAP), the upper half of ebXML definitely covers a narrower range of applications.

20

Document1

The stated goal of ebXML, which grows out of its EDI heritage, is currently limited to electronic trade across business boundaries: A single set of internationally agreed upon technical specifications that consist of common XML semantics and related document structures to facilitate global trade. For example, ebXML lacks the ability to recursively compose general-purpose processes (a la WSFL). Rather, it only enables the recursive composition of cross-enterprise business transactions. There is no question that ebXML is a much more fully specified B2B transaction architecture than the WSNA, but as a result, it is much less general purpose. As stated above, when it comes to spanning layers: Over the long run, average architecture with above average adaptability will displace best of breed architecture with average adaptability. (The good news is that OASIS appears to be in the process of refactoring ebXML to layer it on top of the lowerlevel and more general WSNA.) The goal of the WSNA, which grows out of its Web/Internet heritage, is to enable any type of application either within or between enterprises. Let's analyze the WSNA in terms of each of the three levels of the spanning layer reference model (SLRM) to see how well it achieves this goal.

5.2.

Service Model

The service model defines how the basic resource building blocks are modeled. The service model determines the width of the bottom half of the spanning layer hourglass. The service model can be thought of as abstracting a common intermediate representation (CIR) and common intermediate protocol (CIP) for as large a set of heterogeneous resources as possible. It is the basic wrapper or adapter model the resource on the other side of the protocol is an atomic black box. The goal is to abstract the 20% of functionality that is common to 80% of the resources, instead of trying to capture every exotic capability. The more generic the service model, the broader the market for service providers (e.g., see the diverse technologies competing in the Internet access market dial up, ISDN, DSL, Cable, wireless, etc.). At the same time, the CIR and CIP should be designed for change extensibility, composability, etc. The essential artistic issue is what minimum basic capabilities are required of such heterogeneous basic services; i.e., how tall is the bottom half of the spanning layer. Too much abstraction requires too much complexity from each resource wrapper, limiting the number of resource providers who are interested in providing a binding for the service. In part, this is what prevented CORBA IDL from becoming a universal wrapper. On the other hand, too little abstraction limits how many resources can be bound to the abstraction. The failure of SQL-based interfaces (e.g., ODBC, OLE-DB, JDBC) to become universal resource abstractions is based on the fact that they are too closely tied to resources that implement the relational model.

5.2.1.

The WSDL Service Model

An excellent example of a well-designed service model is the Web Services Description Language (WSDL). WSDL is an XML-based model for describing a simple network-

21

Document1

accessible service. WSDL defines an abstract set of message formats and operational protocols (FAPs) for interacting with a single shared resource via a concrete Internet protocol. WSDL defines a Web service in terms of two fundamental aspects: Service type: The abstract XML-based FAPs (aka CIRs and CIPs) that specify the generic service type. Service binding: The XML-based definition that describes the mapping of a generic service type onto a specific service provider (specified by a URI) and connection to that provider (specified by a transport binding). Unlike traditional wrapper architectures, WSDL focuses on, rather than hides, the issue of service communication. In the WSDL model, the transport is treated as a first class concept. This is an essential difference between an OOA and an SOA such as the WSNA. An OOA API is tightly coupled to a fixed transport implementation (e.g., function call, IIOP, RMI), while a WSNA service is not. The WSNA treats the transport over which a service is accessed as a fundamental design issue that should be exposed, not hidden. Thus, the WSNA is an explicitly network-oriented architecture. Furthermore, one of the primary design goals of WSDL is to enable innovation via extensibility: Extensibility elements allow innovation in the area of network and message protocols without having to revise the base WSDL [service type] specification. WSDL recommends that specifications defining such protocols also define any necessary WSDL extensions used to describe those protocols or formats. [emphasis added]. [WSDL Spec] Although the abstraction performed by the service model is important, by itself it cannot generate more complex composite services. WSDL alone is too simple to define anything except the simplest business services (e.g., verify credit card). The service model corresponds to the traditional device driver model. Driver models such as printer drivers, database drivers, disk drivers, input device drivers (e.g., keyboard) provide a limited type of spanning layer. For example, an OS-level printerdriver framework enables N applications to use M different printers (N+M).

5.3.

Composition Model

However, the device driver model provides no way to compose these basic device services into more complex services other than by programming such a service in some prescriptive programming language (e.g., Java, C++). This is the role of the composition model. The composition model defines an abstract protocol (i.e., a descriptive language) for composing individual service models into a more complex composite protocol that can be distributed across networks, devices, servers, and storage. Thus the role of the composition model or language is often described in the following terms: Flowing (data flow, control flow, work flow) Multiplexing Routing

22

Document1

Clustering Orchestrating Choreographing

While each of these terms obviously refers to distinct architectures, there is a general composition concept that unifies them. We use the term compose to refer generally to any of these related terms. Composition across autonomous systems is referred to as federation. On the Internet, an autonomous system (AS) is the unit of router policy, consisting of either a single network or a group of networks that is controlled by a common network administrator (or group of administrators) on behalf of a single administrative entity (such as a university, a business enterprise, or a business division). Thus, federation is composition across business and administrative boundaries. A truly agile spanning layer should not only be composable, but federalizable. Although simple to define and espouse, it is extremely difficult to design and implement. Note that the original designers of the Internet put distributed management and resource accountability relatively low on the ordered list of design goals (fifth and eighth out of eight). See Figure 5. Hence, the Internet way shows that simple spanning protocols that enable independent management within each AS are more agile than complex end-to-end management and chargeback protocols, e.g., OSI, DECNET, SNA, etc.
The Goals of the Internet Architecture in Order of Priority
1. The Internet architecture must provide an effective technique for multiplexed utilization of existing interconnected networks. Internet communication must continue despite loss of networks or gateways. The Internet must support multiple types of communications service. The Internet architecture must accommodate a variety of networks. The Internet architecture must permit distributed management of its resources. The Internet architecture must be cost effective. The Internet architecture must permit host attachment with a low level of effort. The resources used in the Internet architecture must be accountable.

2. 3. 4. 5. 6. 7.

8. For example, as discussed above, the composition model of the Internet is the IP protocol, which enables a set of individual point[THE DESIGN PHILOSOPHY OF THE DARPA INTERNET PROTOCOLS, David D. to-point paths through heterogeneous networks Clark] across autonomous systems to be composed (federated) into a route from the source to the Figure 5 destination. What was revolutionary about the IP protocol was that it showed that a simple, general-purpose packet-routing protocol could succeed where far more complex and robust networks (OSI, SNA, DECNET) had failed. IP unified autonomous systems across enterprises, government, and geographies around the globe into one inter-network the Internet.

However, composition is not just about generating complex behavior from simple components. Just as important is IP's ability to scale from a 9600 bps dialup to a 10 Gbit/sec Ethernet and to reliably interconnect over 125 million hosts (as of 07/2001; Source: Internet Software Consortium http://www.isc.org/). Thus, it's also about generating high-end performance and reliability from large numbers of low-end components. Multiplexing and clustering are obvious forms of performance and reliability-oriented composition techniques. Clearly, not only fatter and more reliable

23

Document1

pipes, but also multiplexing on a grand scale has enabled the Internet to achieve massive performance and reliability. The ultimate goal of the WSNA is to converge network, computation, and storage composition models into one unified composition model. If this seems to be a lofty but distant goal, recall that ad hoc convergence is already a fact: the massive scalability and reliability of the largest web sites is the result of scale-out architectures based on IP redirection. One such example is the infrastructure for Google's search engine. As of late 2001, Google used a network of over 12,000 Linux servers (each of which has a single Intel processor (many Celeron-based), 256 Mb of memory, and 80 GBs of storage) to store, index, match, and retrieve web pages. There are no centralized storage or lookup servers. And Google manages this with a relatively small support staff and highly automated custom support tools (e.g., an installer that can provision 80 servers at a time). Thus, computation (albeit read-only query computation) and storage have been massively distributed into Google's network. This is the goal of the WSNA, and it is the SLRM, especially the composition model, that makes such designs tractable. Another example is Edge Side Includes (ESI), which is "a simple markup language used to define Web page components for dynamic assembly and delivery of Web applications at the edge of the Internet." [http://www.esi.org/] The goal of ESI is to enable parts of an HTML web page to be generated from servers deployed at ISPs at the edge of the network. For example, the skeleton of the web page comes from the originating site (e.g., www.metagroup.com), while the header, pictures, text blocks, ticker info, etc., are all cached at edge servers. This enables a full page of content to be delivered to a browser much more quickly and reliably. ESI currently unifies network and storage (caching) so that web page content can be distributed throughout the network, including the edge. ESI.org is working on unifying computation as well by specifying a processing model that enables limited forms of presentation-oriented computation to be distributed throughout the network, e.g., simple JavaScript executing at edge nodes. Companies backing esi.org include Akamai, ATG, BEA Systems, Circadence, Digital Island, IBM, Interwoven, Oracle, and Vignette.

5.3.1.

The SOAP Composition Model

Again, the WSNA provides a paradigm of how to design an extensible service composition model. At the heart of Web services is SOAP. (According to the draft SOAP v1.2 spec, SOAP is no longer to be considered an acronym for Simple Object Access Protocol. Several people have suggested Service Oriented Architecture Protocol instead.) SOAP v1.2 enables applications to be composed out of the network itself, completely blurring the line separating what work is done at a tier vs. between tiers. One can view this as either application-level networking or network-level applications. SOAP represents the architectural evolution from N-Tier distributed computing to network distributed computing. The first revolutionary aspect of SOAP is that it decomposes the traditional network layer's highly interdependent address, envelope, and routing standards into independent but composable standards. This is a major advance beyond the traditional

24

Document1

IP protocol (both IPv4 and IPv6). and is much closer in approach to the DARPAsponsored NewArch project (www.isi.edu/newarch/). The SOAP architecture is actually composed of three independent composable standards: 1. an extensible address standard 2. an extensible envelope-exchange and transport-binding processing standard 3. an extensible routing standard First, the address standard for SOAP (and all Web service protocols) is URI (Uniform Resource Identifier). URI has its own composition model and extensibility mechanism, which is rapidly evolving beyond the ubiquitous URL (e.g., http://www.metagroup.com/). Second, the SOAP envelope-exchange and transport-binding processing standard enables composability based on both the envelope's highly extensible XML header structure and the highly extensible transport-binding feature structure. The goal is to enable both processing and transformation of an envelope's headers en route, at each intermediate SOAP network node, without the explicit knowledge or participation of the communicating endpoints. This enables QoS attributes to be added to the envelope in a federated and composable way. SOAP standardizes the relationship between each header in an envelope and a corresponding actor, which can read, modify, delete, or even add headers to the envelope. SOAP actors can be deployed at either of the endpoints or at any intermediary. The SOAP processing model also enables message processing to be flexibly delegated to either the transport or the SOAP nodes. For example, if a transport supported reliable delivery, then responsibility for reliable delivery for a SOAP message could be delegated to the transport, rather than handled by the two communicating nodes. Beyond mere QoS composition, SOAP's header/actor/intermediary composition model defines a distributed, decentralized, heterogeneous, information-exchange model so extensible that it enables the unification of data flow, workflow, and routing architectures. It promises the ability to map a business-process orchestration model (e.g., WSFL or XLANG) onto a distributed network of active XML routers with a few well-formed XML transformations (i.e., bindings). The SOAP actor-based message exchange model is where application-level routing meets active networks (see below) to provide an application-level active network overlay on the Internet. Instead of IP routers parsing and processing IP packets, SOAP routers will parse and execute XML envelopes. Third, although the SOAP v1.2 specification defines a message exchange model defined by active (actor) intermediaries, it does not specify any particular routing model. Microsoft has proposed two SOAP routing standards, WS-Routing and WS-Referral, which respectively define an explicit routing model (with the route contained in the message) and an implicit routing model (with SOAP intermediaries containing routing instructions).

25

Document1

5.3.2.

The WSFL Composition Model

While SOAP provides a powerful model of composition, it is fairly low-level and communication centric. For the WSNA to expand up to the business process level, a higher-level spanning layer is required. IBM has proposed a Web services flow language (WSFL) as just such a spanning layer. Just as the combination of HTML/HTTP enables a rich variety of complex WUIs to be declaratively composed out of GUI building blocks (text, images, sound, links) with little or no code, WSFL enables a wide array of complex services to be declaratively composed out of simple Web service building blocks with little or no code again, composition without (software) components. In terms of the SLRM, the WSFL service model is defined by WSDL. That is, for any basic service to be able to participate in a composed flow, it must be accessible via WSDL. The WSFL composition model is called the flow model, which defines the flow of control and data among the services being composed. Finally, the WSFL global model is called the global model, which enables the flow itself to be represented as one or more endpoints, defined by WSDL. This enables a WSFL composite service to be recursively composed as a basic service within a higher-level WSFL composite service. For example, a WSFL-defined flow model for checking product in-stock status at several distribution centers could be packaged as a WSDL-defined product-availability composite service and then used as the implementation of a basic activity in a WSFLdefined order-processing flow model. WSFL makes use of another proposed Web service standard called Web Service Endpoint Language (WSEL), which enables QoS attributes to be specified for services defined by WSDL. This enables a WSFL composite service to choose a service provider for a basic service based on both the service type and the quality of service attributes offered by the provider. WSEL also enables a WSFL composite service to be attributed with specific qualities of service. WSFL and other recursive Web service composition models (e.g., Microsoft's XLANG, Object Management Group's Component Collaboration Architecture) will enable complex business processes, which span organizations, to be logically decomposed into a network of basic services. While powerful, this is hardly revolutionary; recursive workflow models have been available in commercial products for years. What is revolutionary is that because of the unified XML-protocol-based architecture of Web services, the WSFL logical decomposition can be physically distributed into a network of SOAP nodes in a dynamic and transparent way, based on the QoS specifications provided by the WSEL definitions. Because the emerging WSNA standards are all unified by an architecture based on recursive composition of networked protocols, rather than a layered-software architecture, they span (more accurately, they bind) the traditional strict division between logical design and physical engineering.

26

Document1

5.4.

Global Model

The global model is perhaps the most difficult to understand of the three models that constitute the SLRM, because its effect can be so subtle. Basically, the global model unifies the set of service-model-defined basic services (each with its own lifecycle and QoS) and the composition model that networks them into a virtual single service that has a global (i.e., end-to-end, systemic, holistic) set of service qualities and lifecycle. As discussed above, in network architecture, especially the Internet, the global model is implemented at the transport layer, which is implemented on each of the endpoints (clients, servers, devices) connected to the network. The transport layer is responsible for the end-to-end (hence global) service quality of the connection or message. In the case of the Internet, the principle service quality determined by the TCP transport layer is session reliability. The art of the global model is to make the service as application-blind as possible. In other words: How does one make the service as generic as possible, but still useful enough to each application to ensure its widespread use. From the spanning layer perspective, the service(s) offered by the global model determines the width of the upper half of the hourglass, i.e., how many different ways can the service be applied. To maximize this width, the upper half of the spanning layer should be short but wide. That is, the level of abstraction specified by the global model should be fairly low, with high levels of abstraction achieved by composing additional layers. (Because the WSNA layers protocols and not software, the performance impact of granular composition is not a fundamental architectural problem, though it is an important engineering issue.)

5.4.1.

The End-to-End Argument

Perhaps the key architectural issue regarding the global model is its relationship with the composition model regarding QoS. The fundamental tension is between the degree to which a service's QoS should be provided by the underlying composition and service models vs. the degree to which it should be provided by the global model. In the network world, this tension has been the focus of a twenty-five year debate concerning an Internet design principle known as the end-to-end argument. One of the fundamental engineering design decisions that grew out of the requirement that an Internet session span multiple networks, each with distinct reliability capabilities and mechanisms, was to make reliability of the session the responsibility of the endpoints, not the intermediaries (i.e., the subnet of routers). Specifically, all the QoS requirements (guaranteed delivery, packet ordering, packet correctness, etc.) were supposed to be implemented in software on the hosts connected to the Internet (in the TCP layer), not in the software on the routers (in the IP layer). This end-to-end approach was based on the rationale of fate-sharing. An entity and its state should share the same fate: if the entity is ok, its state should be too. If the entity is lost or crashes, then it's ok to lose its state. The statelessness of the Internet subnet and its best effort (i.e., fairly reliable) approach to message delivery, is one of the keys

27

Document1

to its robustness, as well as its agility. This same approach was repeated by the Web protocol, HTTP, which is a stateless protocol. Its endpoints, the client-based browser and the server-based session manager, manage the state of a Web session via cookies, HTML hidden fields, etc. Note that the end-to-end issue is not just a technical issue; it is also an organizational boundary issue. Normally the endpoints of a service (the global model) are implemented on the systems hosting the peer (or client/server) applications, while the subnet (the composition model) is implemented by a number of independent third parties. Hence, often the only practical way to establish a given level of service is to negotiate between the two peers only, not all the subnet providers as well. This entails that the implementation of the service quality must be on the peer servers. After years of debate about this issue in the network world, there is obviously no right answer. What has actually emerged is an ad hoc aspect to the Internet. The Internet architecture still espouses clean separation of concerns between layers with QoS the sole responsibility of the transport layer. But when one looks at the actual engineering of the Internet, with ad hoc deployment of layer-crossing intermediaries (e.g., firewalls, caches, proxies, NATs, intelligent routers, load balancers, web single sign-on, content delivery networks, edge-side includes), it is clear that the strict protocol layering model is honored more in the breach than in the observance. Accordingly, the correct solution is to refactor the issue to eliminate the distinction. This is exactly what the SOAP envelope structure and message-processing model do. Each stateful QoS attribute (reliability, latency, security, etc.) is represented by a distinct set of SOAP headers and the issue of which node(s) process the header (endpoints or intermediaries) is left open any node can be the actor that processes a particular QoS header. Thus, the WSNA improves upon the Internet by replacing its exception-riddled brightline distinction between endpoint architecture and subnet architecture with a composable architecture that enables service implementation to dynamically shift from endpoint to subnet.

28

Document1

5.5.

WSNA Spanning Layer Summary

The emerging WSNA is a truly revolutionary spanning layer composed of a series of spanning layers forming a recursive SLRM (from the bottom up): Ethernet spans heterogeneous computers TCP/IP spans Ethernet and other network technologies HTTP spans TCP/IP and other transport/network services SOAP spans HTTP and other transport services A particular WSFL-defined service spans SOAP and other service protocols Other WSFL-defined services span lower-level WSFL services and other basic services

See Figure 6. The WSNA is revolutionary both in terms of its well-factored general capabilities and extensibility.

5.6.

Business Impact

The ability to decompose a complex set of business processes into basic services, with each level of the decomposition having explicitly specified service levels enables the business to better understand and more dynamically reconfigure composite processes such as distribution chains. For example, a basic packaged consumer goods distribution chain, defined in terms of service composition, is simply a flow of information regarding demand from consumers to a producer through a series of intermediaries, which aggregate the customer demand, and a WSFL-GLOBAL Global Model WSFL-FLOW subsequent flow of goods from Composition Model WSDL + WSEL Service Model the producer to consumers Global Model WSFL-GLOBAL through a series of intermediaries WSFL-FLOW Composition Model (often the same as the WSDL + WSEL Service Model information intermediaries) which Global Model SOAP (RPC) + WS-Security + disaggregate the bulk containers SOAP-REFERRAL + SOAP-ROUTING Composition Model SOAP (Envelope) Service Model of goods into successively smaller Global Model HTTP containers for eventual individual HTTP (Intermediaries)* Composition Model delivery to the consumer.

HTTP (Message)*

A primary reason for distinct Global Model TCP IP (Routing) Composition Model intermediate service providers is IP (Packet)* Service Model that not every service provider Ethernet can handle retail well, i.e., thousands or millions of Figure 6 consumers hitting your systems (e.g., stores) simultaneously. Retail intermediates that can handle such transaction volumes well will aggregate such individual transactions and product flows into aggregate transactions and product flows, i.e., buying in bulk from wholesale distributors; and so on up the chain to the ultimate provider.

Service Model

29

Document1

The logical design and physical implementation of such a composite service is the central challenge of the distribution chain. Web services standards like WSFL, in conjunction with visual modeling languages like UML promise to make such design issues more tractable by giving the business and the IT organization a common visual language and a common architecture the WSNA. For in the WSNA, the transaction pooling of a 3-Tier order entry application and the transaction pooling of a 3-tier retailwholesale-manufacturer chain share roughly the same abstract model. This offers the hope that business designers and IT architects could speak in common terms about fundamentally similar issues like latency (of information and of product shipments), pooling (of information in caches and of products in warehouses), etc. What is emerging is a composable infrastructure that uses a common composition language (XML) and mechanism (protocol binding) for recursively decomposing higherlevel representations onto lower-level representations from the highest-level businessprocess to the lowest-level engineering solution through a series of intermediate XML representations that incrementally fill in the details with increasingly technical representations. For example, one can begin with a high-level business-process representation, with associated QoS requirements. This can be decomposed into a lower-level representation by binding the business-level entities and behaviors onto a high-level technical architecture representation. Subsequently, this high-level technical architecture representation can be decomposed into a low-level implementation representation by binding the technical architecture onto the implementation representation capable of providing the specified QoS requirements. Most remarkably, this transition from business design representations to technical engineering representations is uniformly treated as simply a series of bindings from one set of formal XML-based representations to another. This helps clarify the distinction between business infrastructure and technical infrastructure. Business infrastructure refers to a business process representation (protocol) that is (a) defined in terms recognized by and relevant to a business person (security policy, PO flow, supply chain), and (b) serves as a spanning layer for a set of higher-level business applications. In other words, business infrastructure is a spanning layer defined in business terms. To actually implement this business process representation (protocol), it must eventually be bound to a protocol that isn't recognized by or relevant to the businessperson. Technical infrastructure is a spanning layer defined in non-business, i.e., technical terms. In practice, a clean separation between a business-level representation language and a technical representation language has been difficult to achieve (recall that COBOL Common Business Oriented Language was originally designed to be used directly by business analysts). For example, Biztalk's business process modeling tool literally splits the screen in two, to highlight the mapping from a business process on the left side to technical implementation bindings on the right. With UML, we are a lot closer to a modeling architecture that can describe business processes that are at least readable by business analysts.

30

Document1

6. Agile Infrastructure: WSNA Operational Issues

While the emerging standards constituting the Web Services Network Architecture (SOAP, WS-Referral WSDL, WSFL, etc.) have filled in some of the detail about how the WSNA works, three key operational issues (security, management, and lifecycle) are barely sketched in at this point. As with the rest of the WSNA, to deliver true agility, these issues must be dealt with in the form of well-factored dynamically-composable protocols that apply the SLRM.

6.1.

Security

Like most emerging standards, the WSNA defers security issues to be dealt with by later standards. In the meantime, immediate use of the WSNA is dependant on existing security architectures and mechanisms. For example, UDDI did not deal with security issues until UDDI v2, which was published in June 2001. Likewise, SOAP does not provide a security model, and a proposed SOAP security model (WS-Security) was only published by Microsoft in October 2001. Other than these two specs, security issues are initially left as an exercise for the reader. While the WSNA is no better (and no worse) with regard to immediately publishing architectural security standards up front, it is better than typical architectures in two regards. First, because the WSNA conforms to the SLRM, it offers an explicitly federated architecture, which can be mapped to a federated (decentralized) security architecture spanning several organizations. In fact, this requirement is explicitly stated in WS-Security. Second, due to its emphasis on well-factored, composable protocols, it is more likely that such unsecured protocols can be composed with a variety of well-factored security protocols as they emerge. For example, it is already clear from activity in the Digital Rights Management (DRM) arena that security issues must be factored into at least dynamically composable rights models and trust models. The eXtensible Rights Markup Language (XRML) is one such rights model that deals only with the issues of rights, permission, and obligations (i.e., property rights) regarding information and services. Different standards will specify a composable trust model based on digital certificates, trusted certificate authorities, and digital signatures. Finally, the SLRM distinction between the composition model and the global model will make decisions regarding end-to-end vs. distributed security approaches more tractable.

6.2.

Management

Like security, management issues raised by the WSNA are left as an afterthought. Although such neglect can never be justified, it can be explained. As with security issues, the explicit-composition approach of the WSNA and the SLRM strongly encourages specifications to omit independent issues such as security and management in order to enable the specification to map to a variety of alternatives. The

31

Document1

bad news is that there has been little direct work in the WSNA concerning management issues. The good news is that independent management initiatives are headed in the same direction as the WSNA and are beginning to converge. First, the TeleManagement Forum (TMF an international consortium of communications service providers and their suppliers) has undertaken a major initiative, New Generation Operations Systems and Software (NGOSS), to provide the architectural framework, analytical foundation, and development methodologies needed for rapid and flexible integration of operations and business support systems. Like the WSNA, the NGOSS architecture is loosely coupled and service-oriented. It supports an XML-based, model-driven approach to OSS integration to enable agility. Much of its loose coupling is based on the concept of an NGOSS contract, which, like the WSNA, separates the abstract specification of the behavior of a service from the binding of the behavior to a variety of technology realizations of the service. Work is just getting underway to ensure that NGOSS and the WSNA converge. At the very least, NGOSS can be used as a conceptual blueprint for designing a WSNA management framework. Second, the Distributed Management Task Force (DMTF) is also tracking the WSNA standards to ensure that DMTF's core standards (CIM Common Information Management, WBEM WeB Enabled Management, and DEN Directory Enabled Management) are applicable. As with the TMF, the DMTF is heading in the same direction as the WSNA: use of XML representation, HTTP as a transport, abstract modeling of interfaces in UML, etc. One other positive management aspect regarding WSNA is that, like the Internet, it is designed for federation across autonomous systems, which are separately managed and owned.

6.3.

Lifecycle

Every system, be it a product or service, has a lifecycle composed of phases from the initial conception of the system, through its design, implementation, deployment, use, change, and termination. Given that the unit of composition in the WSNA is a service specified only by its protocol, lifecycle issues are both harder and easier than they are for an architecture based on software-component-based products. The easier part is that many complex software deployment phases of the software-component lifecycle disappear. (Think of how the browser has reduced a variety of client software deployment issues to just one: deploying and upgrading the browser itself.) However, the harder part is dealing with the potentially long-term relationship between the service provider and the service subscriber. As discussed above, the essential difference between a product and a service is not whether or not an asset or set of assets is involved; rather it is which rights and obligations concerning the assets are transferred in the transaction concerning the assets. In the case of a pure product (e.g., buying a used car as is), the buyer assumes full ownership of and responsibility for all product lifecycle issues post-sale. By contrast, in the case of a pure service (e.g., a car

32

Document1

service), the provider retains full ownership and responsibility for all assets involved in providing the service (e.g., the car). Given the potentially long-term nature of the rights and responsibilities between the service provider and subscriber, there is a much greater need for a well-defined service lifecycle contract framework. Unfortunately, the emerging WSNA standards do little to deal with lifecycle issues directly. For example, currently the implicit contract established via finding and binding a service via UDDI is simply best effort and at will, i.e., if the service doesn't work as advertised or it is changed or discontinued without warning, too bad. Any contractual agreement beyond this must be established offline via traditional contracting. However, to create a truly agile infrastructure based on e-business process automation, more and more agreements regarding lifecycle issues must be automated directly by the WSNA. Accordingly, let us sketch a lifecycle framework, and then see how well the WSNA realizes it.

6.3.1.

Lifecycle Framework

A service relationship between a provider and a subscriber is a contract. Service providers and subscribers need the ability to negotiate a service contract that defines the terms and conditions of the service for the duration of the service relationship. Such a contract has three aspects: functional, QoS, and lifecycle. Negotiating the functional aspect of the contract is straightforward. It is simply agreeing on which service capabilities the subscriber will actually use and how to invoke such capabilities, e.g., a credit card verification service via a WSDL interface. The emerging WSNA standards have dealt almost exclusively with this issue of defining, finding, and invoking the functional behavior of a service. For example, a WSDL port type specifies the functional behavior of a service. Negotiating the QoS of a service contract is about negotiating normally expected service levels for the functional interface, including the price and the consequences of failing to meet such expectations. For example, as discussed above, WSEL specifies the QoS attributes of a WSDL-defined service. Negotiating the lifecycle aspect of a service contract is the least common and therefore the least understood form of negotiation. (Which is why parties usually enter into such poor long-term contracts, e.g., outsourcing.) The lifecycle aspect of a service contract can be divided into a composition of lifecycle phases, each of which entails (sub-) contractual agreement. See Figure 7. The level of detail articulated in the lifecycle aspect of a service contract is a reflection both of the strategic importance of the service as well as the duration of the service relationship. In its most elaborate form, negotiating the lifecycle aspect of the service contract for a Web service should be equivalent to negotiating an outsourcing agreement, which is essentially what it is. Components and objects, by comparison, require only minimal articulation of the post-sale lifecycle phases, given that the buyer assumes almost complete responsibility for the majority of such phases.

33

Document1

A fully articulated lifecycle aspect of a service contract is essential for the ultimate success of the WSNA. If a potential subscriber to a Web service cannot be assured that it can rely on the service it is sourcing from a provider, the subscriber will buy the underlying asset (or build a substitute) rather than subscribe to the service. Such a framework is also important for coordinating, unifying, and concurrently designing and engineering each lifecycle phase across services, e.g., designing a common automated search-phase process for all services, e.g., UDDI. The WSNA provides very little in the way of lifecycle description or automation. Its biggest contribution is UDDI, which deals with several of the issues concerning subscribing to a service from a service provider, but not all, e.g., negotiating, contracting.

A Basic List of Service Lifecycle Phases

1. Find 1.1. search 1.2. evaluate Bind 2.1. negotiate (which itself divides up into price and permission negotiation this is the virtual equivalent of transacting in the market) 2.2. agree 2.3. contract 2.4. settle 2.5. provision 2.6. test 2.7. activate Use 3.1. access (which may entail authentication and permission checks as part of a general property rights and trust contractual framework) 3.2. invoke (which is just the functional interface) Manage 4.1. Handle exception (as part of a general contractual obligation/liability framework) 4.2. upgrade (when service levels might be degraded) 4.3. repair 4.4. recover (fail over, D/R, partial outage when, again, service levels might be degraded) Change 5.1. renegotiate (includes change to functional, QoS, or lifecycle aspects of service contract) 5.2. suspend End 6.1. terminate 6.2. de-provision 6.3. dispose.

2.

3.

4.

5.

6.

The WSFL flow model provides Figure 7 several lifecycle interfaces for activating, invoking, and terminating a service. ebXML, a related XML e-business service architecture places somewhat more emphasis on lifecycle phases, especially service agreement negotiation (see the Collaboration-Protocol Agreement CPA standard). An example of the business importance of automating such lifecycle phases can be seen in the telecommunications industry. The telecom industry is a mature service industry. It has dealt with the issues facing service providers for many years, so its history gives insight to the future of the emerging WSNA-based industry. One of the biggest cost factors in the telecom industry is the cost of service provisioning. Consequently, one of the hottest issues in telecom in 2002 is flow through provisioning: fully automating the provisioning lifecycle phases from activation and configuration to billing. To avoid repeating a similarly painful evolution, the WSNA must standardize the provisioning phase of a Web service as quickly as possible.

6.3.2.

Dynamic Lifecycle Phases

As discussed above, while UDDI provides some automation of the publish, find, and bind lifecycle triad, it does little to enable such automation at run time. In fact, UDDI was initially intended for design-time use by developers as a universal service repository. The other WSNA standards likewise have little to say about how they can be used to dynamically bind at run time.

34

Document1

Yet the ability to deal with changes dynamically (i.e., at run time while continuing operation) is second only in importance to the ability to decompose complexity via the SLRM. While the WSNA's emphasis on explicit XML binding between abstraction and realization provides a clean conceptual foundation, it does not provide an actual dynamic binding framework or mechanism (with the possible exception of the somewhat ad hoc WSFL service locators). The WSNA must quickly articulate an innovative dynamic binding framework that deals systematically with five basic types of infrastructure change: Service model 1. Changing technologies 2. Changing providers Composition Model 3. Changing ilities, i.e., capacity on demand Global Model 4. Changing uses (applications) 5. Changing subscribers Like the WSNA, the SLRM provides a conceptual foundation for deciding where such changes should be dealt with, but it does not provide any framework or mechanism for hot swapping of technologies or providers, nor for automatic provisioning of new applications or users. General protocols for such mechanisms should be a high priority when fleshing out the WSNA. Such mechanisms should deal not only with new technologies, new applications, adding capacity, and adding users, but also with accommodating legacy technology, legacy applications, reducing capacity, and removing users. The ability to incrementally increase or decrease scalability and availability dynamically is becoming increasingly important. Life, especially business life, is becoming burstier: In networks, source burstiness is the central phenomenon that underlies the process of resource sharing for communications. [Information Theory and Communication Networks] As infrastructure becomes more network-like, the burstiness of subscriber demand is becoming central to computational and storage resource sharing as well. As services grow larger in scale, the traditional static over-engineering for dealing with such burstiness becomes cost prohibitive at some point, e.g., providing 10x capacity for storms of 100,000 simultaneous desktop users is possible, but providing 10x capacity for storms of 10,000,000 pervasive devices is not.

6.3.3.

Dynamic Interfaces

Arguably the most important lifecycle phase is the renegotiation of the service interface itself, e.g., changing the WSDL port type definition. A change to a published service interface requires that all users of the interface must update their systems to accommodate the change, or it requires the service provider to continue to offer old

35

Document1

versions of an interface ad infinitum. One of the biggest drags on innovation and agility is dealing with interface-change management. While the WSNA, like the Internet it is modeled on, provides a very effective architecture for insulating a service subscriber from changes to a service provider's implementation (e.g., upgrading a router), it does very little to minimize the impact of a change to the service contract between the service subscriber and provider. It is imperative that the interface (protocol) between provider and subscriber be recognized as a shared resource that is not owned by either. Thus, a unilateral change by a provider is as unacceptable as a unilateral change by a subscriber. This is ultimately the impetus behind open standards the desire for joint control over disruptive changes to standard interfaces. Thus, an important part of lifecycle negotiations will be promises concerning the lifetime of an interface. Subscribers will prefer providers that promise to maintain interfaces for longer periods of time. Inevitably, however, interfaces will change. In fact, WSNA standards like SOAP, WSDL, UDDI, are changing rapidly, and will continue to do so for another year or so, hopefully with backward compatibility. Thus, one of the most important issues facing the WSNA is how to coordinate changes to service interfaces during continuous operations, especially to those that become fundamental spanning layers, e.g., the SOAP envelope. Ironically, the most successful spanning layers are the hardest to change. For example, the spanning layer of the Internet the Internet Protocol (IP) is so stable and so widely embedded that it has become legacy architecture. (Any system that substantially resists modification, evolution, or integration is legacy.) The current Internet Protocol (IPv4) is essentially 20 years old, and despite the availability of the next version (IPv6) since the early nineties, and an urgent need for it, the complexity of upgrading the Internet interface has prevented innovation of the Internet itself! To create a truly agile infrastructure, a spanning layer must not only enable rapid evolution above and below, but also rapid evolution of the layer itself, all while maintaining continuous operations. At the very minimum, each interface change must be backward compatible with the prior version. If the WSNA does not quickly design such agility into its architecture, we are simply deploying the next instant legacy infrastructure. Grand initiatives such as IBM's project Eliza, Grid computing, etc. must deal with this issue as soon as possible. It turns out that such an agile infrastructure would not only be rapidly evolvable, it would also be incrementally available and scalable as a consequence. To see this, let's look in some detail at the engineering of an infrastructure that could accommodate interface upgrades during continuous operations.

6.3.3.1. Engineering Dynamic Interfaces

An agile infrastructure is one in which any single component at any layer of the infrastructure can be swapped out and replaced by a substitute component (including a component with an updated interface) at any time without impacting the availability of the layer above it. This means that agile infrastructure must enable rolling upgrades of every spanning layer of the infrastructure stack. This is both a design and engineering issue. The design part of the issue is ensuring that each interface upgrade is backward

36

Document1

compatible with the immediately prior interface. The engineering part is how to switch versions while the system is online. To engineer this, there must be at least two of every component, with all of them operating in tandem. (Hot backup is not fast enough to meet the requirement of not impacting the layer above since there is typically a short interval seconds to minutes where no work can be done). Two is not sufficient however. If one needs to upgrade the interface itself (e.g., switch from UDDI v2 to UDDI v3), there must be at least four servers: two running v2 (so that users at the layer above, who can't upgrade immediately can still operate reliably) and two running v3 (for those who can upgrade). In fact, true agility would mandate six servers all running in tandem (two with the old version, two with the current version, and two with the new version undergoing live testing). Once one is designing for 6 servers running 3 versions, one might as well go ahead and design generally for N*M servers (where M is >= 2) running N versions of the interface (where N is >= 3). Dialing up N enables greater and greater rolling upgrade flexibility (the primary design goal), while dialing up M enables incremental scalability and availability. Thus the N*M tandem design, which is required for agility, enables incremental scalability and availability as a secondary effect. Note that it is the ever-improving price/performance of the IT Curve that makes such a massively parallel architecture economically feasible. It is clear that the component cost of an agile infrastructure is a least 6x a non-agile one (but offsetting reductions in maintenance and upgrade costs will be far greater). When the component was a $1MM mainframe, the difference between $1 and $6MM was cost prohibitive for most apps. When the component is a $100 Intel 4-way blade (soon), the difference between $100 and $600 means a lot more applications will be deployed on agile infrastructure.

7. Agile Infrastructure: Future Implications

The WSNA is just one of several major IT paradigm shifts currently underway. Let's look briefly at how they converge towards infrastructure agility.

7.1.

Component Frameworks

The emerging WSNA will certainly have a major impact on distributed component architectures such as J2EE and COM. Microsoft obviously feels that the impact is so great that it is essentially replacing its COM architecture with the .Net architecture. The J2EE camp has been a bit slower to embrace the WSNA, and has done so through the traditional API-proliferation approach, e.g., JAX-Pack. Longer term, the trend is towards more data-driven, XML-protocol driven, declarative infrastructure and less softwarecode imperative infrastructure. As a result, software-code components will be embedded in XML protocols instead of the other way around. Each of the nodes in a Web services network will have a JVM or an instance of Microsoft's Common Language Infrastructure (CLI), or both, and some amounts of code will be moved around via SOAP messages and cached at the nodes for truly network distributed computing.

37

Document1

7.2.

Active networks

This vision of network distributed computing is very much in line with an emerging paradigm known as active networks, in which network nodes can perform computations on and modify packets flowing through them. The technology pull for active networks is normalizing the increasingly complex ad hoc set of network nodes that currently perform some sort of computation beyond simple routing, e.g., firewalls, proxies, multicast routers, mobile proxies, video gateways, application gateways, content distribution networks, edge side includes, etc. Two approaches to active networks are being pursued. First, the programmable switch approach, which dynamically deploys software across nodes under network-administration control. Second, the capsule or smart packet approach, which deploys the software with the packets themselves under the control of the application developer, either by directly embedding the software or by a pointer to the software. (See http://www.darpa.mil/ito/research/anets/vision.html for a list of DARPA-funded active network projects.) SOAP's envelope-processing model is essentially an active-network processing model in which SOAP actors perform computations on SOAP envelopes at each node of the SOAP network. This is why we call the WSNA an application-level active network. The five or six years of active network research has investigated the key challenges of security, efficiency, and node resource management. The WSNA community must look to active network research to adequately address such issues.

7.3.

Grid computing

Another very related emerging computing paradigm is Grid computing: The real and specific problem that underlies the Grid concept is coordinated resource sharing and problem solving in dynamic, multiinstitutional virtual organizations. The sharing that we are concerned with is not primarily file exchange but rather direct access to computers, software, data, and other resources, as is required by a range of collaborative problem-solving and resource-brokering strategies emerging in industry, science, and engineering. This sharing is, necessarily, highly controlled, with resource providers and consumers defining clearly and carefully just what is shared, who is allowed to share, and the conditions under which sharing occurs. A set of individuals and/or institutions defined by such sharing rules form what we call a virtual organization (VO). [The Anatomy of the Grid.] While the Grid paradigm emerged from the needs of the technical supercomputing community, its goals are very similar to those of the WSNA. In fact, the Object Management Group (OMG) recently sponsored a workshop entitled Software Services Grid Workshop (http://swradio.omg.org/workshop) to compare notes among the Grid, Web services, and OMG communities.

38

Document1

Like the WSNA, the Grid architecture is an application-level network protocol architecture. In fact, a seminal article on Grid computing architecture, The Anatomy of the Grid even applies the concept of the spanning layer (which it calls the hourglass model) to identify the Figure 8 core set of grid protocols at the waist of the hourglass. See Figure 8. This core set of protocols, collective and resource, roughly matches the SLRM composition and service layers, respectively. (It appears to lack a global model.) The Grid community has focused substantial research on the federated aspect of the Grid, in which resources are securely and fairly shared across business boundaries to form virtual organizations. The WSNA community must look to grid research to adequately address such issues.

7.4.

Model Driven Architecture

While Grid computing and active networks are technologies related to the WSNA, the Model Driven Architecture (MDA) initiative is a powerful conceptual framework (and supporting technology) proposed by the OMG that generalizes many of the protocolbased concepts of the WSNA and applies them across all architectures. This white paper has stressed the fundamental importance of designing spanning layers to eliminate combinatorial explosion by abstracting away the engineering, QoS, and lifecycle differences among a set of heterogeneous technologies and exposing a unified set of functional capabilities that a wide variety of applications can build upon. The Internet (IP) did this for heterogeneous network technologies. The Web did this for heterogeneous GUI technologies and resources. And the WSNA will do this for a wide variety of network, computational, and storage technologies. But the WSNA will do it differently than the Grid computing technologies will, which will do it differently than the active network technologies. We will never achieve one unified technology consensus nor should we. As certain technologies converge (e.g., proprietary Java component technologies into J2EE), other ones will emerge (e.g., Jini and Juxta). Thus, it is essential that infrastructure developers become adept at creating spanning layers to insulate applications from changes within and among such technologies. For example, there are at least four emerging business process composition models emerging: BPSS (ebXML), WSFL (IBM), XLANG (Microsoft), and BPML (BPMI.org). An

39

Document1

application that simply needs to interact with a business process defined in one of these models should loosely couple to any one of them via an abstract interface that prevents any dependencies on any one of them. This way, the application can be rebound to a different model, say from BPSS to WSFL without recoding the application, and eventually, without even stopping the application (i.e., dynamic rebinding). What is needed is a general architecture (a meta-architecture) and repeatable process for quickly and easily generating spanning-layer abstractions across diverse technologies, which the MDA calls platforms. The MDA is just such a meta-architecture. It uses a three-step, three-model process. First, an architect creates a spanning-layer abstraction in UML called a platform-independent model (PIM). Then the architect creates one platform-specific model (PSM) in UML for each technology to be mapped onto. Finally, the architect creates a UML mapping from the PIM to each PSM. Although the MDA initiative was only announced in early 2001, it is based on many years of modeling standards (UML, MOF, CWM) and is conceptually in production at leading-practice enterprises like Wells Fargo (Wells Fargo's Business Object Services: A Case Study in Model Driven Architecture at http://e-serv.ebizq.net/obj/harmon_1.html). An ambitious OMG effort to extend UML into a general-purpose spanning-layer modeling tool is already well underway. In late 2001, the OMG adopted the UML Profile for Enterprise Distributed Object Computing (EDOC). At the heart of EDOC is the Component Collaboration Architecture (CCA): Component Collaboration Architecture (CCA) details how the UML concepts of classes, collaborations and activity graphs can be used to model, at varying and mixed levels of granularity, the structure and behavior of the components that comprise a system. It defines an architecture of recursive decomposition and assembly of parts, which may be applied to many domains. [EDOC Spec] The CCA enables UML to model (and therefore translate among) any recursively composed spanning layer architecture (i.e., any architecture that fits the global, composition, service layering of the SLRM). Examples include WSFL, ebXML-BPSS, and BPML. It then facilitates the binding of such architectural models to actual technologies for deployment. Model-driven architecture represents a major evolution of protocol-driven and datadriven thinking. The goal is to create a meta-architecture that is completely independent of any particular business model, technical architecture, or specific technology, so that each of these layers can innovate independently. Yet, at the same time, the metaarchitecture can represent any business model (e.g., order processing), technical architecture (e.g., N-tier), or technology (e.g., J2EE) and map from one representation to the next. Viewed from this perspective MDA represents a meta spanning layer: enabling heterogeneous architectures to be composed into unified global architectures.

40

Document1

7.5. Composable Hardware: From Platforms to Networks

Infrastructure agility is all about virtualizing hardware with software and virtualizing software with data-driven models. Agile infrastructure is virtual infrastructure, and vice versa. The more virtual it is, the easier it is to design, develop, deploy, manage, change, and exit. However, ultimately, models must be realized by software and software must be realized by hardware. Accordingly, what can be done to make hardware as agile as possible? Simple. Apply the same Internet-inspired SLRM to hardware, which is exactly the major trend in hardware architectures today. Just look at Storage Area Networks, RAID arrays, server farms/clusters (at the web, app, and DB tiers). Network-based compositions of simple, heterogeneous hardware components are steadily replacing monolithic bus-based server platforms. For example, two key emerging server and storage interconnect standards are Infiniband and iSCSI, which are both basically specialized adaptations of the IP protocol. iSCSI is literally SCSI over IP, and Infiniband is based on IPv6 addresses and packet headers. At the same time, the server and storage units continue to modularize to the atomic blade, brick, or disk level. Thus, the most agile hardware layer for supporting agile model and software layers is a heterogeneous (because we always want to encourage innovation), fine-grained, network fabric of processing, storage, and communications nodes that can be assembled into higher-level technical and ultimately business services.

7.6.

Agile Software Development

One last aspect of agility cannot be ignored agile software design and development, especially in the form of open source. It is no coincidence that just as infrastructure agility is a hot button issue throughout the IT industry, so too are more agile processes for application design and development. Hence we see the rise of new types of methodologies, such as eXtreme Programming (XP) and its offshoots, Agile Design and Agile Development. While such methodologies differ (sometimes heatedly) in many ways, all of them emphasize sharing of source code across teams and a continuous process of taking a given design and refactoring it into a more composable design built from simpler components. The often-unarticulated goal of such refactoring-centric methodologies is to maximize separation of concerns so that different groups can evolve the design of their subsystems independently at different rates. This is simply the methodological and organizational flip side to the architectural goals of the SLRM. The ultimate example of such a separation-of-concerns agile software development methodology is open source. Not only is open source software development composable, it is federated delegated across business boundaries. There now is no question that the standard protocols of the WSNA must be open, i.e., developed and evolved via a federated process across business boundaries. Given that WSNA also stands for Work with Services, Not Assets, there is little question that the standard

41

Document1

software assets (especially the source code) that implement Web services will eventually be open as well, i.e., developed and evolved via a federated process across business boundaries. In other words, open source. This is simply the future replaying the past. All of the Internet protocols were implemented via an open source process, even though it wasn't referred to as such. Even today, many of the software servers that realize the Internet protocols (DNS, HTTP, FTP, SMTP, etc.) are open source. Remember, the value is in the service, not the asset that realizes it.

8. Conclusion
Over the next two to three years, the IT market will determine the general scope of XML Web services and the distributed computing paradigm they enable. Then the general scope will be realized over the following five to ten years. While it is possible that certain factors will limit Web services to just another RPC technology, it is META Group's belief that its impact will revolutionary. Web services will provide the foundation for a computing paradigm that distributes "applications" not into just N "tiers," but into a "network" of nodes. This paradigm shift will redefine the very notion of an application from a static construction of unshared business logic and infrastructure to a dynamic web of shared services. All of this will be the result of expanding the span of the Internet way in the three dimensions stated at the beginning of this paper: 1. Higher into the business processes of the enterprise 2. Deeper into the IT infrastructure of the enterprise 3. Broader in the lifecycle scope of products and services across the entire value chain

42