Patent Application
20090077251
In computing, an enterprise service bus serves as the integration platform within service-oriented architectures. The enterprise service bus (ESB) refers to an abstraction layer on top of an implementation of an enterprise messaging system that attempts to remove the coupling between the messaging service called and the transport medium. The ESB may be implemented as software or as a hardware device. The ESB is responsible for, along with many other functions, enforcement of policies, routing of service requests, and performing content and/or transport protocol transformation. There are numerous technical and business issues which affect the choice of topology for the deployment of ESBs.
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 the enterprise. The term federation refers to a group of two or more ESB deployments that share at least some routing state. The goal of federation is to provide a logically centralized (at an appropriate scope) integration infrastructure across different geographic and business boundaries.
There is a practical need for interconnecting such autonomous federations of ESBs; the need arises, for example, in B2B environments, in which separate enterprises have to 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 even 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. With current technology, there is a large amount of manual configuration that must occur in order to deploy a service, connect it to an ESB, and finally to enable consumers throughout an enterprise to invoke the service. For example, service endpoint interface documents (i.e. WSDL, XSD, etc) must be manually written (or generated from tooling). Then the local ESB must be configured to host the service endpoint, and mediation flows are defined manually for the service. Policy documents would also be created at this point which would define exactly who, when, and how the service could be invoked. The combined set of service metadata is then manually committed to the local registry. These manual configuration steps are not addressed by this disclosure; rather we list them to fully pinpoint the complexity of the interconnected ESB system at three levels: (a) a single ESB, (b) federation of ESBs, and, (c) interconnection of multiple, disparate, autonomous federations of ESBs.
Assuming that one or more services have already been manually deployed and hosted through an ESB, there are three known solutions to federate ESB deployments together to support reuse of services throughout an enterprise: manual configuration, utilizing a broker ESB, or deploying a centralized service registry. The same approaches could, in theory, apply to interconnect autonomous federations of ESBs.
One way of federating ESBs (at either the second or the third level described above) 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 on the ESB must be defined that selects appropriate requests to be forwarded to the remote ESB, performs necessary content/protocol transformations, and then 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.
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 the 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 to S). Since there is no mechanism to update the mediation metadata based on dynamic service availability, the broker ESB solution is inflexible. The broker ESB then becomes the architectural bottleneck, which introduces issues with scalability and fault tolerance.
The final known approach is to deploy a centralized registry for the entire enterprise. When ESBs need to route service requests to other ESBs, the ESBs consult a central 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). However, centralizing all service metadata and status into a single registry forces the registry to be the architectural bottleneck in such a federated system, 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 B2B 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.
In summary, the existing approaches to federating ESBs require tedious manual configuration, which is prone to errors and inflexible to dynamic IT environments. The broker ESB and centralized registry approaches require the consolidation of service metadata into a centralized location, which causes concerns with scalability and reliability of the integration infrastructure.
In a method and system for creating an interconnection between autonomous enterprise service buses (ESB) federations, each one of the ESB federations comprise at least one ESB deployment, which further include a plurality of ESB nodes that provide connectivity to one or more services. According to a protocol, a first ESB node is designated in each of the ESB federations as a boundary node that is responsible for establishing and maintaining an interconnection between at least two of the ESB federations. Advertisement messages are transmitted between the boundary nodes that include routing information. In response to receiving the advertisement messages, each of the boundary nodes store the routing information received from other boundary nodes in respective distributed registries to create a local view of routable service endpoints in the federation. Each of the boundary nodes then use the respective distributed registries to make routing decisions when routing service requests.
According to the method and system disclosed herein, a routing/management protocol is provided for enabling the federation of enterprise service buses in a dynamic and scalable manner. The protocol creates a distributed service registry and may synchronize relevant service metadata amongst ESB deployments as appropriate under defined business policies.
The present invention relates to a protocol for enabling dynamic and hierarchical interconnection of autonomous federations of enterprise service buses. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiments and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features described herein.
The preferred embodiment provides a routing/management protocol for enabling the interconnection of federated enterprise service buses in a dynamic and scalable manner. The routing/management protocol enables creation of ESB federations having topologies that may align with business structures and that may automatically respond to changes in network and/or service conditions. The exemplary embodiment is based upon the concept of using the routing/management protocol and a distributed service registry to synchronize relevant service metadata amongst federated ESB deployments as appropriate under defined business policies.
According to one aspect of the exemplary embodiment, a routing/management protocol is used by each of the ESB nodes 12 to allow the ESB nodes 12 to disseminate and share their routing and service state information with other ESB nodes 12. According to another aspect of the exemplary embodiment, each of the ESB nodes 12 may maintain its own respective distributed registry 14A through 14E (collectively referred to as a distributed service registry 14) to store the shared routing and service state information received from the other ESB nodes 12. The state information stored in each of the distributed registries 14 may include each ESB node's reachable neighbors and the services 18 run by each of those neighbors. Thus, the routing/management protocol and the distributed registry 14 of the exemplary embodiment can be used to enable dynamic and scalable federation of ESBs. As used herein a federation of ESBs may refer to an architecture where two or more ESB deployments 10 share routing state information, including routable service endpoints in the federation.
The advertisement messages sent from each of the ESB nodes 12 share the ESB node's service state data from each of the node's respective distributed service registry 14. According to the exemplary embodiment, the amount of service state data from the distributed service registry 14 that is shared with each ESB node 12 member of the federation is configurable via policy; which is referred to as policy-based service advertisement. Policy-based service advertisement allows different members of the federation to have different views of hosted services 18 at a particular ESB node 12 in the federation. In one embodiment, the policy-based service advertisement may be configured to define that certain services 18 are only exposed to certain ESB nodes 12 in the federation, and that the advertisement of particular services 18 are either allowed or disallowed. Thus, predetermined policy decisions determine how the ESB nodes 12 of one ESB deployment 10 are configured to send advertisement messages to other ESB deployments 10, and therefore determine the overall topology of the resultant ESB federation and the peer relationships of the ESB nodes 12 therein.
One result of ESB federation is that it may provide a logically centralized (at an appropriate scope) integration platform across different geographic and business boundaries, such that the topology formed by the federation of ESB deployments 10 may align directly to the structure of entities within an enterprise.
The exemplary embodiment may overcome manual configuration approaches to federating ESBs by utilizing a protocol to disseminate service data dynamically by allowing each ESB node 12 to distribute its local state information throughout the federation 30 through the use of advertisement messages, thus enabling a federated environment that is flexible to changes in service availability. In addition, the distributed service registry 14 may minimize scalability and reliability issues and enable the ESB nodes 12 to communicate together in order to provide a seamless policy-driven integration platform.
In one embodiment, the Intra-Federation routing/management protocol may be implemented similar to an Open Shortest Path First routing protocol and may be built atop a Web Services Distributed Management (WSDM) framework. A reliable messaging infrastructure, such as WS-ReliableMessaging or WSRM could be utilized to ensure delivery of messages between federation ESB node 12 members. Also, a security mechanism, such as mutually authenticated SSL, could be used to ensure that communication only occurs between actual federation members.
In one embodiment, the Inter-Federation routing/management protocol may be implemented similar to a Border Gateway routing protocol and may be built atop a Web Services Distributed Management (WSDM) framework. A reliable messaging infrastructure, such as WS-ReliableMessaging or WSRM could be utilized to ensure delivery of messages between federation ESB node 12 members. Also, a security mechanism, such as mutually authenticated SSL, could be used to ensure that communication only occurs between actual federation members.
Once the boundary nodes in each of the ESB federations 30 have been designated, the boundary nodes transmit Inter-Federation advertisement messages between one another, where the advertisement messages 504 include routing information (block 602). In response to receiving the Inter-Federation advertisement messages 504, each of the boundary nodes stores the routing information received from the other boundary nodes in respective distributed registries 14 to create a local view of the routing service and parts of the interconnected ESB federation 500 (block 604). Each of the boundary nodes then uses the respective distributed registries 14 to make routing decisions (block 606).
According to the exemplary embodiment, the Inter-Federation routing/management protocol may have a plurality of different advertisement message types to establish and maintain the interconnection between two autonomous ESB federations 30. For example, the Inter-Federation routing/management protocol may be implemented with four main types of advertisement messages, including an Open message, an Update message, a Keepalive message, and a Notification message.
The Open message may be the first message exchanged between two boundary nodes, and may be used to establish a connection between the boundary nodes in the interconnected federation 500. The Open message may also provide a mechanism to detect if a boundary node is currently reachable or not so that the distributed registry 14 can be updated appropriately. The Open message may also be used in the case where a boundary node suffers failure in order to request a current update of the distributed registry, including any changes that occur during the failure.
The Update message may be used to convey routing information between the boundary nodes, to share the sender's current view of the topology with the receiver, and to advertise new service availability or withdraw an unavailable service. The Update messages also may be used to advertise routes to individual or aggregated services. Note that the routes themselves may be calculated to optimize some criterion (which is outside the scope of this disclosure) or they can be “default” routes.
The Keepalive message may be used to maintain “reachability” between peers; reachability is the notion of knowledge of whether the end-to-end path between entities running the protocol is operating correctly. It is used to affect the routing tables built by the protocol, because if a link or an ESB node is unusable, then more service requests should not be forwarded to that particular node. The Notification message may be sent when an error condition is detected. As an example, such a message may be used by to boundary nodes to detect incompatibilities between two ESB federations.
In the text below and in
The above show examples of how the routing/management protocol is used to create and synchronize the distributed service registry 14 between interconnected ESB federations 500.
In response to one of the boundary nodes receiving a service request either directly from a service requester or forwarded from another ESB node 12, the service request is passed to a routing mediation procedure within the boundary node (block 900). The routing mediation performs a table lookup of the distributed service registry 14 (which includes its own locally defined service connections) to find matching services 18 available in the entire interconnected ESB federation 500 and to determine a destination of where to send the service request (block 902).
It is then determined if the destination for the service request exist within the interconnected ESB federation 500 (block 904). If it is determined that a destination for the service request does not exist within the interconnected ESB federation 500, then the service request is discarded as not being serviceable within the interconnected ESB federation 500 (block 906). Otherwise, it is determined if the destination for the service request exists that is local to the boundary node's ESB federation 30, such that there is an ESB node 12 reachable in an ESB deployment 30 within the local ESB federation 30 that is appropriate for handling the service request (block 908). If so, then the service request is forwarded to the appropriate ESB node 12 within the ESB deployment 10 (block 910). The service request is then processed by the appropriate ESB node's mediation flow, and eventually forwarded onto the requested service 18 (block 912).
If it is determined that the destination for the service request exists in the interconnected ESB federation 500, but that the destination is not local to the boundary node's ESB federation 30 (block 908), then the service request is forwarded to an identified ESB deployment 10 within an identified ESB federation 30 (block 914) and then forwarded onto the appropriate ESB node 12 that provides connectivity for the particular service 18 being requested (block 910).
In one embodiment, default rules or namespace rules can be used to facilitate the routing lookup operations described in blocks 904 and 908. The advantage of such a capability would be to a) limit the amount of information in the distributed registry 14, b) allow an ESB node 12, including a boundary node, to add new services to a group that automatically get routed by other nodes 12 in the federation through an existing routing rule, c) allow intermediate nodes 12 in a complex routing topology to be entirely ignorant of some specific services—and conversely, allow owners of some specific services to receive requests for them without having to broadcast detailed knowledge about the services to ESB nodes 12 that don't need to know. One way to aggregate services could rely on an assumption that a common namespace is in use throughout the entire interconnection of federated ESBs 500 (e.g., URLs are in common use). In such a case, services can be aggregated by using any suitable “prefix” of the name describing the service.
In summary, the exemplary embodiments provide a routing/management protocol for enabling dynamic and hierarchical interconnection of autonomous federations of enterprise service buses in a dynamic and scalable manner. The protocol is based upon the concept of creating a distributed service registry 14 and may synchronize relevant service metadata amongst ESB deployments 10 as appropriate under defined business policies.
The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.
A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers.
Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
A method and system for enabling dynamic and hierarchical interconnection of autonomous federations of enterprise service buses has been disclosed. The present invention has been described in accordance with the embodiments shown, and one of ordinary skill in the art will readily recognize that there could be variations to the embodiments, and any variations would be within the spirit and scope of the present invention. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.
The present invention is related to application Ser. No. 11/853,236, entitled PROTOCOL FOR ENABLING DYNAMIC AND SCALABLE FEDERATION OF ENTERPRISE SERVICE BUSES filed on Sep. 11, 2007.
