Supporting Dynamism in Architectural Level

In the past decade or two, there were several attempts to come up with a proper way to support the dynamism in software architecture. Different approaches such as architectural style based, graph grammars and Architecture Description Languages (ADL) based models were also introduced.
According to my understanding the actual constraint comes when we map the dynamism that can be seen in the design to the implementation. The barriers posed by limitations in operating systems, programming languages and hardware would take some time to resolve. But our approach as software architects or engineers to find ways to support dynamism in the design level. That’s only the first step there are bunch of other questions to be answered.
I came up with a typical set of questions that to be answered and not limited to, in supporting dynamism in the implementation level, are follows.

1. How to analyze run time changes? And how to analyze them in run time?
2. How to map run time changes to implementations.
At the end what ever the design, we have to map the design into an implementation.
3. How the implementation platform supports run time changes. What changes to be done in the platform level? If not feasible, what are the alternatives we can find?
Constraints in languages, operating systems, tools need to be considered
4. How to preserve the system integrity? How to prevent any security violations?
5. What are the cost effective ways to implement changes?
6. What approaches associated with lesser risk

Change management in Services Oriented Architecture

Also if we map the question in hand to the Services Oriented Architecture, what are the approaches we have taken in terms of supporting dynamism and change management? It is unavoidable as in other software systems; the components (mainly services and consumers) too need to be evolved over the time. Especially the continuos availability of services is concerned. So the services need to be changed due to following reasons.
1. Change of requirements that are initially set.
2. Change in the environment
3. Changes due to fixes and patches

Advantages in Services Oriented Architecture

The SOA model itself has some characteristics that support the dynamism
1. Loosely coupled nature minimizes problems in services dependencies
2. Service descriptions makes it easier to propagate changes to other systems
3. Abstract business logic hides details from its consumers via encapsulation
4. Stateless behavior
5. Self described nature
6. Re-usability
7. Ability to compose or assemble services

So the above characteristics make systems in SOA to show more support in dynamism than the conventional systems. But are there any specific issues related to SOA, in supporting dynamism? This is going to be a god research topic I think.

Make it adaptive, but avoid the complexity

That’s where the ROAD heading
One of the major challenges to be faced in designing adaptive software systems is the how to avoid the complexity. A complex design is always hard to develop and then very hard to maintain.
The complexity of such a system arises due to following reasons, which are in turn challenges to be faced by software architects.

1. How to represent changing requirements at runtime?
   
2. How to account for computational and network contexts at runtime?
   
3. How to manage the system in a distributed architecture
   

Changing requirements

As we studied in our Software Engineering lectures, it is better to separate the user requirements from the design itself, to make it more maintainable. The design itself shows very little evidence about the exact requirements and most of the time is developed using set of interfaces and abstract functions. Requirements or the awareness of the run time environment is kept separate.
But the problem with this approach when it comes to adaptive systems is that it is necessary to know these requirements and make it available within the software itself. Java like languages tries to make the implementation to be separated by the specification using interfaces. But there are limitations in this approach too

1. No mechanism to update interfaces at runtime
   
2. Only functional requirements can be met
   
3. Requirements are related to entity. Not the context in which they are applied to
   

Computational and network contexts at runtime
At the end the designed software executes on a physical computers or a network. The challenge posed by adaptive systems is how to identify the computational context in which operates on. This is further complicated by the fact that these contexts need to be account both for entities and for the composite as a whole.

Distributed/Open architecture
Though there are many attempts to go for a common middle ware standard, there is still no such. So the system needs to work with heterogeneous components in a distributed architecture.
So the question is how to find answers to these inherent challenges at the same time avoiding the complexity?

ROAD Framework
Role Oriented Adaptive Design is or ROAD in short is an attempt to answer the questions mentioned above. ROAD framework is based on the view that adapting the relationships among entities rather than entities it self. To put in another way adaptation is a property of the relationship rather than a property of an entity.

Key concepts

1. Role: Description of the behavior of a functional entity
   
2. Functional Entity : Role players such as services, objects and components
   
3. Contracts: Connectors between roles.
   
4. Organizer: A role that create/destroy roles.
   
5. Self Managed Composite: A set of roles and contracts manages internally by an organizer.
   
6. Management Interface: The interface of the SMC (Self Managed Composite) to the external world.
   

In my view the power behind the RODE framework is the separation of roles from its role player and the concept of self managed composites. All contracts are internal to the SMC, avoiding the complexity of the design.
Note that such a composite system can again be an entity which plays a role of another global SMC.

Let’s see how above challenges are met in ROAD framework

Facing Challenge #1:
The organizer manages the contracts rather than functional entities. Functional entities are bound to play the roles which can be reconfigured at run time depending on the changing requirements. New roles and contract may create depending on the requirements. Also the Manager binds the functional role players to its roles.

Facing Challenge #2:
As the runtime environment changes, the framework allows to add/drop roles or assign/replace/remove role players. The contract oriented nature facilitates such, without actually damaging the initial design.

Facing Challenge #3:
ROAD doesn’t require the knowledge of entities. Thus entities in heterogeneous technologies can interact and be managed.

More details can be found in this paper

Adaptive systems... more reliable or not?

Would the adaptive systems or the systems that can adapt themselves to fluctuating environmental conditions actually bring the reliability? Or would the reliability is compromised in such a system?
One can argue that the internal structure or the behavioral patterns of the system are tend to change more in an adaptive system. Thus the initial reliability index can be changed with the environment changes. And also prone to be attacks/failures that never imagined before.
But again adaptiveness or the flexibility can also be a sign of a reliable system. Like a grass bending to the wind. Or take us, the humans beings for example. We adapt to the environment and thus survived so far in the world(Until we try to adapt the environment to suit us ;-) )
So how far we can go with adaptiveness in a system? What are the areas that we need to consider in designing adaptive systems? How to assess/predict the reliability of such systems?

Security concerns of composite systems

For last couple of days I managed to read a bit about composite systems and how useful the component based Software Engineering when it comes to the industry. The flexibility of coupling and decoupling components in a composite systems and reusability of using one component in a number of such systems makes them very attracted in numerous applications.
But at the same time we have to consider about the security concerns in that approach. These concerns can be divided into two categories.

1.Security concerns of the component
2.Security concerns when the component is inegrated and used

When forming or modifying composite systems by coupling and decoupling different components the integrator has to evaluate how the component is secured itself. In other words how securely the component is being built by the developer.
Also the integrator has to evaluate how the system is secured from the components. A set of secure components doesn’t always guarantee a secure system. The integrator has to determine for what extent the system can trust the component.
This brings us to the topic of Trust Management in component based software engineering.

Cross roads

For the past two or three years, I've been working on SOA (Services Oriented Architecture) systems. To be more specific web services. In the same time I was lucky enough to study/implement certain web services security specifications, by polishing my knowledge in Computer Security.
As I start my higher studies in Swinburne University of Technology, now I'm expanding my knowledge towards adaptive systems. I'm now hopping along this new axis with the help of Swinburne Research in Melbourne.
I'm still just enjoying the sceneries in this path and occasionally glance through the track I used to travel earlier.
Would I be able to divert the current path and form a new junction with the former?
Or is it too early sketch the map?