Platform/Part Architecture

Have you ever wanted to make changes to your system without having to update or recompile the code? For example, have you ever wanted to remove or add a method or class or property? Have you ever needed to pause a function, discontinue its usage, or even condition its access?

Dramatic changes to systems, from their design to their implementations, can be done through a part/platform architecture shown here. This is nothing more than a proper adoption of relevant design patterns and experiences used in operating system and server designs.

In this design I customize, scale, and revisit the principles, thoughts, and ideas that 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 that are defined before the system is compiled. This restricts the expansion or changes that can happen to designs, code chunks, or mechanisms of code distribution within projects without being recompiled and revalidated.

In a transparent virtual world, like a Java virtual machine (JVM) and the .NET Framework, more dynamic, rich, and enhanced environments and capabilities have been introduced to developers and architects. Regardless of hardware setting or device size, code should always work. These code pieces, however, are bound with the old rules that limit dynamic and critical changes to systems at runtime. [Editor's note: With reflection and attributes, changes can be made at runtime.]

In Web servicing and distributed environments, protocols, standards, and the internal architecture of each piece working on each channel end remains statically defined in the inside and each piece signs 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. 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 one part and another. These subscriptions have a certain sequence that is also defined in the part's behavior. Although parts are well defined, this doesn't mean they have to tell everyone how they are used—that is where the Platform's role comes into play.

The Platform is the orchestrator that hosts all the parts in a system. It can be a group of programs, services, or servers that are distributed or placed in one location. 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 their own; they require a platform as well as other parts that service it through its well-defined behavior.

Platform requires that each part thoroughly defines 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, in part, requires it 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 keep the exchange and interaction validated by the platform.
  • A set of subscriptions. Sequences of these subscriptions and internal good implementation of tags that enable unique identification of this part against keys in their platform records, as well as defined states.

All of the above are stored as records in the platform data container where parts subscriptions can be altered dynamically. Additionally, part subscriptions can be removed or added and their states can be modified. Commands even can be fired to the platform.

The states of a part can be:

  • Online
  • Running
  • Busy
  • Idle
  • Offline
  • Disconnected
  • Discontinued
  • Paused
  • Enabled
  • Disabled

States cause the platform to react in a certain way whenever an action is attempted against a part with a certain state. If that part has a subscription for that state, the platform wakes the subscription on the event that such a state was reached.

In general, the normal sequence on the platform/part initiation would be the following:

An action taken

The 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 because of their behavior they are put into 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 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, and so on.

For example, a menu would have a group of subscriptions to certain actions. These actions, once triggered through a mouse click on any of the 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.


From a property or method to a stored procedure, anything can be made a part. Defining it correctly 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 a better idea, consider this system like any Internet applications hosting server (such as 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—removing and adding from the first brick to the last brick with total freedom and flexibility.

As with these Internet servers, the server would handle what it can if it wasn't directed to do otherwise. The same is true with the platform. If no behavior from the part tells to how handle a specific error or exception, the error or exception is handled by the part on its own. Parts can subscribe to 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

The logic containers 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 is tagged internally with a GUID that has an exact match in their predefined records in the platform.

To be continued...


  • Another attempt for the ultimate generic contractless system

    Posted by jconwell on 06/22/2005 04:32pm

    I'm sorry, I donbt want to sound like I'm flaming this article, but I have to speak my mind on this topic. People have been talking about this sort of "group of reusable generic, interfaceless, parts that just fit seamlessly together to make a system" sort of thing for a while now. I've worked on/with a few and they always turn out to be too much of a pain to deal with. They just aren't efficient enough, both in a dev and a runtime aspect, to be worth while.
    Its just not a realistic paradigm.  How often does what you write for a system end up being so useful that you want to use it in multiple places?  About 10% - 15%?  Maybe not even that.  Applications have a specific goal to accomplish.  There are housekeeping tasks that are shared across all applications, sure (error handling, logging, instrumentation, thread safety, etc).  But the majority of logic is very specific towards the problem the application is trying to solve.
    As for that 10% - 15% of reusable logic that is generally shared across different applications, I tend to lean towards AOP (aspect oriented programming) to accomplish that. There are several implementations for .Net that use one type of proxy approach or another to acomplish AOP.
    The other aspect that I really donbt like about this 'part' architecture is how SLOW it would run.  The paragraph on how a menu would trigger its associated action is any performance engineer's nightmare.  Lets see, read XML, use XLS to create new XML, another XSL transform, XSD validation, then reflection to invoke the method and reading the xml to pull parms.  Okb&general rule for performance in .Net.  Donbt use the following: XML, XSL, XSD, Reflection.  The scalability issues of this architecture are mind boggling.  If you implemented this for a web site you might be able to serve up 2-4 requests per second, but not much more.
    Also, you mentioned security.  When your code is in a dll, that dll cant be tampered with very easily.  But, xml is very easily modified.  If I hacked into your IIS server, then modified all method calls to call a part that deletes data from the database.  Big problem.  With compiled code you donbt have as much to worry about.
    Now, I'm sure the code behind all this is sound.  It sounds like a fun thing to code.  But its just not realistic for anything commercial.

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • As all sorts of data becomes available for storage, analysis and retrieval - so called 'Big Data' - there are potentially huge benefits, but equally huge challenges...
  • The agile organization needs knowledge to act on, quickly and effectively. Though many organizations are clamouring for "Big Data", not nearly as many know what to do with it...
  • Cloud-based integration solutions can be confusing. Adding to the confusion are the multiple ways IT departments can deliver such integration...

Most Popular Programming Stories

More for Developers

RSS Feeds

Thanks for your registration, follow us on our social networks to keep up-to-date