Server-Independent Plug-In Deployment via Registry
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current systems for deploying Flex components lack flexibility in supporting distributed deployment and require cross-domain policy files, making it difficult to update and manage Flex components across multiple server platforms without recompiling.
Innovation Solution
A server-independent deployment method that involves a plug-in repository and registry, allowing plug-ins to be deployed across various platforms, identified by their extensions, and retrieved based on client requests for generating graphical user interfaces, enabling incremental and platform-independent updates.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If Flex components are deployed through standard server mechanisms (folder paths or .WAR files), then deployment is straightforward on single server platforms, but the system lacks flexibility for distributed deployment across multiple server platforms
Solution Approach 1:
The deployment mechanism is segmented into two independent parts: a server-independent package format (for client distribution) and a server-agnostic registry system (for server-side management). This segmentation allows the same package to be deployed across multiple server platforms without modifying the deployment mechanism, thereby enabling distributed deployment while maintaining simplicity.
Solution Approach 2:
The patent creates a universal package format and registry system that functions independently of any specific server platform. The package can be deployed on any server (Apache, IIS, Tomcat, etc.) without requiring platform-specific adaptations, achieving multi-functionality across diverse server environments and eliminating the need for complex platform-specific deployment mechanisms.
2Reliability
If Flex components are updated by re-compiling and re-deploying the entire package, then update consistency is maintained, but update time and resource consumption increase
Solution Approach 1:
The package is segmented into modular components that can be independently updated. Instead of re-compiling and re-deploying the entire Flex package, individual components can be updated separately and registered with the server, maintaining update consistency for modified components while avoiding unnecessary processing of unchanged components, thereby reducing update time.
Solution Approach 2:
The manifest file is prepared in advance during package creation, containing all necessary metadata about package components, versions, and dependencies. This preliminary action enables the server to efficiently identify and update only the specific components that need changing, rather than re-deploying the entire package, thus maintaining reliability while reducing update time.
3Reliability
If cross-domain policy files are required for Flex component access, then security control is achieved, but deployment transparency is reduced and additional configuration is needed
Solution Approach 1:
The security policy information is merged into the package manifest file itself, rather than requiring separate cross-domain policy files on the server. The manifest contains embedded security metadata that enables the server to enforce access controls transparently during the normal package registration and deployment process, maintaining security control while eliminating the need for separate policy file configuration.
4Reliability
If platform-specific deployment is used for Flex components, then server compatibility is ensured, but adaptability to different server platforms is reduced
Solution Approach 1:
The patent creates a universal package format with a standardized manifest structure that works across all server platforms. The package includes platform-independent component definitions and metadata, allowing the same package to be deployed on any server (Apache, IIS, Tomcat, Jetty, etc.) without modification, achieving both server compatibility and platform independence simultaneously.
Solution Approach 2:
The registry system acts as an intermediary layer between the universal package format and platform-specific server implementations. The registry translates the platform-independent package metadata into server-specific deployment configurations automatically, ensuring compatibility with different servers while maintaining adaptability to various platform environments without requiring platform-specific package variations.
Data Source
AI summary
Disclosed are methods and systems for deploying one or more plug-ins. The method and systems involve receiving a request for generating a graphical user interface at a client computing device, the request includes a configuration for flash content of the graphical user interface, identifying a one or more plug-ins associated with the request and at least one extension of the identified one or more plug-ins, the one or more plug-ins having been deployed at a plurality of content servers across plurality of platform types and stored in a plug-in repository, retrieving the identified one or more plug-ins based on the extension of the identified one or more plug-ins and generating the requested graphical user interface based on the retrieved one or more plug-ins.