ABSTRACT
CALLAWAY, ROBERT DAVID. An Autonomic Service Delivery Platform for Service-Oriented Network Environments. (Under the direction of Michael Devetsikiotis and Yannis Viniotis.)
Service-oriented architectures offer a more effective and flexible approach to integrating
technology with business processes than traditional information technology (IT) architectures.
Service-oriented architectures are the foundation for both next-generation telecommunications
and middleware architectures, which are rapidly converging on top of commodity transport
ser-vices. Services such as triple/quadruple play, multimedia messaging, and presence are enabled
by the emerging service-oriented IP Multimedia Subsystem, and allow telecommunications
ser-vice providers to maintain, if not improve, their position in the marketplace. Serser-vice-oriented
architectures are aggressively leveraged in next-generation middleware systems as the system model of choice to interconnect service consumers and providers within and between enterprises.
We leverage previous research in active, overlay, and peer-to-peer networking
technolo-gies, along with recent advances in XML and Web Services, to create the paradigm of
service-oriented networking (SON). SON is an emerging architecture that enables network devices to
operate at the application layer to provide functions such as service-based routing, content
transformation, and protocol integration to consumers and providers. By adding
application-awareness into the network fabric, SON can act as a next-generation federated enterprise service
bus that provides vast gains in overall performance and efficiency, and enables the integration
of heterogeneous environments.
The contributions of this research are threefold: first, we formalize SON as an
ar-chitecture and discuss the challenges in building SON devices. Second, we discuss issues in
interconnecting SON devices to create large-scale service-oriented middleware and
telecommu-nications systems; in particular, we discuss the concept of federations of enterprise service
buses, and present two protocols that enable a distributed service registry to support the
feder-ation. Finally, we propose an autonomic service delivery platform for service-oriented network
environments. The platform enables a self-optimizing infrastructure that balances the goals
of maximizing the business value derived from processing service requests and the optimal
An Autonomic Service Delivery Platform for Service-Oriented Network Environments
by
Robert David Callaway
A dissertation submitted to the Graduate Faculty of North Carolina State University
in partial fulfillment of the requirements for the Degree of
Doctor of Philosophy
Computer Engineering Raleigh, North Carolina
2008
Approved By:
Dr. Adolfo F. Rodriguez Dr. Mihail L. Sichitiu
Dr. Yannis Viniotis Dr. Andrew J. Rindos
Co-Chair of Advisory Committee
DEDICATION
Dedicated to the memory of my late father,
Michael Brown Callaway,
BIOGRAPHY
Robert (Bob) David Callaway was born in May of 1982 in Charlotte, North Carolina. He
graduated cum laude from North Carolina State University in May of 2003, with Bachelor of Science degrees in Computer Engineering and Electrical Engineering and a minor in Business
Management. During his undergraduate education, he participated in the University Scholars
Program and was inducted into the Beta Eta Chapter of Eta Kappa Nu.
Bob has been working under the guidance of Professor Michael Devetsikiotis as a
Re-search Assistant since January of 2002 and joined the graduate program at NC State University
in the summer of 2003. He earned the Master of Science degree in Computer Networking in
December of 2004. He is currently a candidate for the Doctor of Philosophy degree in Computer
Engineering, focused on the area of service-oriented networking. His research and development
interests are in network performance, service engineering, and distributed systems. Bob was
awarded an IBM PhD Fellowship for the 2007-2008 academic year. He has also recieved two
IBM Invention Achievement Awards and has five patent applications pending in the U.S.
Upon completion of his doctoral degree, Bob will join the WebSphere Technology
Institute of IBM Software Group as an Advisory Software Engineer, focusing on the design and
ACKNOWLEDGEMENTS
I would like to express my profound appreciation to my advisor, Dr. Mike
Devetsikio-tis, for giving me the opportunity to work with him for the last six years. I am deeply indebted
to him for providing a supportive environment for my undergraduate and graduate research.
His insight, patience, and encouragement have been invaluable to me during this process and
have undoubtedly changed me for the better.
I would also like to give thanks to Dr. Yannis Viniotis for his passionate assistance
with the direction of this research. Our numerous discussions and his insightful suggestions
have greatly increased the quality, as well as the impact, of my PhD.
I would have never started this journey, if not for the advice of Dr. Andy Rindos.
He was just as helpful as our paths crossed again as he moved from the role of my “queueing
theory instructor” to my manager at IBM. His support of me and this work was crucial for its
completion, and for that I am sincerely appreciative. Also many thanks to Dr. Tom Bradicich
and Dr. Norm Strole for their advice that led me down this rewarding academic path.
I must also give special thanks to Dr. Adolfo Rodriguez for being a very patient
mentor and, more importantly, a good friend and colleague. His insight, vision, and guidance
were critical to the success of this work, and his support and confidence in me throughout the
last three years have made this a fulfilling and enjoyable endeavour.
Also, special thanks are due to Dr. Mihail Sichitiu and Dr. Sharon Setzer for serving
on my advisory committee, to Kyle Brown and Dr. Rick Robinson for their assistance with the
ESB federation work, and to Dr. Bart Vashaw for providing me with the opportunity to join
the WebSphere Technology Institute, as well as for the financial support that has sustained me
throughout the last three years.
On a more personal note, I would also like to express my love and gratitude to my
wife, Gina, for being there for me throughout the last nine years. Your patience, love, and
compassion are truly inspring to me, and I cannot even begin to thank you for all that you do
for me. I love you more than words can say, and I can’t wait for the rest of our lives together.
Very special thanks are also due to my family (Chris, Leslie, Logan, Dale, Maria, Steve,
Lois, Elaine, Ron, and Pam), my close friends (Josh, Kati, David, Liz, Amy, Erik, Praveen, and
Chris), my beloved basset hound, Bella, and my esteemed colleagues at IBM (John, Marcel,
and Murali) for their encouragement and support. Thank you all for the good times, laughter,
smiles, and friendship. You have helped make the time outside of the PhD memorable and
I would like to thank my brother, Tom, for always being there for his little brother.
Your courage is an inspiration to me, and I certainly owe you at least partially for my interest
in technology. I am proud to have you as a brother and grateful for your presence in my life.
Last, but surely not least, I am forever indebted to my parents for everything they
have given me. Mom, thank you for all that you have done in every part of my life. Dad, I owe
so much to you and I strive every day to make you proud of me. Thank you for having been a
TABLE OF CONTENTS
List of Figures . . . viii
List of Tables . . . x
1 Introduction & Motivation . . . 1
1.1 The Need for Adaptive Service-Oriented Systems in the 21st Century . . . 1
1.1.1 A Brief History of Information Technology . . . 2
1.2 Service-Oriented Architectures . . . 4
1.2.1 Enterprise Service Bus . . . 4
1.2.2 The Emergence of XML . . . 5
1.2.3 Web Services . . . 5
1.3 Contributions of this Dissertation . . . 6
1.4 Outline of this Dissertation . . . 8
2 Service-Oriented Networking . . . 10
2.1 Previous Efforts in Application-Aware Networking . . . 10
2.1.1 Active Networks . . . 10
2.1.2 Overlay Networks . . . 11
2.2 The Paradigm of Service-Oriented Networking . . . 11
2.2.1 Benefits . . . 12
2.2.2 Functions . . . 13
2.3 Research Challenges in Building SON Devices . . . 16
2.3.1 Implementation Considerations . . . 16
2.3.2 Robustness . . . 17
2.3.3 Specialized Hardware . . . 18
2.3.4 Security . . . 18
2.3.5 Resource Allocation . . . 18
2.4 Research Challenges in Interconnecting SON Devices . . . 19
2.4.1 Manageability . . . 19
2.4.2 Resource Allocation . . . 20
2.5 Conclusions . . . 21
3 Large-Scale Service-Oriented Systems . . . 22
3.1 Introduction & Motivation . . . 22
3.2 Current Approaches to ESB Federation . . . 24
3.2.1 Manual Configuration . . . 24
3.2.2 Broker ESB . . . 24
3.2.3 Centralized Registry . . . 25
3.3 Federation Architecture . . . 25
3.3.1 Related Work . . . 28
3.4.1 Service Request Forwarding . . . 32
3.5 Interconnecting Autonomous Federations . . . 35
3.5.1 Service Request Forwarding . . . 39
3.6 Conclusions . . . 41
4 An Autonomic Service Delivery Platform . . . 42
4.1 Introduction . . . 42
4.2 Architecture of Service Delivery Platform . . . 44
4.2.1 Overview . . . 44
4.2.2 Key Assumptions . . . 44
4.2.3 Methodologies Integrated in the Platform . . . 46
4.2.4 Related Work in Service Systems . . . 49
4.3 Analytic Framework of Service Delivery Platform . . . 50
4.3.1 Distributed Algorithm . . . 52
4.4 Engineering Tradeoffs in the Service Delivery Platform . . . 54
4.4.1 Fairness versus Efficiency . . . 54
4.4.2 Concavity versus Nonconcavity . . . 55
4.5 Simulation . . . 58
4.5.1 Experimental Setup . . . 58
4.5.2 No Congestion Functions . . . 60
4.5.3 Delay Sensitive Function . . . 70
4.5.4 Hop Count Congestion Function . . . 75
4.6 Conclusions . . . 79
5 Conclusions . . . 81
5.1 Summary of this Dissertation . . . 81
5.2 Future Work . . . 82
5.2.1 Multipath XML-Based Service Routing Protocols . . . 82
5.2.2 Minimizing Optimization Computations using Wavelet-Based Traffic Prediction . . . 82
5.2.3 Measurement of Effective Capacity of Resources . . . 83
Bibliography . . . 85
Appendices . . . 94
LIST OF FIGURES
Figure 1.1 Evolution of Information Technology Architectures . . . 2
Figure 1.2 Diagram of an Enterprise Service Bus . . . 5
Figure 1.3 Estimated Percentage of XML in Overall Network Traffic . . . 6
Figure 2.1 Example of Functional Offloading . . . 14
Figure 2.2 Example of Service Integration . . . 14
Figure 2.3 Example of Intelligent Routing . . . 16
Figure 2.4 Comparison of Software and Appliance Approaches . . . 17
Figure 2.5 Example of Adaptive Admission Control: SEDA Response Time Controller . . 19
Figure 3.1 Example Topology of Multiple ESB Deployments - Hub & Spokes . . . 26
Figure 3.2 Example Topology of Multiple ESB Deployments - Peer Business Divisions . . 26
Figure 3.3 Example Topology of Interconnected Autonomous Federations . . . 27
Figure 3.4 Message Exchange Between Two ESBs Within a Federation . . . 31
Figure 3.5 Example of Contents of Hello XML Message . . . 31
Figure 3.6 Example of Contents of Database Description XML Message . . . 32
Figure 3.7 Example of Contents of Acknowledgement Database Description XML Message 33 Figure 3.8 Example of Contents of Service State Update XML Message . . . 34
Figure 3.9 Flowchart for Forwarding Service Requests within a Federation of Enterprise Service Buses . . . 34
Figure 3.10 Message Exchange Between Two Autonomous Federations . . . 36
Figure 3.11 Example of Contents of Open XML Message . . . 36
Figure 3.12 Example of Contents of KeepAlive XML Message . . . 37
Figure 3.13 Example of Contents of Update XML Message . . . 37
Figure 3.14 Example of Contents of Notification XML Message . . . 38
Figure 3.15 Message Exchange Between Three Autonomous Federations . . . 38
Figure 3.16 Example of Contents of Open XML Message . . . 38
Figure 3.17 Example of Contents of KeepAlive XML Message . . . 38
Figure 3.18 Example of Contents of Update XML Message . . . 39
Figure 3.19 Example of Contents of Update XML Message . . . 40
Figure 3.20 Flowchart for Forwarding Service Requests Between Autonomous Federations of Enterprise Service Buses . . . 40
Figure 4.1 Example of SON Topology with Multiple Service Providers . . . 45
Figure 4.2 Examples of Nonconcave Utility Functions . . . 56
Figure 4.3 Service-Oriented Network Topology Used in Simulation . . . 58
Figure 4.4 Topology Matrix for Simulation . . . 59
Figure 4.5 Equal Service Priorities: Offered Rates vs. Time . . . 60
Figure 4.6 Equal Service Priorities: Utility vs. Time . . . 61
Figure 4.7 Equal Service Priorities: Service 1 Throughput vs. Path and Time . . . 64
Figure 4.9 Weighted Service Priorities: Offered Rates vs. Time . . . 65
Figure 4.10 Weighted Service Priorities: Utility vs. Time . . . 66
Figure 4.11 Weighted Service Priorities: Service 1 Throughput vs. Path and Time . . . 69
Figure 4.12 Weighted Service Priorities: Service 2 Throughput vs. Path and Time . . . 69
Figure 4.13 Delay Sensitive Service: Utility vs. Delay . . . 71
Figure 4.14 Delay Sensitive Service: Service 1 Throughput vs. Path and Delay . . . 74
Figure 4.15 Delay Sensitive Service: Service 2 Throughput vs. Path and Delay . . . 74
Figure 4.16 Hop Count Sensitive Service: Utility vs. Gamma . . . 76
Figure 4.17 Hop Count Sensitive Service: Service 1 Throughput vs. Path and Gamma . . . 78
Figure 4.18 Hop Count Sensitive Service: Service 2 Throughput vs. Path and Gamma . . . 78
Figure 5.1 Using Traffic Prediction Algorithms to Minimze Optimization Calculations . . 83
Figure A.1 Mediation State Machine . . . 110
LIST OF TABLES
Table 4.1 Equal Service Priorities: Node Throughput at Time 0 . . . 62
Table 4.2 Equal Service Priorities: Node Throughput at Time 100 . . . 62
Table 4.3 Equal Service Priorities: Node Throughput at Time 200 . . . 63
Table 4.4 Equal Service Priorities: Node Throughput at Time 300 . . . 63
Table 4.5 Weighted Service Priorities: Node Throughput at Time 0 . . . 66
Table 4.6 Weighted Service Priorities: Node Throughput at Time 100 . . . 67
Table 4.7 Weighted Service Priorities: Node Throughput at Time 200 . . . 67
Table 4.8 Weighted Service Priorities: Node Throughput at Time 300 . . . 68
Table 4.9 Delay Sensitive Service: Node D Delay = 1 . . . 72
Table 4.10 Delay Sensitive Service: Node D Delay = 5 . . . 72
Table 4.11 Delay Sensitive Service: Node D Delay = 6 . . . 72
Table 4.12 Delay Sensitive Service: Node D Delay = 7 . . . 73
Table 4.13 Delay Sensitive Service: Node D Delay = 8 . . . 73
Table 4.14 Hop Count Sensitive Service: Gamma = 0.005 . . . 76
Table 4.15 Hop Count Sensitive Service: Gamma = 0.01 . . . 77
Table 4.16 Hop Count Sensitive Service: Gamma = 0.05 . . . 77
Table A.1 IFRP Message Types . . . 101
Table A.2 IFRP Service State Advertisements (SSAs) . . . 102
Table A.3 Mediation State Transitions . . . 113
Table A.4 Peer State Transitions . . . 120
Table A.5 Mediation State Transitions . . . 133
Table A.6 The SSA’s Service State ID . . . 134
Chapter 1
Introduction & Motivation
1.1
The Need for Adaptive Service-Oriented Systems in the
21
stCentury
Over the past 15 years, the global economy has been dramatically altered by the
pervasive nature of information technology (IT) and networking. The resulting interconnected
global marketplace, where information is the transactional medium, has caused a dramatic shift
in the global economy. For example, the service sector of the U.S. economy, the primary user of
IT across all other economic categories, contributes to over eighty percent of the nation’s gross
domestic product [1]. Successful service-based systems can autonomically adapt to changes and
advances in business processes, IT, and the global marketplace [2]. Furthermore, the penetration
of the Internet into global culture further increases the importance for businesses to adapt to
an increasingly quality-sensitive, content-driven customer base. The ability to offer dynamic,
stable, robust, and high performance service offerings is, and will continue to be, crucial to
corporations in the 21st century.
One example of the transformation required in industries due to the influence of IT
can be observed in the case of telecommunications service providers. Telecommunications
ser-vices, such as the basic landline telephone system in the U.S., were relatively profitable for
service providers in the latter end of the 20th century. These traditional telephone providers
primarily depended on value-added services (such as long distance, caller ID, and voicemail)
to generate the majority of their operational profits, since they allowed the providers to
differ-entiate themselves in the marketplace. Today, however, telecommunications services like the
telecommunications providers. Network service providers are earning low profit margins with
high operational investments while being compelled to provide a near-perfect quality-of-service
to satisfy their customers. This is not surprising since basic economic theory states that profit
and degree of commoditization are inversely proportional to one another.
1.1.1 A Brief History of Information Technology
Due to the pervasive nature of IT in corporations, heterogeneity and change are the
greatest issues facing IT managers today [3]. Even with wider adoption of open standards, it
remains a daunting task to make legacy IT systems communicate across vendor, protocol, and
software differences. The rate of change in available hardware and software products enhances
the difficulty of supporting a dynamic infrastructure that is adaptable to business requirements
and industry trends.
The evolution of information technology architectures over the last sixty years enables
us to gain great insight into the motivation behind service-oriented architectures (SOA). Figure
1.1 (reprinted from [3]) gives a general description of the transitions between various computing
architectures. Many of the design principles behind SOA are based on the lessons learned in
the development of centralized and distributed computing systems of the past.
Figure 1.1: Evolution of Information Technology Architectures
Centralized computing emerged as the first prevalent IT architecture during the period
between 1950 and 1970. It is based on having a single source of computing power, known as the
numerous processors and thousands of users simultaneously. Users interacted with traditional
mainframes using “dumb-clients”, terminals that did not perform local processing of programs
or data that a user was requesting.
With the increase in development of smaller computers, and eventually with the release
of the personal computer (PC) in the early 1980s, the influence of the computer became more
widespread. With this, users possessed the capability to perform some processing on their own
PC, yet leave more complicated tasks to the mainframes or more powerful personal computers
known as servers. These innovations sparked the deployment of the first architecture based on
distributed computing principles that became known as the Client/Server model. Computer
and telecommunication networks played a larger role as systems became interconnected in order
to support this architecture.
The wide-scale adoption of the Internet and graphical user interface continued to
push the development of distributed systems even further. Basic applications, such as e-mail
clients and web browsers, became extremely popular; this led to the development of more
advanced Internet-enabled applications, such as instant messaging and e-commerce. Web sites
that featured dynamic content helped to drive the development of three-tier and multi-tier
architectures. In a three-tier architecture, the first tier would typically contain web servers
responsible for acting as user agents. These servers would format and send data received from
the second tier, which is comprised of application servers. Application servers, which execute
the requisite business logic based upon data retrieved from databases, comprise the third layer.
As computers continued to infiltrate into almost every industry, application servers
and middleware systems became more prevalent in corporations. However, many corporations
had disparate systems running a variety of applications that neededto cooperate with one
another. This need inspired the development and deployment of distributed objects, based
upon standards for software modules that are designed to work together but reside in multiple
systems throughout an organization; examples of these standards are the Common Object
Request Broker Architecture (CORBA) [4], Distributed Component Object Model [5], and
Java Remote Method Invocation [6].
The ability to componentize these distributed objects and their reuse throughout an
enterprise can have impact in terms of shorter application development time and fewer
soft-ware bugs. The three primary componentization efforts are CORBA Componentization Model,
Enterprise Java Beans (EJBs), and Component Object Model. The popularity of
languages and techniques.
Middleware consists of software agents acting as an intermediary between different
application components. Software packages, such as IBM WebSphere [7], support the
devel-opment and deployment of software components, such as EJBs. Middleware can be viewed as
the glue that enables the integration of disparate applications with other software components
within an enterprise.
1.2
Service-Oriented Architectures
Service-oriented architectures were designed to be the next generation of middleware
systems that directly addressed the issues of heterogeneity and change that existed in previous
IT architectures [8]. They integrate the concepts of enterprise service buses and web services,
which are discussed in Sections 1.2.1 and 1.2.3, respectively.
Services, the core unit of an SOA, are defined as “a course-grained, discoverable
soft-ware entity that exists as a single instance and interacts with applications and other services
through a loosely coupled, message-based communication model” [3]. Services are based on
the idea that IT infrastructures should be directly aligned with relevant business processes,
rather than with the more traditional horizontal or vertical alignment. Services are comprised
of a combination of various software components that, together, execute a reusable business
function.
One key property of services is that they are loosely coupled with one another within
the SOA. Loosely coupled is defined in [9] as having “no tight transactional properties among
the components.” This property is essential to SOA because it removes dependences on
imple-mentation specifics by relying on interaction between services through standardized interfaces.
Services can be implemented in different languages and deployed on different platforms. The
use of standardized interfaces is the key to the enablement of SOA as a flexible architecture.
If adopted and implemented correctly, SOA can provide a framework that leverages
elements of an existing IT infrastructure, which will reduce costs and provide a more flexible
and robust environment for the integration of IT and business processes.
1.2.1 Enterprise Service Bus
The key item for integration of services within an SOA is the Enterprise Service Bus
business logic of the enterprise to be developed and managed independently of the infrastructure,
network, and provision of those business services” [3]. Figure 1.2 (reprinted from [3]) shows the
interaction of the ESB with service providers and consumers. An ESB serves as the centralized
control and administration entity within the architecture, while also being responsible for the
integration and interaction of deployed services [10].
Figure 1.2: Diagram of an Enterprise Service Bus
1.2.2 The Emergence of XML
Furthermore, there has been a recent trend in the application/integration middleware
space towards XML-aware networking. The Extensible Markup Langage (XML) is a standard
for representing self-describing application data in a textual format, thus enabling heterogeneous
systems to easily operate on the data. Its simplicity, readability, and focus on interoperability
has been key to its success, while sacrificing size and/or processing performance. As such,
applications have embraced XML, not only for representing data amongst internal components,
but also for communicating this data across enterprises. As seen in Figure 1.3 (reprinted from
[11]), XML currently composes a large percentage of network traffic and this percentage is only
expected to increase in years ahead due to the increasing popularity of technologies that rely
on XML, such as Web Services.
1.2.3 Web Services
Web Services (WS) is an emerging standard for application to application
communi-cation over the Internet [12]. Based upon the passing and processing of XML documents, WS
aims to enable distributed computing using defined interfaces in a manner similar to services
currently offered through the World Wide Web.
The Web Services Description Language (WSDL) is an XML-based standard that
author-2002 2003 2004 2005 2006 2007 2008 0
5 10 15 20 25 30 35 40 45
Year
Percentage of Network Traffic
Figure 1.3: Estimated Percentage of XML in Overall Network Traffic
itatively enumerates the interface for accessing a WS. Typically, the SOAP protocol is used to
actually interact with a WS. The main container within the SOAP protocol is called the SOAP
envelope, and contains header information as well as the actual data to be passed to and from
a WS. The Universal Description, Discovery, and Integration (UDDI) language provides the
ability for users to search for a web service.
Web Services are a substantial building block in a complete SOA solution. They
provide a distributed computing approach for integrating heterogeneous applications over the
Internet based on open standards that provide interoperability between vendors and systems
[3].
1.3
Contributions of this Dissertation
We believe that a main underlying assumption of previous attempts at
application-aware networking, the inflexibility of the network layer, has become invalid due to advances in hardware, software, and networking technologies. Due to Moore’s Law, the cost of
high-performance, off-the-shelf hardware is decreasing. Innovations in hardware-based acceleration
introduced by XML. Linux, a free open-source operating system, has emerged as a cornerstone
in numerous enterprise computing environments due to its robust networking capabilities and
scalability as a platform for hosting mission-critical applications. The prevalence of optical
networking has removed the notion that bandwidth is a restricted commodity within
enter-prise networks. Furthermore, next-generation telecommunications and middleware systems are
converging under the theme of service-orientation. With this convergence, the properties of
network devices and the larger service-oriented network architecture are an emerging and open
research area that draws from a diverse background of prior work in numerous disciplines.
We argue that these factors combine to invalidate the assumption made in previous
attempts - that implementing application-awareness in the network fabric is too costly and
complex; this serves as the motivation for the paradigm of service-oriented networking. This
architecture assumes that XML is now thelingua franca of network communication, and lever-ages XML-aware devices placed in the network fabric to perform content-based routing, among
many other functions. It is the goal of our research to summarize the breadth of the research
area and make substantial in-depth contributions to particular problems that are currently open
in the literature.
The contributions of our research are as follows:
• We formally name and propose the concept of service-oriented networking (SON). SON
enables network components to become application-aware so that they are able to
under-stand data encoded in XML and act upon that data intelligently to make routing decisions,
enforce QoS or security policies, or transform the data into an alternate representation.
We describe the motivation behind service-oriented networking, the potential benefits
of introducing application-aware network devices into service-oriented architectures, and
discusses research challenges in the development of SON-enabled network appliances as
well as interconnecting them into large-scale service-oriented networks.
• It is often desirable to have multiple ESB deployments federate with one another to
provide a distributed integration platform that promotes the reuse of services within and
across enterprises. However, the existing solutions to federate ESBs are limited by their
inflexibility to change and inability to scale. We propose the enablement of a federation of
enterprise service buses via a distributed service registry and SON that distributes
policy-appropriate service metadata to federation members. We provide a high-level description
autonomous federations. We argue that the use of a distributed service registry and the
associated enabling protocols is a novel application of existing technology that creates a
robust, scalable, and flexible federation of ESBs that is essential to the next generation
of large-scale SOA deployments.
• Finally, we present a novel autonomic service delivery platform for service-oriented
net-work environments. The platform enables a self-optimizing infrastructure that balances
the goals of maximizing the business value derived from processing service requests and
the optimal utilization of IT resources. We believe that our proposal is the first of its kind
to integrate several well-established theoretical and practical techniques from networking,
microeconomics, and service-oriented computing to form a fully-distributed service
de-livery platform. The principal component of the platform is a utility-based cooperative
service routing protocol that disseminates congestion-based prices amongst intermediaries
to enable the dynamic routing of service requests from consumers to providers. We
pro-vide the motivation for such a platform and formally present our proposed architecture.
We discuss the underlying analytical framework for the service routing protocol, as well
as key methodologies that, together, provide a robust framework for our service delivery
platform that is applicable to the next-generation of middleware and telecommunications
architectures. We discuss issues regarding the fairness of service rate allocations, as well
as the use of nonconcave utility functions in the service routing protocol.
1.4
Outline of this Dissertation
The outline of the dissertation is as follows:
• In Chapter 2, we formally propose Service-Oriented Networking as an emerging
architec-ture. We discuss the challenges, both in building SON devices, as well as in interconnecting
the devices to form a service-oriented network.
• In Chapter 3, we continue the discussion regarding large-scale service-oriented networks.
We explicitly discuss a use case for SON, federations of enterprise service buses. We
describe how federations are enabled by a distributed service registry, and provide details
and examples of two protocols, based on Internet routing protocols, that enable a robust,
• In Chapter 4, we present our autonomic service delivery platform. The goal of this
platform is to optimally route requests from service consumers to providers. We provide
details of the underlying utility-based analytic framework, as well as results from an initial
experiment that shows the ability of the framework to optimally route and throttle load
under resource constraints.
• In Chapter 5, we summarize our work and propose extensions for future work on the
autonomic service delivery platform.
• In Appendix A, we provide the specification for the Intra-Federation Routing Protocol,
Chapter 2
Service-Oriented Networking
2.1
Previous Efforts in Application-Aware Networking
Application-aware networks, which provide differential treatment of traffic dependent
on application data, are an emerging technology that promises to provide increased
end-to-end system performance for next-generation applications and networks. Internet Protocol (IP)
routers currently attempt to be application-aware and regularly inspect application data
con-tained in packets; for example, a router may compare passing application data to a virus
signature and discard the traffic when a positive match is triggered. In the past, the bulk
of application data that traversed the network was built around a wide array of closed and
proprietary data specifications. As a result, the majority of network components have
re-mained application-agnostic. However, there have been two significant research areas that have
addressed issues in this area. Active and overlay networks have both attempted to provide
application-aware functionality in the network without an open standard for
application-to-application communication.
2.1.1 Active Networks
Active networks sought to improve the deployment of emerging networking
technolo-gies and protocols by adding application layer functionality in specificactive nodes. While data would still be passed in packets as in a traditional packet-switched network, active networks
would support “smart” packets, which would carry bytecode, along with data, to be executed
in active nodes. The main underlying assumption in active network research is that the
services. Since standardization of new protocols is often a lengthy process, active network
technology attempted to leverage advances in compilers, operating systems, and programming
languages that would facilitate running user-supplied code in active nodes [13, 14]. Several
groups [15, 16, 17] proposed examples of potential architectures for the organization of
infor-mation and program code into the packet headers, showing results in which active networks
suffer a slight degradation in performance when compared with a software router.
However, active networks were not widely deployed due to issues with security, resource
allocation, and the substantial cost of deployment. Since packets could contain arbitrary code
to be executed on an active node, precautions must be taken to ensure that a rogue user
could not execute code that would corrupt the operations of other users. It is essential to
manage the computing resources of the node to ensure that programs are fair to each other.
Furthermore, the deployment of active network technology in the network would require a
substantial investment for network operators in order to support this new architecture.
2.1.2 Overlay Networks
The development and subsequent deployment of active networks showed that enabling
application-awareness in the network by executing user-supplied code in the network layer is
infeasible. Overlay networks sought to provide application-aware functionality by pushing the
complexity of such algorithms towards the end users of the network. The major assumption
in overlay networks is that application-aware functionality should not reside in the network
layer due to the issues presented in active networks; rather, application-awareness should be
enabled in the application layer where issues of security and resource allocation could be more
easily addressed. Overlay networks consist of peer nodes that self-organize into a distributed
data structure based on application criteria. Strategically placed application-level agents serve
as intermediaries for forwarding data from a source to a set of destinations, in effect, forming
an overlay on top of the underlying IP substrate. Overlay networks can be used to deploy
new protocols such as multicast [18], or enable application-aware routing where messages are
forwarded based on application data or state.
2.2
The Paradigm of Service-Oriented Networking
The rapid adoption of XML, Web Services, and SOA have enabled network
traditional data-center. Differences in application data-encoding that once hindered the
net-work’s ability to comprehend true application intent are now described by XML. Routing has
become XML-oriented with the use of functions such as XPath routing [19] to direct traffic
based on XML content. Web Services Security (WS-Security) defines security criteria within
XML Web Services envelopes across service invocations. Further, additional offload
capabil-ities are now possible, such as XML transformation (XSLT) [20] to change XML content as
it traverses the network, and service mediation to enable the interoperability of Web Services
in heterogeneous environments. These have key benefits to SOA as they enable services to be
integrated in a loosely-coupled manner where implementation details of components are hidden
from the requester of the service.
Service-Oriented Networking (SON) is an emerging architecture that enables network
devices to operate at the application layer with ESB-like features such as offloading, protocol
integration, and content-based routing. By adding application-awareness into the network
fab-ric, SON can provide vast gains in overall performance and efficiency and enable the integration
of heterogeneous environments. We refer to this collection of network-resident application-level
operations as SON functions. Among others, SON functionality provides three key benefits:
service virtualization, locality exploitation and improved manageability.
2.2.1 Benefits Service Virtualization
Service virtualization transparently maps a set of services to the protected back-end
resources that actually provide the service. A SON device can serve as a proxy for actual
services by masking internal resources via XML transformation and routing techniques. The
SON device could also be leveraged to manage security and denial-of-service (DoS) policies for
incoming requests.
Locality Exploitation
By deploying certain functions in the network fabric, SON devices can be provisioned
and customized to handle unique workloads. For example, these systems can be provisioned
with cryptographic hardware assist for SSL or other security functions. Similarly,
domain-specific hardware to optimize XML processing can be installed to offset the cost of processing
lead to greater efficiencies and can be more cost-effective than provisioning the entire enterprise
with these capabilities. Lastly, a potential performance benefit is gained from exploiting locality
within co-located SON functions. For example, consider a function executing an XSLT schema
transformation while another is performing XPath routing. The two functions can communicate
to avoid parsing the request twice. Locality also has benefits at lower levels of the system, such
as in cache utilization.
Improved Manageability
Offloading function into the network enables centralized, and therefore simplified,
man-agement of the function and corresponding configuration. For example, style sheets, security,
caching and routing policies can all be centrally managed at SON devices versus decentralized
across a cluster of enterprise servers.
2.2.2 Functions
Three examples of SON functions include functional offloading, service integration,
and intelligent routing, each of which is described below: [21].
Functional Offloading
Offloading security-related operations has been a common practice for Internet-based
application environments; this practice is also applicable to document-centric service-oriented
environments. Like the HTTP server, a SON device can be specially provisioned to handle
cryptographic functions. This enables the device to optimize the validation of digital certificates
in the context of WS-Security. We illustrate this in Figure 2.1, where the SON appliance
intercepts WS-Security SOAP envelopes, performs the appropriate cryptographic functions,
and forwards the requests on to the service provider.
A SON device can also perform a firewall-like security function to validate service
requests (for example, against a corresponding WSDL or XSD document) before forwarding
them to the enterprise server for processing. These checks would ensure that only well-formed
service requests are forwarded. This prevents DoS attacks and ensures that enterprise servers
are encountering only valid service requests.
The most efficient form of offloading is in full-function offload where the service
Service Provider Encrypted &
Signed SOAP/XML
Decrypted & Authenticated SOAP/XML
WS-Security: Decryption & Authentication Service
Originator
SON Appliance
Figure 2.1: Example of Functional Offloading
technique that accomplishes this, is most effective for read-mostly interactions where requests
do not update back-end states or databases. For example, service requests that retrieve stock
quotes, where ticker values are updated every five minutes, are well suited for this type of
of-fload. If done correctly, a large proportion of the read traffic can be completely serviced by the
appropriate caching component, thereby reducing the load on enterprise database servers. A
cache policy contains rules that define how results from specified services requests are cached.
Service Integration
WidgetsRUS
Service Provider Purchase Order in
Widgets, Inc.
XML Schema
Purchase Order in
WidgetsRUS
XML Schema
XSL Transformation
Widgets, Inc.
Service Originator
SON Appliance
Figure 2.2: Example of Service Integration
Figure 2.2 illustrates the service integration aspect of the SON device in which a widget
retail store (Widgets, Inc.) is ordering a collection of parts by invoking a service request back
chooses the best parts supplier and forwards the service request to that supplier. However, in
this case, the XML schema ofWidgets, Inc. is different depending on the chosen supplier. The SON device is capable of transforming the original order to schemas of participating providers,
in this case WidgetsRUS. Other widget manufacturers would likely require different schemas, requiring the SON function to apply the appropriate XSLT transformation dependent on the
supplier.
Since the majority of corporate data today exists in mainframe databases, service
integration also provides the ability to interface with existing legacy systems, giving a system
architect more flexibility to migrate towards a service-oriented environment. This increases the
number of service consumers that can take advantage of these programs and data and extends
the reach of SON and SOA further into the enterprise.
Intelligent Routing
Content-based routing (CBR), like priority-based routing, is driven from policy
doc-uments. The policies typically apply a rule against some part of a service request (header or
content), and derive a token as a result. The token is then used to look up a corresponding
enterprise server address in a routing table. For example, a CBR policy might be created by
combining the port-type and operation-name of a service and mapping it to a specific enterprise
server. In a SON device, CBR can be realized by using XPath-based expressions to determine
the destination of the request as shown in Figure 2.3.
CBR also allows an affinity between a class of services and the enterprise server that
services the request; this concept is named service partitioning. Figure 2.3 illustrates this service
partitioning pattern. Service partitioning can be used as the foundation to address bottlenecks
that occur in high volume Online Transaction Processing applications that intensively read and
write data to databases and require the utmost in data consistency and availability. Examples
of such systems include trading, banking, reservation, and online auctioning systems. While a
strategically located SON device enables service partitioning, the value is actually garnered on
the enterprise application servers where the services are deployed. For example, service-based
applications can now assume that their variation of the service is not running elsewhere in the
enterprise server cluster. The applications can then aggressively cache interactions without the
processing overhead of maintaining data consistency within that cluster. Service partitioning
also enables other optimization techniques such as data batching where insertions, updates, and
Service Providers Unclassified
Requests
XPath Routing SON Appliance
Figure 2.3: Example of Intelligent Routing
2.3
Research Challenges in Building SON Devices
We believe that SON is an exciting new research area that can have a dramatic impact
on the design, performance, integration, and management of service-oriented environments.
Therefore, we believe that significant research is needed in the following areas in order to create
an adaptive and robust SON device that can provide the benefits of service-oriented networking
as we have described in this chapter:
2.3.1 Implementation Considerations
A tradeoff exists between the performance of implementing SON functions in a network
appliance versus software, the extensibility of arbitrary programs versus the hardened security
of an appliance based upon standardized security mechanisms, and the flexibility of a software
solution versus the increased consumability of an appliance; this tradeoff is depicted in Figure
2.4. Since care must be taken to ensure that the SON function improves the overall performance
of the architecture, rather than degrading it, we believe that network appliances that host SON
functionality can leverage hardened software and specialized hardware solutions and overcome
the limitations experienced in previous attempts to introduce application-awareness into the
network fabric. SON functions could be collocated within a switch or router, as in the Cisco line
Security Extensibility
Appliance Performance
Software Performance
Consumability
Flexibility
SON Appliance
Figure 2.4: Comparison of Software and Appliance Approaches
appliance as in several products sold by DataPower, recently acquired by IBM [23].
2.3.2 Robustness
The SON device should scale to support a large number of requests to be processed
concurrently. It should be robust to overload conditions, continuing to prioritize and process
high priority requests and shed low priority requests while operating in an overloaded regime.
Admission control ensures that a server always operates in a stable regime; even in overloaded
conditions, the server can scale and continue to provide differentiated service to its users. In
order for an SON device to provide services that are fair to the requesting users, a policy should
be defined that enumerates the differential treatment that requests are to receive. This policy
should define strategies to prioritize traffic under both normal and overloaded conditions. Since
requests must be classified before they can be prioritized, it is essential in overloaded conditions
that the system can continue to process high priority requests while possibly shedding lower
priority requests. Therefore, fast methods for classifying incoming requests are needed. The
classifications could be based on network layer information or upon information residing within
the XML content. Algorithms for executing XPath expressions on streaming XML such as
2.3.3 Specialized Hardware
One main benefit of SON is that it can leverage specialized hardware, such as
hardware-accelerated cryptographic or XML processing functionality, to enhance the overall performance
of the device. However, the SON device will contain software components that process requests
in conjunction with the available hardware devices. Since these components could block upon
the remote invocation of services, it will be important to ensure an efficient and robust
coop-eration scheme between these hardware and software components exists, as this scheme will be
crucial to the overall stability and performance of the SON device.
2.3.4 Security
As in active networks, SON provides software functionality that will be executed in
the network fabric. However, with the introduction of open standards such as XML and
WS-Security, we believe that SON devices will not suffer from the same security issues as active
networks. The use of XML in network operations raises new research questions regarding how
open standards such as XML and Web Services could be leveraged together in an SON appliance
in order to create a device that is hardened against XML and Web Services-based DoS attacks.
One approach is to leverage well-formedness checking and XML schema validation against all
incoming documents in order to ensure that only valid requests proceed within the device for
further processing.
2.3.5 Resource Allocation
The SON device should be adaptive, changing its underlying execution model to
sup-port different types of software components in order to maximize the efficiency of the system.
We believe thatconcurrency mechanisms will be a significant component of resource allocation within a scalable and adaptive SON device. Concurrency mechanisms have a dramatic effect
on the overall performance and efficiency of a device. Internet services are unique because they
require massive concurrency but also block while waiting on unavailable resources. It is this
unique combination of requirements that suggests a hybrid architecture that could be used to
exploit the benefits of different concurrency mechanisms. Models such as the Staged
Event-Driven Architecture (SEDA) [25] could prove useful in building an adaptive resource allocation
system for an SON device.
each having its own thread pool and is connected with others as a network of queues in order
to provide the desired application functionality. Admission control is used at each stage, and
adaptive controllers that can modify the thread pool size or the amount of requests that are
processed by each thread (batching) are included. Figure 2.5 (reprinted from [26]) shows how
admission control is performed on requests to a SEDA stage using a response time controller.
Figure 2.5: Example of Adaptive Admission Control: SEDA Response Time Controller
2.4
Research Challenges in Interconnecting SON Devices
The initial work presented here concentrates on enablement technologies that
logis-tically deliver and deploy SON functions manually; however, we look toward the autonomic
configuration and coordination amongst these functions.
2.4.1 Manageability
Specifically, we anticipate that enterprise applications of the future will begin to
lever-age distributed SON deployment patterns where large numbers of SON devices coordinate with
peers using network-wide application-specific policies. Manual configurations are not able to
scale with these environments, nor can they adapt the configuration to dynamic network and
application conditions. For example, a large-scale SON deployment could be leveraged to enable
appropriate points in the network to perform configuration changes based on prevailing network
and application conditions.
2.4.2 Resource Allocation
Also in this light, we envision that SON devices will need to collaborate to effectively
allocate their computing resources in order to effect the aforementioned application-specific
service policies. Our contributions in this area are discussed in Chapters 3 & 4; however, there
are some initial efforts towards collaborative resource allocation present in the literature that
we review below.
Kallitsis et. al introduce a pricing model that ensures efficient resource allocation that provides guaranteed quality of service while maximizing profit in multiservice networks
[27]. Specifically, they examine a centralized dynamic allocation policy that relies on online
measurements while operating each service class under a probabilistic bound delay constraint.
In [28], Kallitsis et. al continue their previous work regarding optimal resource allo-cation of next generation network services under a flat pricing scheme and quality of service
policies. They present a complete framework that dynamically allocates resources when it is
required. To in order to effect that, they apply an online traffic estimator and monitor traffic
changes using an Exponentially Weighted Moving Average control chart; therefore, the profit
maximization of the provider is done efficiently since their optimization algorithm will only
solve the problem when a traffic shift is detected that would yield a significant change in the
allocation.
Finally, Kallitsis et. al present a distributed algorithm that dynamically solves an optimization problem so as to allocate the available resources to delay-sensitive services offered
in a SON [29]. Somewhat similar to the work presented in Chapter 4, pricing is used to
differentiate services based on their quality-of-service requirements. Their performance metric
is the end-to-end delay that a service class would experience in the network; a deterministic
upper bound of end-to-end delay is derived from the theory of network calculus. The moving
average control scheme adopted for capturing traffic shifts in real time makes their solution
react adaptively to traffic alterations. Finally, they evaluated their system using real network
2.5
Conclusions
The emergence of XML along with advances in hardware, software, and networking
technologies serves as the catalyst for the development of service-oriented networking. SON
devices are application-aware network components that are able to understand data encoded in
XML and act upon that data intelligently to make routing decisions, enforce QoS or security
policies, or transform the data into an alternate representation. Using design patterns such as
functional offloading, service integration, and intelligent routing, SON can enable service
vir-tualization, increase manageability and exploit locality. In this chapter, we have described the
motivation behind SON, the potential benefits of introducing application-aware network devices
into service-oriented architectures, and discussed research challenges in the development and
in-terconnection of SON appliances. We believe that SON provides exciting new multidisciplinary
research opportunities in service-oriented computing, hardware, software, and networking that
Chapter 3
Large-Scale Service-Oriented
Systems
The enterprise service bus acts as the integration and communications platform for
connecting service consumers and providers. It is often desirable to have multiple ESB
deploy-ments federate with one another to provide a distributed integration platform that promotes
the reuse of services within and across enterprises. However, the existing solutions to federate
ESBs are limited by their inflexibility to change and inability to scale. In this chapter, we
pro-pose the enablement of a federation of ESBs via a distributed service registry that distributes
policy-appropriate service metadata to federation members. We provide a high-level
descrip-tion of two protocols that maintain the state of the distributed registry within and between
autonomous federations. We argue that these application of a distributed service registry and
the enabling protocols is a novel application of existing technology that creates a robust,
scal-able, and flexible federation of ESBs that is needed in the next generation of large-scale SOA
deployments.
3.1
Introduction & Motivation
As a critical infrastructural component of service-oriented architectures, the ESB acts
as the integration and communications platform for connecting service consumers and providers
[30]. As such, the ESB is responsible for, along with many other functions, the enforcement of
policies, routing of service requests, and performing content and/or transport protocol
As the number of services in an organization increases, the need for a service discovery
and governance platform arises. The service registry enables consumers to find available services
and providers to advertise available service instances. The registry can optionally serve as a
repository for governance metadata, policy documents, and XML schemas.
Instantiating the ESB in a message-oriented middleware product, along with deploying
a service registry, provides an intuitive solution towards implementing a small to medium-size
SOA. However, recent market trends show that SOA is being rapidly adopted; therefore,
strate-gies for creating more large-scale deployments are needed. A typical approach to transitioning
from a moderate-scale to a large-scale SOA deployment is to “scale-up”; that is, leave the
topology of the architecture fundamentally unaltered while adding additional resources to the
individual architectural components. “Scaling-out” yields a distributed approach to the
large-scale problem that involves altering the topology of interconnected architectural components.
Furthermore, we argue that the rapid adoption of SOA is causing an increase in the number
of business-to-business transactions between autonomous SOA deployments. Primarily for
rea-sons of governance, these types of interactions exemplify the need for a large-scale distributed
ESB; we refer to such a system as a federation of enterprise service buses.
In a federation of ESBs, the primary problem is to appropriately disseminate
infor-mation throughout nodes that comprise the ESB to enable policy-driven service discovery and
routing. We propose that a distributed service registry is a scalable and robust approach to
enabling federations of enterprise service buses. The distributed service registry is
hierarchi-cal in nature and is maintained by two protocols that synchronize relevant service metadata
amongst ESB deployments as appropriate under defined business policies. There are three main
advantages to our proposal over existing approaches:
• We enable the federation of ESB deployments within an enterprise in a flexible and scalable
manner.
• The distributed service registry and the supporting protocol allow our solution to adapt
autonomically to dynamic network and service conditions.
• This architecture provides the capability to support on-demand techniques such as fast
failover or priority-based load shedding in an autonomic fashion.
The remainder of the chapter is structured as follows: in the following section, we
our architecture that enables the dynamic and scalable federation of ESBs. In Section 3.4, we
present an overview of the first of two protocols that maintains the consistency and availability
of service metadata within an autonomous federation. In Section 3.5, we present the second
protocol that is responsible for the maintenance of interconnections of autonomous federations.
3.2
Current Approaches to ESB Federation
Currently, there are three approaches to addressing the problem of policy-driven
ser-vice metadata dissemination: manual configuring interconnections, deploying a broker ESB,
and utilizing a centralized registry across or between enterprises.
3.2.1 Manual Configuration
One way of federating ESBs is by manually configuring functionality within an ESB
that serves as a “proxy” to other ESBs in the federation. For each service that is managed by
a remote ESB, a mediation must be defined that selects appropriate requests to be forwarded
to the remote ESB, performs necessary content/protocol transformations, and subsequently
forwards the request onto the remote ESB. Matching mediations must exist on remote ESBs
in order to support bidirectional communication in this case. Since this configuration must be
done manually by a systems administrator at each ESB, the configuration of such a solution
is tedious and prone to error (for S services and N ESBs, there are possibly SN proxies to be configured). There is also no mechanism to change the properties of this mediation based
on changes in network or service availability. Manual configuration allows basic federation of
multiple ESBs; however, this is an inflexible and impractical solution for large scale enterprises.
3.2.2 Broker ESB
Rather than statically defining the routing mediations at each ESB, a separate ESB
called a “broker” ESB can be deployed, whose sole function is to implement the requisite
mediations to support federation. This helps to consolidate the many different mediations that
might exist in the manually configured solution described above into a single ESB. However, this
consolidation is still dependent on a systems administrator to manually define the mediations
required for each service (in this case, the number of proxies to be configured is minimized
service availability, the broker ESB solution is inflexible. The broker ESB then becomes the
architectural bottleneck, which introduces issues with scalability and fault tolerance.
3.2.3 Centralized Registry
The final known approach is to deploy a centralized registry for the entire enterprise.
When ESBs need to route service requests to other ESBs within the SOA, they would consult
the registry at runtime to make a forwarding decision based on the current location of a service
instance, thus addressing the manual configuration concerns raised by the previous solutions (as
with the broker ESB, the number of entries in the centralized registry is equal to the number of
services S). However, centralizing all service metadata and status into a single registry forces the registry to be the architectural bottleneck in such a federated system, thus causing concerns
with system performance, scalability, and fault tolerance. The centralized registry is ideal from
the standpoint of the consolidation of service information, but is infeasible in many realistic
business scenarios due to business-to-business interactions, disparate geographical locations,
and limitations imposed by business structures. Today, manual configuration of the centralized
registry is required to insert/update/delete service metadata, which limits the flexibility of this
solution.
3.3
Federation Architecture
The overarching goal of ESB federation is to provide a logically centralized (at an
appropriate scope) integration platform across different geographic and business boundaries;
that is, the topology formed by the federation of ESB deployments should align directly to the
structure of entities within an enterprise. Examples of federated ESB topologies that align with
common business structures are presented in [31].
Figure 3.1 shows the logical topology of a hub/spoke federated ESB. This type of
topology directly aligns with the Store/Branch business structure described in [31] and forces
all service routing to be done through the hub ESB deployment.
Figure 3.2 shows the logical topology of a directly-connected federated ESB. In this
topology, all ESB deployments are connected directly to one another, so that service requests
that are routed within the federation pass directly from the source ESB to destination ESB. This
type of topology directly aligns with the Multiple Geographies & Multiple Business Divisions
Figure 3.1: Example Topology of Multiple ESB Deployments - Hub & Spokes
Figure 3.2: Example Topology of Multiple ESB Deployments - Peer Business Divisions
A natural extension of the intra-federation topology is interconnecting multiple
fed-erations, as shown in Figure 3.3. There is a practical need for interconnected federations; the
need arises, for example, in business-to-business environments, in which separate enterprises
must interact to provide a service to each other or to create a composite service to be offered
to an external customer. The same need arises within a single but large enterprise (e.g., in
an e-government setting), when the enterprise itself is organized as multiple, autonomous, and
heterogeneous federations of ESBs.
A key concept in our proposal is the notion that the amount of service registry data
that is shared with a federation member is configurable via policy; we refer to this concept
as policy-based service advertisement. For example, in the hub & spoke case, it is desirable
for a spoke to share appropriate service information (as defined by policy) with the hub ESB,
and share no service information with any other spoke ESB. Policy-based service
advertise-ment allows different members of the federation to have different views of hosted services at
a particular federation member. We envision that certain services should only be exposed to
certain federation members, and that it may be desirable to allow or disallow the advertisement
policy documents is an orthogonal problem to the one we are addressing and is therefore outside
the scope of this manuscript.
Our method to achieve a dynamic and scalable federation of enterprise service buses
is based upon the concept of a distributed service registry. Federation members create a
dis-tributed service registry by sending policy-based service advertisements to peer members. Each
federation member will have its own (possibly unique) converged view of all routable service
endpoints in the federation, which it will use in making routing/forwarding decisions. This
model contrasts with the centralized registry solution described in Section 3.2; notably, the
distributed nature of the registry allows it to overcome the scalability and robustness concerns
that exist with a centralized solution. In order to allow the federation members to distribute
service state amongst themselves, protocols are needed that implement the policy-based service
advertisements in an automated fashion.
3.3.1 Related Work
There are several previous attempts that have been made towards developing federated
service discovery architectures that are based on service registries. The authors of [32] propose
defining a topology for collaborative service discovery, and subsequently floods the topology with
the discovery query, and all nodes respond to the client with the results. A similar proposal
is presented in [33], where UX servers are part of a federation, and a minimum spanning tree
is found in order to flood queries if an initial lookup returns null. However in both of these
proposals, flooding is required and such systems are known not to be scalable.
There are several proposals for distributed service discovery based upon distributed
hash tables (DHT) and P2P technologies. [34] proposes the integration of distributed hash
tables with UDDI registries to enable a larger distributed registry; however, they do not consider
governance issues in a cross-domain system in the proposal. The authors of [35] present the
use of DHT as a way to enable a scalable service discovery platform for Grid environments.
In [36], a P2P network is used to interconnect registries using a layered approach. Clients
issue queries about available services (that meet their desired semantics and QoS) to a gateway
layer, that is responsible for the translation of the query into the ontologies of the different
types of ontologies supported at the different registries within the federation, and then passes
the query off to a routing layer that transmits the query onto the appropriate registry. Finally,
[37] focuses on the discovery component of the service composition problem; they utilize Pastry
