Application Security Testing: An Integral Part of DevOps
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:
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.
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...