Part/Platform Architecture

Have you ever wanted to remove or add a method or class or property or any kind of change in your system without having to update or recompile the code?
Have you ever needed to pause a function or an object or discontinue its usage or even condition its access?
Dramatical changes to systems from their designs to their implementations can be done through this part/platform architecture which is nothing more than a proper adoption of relevant design patterns and experiences used in operating system and server designs.
In this design I Customized, scaled and revisited the principles, thoughts and ideas to make it possible for web, desktop and service applications to be better distributed, free of constraints and better validated and secured.
Platform/Part Architecture Introduction
In Object Orientation, materials that build up the system are tightly coupled, they are loaded consistently and managed before and after execution, all objects have to conform to specific rules and signatures very much defined before even being compiled, restricting the expansion or changes to designs, code shunks or mechanisms of code distribution within projects without being recompiled and revalidated.
In Transparent Virtual World, like java virtual machines and .net framework, more dynamic, rich and enhanced environments and capabilities were introduced to developers and architects, whatever hardware setting or device size, code would always work. But still these code pieces are bound with the old rules that limit dynamic and critical changes to systems at runtime.
In Web Servicing and distributed environments, protocols and standards and internal architecture of each piece working on each channel end remains statically defined in the inside and signing itself to the world with static metatags as well. Whenever a piece gets itself updated, it changes its old static definitions to new static ones that requires all consumers to update their ways of consuming it as well.
In the new Platform/Part architecture, a diversity of features and capabilities can be implemented with the proper adoption of its architecture and design.
Here, everything is considered a part, not an object, not a class, not a method, not a property, just a part.
Each part has a certain dynamic behavior, this behavior defines the way that part wants to exist in certain contexts, so with multiple behaviors defined, the same part can be used in a total different way. These behaviors are a set of subscriptions, each is between a part and another, and these subscriptions have a certain sequence that is defined as well in the part's behavior. Parts are well defined but being so doesn't mean they have to tell everyone how to use them, here comes the Platform role.
Platform is the orchestrator that hosts all the parts in a system, it can be a group of programs, services, servers, distributed or placed in one place, in the end it forms what can be considered the virtual transparent playground for the parts to collaborate together. Parts in general cannot exist on its own, it requires a platform as well as other parts that service it through its well defined behavior.
Platform requires that each part defines quite well the following three important basic requirements:
-a logic container that defines what holds the logic for that part, it could be a stored procedure, class in a library, a resource or even a basic command.
-a knowledge container that defines the runtime and design time data that part requires to be able to do its internal logic, exchange knowledge with the platform and consume information expected through its subscriptions, these are represented in a group of XML files to hold the raw data, XSL files to enable the platform to better transform the needed data for each of the part's subscriptions and XSD files that keeps exchange and interaction validated by the platform.
-a set of subscriptions, sequences of these subscriptions and internal well implementation of tags that enables unique identification of this part against keys in their platform records, as well as defined states.
All above are stored as records in the platform data container, where dynamically parts subscriptions can be altered, removed or added, parts' states modified and even commands are fired to the platform.
States of a part can be:
Online
Running
Busy
Idle
Offline
Disconnected
Discontinued
Paused
Enabled
Disabled
States causes the platform to react in a certain way whenever an action is attempted against a part with a certain state, if that part had a subscription for that state then the platform wakes the subscription on the event of such state was reached.
In general the normal sequence on the platform/part initiation would be:
An action taken, platform locates a best bet part to carry it on its behalf, the part finds itself undergoing a state change, it then requires a step to hold up to the challenge, once done it results out and platform consumes and updates subscribers.
Actions on platform:
They are just parts but of behavior that puts them in a logical context that makes them considered as actions.
Actions are initiated through subscriptions, parts subscribe to certain actions, these actions might be shared and being consumed by hundreds of parts, these actions have a well defined set of subscriptions of its own, that define how they are initiated, what kind of events that could trigger them..etc.
For example a menu would have a group of subscriptions to certain actions, these actions once triggered through a mouse click on any of that menu items would request a translation of the exact context and requirements of that click through its own subscriptions, it would update its internal XML, flag its needed subscriptions and define the priority and interval it wants the platform to look that subscription up for it. The platform steps it, reads its XML, locates the right XSL and transforms that into an output XML, considered as parameters in the casual world, it then locates the other end of the subscription loads up the XSL of that part, translates the parameters into a final result set and validates it against the other part XSD, it then updates and merges data in the right XML store of that part and fires the internal method into that part. The part wakes up to find all its parameters are already there and all it has to do is to perform its internal logic and addition subscription requests if any existed.
Parts:
From a property, method to a stored procedure, anything can be made a part, defining it right for the platform to consider it in its constant loop makes it ready for use right away.
Further into the platform and parts:
How would exceptions, errors and many of the standard and basic needs be covered, specially that this system is dynamic?
To get the idea closer, consider this system so like any internet applications hosting server, i.e. IIS or Apache server, but with much deeper dynamic taxonomy, here it is not just about adding dynamic projects, it is about each piece of the system, removal and adding from the first brick to the last brick with total freedom and flexibility.
As in these internet servers, the server would handle what it can if it wasn't directed to do otherwise, the same with the platform, if no behavior from the part tells it to how handle a specific error or exception, it handles it on its own. Parts can subscribe on other parts to handle these exceptions and errors for them.
Scaling the platform together with its parts, is a very easy and reliable process, as founded the basis of the platform defines the location of the logic and knowledge containers for a specific part, enabling it to exist anywhere and in any form. Platform includes the sufficient logic to know how to handle different situations, should new types exist, code to handle how to access these would have to be added to the platform.
Platform can be composed of a static set of objects or it can make use of the dynamic platform part itself minimizing that static part to the least but losing much of the performance perspective.
Logic Containers:
These hold the core logic of each of the parts defined in the system, they can be methods, stored procedures or external calls to services or servers or web services.
Each are tagged internally with a GUID that has an exact match in their predefined records in the platform.
To be continued..