Client API for SOA via Enterprise Service Bus Registry
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing service-oriented architecture (SOA) systems require additional client code to interface with service implementations, leading to increased complexity and maintenance overhead due to the need for transport-specific code and configuration management.
Innovation Solution
A system and method that utilize an enterprise service bus (ESB) with a service registry, allowing the application client to dynamically create service instances and invoke service interfaces without requiring transport-specific code, by using a client API that abstracts away message formatting and transport mechanisms.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If transport-specific client code is used to interface with service implementations, then service functionality can be accessed, but device complexity and maintenance overhead increase
Solution Approach 1:
The patent introduces an Enterprise Service Bus (ESB) as an intermediary component that mediates between client applications and service implementations. The ESB handles transport-specific code, message formatting, and communication protocols, allowing clients to access services without requiring transport-specific code. This resolves the contradiction by maintaining service accessibility while reducing client code complexity through the mediating ESB layer.
Solution Approach 2:
The patent implements a universal client API that can interface with multiple service implementations through the ESB. Instead of requiring separate client code for different transports, the universal API provides a single interface that works across all service implementations, abstracting away the complexity of different transport mechanisms while maintaining broad service accessibility.
2Adaptability or versatility
If transport-specific wrapper classes are implemented, then service communication can be established, but ease of manufacture and maintenance deteriorate
Solution Approach 1:
The ESB serves as a centralized intermediary that manages all transport-specific communication details. Wrapper classes are eliminated in favor of the ESB's message routing and formatting capabilities, which are centrally maintained. This improves ease of manufacture and maintenance by centralizing communication logic in the ESB rather than distributing it across multiple client wrapper classes.
Solution Approach 2:
The patent extracts transport-specific code from client applications and places it in the ESB infrastructure. By taking out the complex transport handling logic from client code and concentrating it in the ESB, the system maintains communication capability while significantly improving maintainability, as changes in transport protocols are made in one centralized location rather than across multiple client implementations.
3Adaptability or versatility
If physical locations of service implementations are stored in configuration, then service discovery is enabled, but configuration management complexity increases
Solution Approach 1:
The ESB introduces a service registry as an intermediary that manages service implementation locations and metadata. Instead of storing physical locations in client configuration files, the service registry provides a centralized service discovery mechanism. This enables service discovery functionality while reducing configuration management complexity by centralizing service location information in the ESB's registry rather than scattering it across client configurations.
Data Source
AI summary
Described are a client application-programming interface (API) in a service oriented architecture (SOA). A system includes an application client having application code, one or more service interfaces, and a processor. An enterprise service bus (ESB) having a service registry connects one or more service implementations with the application client through the ESB. A processor is configured to execute the application code to invoke at least one of the one or more service interfaces and request at least one of the one or more service implementations via a request message. The request message comprises application code language based objects requesting a service. The processor is further configured to dynamically create a service instance for the service message. The service instance comprises the service message formatted for transport in the ESB and an endpoint reference for the one of the one or more service implementations as determined by the service registry.