Autonomous Computing: Living with your environment, rather than subduing it

The concept of "Autonomous Computing" is emerging in response to the challenges of flexibility and the increasingly complex interoperability problems with which enterprises are faced. Users (functional departments, project sponsors and/or clients) are clamoring for flexibility. Interoperability between systems is omnipresent, both within enterprises (with the challenges of integration between new and existing applications) and between them (in order to set up automated relationships between computer systems).


Market Analysis

Autonomous Computing: Living with your environment, rather than subduing it

The concept of "Autonomous Computing" is emerging in response to the challenges of flexibility and the increasingly complex interoperability problems with which enterprises are faced. Users (functional departments, project sponsors and/or clients) are clamoring for flexibility. Interoperability between systems is omnipresent, both within enterprises (with the challenges of integration between new and existing applications) and between them (in order to set up automated relationships between computer systems).

What's the problem?
Until now, the recommended strategy to resolve these integration issues has been based on transactional principles, underpinned by sophisticated middleware technologies -Message Oriented Middleware (MOM), Enterprise Application Integration (EAI) solutions, etc. - and transaction monitors that steer and coordinate complex, distributed transactions. At application or project level, these transactional constraints remain manageable, insofar as the IT team is proficient with the systems in question. When applied within the enterprise (covering the entire company in its diversity), transactional principles are still valid, but they are extremely intrusive as regards the systems already in place.

Beyond the boundaries of the enterprise, the challenges become even more ambitious, and the obstacles more numerous. Yet the sharing of information, services and applications -whether within or between enterprises- is a crucial requirement. The technologies associated with transactional principles are able to cope with complexity, but begin to crack or crumble when the additional constraint of flexibility is brought into the equation.

The essence of a transactional solution is its utter reliability and security, which calls for complete mastery of all the elements making up the transactional chain: interaction with the user in an application, processing of actions, management of transactions, synchronization of storage structures, and so on. The only way to achieve the goals of security and reliability is to put together a transactional chain whose links are tightly coupled. However, when the flexibility constraint is introduced, the whole transactional edifice is weakened, as the slightest movement of one component will create aftershocks that can be felt on every level.

A new concept to save the day?
So how do we manage this matrix of constraints and reconcile the need for flexibility with the increasingly sophisticated and complex transactional technologies? At the risk of disappointing some of my readers, I'm afraid I cannot unveil a miraculous "silver bullet". Instead, let me introduce the concept of "Autonomous Computing", which provides a complementary approach to the transactional principles which reign supreme over enterprise computing.

The concept of Autonomous Computing emerged from research work in various fields such as IT, cybernetics, and so on. When applied to management information systems, Autonomous Computing invents nothing novel; it simply observes practices and sets them down in accordance with one fundamental principle: simplicity.

Defining Autonomous Computing
The ambition of Autonomous Computing is to define how several computer systems, controlled and managed completely independently, can relate with one another, bearing in mind that in theory they do not trust one another. What is the point? And how is it possible to establish the slightest relationship in such a hostile environment? The idea emerged essentially from the observation of our environment (interactions between various systems in our immediate surroundings), and by observing the computer systems currently in place and their methods of interaction.

Autonomous Computing is based on a simple premise: our existing environment is made up of a multitude of systems, which are diverse and clearly incompatible (i.e. incapable of communicating naturally with one another) and which, in addition, theoretically do not trust each other.

Let us take this premise as our starting point, as it represents fairly well the situation of enterprise computer systems. How can exchanges be enabled? Autonomous computing introduces the following terminology in order to define the elements in the new chain of links that we wish to reproduce:

  • Fiefdoms: these possess independent applications or services and manage their own private data. Fiefdoms do not trust outsiders (any element outside the fiefdom is considered to be an outsider).
  • Requests: Fiefdoms are able to define a certain number of requests, which they can execute on demand, according to certain conditions which are specified in a contract published by the fiefdom when it makes a request available.
  • Reference and context data: This data will supplement requests/responses during exchanges. Reference data is generally provided by the fiefdom, and will help the requester build its request. Context data belongs to the request. Also, it is important to realize that reference and context data are simply "snapshots" of data taken at a precise moment in time.
  • Emissaries take the simple role of transporting requests (and potential responses). An emissary that presents itself to a fiefdom to carry a request will transport the reference and context data. It has no authority to dictate what the fiefdom should do with the request, but simply presents itself to the fiefdom as follows: "Dear fiefdom, please kindly accept my humble request". Only the fiefdom can decide whether or not to process the request.

An example of Autonomous Computing from everyday life
Mail order selling is an example of a model that implements Autonomous Computing. The first fiefdom is represented by the retailer's order management system. The other fiefdom is a user, the customer of the mail order retailer.
The "Retailer" fiefdom will expose requests that it is ready to accept (e.g.: PlaceOrder, etc.) and make reference data available to other fiefdoms (known or unknown) so that they can build their own requests. In this instance, the reference data will take the form of a paper or online catalog. In both cases, when the Customer fiefdom consults the catalog, it is consulting a snapshot of the reference data at a given moment. There is nothing to guarantee that the data is still valid when the Customer fiefdom uses it. When the Customer fiefdom decides to place an order, it selects the appropriate reference data, attaches the context data (first and last names, address, credit card number, etc.), and lastly, uses an emissary to transport the request. The emissary might take the form of a Web site that will relay the request, or a traditional postal service. Once the "Retailer" fiefdom receives the order; it will analyze the request and decide whether to process it. If it does proceed with processing, then it will be able to enter a "transactional" world; in other words, it will trigger the actions required for the order to be processed within its system. The Retailer fiefdom may return a message to the Customer fiefdom indicating the status of the order. The Retailer fiefdom gives the Customer fiefdom the chance to cancel the order up to a certain point in time (before the delivery is arranged, for example). If the Customer fiefdom does decide to cancel the order, the Retailer fiefdom will not process this request as a Rollback of the preceding transaction, but simply as a new transaction which will compensate for the effects of the previous one.

The obvious limitations of Autonomous Computing
The first observation we can make is that transactions do not work between multiple fiefdoms. According to the principles of Autonomous Computing, we cannot carry out a transaction involving several fiefdoms; however, this does not mean we cannot have a process involving several fiefdoms - simply that it is impossible to have one overall transaction for this process.
To get around this absence of transactions between fiefdoms, the notion of compensation comes into play. With the transactional mode, a lock is placed on a resource at a given moment and held for the duration of the overall transaction, until it is committed or rolled back. The compensation mode only manages single transactions, which can be cancelled by compensation (moving to a new transaction which returns you to the previous state). This mode is restrictive, as it is not always easy to compensate for a transaction.

The beginnings of a solution
No market player has yet adopted the concept of Autonomous Computing, although we can recognize it at Microsoft, under the label "Agility", or at IBM under the appellation "Autonomic Computing". So which is the right road to take?
The first rough solutions can be found in Web services. Web services provide the initial technological components required to implement systems that are in step with the concepts of Autonomous Computing.

Finally, apart from the purely technical aspects, there is the problem of trying to identify the actual fiefdoms, precisely marking out the boundary walls, while not forgetting to set up an exchange area.

References:
IBM "Autonomic computing"
Microsoft "Business Agility"
Autonomous Computing - Robert Ghanea-Hercock


Copyright 2003. Originally published by TechMetrix Research, reprinted with permission. TechMetrix is a technology-oriented analyst firm focused on e-business application development needs. TechMetrix is also backed by its parent company, a European global system integrator - SQLI - with more than 800 developers in the field.

For more information:

  • Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
  • Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
  • For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
  • Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.

  • Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
  • Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
  • Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
  • Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
  • Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.

Dig deeper on Enterprise Application Integration (EAI)

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close