Autonomic computing vs Artificial intelligence

This article "Looking to nature for smarter software systems" explains the use of autonomic computing in a very simple way highlighting how it is different from Artificial Intelligence.

Adaptive software systems and their challenges - Part I

There are different challenges posed by different software executing environments. As the technology advances, the computer is no longer something that you see in your office desk. It can be varied from your mobile to a something distributed along the network. Or may a teeny tiny chip, which can be stored anywhere. And software is not something that ready to do your work once you install it using a wizard. The traditional definitions and methodologies are demolishing so as the traditional software designs. Just like the human beings trying to adapt to the changing environments software itself needed to be adapted. The adaptation is a sign of survival. Just like humans trying to survive in different weather conditions, software systems too need to survive in different environments. For example a system installed in your car or the mobile need to sense the changing environment and adjust itself to suite the changes without dieing.
So what are the challenges faced by different categories of systems when it comes to adaptation? What are the challenges in designing such systems? Following is a brief of such challenges categorized in terms of different types of software systems.

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