SOA Registry Segmentation for Automated Platform Deployment
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The existing approaches to deploying Service-Oriented Architecture (SOA) applications require manual, time-consuming, and error-prone adaptations when redeploying on different platforms due to varying properties such as operating systems and database implementations, which hinders efficient automation.
Innovation Solution
A two-layered SOA-registry architecture that describes SOA applications in abstract, platform-independent terms and maps them to concrete, platform-specific components, allowing for flexible deployment by matching component requirements with target platform properties using ontologies and logical operators.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If manual adaptations are performed for each platform, then the SOA application can be deployed on different platforms with specific properties, but the deployment process becomes time-consuming and error-prone
Solution Approach 1:
The invention segments the component description into two distinct layers: abstract component descriptions that define the functional interface and behavior, and concrete component descriptions that specify platform-specific implementations. This segmentation allows the same abstract component to be deployed across multiple platforms by selecting appropriate concrete implementations, eliminating the need for manual adaptations while maintaining platform compatibility.
Solution Approach 2:
The invention introduces an intermediary layer (the abstract component description) that mediates between the concrete component implementations and the SOA application. This intermediary defines a platform-independent interface that concrete components must implement, allowing automatic selection and binding of appropriate concrete components for different platforms without manual intervention.
2Adaptability or versatility
If manual adaptations are performed for each platform, then platform-specific requirements can be met, but the process becomes costly and error-prone
Solution Approach 1:
By segmenting component descriptions into abstract and concrete layers, the invention separates platform-independent functionality from platform-specific implementations. This allows automated selection of concrete components based on platform characteristics, reducing deployment complexity and errors while maintaining ability to meet platform-specific requirements.
Solution Approach 2:
The invention changes the parameter representation by defining concrete component descriptions with explicit platform requirement parameters (operating system, database, runtime environment). This structured parameter approach enables automated matching between platform capabilities and component requirements, simplifying the deployment process while ensuring platform-specific adaptations are correctly applied.
3Adaptability or versatility
If abstract component descriptions are used, then platform independence is achieved, but mapping to concrete components requires complex matching logic
Solution Approach 1:
The abstract component description serves as an intermediary that simplifies the registry structure. Instead of requiring complex direct mappings between multiple concrete components and the application, the abstract description provides a single, unified interface definition that concrete components implement, reducing registry complexity while maintaining platform independence.
Solution Approach 2:
The abstract component description provides a universal interface that can be implemented by multiple concrete components across different platforms. This universal definition reduces registry complexity by having one abstract description serve multiple concrete implementations, rather than requiring separate descriptions for each platform variant.
4Adaptability or versatility
If concrete component descriptions are created for each platform, then platform-specific requirements are satisfied, but the registry size and maintenance effort increase
Solution Approach 1:
Segmenting component descriptions into abstract and concrete layers reduces registry entries by having one abstract description per component type, rather than requiring separate descriptions for each platform variant. Concrete descriptions are created only when specific platform implementations exist, reducing overall registry size while maintaining platform-specific support.
Solution Approach 2:
A single abstract component description can serve as the foundation for multiple concrete component descriptions across different platforms. This universal base description reduces the total number of registry entries needed, as common functionality is defined once at the abstract level and reused across platform-specific implementations.
Data Source
AI summary
A computing system includes a service-oriented architecture (SOA) registry that includes an SOA-application description, an abstract component description, a concrete component description, and a platform description. The SOA-application description is related to the abstract component description of a component of the SOA-application. The concrete component description includes a requirement of a respective component for a target platform. The platform descriptor describes a property of the target platform. The computing system is configured to deploy the SOA-application and its respective components to the target platform in accordance with the concrete descriptions.