Gateway Registry Protocol Translation for Heterogeneous Federation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional registry federation approaches face challenges with heterogeneity, scalability, and performance, particularly when combining different types of registries such as UDDI, ebXML, OSGi, and ESB, due to the need for a common protocol and tight coupling between the gateway registry and individual registries, which can lead to complexity and inefficiency.
Innovation Solution
A scalable heterogeneous federation of registries is achieved through a network topology where a translation protocol layer is moved into a gateway registry, enabling registry type-independent querying and insulation from code changes, with a master gateway registry translating requests and responses between different protocols supported by target registries.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a common protocol (e.g., UDDI) is enforced across all federated registries, then interoperability is achieved, but device complexity and ease of operation deteriorate due to the need for protocol layers at each registry and inability to support heterogeneous registry types
Solution Approach 1:
The gateway registry acts as an intermediary between client devices and target registries. It translates federation protocol requests into registry-specific protocols and vice versa, eliminating the need for each target registry to implement multiple federation protocols while maintaining interoperability. The gateway registry absorbs the protocol complexity rather than distributing it across all registries.
2Productivity
If a master gateway registry pulls and stores copies of services from all federated registries, then query performance is improved, but device complexity and scalability worsen due to tight coupling and data synchronization requirements
Solution Approach 1:
The gateway registry creates lightweight proxy representations of target registry services rather than storing complete copies. These proxies enable fast query routing and response aggregation without requiring full data synchronization, reducing the coupling complexity while maintaining query performance.
Solution Approach 2:
The federation system is segmented into independent target registries and a gateway registry. Each target registry maintains its own data independently, and the gateway registry coordinates queries without requiring tight coupling or centralized data storage, improving scalability while maintaining performance.
3Adaptability or versatility
If multiple protocol layers are implemented at each registry to support federation, then adaptability is reduced, but device complexity increases due to the need for multiple protocol implementations
Solution Approach 1:
The gateway registry serves as a mediator that handles protocol translation between the federation protocol and various target registry protocols. This allows target registries to maintain their native protocol implementations without adding multiple federation protocol layers, preserving adaptability while reducing overall system complexity.
Data Source
AI summary
Certain example embodiments described herein relate to techniques for creating and maintaining scalable heterogeneous read-only federations of registries, e.g., for use in service-oriented architectures. Federation of heterogeneous registries can be achieved with any types of registries (e.g., UDDI, ebXML, OSGi, ESB, proprietary, etc.), while at the same time avoiding the need to have target registries implement extra protocols or layers. In certain example embodiments, gateway registries may implement translation layers appropriate for the types of registries thereunder so as to provide a scalable and flexible solution. Optionally, registries may be grouped based on type so that messages may be translated only once per group, while avoiding tight couplings with registries and the services they provide.