Indus programming language

Indus is an object oriented programming language for Ubiquitous computing. The primary components of the Indus platform are a programming language to implement software agents, libraries to provide services to agents on a distributed network, and run time environments to enable deployment of agents on a variety of hardware platforms starting from 8-bit devices onwards.

The Indus programming language enables implementation of software agents that have the ability to coordinate with other agents and compose components using connectors.

The libraries for the Indus programming language are segmented according to classes of target host platforms – enterprise platforms, mobile hosts and motes. Standard Indus libraries provide services to deployed agents and components such as activation strategies, lifecycle management, service discovery, routing, communications, interoperability, transaction management, persistence and security. Indus Enterprise libraries are used to enable provision of grid services to agents deployed on enterprise platforms. Indus Micro libraries are used to enable provision of services to agents deployed on mobile hosts. Indus Mote libraries are used to enable provision of services such as timer, power and interrupt management, etc to agents hosted on mote platforms.

Indus applications compile to byte code that can be interpreted by a Virtual Machine (VM) and is suitable for execution on enterprise platforms. In the case of mobile hosts, Indus compiles to C code and binary executables that are managed by the Indus Micro run time. In the case of motes, the Indus compiler generates code targeted at the device platform.

Introduction

Existing middleware for client server computing such as .NET, Java EE and CORBA were not designed for Ubiquitous computing. Indus aims to meet the requirements of adaptive middleware for ad hoc, device centric computing networks. The foundation of the Indus platform is an object-oriented language – Indus - for implementing software agents.

The ubiquitous application developer is therefore expected to model any system as a set of concurrently executing agents, with each agent representing a role, and then use features of Indus – new types such as agent and component, component ports, syntax and semantics for composition and coordination, new libraries for distribution - to implement and deploy agents across a variety of ‘peers’ (enterprise servers, mobile terminals and motes).

The Indus programming language

Why is a new programming language required for Ubiquitous, adaptive computing? For client-server applications that execute on networks with mostly static topology, code for aspects such as synchronization, concurrency, parallelism and distribution are all written together with business logic, which leads to tangled code. Indus, by design, models application systems as concurrently executing processes (agents) that compose components (reusable static code) and coordinate with each other to execute application functionality over a network.

The Indus programming language features syntax and semantics that is similar to Java but provides additional features such as
* "New reference types" – Indus does away with the Java type called Interface and instead substitutes two interface types called Agent and Component. Every Indus class must therefore implement an Agent or Component.
* "Coordination styles" – All object oriented languages support only the ‘call and return’ style of interaction between clients and servers where clients call servers that process logic and return calls to clients. Indus defines syntax and semantics for several coordination styles, e.g., parallel pipes, voter-coordination, blackboards, etc, to facilitate a variety of interactions between concurrent processes (agents).
* "Composition styles" – Indus defines syntax and semantics for several composition styles, e.g., pipes and filters, events, rules, etc, to enable plugging in of components by agents. Component composition facilitates code reuse in Indus.
* "Ports" – Indus defines a type called Ports that defines the ability of components to be plugged in in a number of ways. Ports validate component compositions.
* "Behavior inheritance" – Indus places more importance on interface composition as a way of inheriting behavior than class-based inheritance.

The Indus libraries

In Indus, the code for synchronization and management of concurrent agents has thus been subsumed within the language itself whereas the code for managing distributed agents is provided by the library support to the Indus programming language. These are in addition to the usual Java-like language libraries available for math, graphics, utilities, etc.

The Indus Standard libraries provide general libraries available freely to every agent application developer. The Indus Standard libraries provide services for
* "Self configuration": this enables an agent or component to publish services provided and set parameters such as peer ids, concurrency and transactional policies, and its implementation type. By implementation type, software agents can be classified as User agents (identified by a role that can be played by a number of agents executing on different threads of execution) or Process agents (identified by a role that can be played by agents sharing a single thread of execution); both types of agents are transactional, history aware and persistent. By implementation type, software components can be classified as Service components (non-transactional, not history aware) and Session components (non-transactional and not persistent but history aware within a session boundary).
* "Lifecycle management": this comprises abilities to deploy agents and components and evaluate implementation types and associated invocation rules of agents and components prior to their invocation.
* "Activation strategies" (proactive and reactive): this comprises facilities to queue client requests and schedule them according to different activation strategies. Proactive activation would result in a first in/first out (FIFO) schedule whereas Reactive activation would schedule agent invocations as events occur.
* "Service discovery": libraries for service discovery enable every channel and connector (these are communication abstractions in Indus hidden from the Indus programmer) to discover invoked services on local and remote hosts.
* "Communications": libraries enable run time binding to adapters of various types. This enables a high level of interoperability between agents implemented in Indus and components implemented in other languages such as Java and C++.
* "Intelligent routing" (route discovery, maintenance, shortening, salvaging): this comprises facilities to register and exchange route information between routers running on every agent host, route groups that allow maintenance of routes, discovery of least hop routes and route salvaging.
* "Transaction management" (includes nested transaction management): facilities comprise formation of transaction boundaries across concurrent processes (agents), exchange of transaction data across transaction managers running on agent hosts and commit/rollback operations on transactions.
* "Persistence": library support for persistence enables mapping of agent parameters to data stores and their retrieval when required.
* "Policy management": this includes support for attaching policies at run time to agents and components, and mechanisms for their evaluation at run time.
* "Security": library support for security comprises different encryption schemes for location data, messages and mobile agent code.

The Indus runtime

The Indus compiler family enables step wise but seamless compilation of Indus code to byte code, byte code to C code, and finally from C code to machine dependent executable code.

Indus implementations can therefore execute across a variety of enterprise, mobile and mote platforms from a large number of vendors. On enterprise platforms, Indus agents and components compiled into byte code are managed by the Indus Enterprise container that executes on the Virtual Machine (VM) and is therefore portable to a variety of underlying Operating System (OS) platforms. On mobile platforms, Indus agents and components compiled into C executables are managed by the Indus Micro container that is portable across a number of mobile Operating Systems. On mote platforms, usually 8-16 bit devices, Indus agents and components are managed by the Indus Mote container that is portable across a number of underlying core platform architectures, e.g., the 8051.

Indus containers provide services such as process management, memory management, task scheduling and event management. In addition to container support, Indus Mote utilizes native device APIs for communications (RF, UART, etc), timer and clock, and interrupt management.

External links

* [http://developer.aumeganetworks.com Indus website]