INTEGRATING COMPONENTS INTO OPEN
SYSTEMS
*Jose Mª Troya Linero y Antonio Vallecillo Moreno Dpto. de Lenguajes y Ciencias de la Computación. Universidad de Málaga. Campus de Teatinos, s/n.
29071 Málaga, España. E-mail: {troya,av}@lcc.uma.es
ABSTRACT
The design of components for open systems has led to the study of new systems and their properties, like the independently extensible systems. Most of these systems try to facilitate the design of components by incorporating new features, services and utilities that solve the basic problems of open systems: heterogeneity, partial knowledge of the components, and dynamic changes in the system’s configuration. However, our approach is not focused on the system, but on the components themselves. The present paper defines the properties that components of those systems should have, and introduces a components’ design methodology based on the modular addition of properties.
1. INTRODUCTION
There is now an increasing interest in the study of Open Systems, and in particular in the Independently Extensible systems (Szyperski 1996) as the base for a component market. In this market users are able to buy or rent reusable components off the shelf and compose them to build their applications.
Extensible systems allow new functionality to be added at run time. Independently Extensible systems allow extensions of the system to be developed by different people in ignorance of each other (Weck 1996). In these systems, the key are the software components, individual units that can be reused by any end-user to build up his system. Usually users are third parties willing to compose them without modifications. The study of the properties that systems should have to allow late composition of components is an active area of research, and Component-Oriented Programming (COP) is proving to be a natural extension of Object-Oriented Programming (OOP) for these types of systems. Regarding the components, each one can be considered as an individual unit, with a job to do: its goal. In order to achieve it, the component needs to adapt to the environment of its future user, use the particular resources and services of that system, and be able to deliver its own services to it. Since systems are open, distributed and heterogeneous, the component must face up to the particular problems of these environments: new servers and services may appear, disappear or stop working without previous notification; the component needs to coordinate with other components whose interface is unknown; and of course, delays and errors in the communication medium cannot be underestimated or ignored. There is no longer a global vision of the system; every component has its own local vision of it, probably different from other components’ vision.
So far, most of the efforts have been invested in improving the systems, incorporating the services and facilities that allow components to run on them more easily and to adapt to their changes. Examples of these systems are Hector (Arnold et al. 1996) or ASX (Schmidt 1995), or component architectures as Java™Beans (Sun 1996) or Aglets (Lange and Oshima 1997). In them, the system developer can count on a good set of tools that
*
This work has been partially funded by the “Comisión Interministerial de Ciencia y Tecnología” (CICYT) under grant TIC94-0930-C02-01.
allow a better design and implementation of components. However, all the facilities not directly offered by the system have to be taken over by the components themselves, which forces each designer to add them to its components in an individual fashion and therefore with no guarantee of modularity, portability, or openness. In general, system restrictions must be incorporated, if possible, separately from the component’s code. Hardwiring time or other constraints into the component’s code may bring undesirable results, as mentioned in (Bergmans and Aksit 1996, Ren et al. 1996).
2. OUR PROPOSAL
Our approach is not so much focused on the system itself, but on the components. We need to incorporate the desired properties to them, in a modular and independent fashion. This leads to a methodology for the design of components, whereby components can be designed to concentrate just on their goal (i.e. their computational aspects) without taking into account other particular issues of the systems they will run on. When an end-user buys or rents a component to build up his application, he may buy as well some add-on properties to the component, like time control if his application is time-critical, robustness if his running environment is unsafe, or durability if he pretends to update the component from time to time. In this way, components are designed independently from the systems they will run on, and the components they will compose with. At a later stage, the appropriated properties to cope with the system’s requirements can be added to them. With this in mind, our proposed solution is based on a tripartite structure “components/ add-on properties/systems” instead of the standard pair “components/ systems”. Systems have just to provide he supporting infrastructure for components to work and interoperate among themselves. The add-on properties are abilities that components can incorporate to adapt to the systems. Separating these concerns allows a modular and independent addition of properties to components, contributing to a simpler design.
Car manufacturers design a basic engine and the bodywork, having also available a wide range of standard parts and options that let you configure the car you need: ABS and air conditioning systems, sun-roof and even steering wheel on the right hand side for UK models. These options allow a much simpler design of the car’s core functions while the add-on parts can be designed independently and in a modular fashion too, and incorporated later to the basic car model. In this analogy, systems provide the roads and the petrol stations. Please note that in this market there is not only room for big car designers and manufacturers: small companies can be very competitive designing the car parts and options.
Coming back to the components, we have identified at least three properties: Autonomy, Robustness and Competitiveness. Each one deals with specific problems of the open and extensible systems, like dynamic re-configuration, error detection and recovery, maintainability and adaptability.
On the other hand, we have also simplified the system’s requirements since many of the system’s services can be now incorporated into the add-on properties. Nevertheless, this does not mean that properties do not have be designed without taking into account the final system’s features. In case the end-user system incorporates some features that are part of a property’s function (i.e. service trading or time control), the property should make use of them in order not to duplicate jobs or responsibilities. For instance, the property of Independence for a component running in a CORBA platform should make use of the system’s trading services (Hoffner 1994), but we ought to be able as well to add this property to a component running on a system without these services.
Our approach to the problem leads to two main results. First, to the definition of a general methodology for the design of software components, based on the separation of the component’s core functions and the system specific requirements, and the modular addition of properties to them at a later stage. And second, to a different view of the component’s coordination, where the system is no longer the responsible for the coordination of the components, but the components themselves. Components are not
self-sufficient, and in order to achieve their goal they need to find the appropriated allies and coordinate with them. We have coined the term Self-coordination to describe this concept (Troya and Vallecillo 1997).
The contribution of this paper is twofold. On one hand we have identified some basic properties that allow components to achieve their goals in open and changing environments. On the other hand we introduce an architecture (in the form of a general model and a small set of requirements) to define and implement properties in a modular and independent fashion. Having such a general model facilitates the formal definition of the properties, the uniform design of new ones, and the formal reasoning about them. Being simple and general enough facilitates its implementation on many different systems. To support the model we have built a general framework that allows the definition, design and implementation of properties, that can be added to components by specialization. The framework not only permits the definition of new properties but also the modification of existing ones.
3. THE PROPERTIES
The aim of this section is to describe, in a brief and informal way, the properties that components need in order to cope with the problems of open and distributed systems. We have identified three major ones: Autonomy, Robustness and Competitiveness. Autonomy can be defined as the ability of a component to take its own decisions in an independent way (however, by autonomous we do not mean sufficient or self-reliant). Robustness guarantees reliability and secure access. And Competitiveness provides the component with a general philosophy of survival in terms of a resistance and durability.
Being such a general and complex abilities, the key idea is to define them in terms of the composition of “smaller” basic properties. Thus, we can define the property of Autonomy as the composition of other three properties:
• Independence: The component should be self-governed, able to discover the services it
needs and free to decide the solutions to hire in each situation. Apart from the trading functionality, this property allows a component to select the best of the available options based on the component’s individual preferences.
• Adaptability: The component should be able to accommodate to different interfaces and
protocols, and to changes in the requirements. It has to be composible, flexible, versatile and extensible.
• Self-Protection: The component should protect itself against external failures and
unforeseen circumstances. The component cannot depend on the rest of the components’ behavior and well-functioning.
Robustness is achieved through the composition of three basic properties:
• Integrity: The component has to offer a robust behavior under a variety of
circumstances, different inputs and different uses of its interface, valid or invalid ones. This property may check not only pre-conditions on the incoming messages parameters, but also verify (and put right) the order in which they are received and the time interval between them.
• Secure Access: Every access to and from the component must be authorized. Unlawful
entries and illegal outputs have to be detected and banned. Signatures can be added and later checked using this property, and encryption mechanisms can be used. Laws (Minski and Leichter 1995) can be not only defined with this property, but also enforced.
• High Availability: The component should protect itself against failures in the processes
Finally, Competitiveness can be expressed in terms of other two basic properties:
• Best Effort/Least Losses: The component should try its best to satisfy its users in terms
of response time, functionality and quality of the services provided (Tokoro and Takashio 1993), whilst maintaining its suffering and losses to a minimum when servicing requests.
• Durability: The component has to incorporate mechanisms to be able to be renewable,
keep itself updated and improve over time.
Once they have been informally defined, our aim is now to define a general model that allow us to specify them in a formal way, implement and compose them, and add them to components.
4. THE MODEL AND ITS IMPLEMENTATION
In general, components can be seen as encapsulation of programs. The “capsule” abstracts the program functionality, offers a common interface to the program services, hides their implementation and allows the composition and coordination of components. The idea we use to implement each property is by adding “layers” to the capsule. This is a well-known and accepted mechanism (i.e. see (Gamma et al. 1995)) and good examples of it are the Law-Governed Architectures (Minski and Leichter 1995), the time control for objects (Tokoro and Takashio 1993) or actors (Ren et al. 1996), the Composition Filter model (Bergmans and Aksit 1996) or the layered object model LayOM (Bosch 1996). Each layer acts as an active wrapper that captures and modifies the program’s inputs and outputs, offering to the outside world an interface with the given property. Please note that in our scheme the behavior of a layer is not passive or merely computational as if it were a filter: as a result of an incoming message the layer may send one or more messages to the system, wait for their responses and build up from them the message that will be finally passed to the component. Besides, the layers can be “composed” so the component can have multiple properties or abilities simultaneously.
In this way each layer will implement its property with independence from the component program and from the rest of layers, which allows great flexibility and modularity. It also permits the component to concentrate on its goal, leaving the rest of the “details” to the layers. In that sense, this mechanism helps solving the legacy-systems problem as well. 4. 1 Characterization of Properties
The following definition shows the elements that characterize a given property P.
Definition 1 A property P defined for the components of an open system S is characterized by a tuple:
P = (C, B, E, R)
where C is a set of Components of S that implement the property (since S is open, C can dynamically evolve); B is a set of Controllers, one per each component of C; E is a set of Events related to property P; and R is the set of rules or Strategies that define the behavior of the controllers of B for every event of E.
In this definition we call controllers to the processes that implement the layers. They capture all the incoming and outgoing component’s communication events, should they be messages, RPC’s or accesses to shared blackboards, and modify them according to the strategy implemented by the controller. Strategies define the possible ways the controller of a property may behave (for instance, there may be a conservative and a liberal strategy for a given property). Each controller implements only one of them for each event. The set R contains all the possible strategies for all the events related to the property.
4. 2 Communication Mechanisms
To implement this scheme we need a system’s computational model that allow components to communicate, and define the minimum requirements to do so. We have chosen a very simple one that just contains the functionality required for our purposes. Having a simple and general model will facilitate its implementation in most of the known systems and platforms: Linda (Carriero and Gelernter 1992), Actors (Agha et al. 1994), CORBA (ISO/IEC 1995) or Infospheres (Chandy et al. 1997).
At a low level, our model is based on processes that communicate using message queues (mailboxes). Each component is a multi-threaded process with states. Each state is defined by a set of assignments of values to the variables of the component. The communication between components is asynchronous, and achieved by sending messages to mailboxes.
Each component belongs to its domain: the address of the machine (or net of machines) where it lives. We shall use Internet domains as valid component domains, and name them accordingly. Thus, a component may be running for instance on the domain “@lcc.uma.es”. This allows an easy integration of our model with the WWW and its services, like name servers.
Each mailbox will have a unique global address (mb@domain), given by its name “mb”
and its domain name “@domain”. If the domain is omitted, the current domain name is used. If the mailbox name is omitted, we refer to all mailboxes currently at that domain. This mechanism allows sending broadcast messages to a domain.
There are two basic communication primitives: Send and Receive. The first one sends a message to a mailbox address, and the second one reads a message from a mailbox.
Receive is a blocking operation in case the mailbox is empty, while Send is non-blocking. It is important to note that this model allows the use of formal reasoning methods, similar to the ones outlined in (Chandy and Rifkin 1997).
4. 3 Controllers
Controllers are, as previously mentioned, special processes that wrap the component and modify its behavior. They intercept all incoming and outgoing events by accessing its message queues, and treat them according to their strategy. They are somehow analogous to the object decorators or object adapters (Gamma et al. 1995), to meta-actors (Agha et al. 1994), or to filters (Bergmans and Aksit 1996).
To specify controllers we need to define the messages they deal with and the operations they use to handle these messages. We have defined a general scheme that can be gradually specialized: firstly to specify the controllers that implement each property, and then to particularize them when being added to a precise component in a given system. The more basic scheme of a controller is as follows†:
public class Controller { ...
public void Deliver(Msg m) { // Captures outgoing messages. Outq.Queue(m);
}
public void Received(Msg m) { // Captures incoming messages. Inq.Queue(m);
}
public void TimeoutExp(Msg m) { // Captures timeout conditions. }
}
†
The first method is invoked by the system every time the component wants to send a message out to a mailbox. Method Received is invoked on the receipt of a message and
TimeoutExp allows the controller to know that a sent out message does not get an answer when expected. In general, properties do not need to deal with time; however, they can be aware of these situations with this mechanism.
Once the controller has dealt with an incoming message, its result is put back to the component’s incoming message queue (Inq). Analogously, the controller queues in the outgoing messages queue (Outq) the result of the treatment done to an outgoing message. In case of having several controllers chained together (due to a composition of properties), the end of each Inq.Queue operation causes the invocation of method
Received in the next controller and, analogously, the end of each Inq.Queue operation causes the invocation of Deliver in the next controller.
4. 4 A Framework for Adding Properties
Based on this scheme we have developed a framework for designing, implementing and composing the defined properties. Its structure is the following:
1. On one hand there is the communication basic model, that can be used by any component. Apart from sending and receiving messages, the model incorporates the possibility of attaching controllers to mailboxes.
2. To add a property to a given component it is enough to specialize one of its controllers and attach it to the component mailbox. The framework handles the controllers’ composition and all message passing among them.
3. Every controller specifies the messages it deals with, and implements the three methods above according to its strategy. Some of its classes may be abstract (in Java’s terminology), and specialization is achieved through inheritance and parametrization. As an example, controllers of the property of Independence manage a weighed list of known solutions (pairs service/provider). Although the list and its operations are fully defined in the framework, the component’s preferences (i.e. weights) and its known solutions must be configured when initially instantiating the controller.
4. Each property may have associated several controllers, each one implementing a different strategy. Coming back to the property of Independence, there are different controllers ranging from very conservative ones (that always choose proven and well-known solutions) to liberal ones (that prefer to choose brand new solutions in detriment of the oldest ones). It is the user who decides which controller (only one per property) should be added to a component.
5. IMPLEMENTING THE PROPERTIES
The extension of this paper does not allow the detailed description of the properties defined in section 3. However, we shall briefly mention here the underlying ideas supporting the implementation of each one and in the next section we will describe in more depth one of them.
Independence: The controllers of this property incorporate three mechanisms: i) a weighed list of known solutions; ii) broadcast queries about available services in the system; and iii) the use of publicity to advertise component’s new services or changes in existing ones. These controllers behave as “service brokers” or “traders”, but with additional intelligence: they know their component’s preferences (in the form of weight functions) and use them to decide the services to contract in each situation.
Adaptability: The problem of adaptability is an integral part of open systems, and can be decomposed into two problems: interoperability and extensibility. The controllers of this property behave as “dynamic adapters”, able not only to adapt their
components to different interfaces, but to search in the system for other adapters to new or unknown interfaces.
Self-Protection: The controllers of this property are in charge of watching that the component never waits for a event that will never happen. To achieve this task, they have the information about the maximum time the component can wait for each message, and they manage all pending events.
Integrity: To implement this property, the controllers manage a list of valid conditions for the incoming and outgoing messages. They do all the checkings and also the calling to the rejection procedures in case of invalid entries.
Secure Access: All accesses to and from the component are checked and authorized by the controllers according to the laws they know. Apart from the laws that the controllers handle, they can also search for “local advise” in certain cases; this mechanism allows the implementation of the local and adaptive nature of some laws, since they may vary from system to system. The controllers may be also in charge of adding security mechanisms (signatures, encryption).
High Availability: This property is achieved by the clonation of the component (one or more times), and the monitoring of the availability and activity of the component all the time. The controller may be also in charge of saving/restoring the component’s state when these mechanisms are available.
Best Effort/Least Losses: In case the component offers several method bodies to deal with a message, the controller should decide the body to call in order to minimize the associated cost and to optimize both the response time and the quality of the service.
Durability: The controller should allow the component’s maintainability and updating processes, diverting all component’s events to its designated substitute during these operations.
6. THE PROPERTY OF INDEPENDENCE Let us consider the following problems:
1. We have some amount money P which we do not expect to need for the next two years. Which are the best strategies to invest it?
2. We need to cross by road the country to attend a conference. Which is the best way to do it?
These problems have many things in common:
• They both require services from possibly more than one agent (investment offices,
brokers, real estates and/or banks in problem 1, and different bus, taxi or car rental companies in problem 2).
• The most convenient services depend on factors that change with time (i.e. interest
rates, banks special offers, Stock Exchange situation, or road works, season of the year, etc.).
• Services change, and new ones may appear while other suddenly may disappear. This
means being always aware of the latest changes in our environment.
• Time also influences decisions: time consumed while making up our minds means time
or money lost.
Both are common problems in our real world, a clear example of open and distributed system. How do we solve them there?
In general, we use two different sources of information to solve similar problems: the ones already known and used before, and the ones that we have heard about, but never used. We trust the first ones, but we need to be aware of the changes in our environment (the markets, the roads) as information gets obsolete very soon. We try to use a known
solution unless it is no longer valid or a new one has recently appeared that outweighs by much our known solutions. And in case none of the known solutions is applicable, we also know how to ask (to neighbors, friends, the police) for valid solutions to our problem.
This ability of finding out the service providers we need, together with the faculty of freely selecting one among them (the best, according to our own criteria) gives us the property of Independence. The following is a description of the elements of the tuple that characterize this property.
6. 1 Controllers or “Service Brokers”
In case of the property of Independence, the controller of a component is in charge of finding out and managing the services that the component needs. For this reason we also call them brokers. By delegating these tasks to the controllers, the components become independent from changes in the services of their environments. The use of an individual broker attached to every component instead of general service agents allows the customization to the component’s preferences and it also avoids the dependence to a general or centralized service agent.
Please note that we are not against the centralized or federated agents: if they exist the controllers may use them in order not to duplicate jobs and responsibilities. However, we think that controllers have to be implemented on individual basis to achieve the desired components’ independence.
For a better understanding of the role of a controller of this property, let us think of the problems described at the beginning of this section. The notion of controller corresponds to the investment broker in problem 1 and a travel agency in problem 2. Another idea is the efficient secretary: a senior executive needs to hold business meetings in different countries; he can leave all the travel and accommodation details to his secretary who knows his preferences and uses them when contracting flights, hotels, etc. She can be aware and avoid airport strikes, make use of hotels’ special offers and so forth, while the executive can concentrate on his business.
To accomplish their mission, the controllers of this property implement the following mechanisms:
a) Management of a weighed list of known Solutions. b) Broadcast Queries.
c) Asynchronous distribution of Publicity.
The first one is a list of known solutions to the controller. Services are included in this list because they have been previously used or because the controller has received some information (advertisements) about them. For every service in the list the controller keeps all the relevant information about it: its provider, interface, current status (on-line, out of order,...), pricing information, etc. Together with the list there is also a weight function that assigns a cost to every service and that depends on the particular component's preferences. This weight function allows the controller to compare different solutions and take decisions on which one select.
Regarding the broadcast queries, they are issued by the controller when either the component requests a service unknown to the controller, there are no available solutions in the list at that moment, or to periodically update the list. The meaning of the word broadcast used here does not necessarily imply that the message should reach every component in the system or that every component should respond to it; in fact, the component does not know (and does not care about) how many other components live at this moment in the system. By broadcast we mean “to whom is listening to me, understands my message and may be interested in it”.
The concept of publicity refers to the information exchange between controllers that allow them to keep their lists up-to-date. This exchange is achieved through asynchronous messages describing new services or changes in existing ones.
These mechanisms, together with the weight functions, allow components to always contract the best solutions in a transparent way (through their controllers) and without depending on any other agent or component.
Please note that the property of Independence is something more than service trading: one of the key issues is the “intelligence” of the controller, which can take decisions on the services to contract based on its preferences (by means of the weight functions).
6. 2 Related Events to the Property of Independence
The outgoing events related to the property of Independence are the service requests to other components in the system. The incoming events are the responses to that requests, the queries about the services offered by the component (direct or broadcast) and the asynchronous information received advertising other components’ services.
Please note that service requests received by the component are events not related to the property of Independence.
6. 3 The Strategies of R
These are the different rules used by a controller to decide which solution to contract and how to maintain updated its list of solutions.
In order to decide the solution to contract, a conservative controller will always select a known one, unless it is out of order or has terminated, giving little weight to previously unused solutions. A more liberal program will select always the best of all the solutions it ever heard of, giving little or no importance to the previous history.
Regarding the received publicity, the controller may bin it all and ask for a solution in the moment it is needed, or use it to have always an updated list of solutions. Advertising the component’s services can be also done in different ways: either the controller never sends anything and only answers the broadcast queries received, or it may decide to periodically send information to keep updated its neighbors' lists.
As we can see, there are many possible ways of implementing these mechanisms. The set R for this property collects all the strategies for all the events related to the property of Independence, but it is a (component) design decision to chose which strategy to select for every event for a particular component.
6. 4 An Example
The following example shows a controller implementing the property of Independence. Let us suppose a component C in domain @dom that wants to go from city X to Y next 31/12/1997. Using our model, component C just sends a message to its usual travel agency myTA@dom:
msg.To = "myTA@dom";
msg.Subj = "ServiceRequest: getflightticket"; msg.Info().Serviceid = "getflightticket"; msg.Info().Params().from = "X"; msg.Info().Params().to = "Y";
msg.Info().Params().when = new Date(1997,12,31);
Let us suppose as well that C incorporates the property of Independence, and let BI be the controller implementing this property for C. Thus, message msg will be intercepted by BI
before going out, that can take the following actions with it:
a) If service provider myTA@dom is in the list of known solutions for this service with the highest weight, BI will simply let the message go out.
b) If service provider myTA@dom is in the list of known solutions for this service, but not with the highest weight, BI, depending on its strategy, can either:
− let the message go out (very conservative strategy),
− let the message go out only if the difference of weights with the best solution in
the list is not big, otherwise replacing myTA@dom with the best in the list (conservative strategy), or
− replace myTA@dom with the best provider of the list anyway (liberal strategy).
c) If myTA@dom is not in the list, BI will replace it with the best in its list. In case the list is empty, BI will try the service provider proposed by C.
This is shown in the implementation of BI’s Deliver method:
bestprovider = TheList.Best(msg.Info().Serviceid,msg.Info().Params()); if (!bestprovider.equals("")) {
w1 = TheList.Weight(bestprovider,msg.Info().Serviceid,msg.Info().Params()); w2 = TheList.Weight(msg.To,msg.Info().Serviceid,msg.Info().Params()); if ((w1-w2)>Preferences.WeightDiff) msg.To = bestprovider;
};
Outq.Queue(msg);
Once the destination component services the request it will reply to C with the result of the service. The reply message will be intercepted by BI, that will update its list with this information within the Received method:
...
TheList.Update(m.Reply,alive,m.Info().Serviceid,m.Info().Params()); Inq.Queue(m);
...
If component C never gets the answer and it also incorporates the property of Self-Protection, the system will call the TimeoutExp method of BI, that will register this fact:
TheList.Update(m.To,outoforder,m.Info().Serviceid,m.Info().Params());
And then it will look up for an alternative provider: first in its list and, if no one is known, the controller should search in its environment for one. This mechanism, shown below, has to be also implemented by the controller to cover the cases where any problems with the server are detected: not only no response from it, but also communication errors (invalid address, hardware faults,etc.).
bestprovider = TheList.Best(m.Info().Serviceid,m.Info().Params()); if (!bestprovider.equals("")) m.To = bestprovider;
else {
msg.To = ""; // broadcast to the domain
msg.setInfo(m.Info()); msgref = Mbox.Send(msg); do {
rep = Mbox.Receive();
TheList.Update(rep.Reply,alive,rep.Info().Serviceid,rep.Info().Params()); } while (rep.RefTo != msgref);
m.To = TheList.Best(m.Info().Serviceid,m.Info().Params()); };
Outq.Queue(m);
Please note that in this example we take the first provider that answers our broadcast query. Other Independence controllers may implement different strategies, like waiting for at least three responses and taking the best of them, or just waiting for a while and selecting the best of the answers received during that period.
In case C did not specify the service provider of a message (i.e. msg.To.equals("")), BI
would let the message go out unmodified. 6. 5 Configuring the Controller
Apart from the three methods described above, controllers also incorporate some variables and functions that allow their parametrization according to the user’s preferences. In this section we present two of the configuration methods offered by the controllers of Independence:
• void AddSolution(ListItem x)
This method includes a component’s known solution in the controller’s list. The
ListItem class contains the ServiceId and the parameters of the service, the name of the service provider, and its status (alive, unknown or outoforder). The service provider can be set to null, indicating that this service is offered by the component itself (the controller should also know about the component’s services to advertise them).
• void MyPreferences(IndependenceDP P)
This method sets the component’s preferences by means of the special class
IndependenceDP (DP stands for “Default Preferences”).
Class IndependenceDP contains all the controller’s parameters, and some of its methods are described below. Although the controller has a defaut value for them, they can be overriden to set the component’s preferences:
• boolean IsRelatedToIndependence(Msg m, boolean isincoming)
This method allows the controller to decide whether a message is related to the property or not, that is, with this method the user can specify which messages are captured by the controller.
• float Weight(ListItem x)
This method assigns a weight to an item in the controller’s list. This method is used by the controller to discriminate between registered services in the list.
• boolean DoISendPublicityNow(int nummsgrec, int nummsgtx)
This method is invoked by the controller itself to decide when to send publicity about the component’s services. Its parameters are the number of messages transmitted and received by the controller.
7. RELATED WORK
The idea that originated this work was born from the original papers from (Tokoro and Takashio 1993), and from (Minski and Leichter 1995). The former one mention real time, asynchrony and autonomy as key issues in open and distributed systems, but only deal with the first two concepts in their paper, without paying attention to autonomy. On the other hand, the law-governed architectures are introduced in (Minski and Leichter 1995), a one-property scheme that we have extended and generalized to give birth to our general model.
The use of a Component Framework as a “whitebox component that reveals part of its internal configuration, establishes configuration rules, and may enforce some of these rules” (Weck 1996) fits like a glove to our proposed model. It is not the typical framework for the development of open and distributed systems and applications, as in the case of Hector (Arnold et al. 1996), ASX (Schmidt 1995), Java Beans (Sun 1996) for stationary systems, or Aglets (Lange and Oshima 1997) for mobile ones. Our framework goes in a different direction: it provides the support to our methodology for designing components.
Regarding the properties, there exist a lot of literature about them in the field of Artificial Intelligence, where heated discussions take place about the precise definition of autonomous agents and their properties (Franklin and Graesser 1996). However, apart from various informal definitions we do not know of any work in that or any other field that formally defines them as we do. Nevertheless, the properties mentioned here are well known and many systems and components already implement them. However, as we mentioned before, they are usually hard-wired in the components’ code, or are inherent part of specific systems. The model we have introduce here has proven its powerfulness by being able to specify all of them in a natural way, and implement them in an unified and modular fashion.
Neither the layered model or the communication mechanism based on mailboxes try to be a novelty, but to be functional, general and simple enough to be implemented without major problems in other systems or paradigms, like Linda, CORBA, Actors, Infospheres, LayOM, COM or Oberon-2 (Mössenböck 1995), to cite several possibilities.
Layered models are well known and widely used. Apart from the “Home Processes” for Linda (Minski and Leichter 1995) and the time control for objects (Tokoro and Takashio 1993) in the two aforementioned papers, we can also cite the time control for actors (Ren et al. 1996), the Composition Filter model (Bergmans and Aksit 1996), the layered Object Model LayOM (Bosch 1996), COM’s aggregation or the usage of message handler procedures in the Oberon-2 system. It is important to mention that our layers are not mere filters with delay capabilities at most but more active, able to interrogate the system’s components and to take decisions based on the component’s preferences, more in the style of software adapters (Gamma et al. 1995). The model of processes that capture and modify the communication events of the components is completely reflective, as meta-actors (Agha et al. 1994) or filters (Bergmans and Aksit 1996) are. A good description of different reflective models can be found in (Manola 1993).
Finally, the only special concept used in the communication mechanism is the broadcast facility for domains, in the line of the ideas of Gehani (Gehani 1988) and ActorSpaces (Agha et al. 1994).
8. CONCLUSIONS AND FUTURE WORK
COP aims at producing software components for a component market and for late composition. While most of the efforts are now put on the development of better systems that facilitate the design and composition of components, we have focused on the components themselves and presented here a component framework that supports a design methodology based on the late addition of properties to components. Components are then designed to achieve only their core functionality, leaving the rest of the concerns
to the add-on properties that will be incorporated at a later stage if needed. This not only simplifies their design but makes them more reusable.
A set of basic properties has been defined, each one dealing with a specific problem in open systems. Besides, a general model for defining and specifying properties has been introduced. Having such a framework not only offers a platform to formally define components’ properties, but it also allows to reason about them.
Currently the properties mentioned here have been specified and a prototype of the complete framework in Java with their main strategies is almost ready. We have chosen Java and the Internet as its first platform because of its wide use, the facilities it offers, and for being a good example of a real open system in which to test our model. Once the prototype is finished, we plan to work in three different lines: first, in a formal specification of the properties that allow the automatic development of prototypes for their controllers. Second, in the implementation of the model in different systems and platforms. And last, but not least, in the development of a language that allows the specialization of the controllers to particular systems and configurations.
9. REFERENCES
G. Agha, W. Kim and R. Panwar. “Actor Languages for Specification of Parallel Computations”. In DIMACS, 1994.
D. Arnold et al. “Hector: Distributed Objects in Python”. In Proceedings of the Fourth International Python Conference, Livermore CA, 1996.
K. Arnold and J. Gosling. The Java Programming Language. Addison-Wesley Longman. 1996.
L. Bergmans and M. Aksit. “Composing Synchronization and Real-Time Constraints”. In JPDC, No. 36, pp. 32–52, Academic Press Inc., 1996.
J. Bosch. “Language Support for Component Communication in LayOM”. Presented at the ECOOP’96 Workshop on Component-Oriented Programming (WCOP’96), 1996.
N. Carriero and D. Gelernter. “Data Parallelism and Linda”. In LNCS, No. 757, pp. 145-159, Springer-Verlag, 1992.
K.M. Chandy and A. Rifkin. “Systematic Composition of Objects in Distributed Internet Applications: Processes and Sessions”. In Proceedings of the 30th HICSS, Hawaii, 1997.
K.M. Chandy et al. “A Framework for Structured Distributed Object Computing”. California Institute of Technology. Submitted to Comms. of the ACM, 1997.
S. Franklin and A. Graesser. “It is an Agent, or just a Program?: A Taxonomy for Autonomous Agents”. In Proceedings of the Third International Workshop on Agent Theories, Architectures and Languages, Springer-Verlag, 1996.
E. Gamma et al. Design Patterns. Addison-Wesley, 1995.
N. Gehani. “Broadcasting Sequential Processes”. In Concurrent Programming, edited by N. Gehani and A. McGettrick, Addison-Wesley, 1988.
Y. Hoffner. “A Designer’s Introduction to Trading”. APM Technical Report APM1387.01, Architecture Projects Management, APM Ltd., Cambridge, UK, 1994.
ISO/IEC 10746–1 to 10746–4. Reference Model of Open Distributed Processing. Draft Rec. X.901 to X.904 ISO/IEC JTC1/SC21/WG7, May 1995.
D.B. Lange and M. Oshima. Programming Mobile Agents in Java – With the Java Aglet API. IBM Research, 1997.
F. Manola. “MetaObject Protocol Concepts for a ‘RISC’ Object Model”. Technical Report TR-0244-12-93-165, GTE Laboratories Inc, 1993.
N. Minsky and J. Leichter. “Law-Governed Linda as a Coordination Model”. In LNCS, No. 924, pp.125– 146, Springer-Verlag, 1995.
H. Mössenböck. Object-Oriented Programming in Oberon-2. Springer, 1995.
S. Ren, G. Agha and M. Saito. “A Modular Approach for Programming Distributed Real-Time Systems”. In JPDC, special issue on Object-Oriented Real-Time Systems, 1996.
D.C. Schmidt. “ASX: An Object-Oriented Framework for Dynamically Configuring Extensible Distributed Systems”. BSC/IEE Distributed Systems Engineering Journal, 1995.
Sun Microsystems, Inc. “Java™ Beans: A Component Architecture for Java”. White Paper. http://splash.javasoft.com/beans/WhitePaper.html, 1996.
C. Szyperski. “Independently Extensible Systems – Software Engineering Potential and Challenges–”. In Proceedings of the 19th Australasian Computer Science Conference, Melbourne, 1996.
W. Weck. “Independently Extensible Component Frameworks”. In Special Issues in Object-Oriented Programming –Workshop Reader of the 10th European Conference on Object-Oriented Programming ECOOP’96 in Linz. Max Muehlhaeuser (ed.). Dpunkt Verlag, Heidelberg, Germany, 1997
M. Tokoro and K. Takashio. “Toward languages and Formal Systems for Distributed Computing”. In LNCS, No. 791, pp. 93–110, Springer-Verlag, 1993.
J.M. Troya and A. Vallecillo. “An Open System Model based on Self-Coordinating Components”. Technical Report ITI-97-3, Dpto. Lenguajes y Ciencias de la Computación, Universidad de Málaga.
