A Method for Dynamic Linking and Contextual Extension of Independent Systems
Original Publication Date: 2003-Nov-28
Included in the Prior Art Database: 2003-Nov-28
Many systems are created by assembling sub-components together, with neither the components, nor the final structure being known ahead of time. Such systems still need to operate as one structure, and need to be extendable in an open fashion. This flexibility should allow the overall system to be assembled from available components after deployment. This implies, too, that a component provider should not have to preassemble components or modify configuration data corresponding to a specific set of components, or corresponding to a fixed root final system structure.
A method for dynamic linking and contextual extension of independent systems
Disclosed is a method for dynamic linking and contextual extension of independent systems. The method describes a way of encapsulating extension configuration rules for component deployment, and consequently describes dynamic contexts for components themselves.
Components can exist in a simple hierarchical relationship. By default, if no other method is specified, a single component forms the root structure. Components can also simply exist as unconnected peers. However, since all components are, from the final system's perspective, dynamic (they may or may not exist in the final system), and a component cannot always assume the existence of another component, any given component may choose to indicate its availability only when another component exists and a link to the other components can be created.
To build the final structure of a system, components can be linked together with two complementary integration strategies:
top-down - when a component links/aggregates another component. Note that top-down integration includes the ability to consume root structures, as well as to extend them bottom-up - when a component links to an anchor point specified by another component. Note that this extends hierarchical structures inclusively, and cannot consume the parent component, though it doesn't necessarily inherit context from the parent.
The components of this system can be hardware system, software system, or any other domain in which elements can be represented as sets of hierarchies (or directed graphs).
The unifying paradigm and method for assembling configuration data is carried by each component in a well-formed tagged document. Component configuration is represented as an XML manifest/document called a table of contents (TOC). A method is implemented on a platform over which all components are laid. During system execution, configuration data from all existing components is collected, and linked together according to the specific rules, to form a broader, more product-centric view of the system.
Tables of contents are really the unit of work, the building blocks of the system contents. Tables of contents can link any other table of contents, and can be linked to any other table of contents that allows linking. Once all the linking operation have been performed, some tables of contents are said to be integrated and some not. Those that are not integrated are discarded and the running system only contains the integrated tables of contents.
A table of contents is considered to be integrated if they are: tagged as primary, or linked to another integrated table of contents
A component indicates its desired integration of a table of contents by tagging it as "primary" or not. Consequently, a table of contents is not tagged as primary when it is meant to be integrated into another table of contents a table of contents should be tagged as primary when it is c...