A particular problem for the design of distributed systems is the coordination of the components in such a system. Often it is useful in terms of extensibility and modularity to separate the interaction (usually called the protocol) from the components.
If you use this technique not just for the specification of an interaction but also for the implementation you will do - what I call - interaction-oriented programming. To understand the difference more clearly, regard the illustration on the left side. In typical implementations an interaction is just a concept in the mind of the programmer which is expressed as communicative actions
which are distributed among the components. This means, if you want to understand what is going on on the system level (and not on the component level) you will need to inspect the code of each component involved. In interaction-oriented programming (cf. the illustration on the right side) the interaction is a separate component containing the communicative actions. The participating components are connected to the interaction via roles. Thus there is no direct communication between the components. This concept makes it also easy to change the interaction or to add new components.
LoI ("Language of Interaction") is an experimental application language, which was designed to support IOP. LoI was developed with two goals in mind: On the one hand the language had to be powerful enough to implement protocols in reactive systems and on the other hand the interactions should serve as sources for interface generation (in the spirit of interface definition languages) faciliting the development of agents which perform a role in the protocol. For the achievement of the first goal, it was necessary to offer the means of modern programming languages. The other goal meant, that the flexibilty of the language was limited by the ability to derive interfaces from the communicative actions.
LoI is complete in the sense that you can also develop agents in LoI. But, this is not really encouraged for complex agents, as the module system is more suited for having a large number of small processes than one big process with complex data structures. There is also the silent assumption that those agents will be prgrammed in Java, as the forthcoming compiler will generate Java code. But other code generators might also support other languages.