[New Zealand Digital Library] [Computer Science Technical Reports] [Query Results] ---------------------------------------------------------------------------- 1. Introduction A distributed system can be viewed as a collection of objects working either in cooperation or independently for different tasks. Some of the objects represent execution of algorithms, others represent resources needed to perform the execution, still others represent data manipulated by the algorithms. Collections of objects working together can be modeled in different ways. The client-server model is commonly used in the context of distributed systems, as also cooperating objects. In the client-server model the computing task is divided into modules working together in behalf of the human user. Clients interact with the user and request partial tasks to be performed by the servers. The servers can be general, multi-threaded processes that have no stable knowledge about the status of the task. The server can thus offer either execution of algorithms or stable storaging of information. Depending on the nature of servers, the client has more or less freedom in the phase of binding to server instances. In the model of cooperating objects, the objects are peers. The algorithm of performing the given task is distributed so that the objects can simultaneously compute partial tasks, exchange partial results and thus complete the given task together. Each object also stores part of the status of the task. The client-server model is commonly accepted but it has some problems. One of them is the division between client and server modules so that the computing task can be performed efficiently. The servers should be general enough to be useful in different application areas. Another important problem, although less discussed, is the problem of efficient and flexible binding of servers to clients. This problem is already present in single application systems, where exists functionally identical servers. Especially difficult the problem is in open distributed networks where a computing or transmitting service is offered by almost identical servers for different costs. The same problems occur also in cooperating objects model. Both methods also have the difficulties generated by the distribution: differences in naming schemes, authorization problems and asynchronous faults. Several methods has been introduced to answer these problems. Directory servers offer a way to find the servers or objects and they also help in the name resolving by forcing a global naming scheme. Authorization servers can be used to allow cooperation between different computers in a secure way. As these methods have been used together with remote execution but not properly combined into the remote execution service, the result has not been satisfactory. The latest development is the scheme of trading. Trading should answer to the open question of autonomy in naming, finding the best server at the moment it is needed and the problem of handling slightly different interfaces of servers. 1 ---------------------------------------------------------------------------- In this paper we present a trading system. First, the functions possibly belonging to a trading system are discussed and arranged to a trading taxonomy. The functionality of the Dryad trader is shown based on the taxonomy. Finally, the system structure is described. Facts on the project Dryad are described in Annex 1. 2. Introduction to trader functionality 2.1. System model Trading is based on the model of clients and servers. In this model, a trader is usually considered as a neutral intermediate module between clients and servers [APM92, ODP92]. Servers announce their properties in export messages to the trader and the clients request the trader to search through the service descriptions for what they need. Capabilities of servers are described using attribute values that are stored into the trader data storage. The needs of the clients are passed to the trader in import messages as search criteria consisting of limitations on the attribute values. When the trader has found a suitable service offer matching the client's request, it passes the address of the server to the client, or invokes the server. Trading can also be considered as an enhanced form of naming and binding. In trading the name of a service may be replaced by a description of the desired properties of the server. The components of the descriptive name could be, for example, type or behavior of the server, descriptions of required or desired properties, constraints on some properties and relative location of the server (relative to the users location). This attribute based naming may be used in a user friendly manner. Examples of this naming scheme can be found in [Neu92]. Traditional binding forms a fixed one-to-one relation between a name and an address. In trading, a "name" may be resolved to many alternative addresses. The resolution rule is fixed but it utilizes dynamic data on addressees. When trading is considered as a form of dynamic binding the addressee may be viewed as a persistent object as in [OMG91] or the binding operation may heavily trust on dynamic, virtual attribute values of a looser group of objects as in [ODP92, WoTs91]. The OMG approach sets up first the group of services to be offered and then creates a persistent distributed object for each service to guarantee the accessibility of the service. The service object may be aware of several server instances. In the latter approach the knowledge of existing server instances in a distributed system is stored directly in the trader. The availability of a service is not guaranteed by the trading mechanism itself. Trading actually transforms the model of client - server to a model of client-service. The goal in this transformation is to releave the clients from localizing the servers they need. 2 ---------------------------------------------------------------------------- 2.2. Trading as a system function When pondering about the purpose of the trader, two different views can be adopted: It may be desirable to form a building block for other functions in the system (Figure 1). System functions, including trading, are equal modules that can request services from each other. On the other hand, it may be desirable that the trader serves as an additional layer in composing of objects (Figure 2). The purpose may be to form an intermediate, invisible module that collects together other system functions to a consistent combined service offered to the application layer. operating systems applications system functions, trading among them Figure 1. Trading as an additional function in the system structure. trading function operating systems applications including system functions Figure 2. Trading as an unifying layer for other functions in the system structure. 3 ---------------------------------------------------------------------------- The ODP group is forming a standard on the trading function [ODP92]. They have included the trader into the ODP model of distributed systems. The ODP Reference Model provides a description of the functions required to achieve Open Distributed Processing [ODP93]. The model introduces - management functions (nucleus, object, cluster, capsule, communication domain and interface reference management functions) - transaction function - group function - repository functions (storage, relocation, type repository and trading function) - security functions (access control, audit, authentication, confidentiality, integrity and non-repudiation functions). These functions are required to support distribution transparency, that includes some of the following: - access transparency - transaction transparency - failure transparency - federation transparency - migration transparency - group transparency - resource transparency. As the RM-ODP defines trading as "the interaction between objects, in which information about new potential contracts is exchanged via a third party object" [ODP93], there is no explicit requirement for transparency functions in trading. Although, other functions may use trading as a building block to offer transparent services. The model looks similar to that of Figure 1. An example of a trading model the model of Figure 2 gives the Dryad trader, introduced later in this paper. Dryad trader is more like an action management function. The trader offers invocation of objects' actions or methods, but not necessarily any transaction management features. Transactions may be formed between objects if their action behavior includes them. Action management function of the trader offers access, failure, federation and group transparency. 4 ---------------------------------------------------------------------------- 2.3. Role of the trader in system behavior When considering the utilizability of trader, the services offered by the trader itself are most important. The basic task of the trader is to select the server matching the selection rules given by the client and some policy rules. Depending on whether the trader uses both user given and internal selection rules or only one of those, the trader adopts different roles in the system. The tasks of the trader may also include invocation of selected servers, or reserving resources for the invocation so that the invocation is guaranteed to succeed. The trader does not necessarily know any suitable server for the client, but it may be possible to combine different servers together serially to offer the requested server. Also the data available for the server selection in trader affects on the role of the trader in the system. The trader handles the server data as objects that include attributes describing the server interfaces, availability and status. An attribute is either static or dynamic. A static attribute value is only evaluated once, but dynamic values are re-evaluated following some policy. Thus the dynamic values may be somewhat out-of-date values. If the value is evaluated at every reference it is said to be reliable, otherwise it is unreliable. In a distributed system the values are always a little old, because of the delay of delivering them to the trader. In the implementation of the trader, differences on the reliability of the values may be achieved either by active evaluation and periodical delivery of values by the servers or by by-demand evaluation activated from the trader. The trader also has the problem of missing attribute values. If the dynamic values are not reliable, they may be unavailable at server selection time. The data of servers may also contain mandatory and optional attributes. Of course, the trader can not trust values for optional attributes to be present from all servers. The trader has optional methods of collecting data needed in server selection. The ODP style [ODP92] is that the servers themselves send the attribute values on the export messages. When the values change, the trader either does not know of the change and operates on the old values, or the server must do a new export operation. The responsibility may also be set on the trader. Each time it needs a value, it asks for it from the server. This may be optimized with caching. The source of the attribute values of a server can also be derived from other sources than the server itself. Most of the applications in use today are not able to response into queries themselves, but there is other applications or servers collecting data and giving out values. These sources can be active server processes continuously running in the system, executable programs, text files or databases. To the service interface of the trader also belongs the language on which the clients may express the selection rules of the servers. That language uses attributes and operations on attribute values. Operations include at least simple comparations, both for strings and numericals, boolean values and logical operation (and, or, not). Belonging into a group is a helpful operation in the group of arithmetic operations 5 ---------------------------------------------------------------------------- (+,-,*,/, mod) as well as less restrictive operations like "looks rather similar to". Some functions are handy: maximum, minimum, average, cost of trading operation. Interesting effect could possibly be obtained if the logical operations contained the value "may be". The language can allow the client to express the selection rule as a set of separate selection criteria, each criterion attached with a priority. The priority divides the rule in two parts, requirement and preference. The trader is not allowed to offer the client a server not fulfilling the requirement part. But, if there is no servers available fulfilling all preferences, a server that fulfills all requirements and most of the preferences, is allowed to be offered. The selection criteria is evaluated in priority order as far as there is at least one server left. In the ODP trader description, the requirements and preferences are called matching constraints and selection criteria [ODP92]. Six different roles of trader is presented: match maker [MuVi85?], dispatcher, trustee, consultant, coordinator [WoTs92] and secretary. Match maker works on compulsory, static data, while the others can utilize also dynamic values. Match maker is the simplest trader system and for example directory servers can be utilized as such. Dispatcher and trustee both do the selection on one selection rule source. Dispatcher follows the internal rules, while trustee only depends on the rules of client. Consultant and coordinator uses both sources of instructions, and the difference is in the order. Consultant lets the client select from the group of servers allowed after using the internal policy rules. Coordinator has some internal scheduling rules to select between the servers accepted by the client. Using priorities in selection rules, we can combine the roles of consultant and coordinator to still another role, secretary. A secretary trader limits the group of servers within which the clients may freely select the desired server. It also helps to schedule task, if the clients do not fully define the server selection. 2.4. Cooperation between network nodes and organizations The trader at a trading domain can be either a centralized, replicated service or a distributed server. The basic idea is to have one trader in each organization where the size of the organization may vary from one host machine to hundreds of computers. A distributed server offers simultaneously services from different nodes belonging to the trading server. The load of import requests is divided or balanced between these nodes. The trader nodes must exchange information to notify of the changes in the system status they cause by scheduling tasks on servers. If some of the nodes fail, the working nodes can continue and divide the load among themselves. The division of load can be done per service type basis or by clients or the whole information pool can be shared. If the organization if considered rather small, the centralized, replicated trader is convenient. From the computers of the organization a few nodes is selected to maintain the trading service. Only on of these nodes is actively serving at a time, but when a failure occurs, the replicas elect a new server among themselves. The protocol among trader modules is simpler and less expensive, but the load balancing and division is more difficult in comparison to using a distributed trader. 6 ---------------------------------------------------------------------------- To be able to maintain small, cooperating organizations, the scheme of federating traders is important. Federation means, that each trader can independently manage the servers in its domain, but traders may offer their servers to be used via remote traders and also request services for their own clients from remote traders. A distributed trading server could also be seen as a federation of centralized traders, that have only one replica in an organization with one node. Although, in the federation model, agreements on the cooperation are needed and thus there is a mechanism of restricting the behavior of remote clients (Figure 3). c o n t r a c t client server client server client trader server trader organization 1 organization 2 Figure 3. Federating traders. 2.5. Responsibility aspects As the trading service is rather central to the usability of the system, the trader itself must be trustworthy. The services of the trader must be continuously available and fault tolerant. The trader is not suitable for hard real time systems, as the related goals are contradictory. Late binding required for flexibility and fault tolerance does not allow hard deadline scheduling. The mechanism of the trader itself can be done reasonably fault tolerant, but the trader cannot guarantee the behavior of the servers. The trader has very little knowledge about the right behavior of the server, and thus the trader is unable to tell whether the server is working correctly. If the trader receives a "fault indication" from the invoked server, there is means to "restart" the service by selecting another server and invoking it. As it was already mentioned, the trader has no means to automatically measure the 7 ---------------------------------------------------------------------------- behavior of the servers, it has also no possibilities to assure that the exporters follow the service description. If the trader allows any server export services, Trojan horses are easy to install. If the trader is closed and only indicated servers are allowed to export services, some manual quality control can be done beforehand. Beside trustworthiness, also security is essential. Access control and authentication can be combined to the trading functionality, if invocation service is offered. These features can be implemented using other system functions native to the underlying system architecture. Of course, much of security checking responsibility is placed on the client and server modules. If these don't care or are unable to perform actions needed in the authentication protocol, the trader system can not make the environment more secure for them. In federation and some other situations, the trading system may act in behalf of an "trusted" client, for example, vouch for the client for a remote trader. 2.6. Interfaces For the effective use of trader, the range of interfaces is important. There is two different modes of trader usage: explicit trading (Figure 4) and implicit trading (Figure 5). Explicit trading is familiar from the ODP Trader Model [ODP92]. It follows the example of RPC mechanism. The client module directly sends import messages, describing the needed service, to the trader and waits for replies. After receiving the address of the selected server in the reply message, the client contacts the server directly. It is also possible that the invocation of the server is done from the trader, but the custom of using a separate description-to-address translator has become prevalent. In implicit trading there is an agent that formulates the import request on behalf of the client, describing the requested service. The agent also receives the reply from the trader and is able to smoother the differences of interfaces. It is a natural way to hide the description-to-address translation into the server calling modules. server 1 server 2 server 3 trader appli- cation application interface RPC calls for trader Figure 4. Explicit usage of trading. 8 ---------------------------------------------------------------------------- . application interface server 1 server 2 trader reactive virtual server object RPC calls for trader appli- cation Figure 5. Implicit usage of trading. In the implicit trading model, the clients are offered a group of virtual servers. They see a group of nicknames of service descriptions and they can utilize these services as they would utilize any local servers. A server is traditionally implemented as a file. An execution server needs a program file to run, a resource needs data describing the status of it and also an execution server to utilize the resource. Also information stored into the system is a service - it may be utilized as a file as it is or it needs an execution server to offer the information (database systems). In implicit trading the traditional server objects are replaced with reactive server objects. When a reactive object is requested for service it may in turn request services for other objects. In this case, the virtual server object makes a service call towards the trader. Technically the interface to the server object is preserved as a file system interface. When the service object is requested, it activates and communicates with the trader to process the current status of that requested server object. In this processing policies of load balancing and authority control can take effect, as well fault tolerance of the services may be increased. 2.7. Taxonomy The above discussion leads us to a taxonomy of trading functionality, presented in Figure 6. The user interface axis represents a conclusion of section 2.6. about interfaces. Management an responsibility are related to sections 2.5 of responsibility aspects and 2.4. of cooperation between network nodes. Section 2.3. about role of the trader is viewed as axes called "services of the trader", "language of server selection criteria" and "role of the trader". Also the axis of "cooperation" is desctibed in 2.3. but also in 2.4. 9 ---------------------------------------------------------------------------- cooperation working alone monitoring of the servers responsibility on client on trader language of server selection criteria dynamic attributes static attributes simple comparisions management integrated user interfaces modifications of service interfaces selection invocation reservation of resources role of the trader dispatcher consultant coordinator match maker aritmetics approximate comparisions criterion with priorities fault tolerant explicit trading implicit trading of virtual servers interactive interface for humans services of the trader on client and server federated collector of information actively requests for information separate trustee secretary Figure 6. Taxonomy of trading functionality. 10 ---------------------------------------------------------------------------- 3. Introduction to DRYAD In the following chapters the Dryad trader is introduced. We have used the following terminology: By an (end) user we always mean a human user. The computing environment is represented by clients and servers sharing the computing tasks given by the user. The trader is placed between clients and servers in order to relieve the clients from locating the servers. A client is a program or a process working for the user and a server is a program, a process, a resource or an information object (for example data describing a user). Client and server only denote the roles of application modules in relation to the trader. The same application module can play both roles. To the end user two different methods is offered to for exploitation of the capabilities of the trader. The first method is interactive usage by means of specific user interface software. The user may run this software on his own terminal and it interprets the user's choices into a form understood by the trader. Servers may be shown as lists, each server may have its description shown, the user may inquire different attribute values and make search operations. Only a few concepts are introduced to the user: service class, service and property or attribute of the service. Service classes are groups of servers that can conveniently be described using same attributes. Servers inside the class are identified by different values of these attributes. The alternative method of utilizing the trader is to weave trader calls into applications. The end user may not necessarily know that the application he is using exploits trading and thus no new concepts are introduced. At the application level trading can be exploited either explicitly or implicitly. 3.1. Trader model The Dryad trader model is illustrated in Figure 7. In the model the requirement on servers and clients caused by trading are minimized. On the server side, servers are categorized as active and passive, and the responsibility of acquiring the needed information in the trading decision process is placed on to the trading system itself. To the client side, the implicit trading method has been added to move the responsibility of expressing the server selection criteria in some situations from the client to a "secretary process". On the application level the communication between the application and the trader can be explicit. The application programmer uses direct calls to the trader and can also interrogate the user to collect all information needed before calling the trader. This style is used for example in the interactive user interface mentioned earlier. Other examples could be a desktop publishing system requiring knowledge about available printers and a statistical analysis system searching for free processors for massive computations. Explicit trading is illustrated by user E in Figure 7. 11 ---------------------------------------------------------------------------- If the application program is unfamiliar with the trading concept or it is desirable to hide the description-to-address translation, the explicit trading method is unsuited. Into the application the programmer can traditionally code references to a server names (program, resource names) he presumes to exist. Thus, on the application level there is no knowledge about the trader, but the exploitation of trading takes place on the level of the underlying system. The supposed server names are interpreted as virtual servers. The references are interpreted by a "secretary process" (called Daphne) and translated to service requests for the trader. The Daphne process collects the needed trading information from user specific trading profiles and virtual server specific trading profiles expressing the user and system requirements for the server to be selected. This method, implicit trading, is illustrated by user I in Figure 7. end user I trader end user E virtual server trading profile: system requirements "secretary" (Daphne) active server passive servers proclamation service request service request sources of data: system calls, directory servers, databases personal trading profile: user requirements external server sources: traders, directory servers service request client client virtual server local server call Figure 7. Overall system structure of the Dryad trader. As discussed before, the servers can be categorized as active and passive servers. Active servers are continuously running servers i.e. processes that usually start at the system startup time. Passive servers are activated through active servers. For example, a database server is an active server and normal program files are passive 12 ---------------------------------------------------------------------------- servers. Active servers proclaim themselves to the trader when they are started. They may also proclaim the group of passive servers they are responsible of. When an active server is closing down it withdraws itself and its group of passive servers from the trader. The proclamation of servers differs from the export operation in ODP traders [2]: the proclamation only contains addresses and types of the servers, but no attribute values. It is not necessary for the servers to be able to declare their attribute values. Instead, rules for the evaluation of these attributes are stored in the trader database. These rules may include for example normal operating system calls. By using proclamations instead of exports we allow servers that are passive or not knowledgeable enough to cooperate with the trader. We also achieve more up-to-date attribute values with less overhead, as the trader is able to re-evaluate the values only on demand. 3.2. Plans for functionality From the taxonomy point of view (Figure 6), we include virtual server interface as well as explicit trading. We also offer an interactive user interface for learning from the system itself. The trader will actively collect the data it needs from the overall system, using system calls, data based and directory servers. Server selection criteria language is going to include full range of operations. From the services of the trader we implement the selection of servers and invocation. As the trading system needs not to be totally trustworthy, we do not implement the resource reservation nor include it to our system model. Instead we plan for service interface modifications and server monitoring for increasing server fault tolerance. In fact, if the trader is able to notice that a server fails for insufficient resources, it can retry to select another server and thus correct the mistake it made and resource reservation was not needed. We plan to implement a trader that leaves responsibility of monitoring the success of services to the client, but we also describe a model of a trader that is able to handle this responsibility.Management of the trader is going to be integrated to the overall system management and the trader is able to handle the role of secretary, which includes all the other roles as special cases.The trader is going to be federated and in late phases of the project fault tolerant trader is implemented. These targets leads us to series of cooperating modules on different axis of taxonomy. These modules are represented in Figure 8. Into the figure a group of borderline has been drawn to represent phases of implementation. In the autumn of 1993 phase 1 is implemented as a prototype. 13 ---------------------------------------------------------------------------- data retrieval closed trader using authority server service selection method free choiche of all methods security attributes decision process limited resource usage supplementary criteria aritmetics access control prioritized criteria directory servers and data bases system services private data storage components of the trader invoker modifier of service interfaces data storaging in object database local selector of services interpretor of requests trustworthiness replication information retrieval and storage policy integration of management static optional reliable dynamic unreliable dynamic authority server local servers only federation with serial search federation with parallel search additional fault tolerance of servers open trader closed trader phase 1 phase 2 Figure 8. Functionality modules of the trader. 14 ---------------------------------------------------------------------------- 3.3. System architecture The features of trading service described above can be implemented using the following system architecture, represented in Figure 9. Each block is first shortly described in this section and a more detailed description of Daphne and trader database and monitor modules is given sections below. Applications may use the operating system services or other services lying underneath directly or via trader or Daphne. Services can also be retrieved from the application layer either directly or via Daphne and the trader. Daphne offers virtual server interface and implicit trading. It uses the services of the trader. For the clients, local servers and virtual servers look alike. The direct communication link represents explicit trading. Operating System Debbie statistics server trader Daphne applications m a n a g e m e n t t o o l s aut- ho- ri- za- tion clients servers object database concierge monitor RPC replica management Figure 9. DRYAD trading system structure. 15 ---------------------------------------------------------------------------- The trader module consists of an object database, a concierge and a monitor. The trader module offers several functions: selection of servers, invocation of servers, federation with other traders, information storage and retrieval, matching server interfaces and modifying them. The database module is responsible about all other functions except invocation which is offered by the monitor. The concierge module is required to integrate the trader to the overall architecture. The database is a simple relational database that includes objects. The basic object type describes a server. Each server object includes a server description, attribute evaluation rules and temporarily stored attribute values. For each incoming message an active agent object is created to process the request. These agents may run in parallel and each of them may start parallel attribute evaluations in several server objects by calling server methods.The sources of attribute values may vary depending on the evaluation rules stored into the database. The sources may include system calls, sensor processes and databases. An interesting data source is a dedicated statistic server. The statistic server is a sensor or monitor of sensor agents, collecting data and processing it to more structured form. The division between tasks of the trader and the statistics server is vague. A rule of thumb is, that values needing special processing or values needed seldom, should be evaluated outside the trader database. Thus the role of statistic server is to optimize the performance of trader database. To manage the object database we use Debbie database system. The main feature of Debbie is fastness. The amount of data is small compared to normal database applications. Also the nature of data is exceptional. The data is either rather static or very temporary. For example lists of allowed servers, service types offered and attribute value evaluation rules are created once and possibly never changed. Instead attribute values live only a very short time. We call the part of the database containing only static data the basic database or passive database. When the database is activated, it automatically collects also the temporary data and becomes what we call an active or full database. Due to this duality in the information stored, we do not need rollback features and data replication inside the database management system. What we need is fast service, locking mechanism and parallel execution of object methods. The dual nature of information stored into the trader database also dictates the replication mechanism of the trader. In the trader, the concierge module is concerned about the replication. Figure 10 shows the replication mechanism providing the fault tolerance of the trading service. A replicated concierge process is resident in all computers that are able to take the responsibility of trading service. The concierges negotiate where the trading service is located and the address of the selected primary concierge is passed to the communication layer. The selected concierge offers a service interface to clients from this machine until it fails and the concierges elect a new primary that starts a new trader database incarnation. Each concierge has a copy of the basic trader database that consists of static data. All the dynamic data in an active database lives only a very short time and thus the replication of dynamic data is not applicable. 16 ---------------------------------------------------------------------------- communication layer client monitoring of the concierges and passing of the message to the primary concierge trader object call trader for service request primary concierge secondary concierges ... active database passive database Figure 10. Replication mechanism for the trader. The communication layer in Figure 10 consists of replica management and RPC services shown in Figure 9. The RPC layer is responsible of transmitting (and retransmitting) the requests until a response is received or the upper layer decides to break the RPC call. The upper layer is responsible of replica management. There is a known set of replicas, arranged so that one of them is a primary copy and others are backups. Each replica may fail independently. The replica management layer holds a handle that includes a list of replica addresses and knowledge about the primary address. When a remote service is called, the replica management layer passes the call as a RPC call to the underlying RPC layer with one of the addresses. It also starts to make privileged status query RPC calls to the same address. The server acknowledges these messages as long as it has not failed. The RPC layer may retransmit the request if the reply is delayed. If the reply to the status query is delayed too much, the replica management layer decides that the RPC server has stopped. It aborts the RPC call and selects the next address from the server handle and makes a new RPC call towards another server replica. The trader monitor, shown in Figure 9, is responsible for invoking the selected servers. As the server selection mechanism of the trader selects only servers that are in a working condition at the time of invocation request, some fault tolerance is achieved by using the trader. Furthermore, the invocation mechanism may be structured so, that the invoker monitors the execution of the server until it is successfully done. It is even possible to invoke a group of servers instead of one, just to make sure that at least one of them succeeds. The client accepts the first result or requests the group to vote for the result. The trader monitor must also be concerned about authorization. In this task the trader may utilize normal authorization mechanism offered by the overall system architecture. 17 ---------------------------------------------------------------------------- 3.4. Trader database The basic concepts reflected by the database structure are service classes and servers. There is no hierarchical relationship between different classes or any standard that should be followed when selecting the classes. Each administrator is free to select those classes needed in the organization controlled by that trader. The functionality of the trader database is illustrated by Figure 11. The trader database consists of objects. There are active objects, such as agents handling service requests coming from clients and proclamation handlers. There are also storage objects representing servers. Server objects are reactive. They offer public methods for requesting attribute values. The value is either retrieved from a cache private to the object, or a new value is evaluated using a private evaluation method. The server object may be grouped as native and temporary objects. Native objects are those created when a server sends a proclamation. Temporary objects are created only on demand and are deleted through timeouts. It is characteristic of the Dryad trader to acquire information from external sources, such as federating traders and databases or directory servers. Temporary server objects are introduced to accommodate results of these queries. For example, it is not feasible to store information about all devices into the trader database. Instead temporary objects may be created on demand to represent the group of devices under inspection. The trader database includes rules for requesting information from the information repository and for creating temporary objects based on the response. Federation with remote traders and data retrieval from external data servers, such as directory servers, are handled similarly. Temporary objects may be composed objects. That means that each object may include data retrieved from several sources. To be able to create objects, the trader database must include templates to these objects. The templates are constructed at the time of database creation under control of system administrators. This data forms a static database portition, called the basic database. The database creation process is supported by an application offering means to handle service classes, attributes known in each class, attribute evaluation rules and such. It also supports the distribution of the basic database. The templates for object creation are called contracts. Slightly different templates are describing trading contracts, federation contracts and information retrieval contracts. Trading contract describes which servers are allowed to proclame services and to which area of clients. It also describes the attributes known of the service at the local trading domain. Federation contract describes what trading domain may be connected to the local domain when a certain service is requested. As the service description may be different at separate trading domains, the federation contract includes rules for fetching and transforming the attribute values of the remote trading domain to those known at the local trading domain. Information contract is 18 ---------------------------------------------------------------------------- similar to the federation contract, except that the attributes may be fetched as groups from more than one source. service request client concierge monitor sources of data: evaluation of attribute values reply system calls, directory servers, databases the trader database agent server object server object reply object temp. server object search proclamation handler server create external search agent X.500 federating trader search object creator Figure 11. The building blocks of the Dryad trader. A distinct active object in the database is the agent that handles service requests. Each incoming request is processed by an agent of its own. As the processing goes simultaneously on in the agents, data is accumulated and casched into the server objects. Thus the agents get advantage of each others work. The agent object is responsible of the server selection. It gets selection rules from the service requests and also it has to fulfill some policy rules set on each service class. Policy rules run always over the user rules and thus the administrators have means to force policies in system usage. When the trader has been requested to 19 ---------------------------------------------------------------------------- invoke a server, the best server at the moment should be selected. It is possible that the policy and user given selection rules does not fully define the selection. Therefore in each service class there exists a "sort function" for resolving ambiguous situations. The "sort function" may be a combination of additional selection rules and an external procedure, for example a load sharing algorithm. In to the matching procedure also the server interface matching must be included. The server interface description must for example include parameter type descriptions. The client and the selected server must have the same view to the interface or otherwise the interface views should be matched by a transformatter. This process of interface matching is planned to form a separate module, a type manager. 3.5. Trader monitor Trader monitor is responsible of invoking the servers selected by the trader selection modules. The monitor is constructed by a group of processes. The master process works in the same node as the active trader database incarnation. Others are situated in each node hosting servers. The role of the master monitor process is to construct a stub program that - collects the essential information about the client processes environment and parameters for the server (this data is passed to the trader in the service request message as attribute values), - transmits these into the server's host machine, - starts a process and runs it into a state corresponding to that of the client, - invokes the server with the passed parameters and waits for it to exit (or calls a continuously running server and waits for reply) - collects the results and transmits them to the client environment, - informs the monitor master process that the task is successfully completed, - releases the client to continue processing and - releases resources needed during the processing. After the stub has been generated, the master process passes it to one of the execution controller processes to be executed. Depending on the nature of the stub program, different execution schemes are achieved. Into the stub requests for access control functions, authentication functions, replication functions etc. can be embedded. Figure 12 illustrates the role of trader monitor. The monitor is shown to offer a single access point to several system functions related to execution.The trader system forms an interaction channel between client and server objects. 20 ---------------------------------------------------------------------------- client virtual server trader: selection trader: monitor server server server server machine boundary execution controller execution controller execution controller system functions (security, group, transaction functions, etc.) Figure 12. Trader monitor system. 21 ---------------------------------------------------------------------------- 3.6. Daphne The purpose of Daphne is to offer virtual servers to the clients. Virtual server interface is to be similar to that of any local server interface. Technically, all servers are files. Thus a reference to a file can be abstracted to mean a request for service. Instead taking the reference to point to a identified incarnation of a certain type of service, the reference it taken as a pointer to a group of servers all of the same service type. The virtual server interface is implemented by a file system called Daphne. It works much like a NFS file system, but instead of reading out contents of files to the clients, it itself reads the data stored into the files and takes that for instructions how to generate the requested file contents. Daphne file system is always a read-only file system. It handles requests for read, change directory and understand the meaning of symbolic links. Virtual servers are categorized as execution servers and information servers. These are handled differently in the Daphne process. When the client requests an information server, the Daphne process formulates a trader call, waits the trader to reply and formulates the reply into a suitable format for the client. If the client requests for an executable server, the Daphne process formulates a program file containing the trader call and passes this program for the client. The client is thus requesting the trader for execution of a certain type of service. A more detailed description of the Daphne process can be found in [Kut93]. 22 ---------------------------------------------------------------------------- References APM92 Architecture Projects Management Limited, An Overview of ANSAware 4.0. Document RM.099.00. March 1992. Kut93 Kutvonen, L., Kutvonen,P., Broadening the User Environment with Implicit Trading. To appear in Proceedings of the IFIP TC6/WG6.1 International Conference on Open Distributed Processing. Berlin, Germany, 13-16. September, 1993. MuVi85 Mullender, S. J., Vitarnyi, P. M. B., Distributed match-making for Prosesses in Computer Networks. Proceedings of the 4th ACM Symposium on Principles of Distributed Computing. August 1985, pp. 261-271. Neu92 Neuman, B. C., The Prospero File system. A Global File System Based on the Virtual System Model. Workshop on File Systems, May 1992. ODP92 ODP Trader Rappourteur Group, ISO/IES JTC1/SC21 N7047 Basic Reference Model of Open Distributed Processing. WG 7: ODP-Trader. Revised text. Ottawa, May 1992. ODP93 ISO/IEC JTC1/SC21 N8125 Information Retrieval, Transfer and Management for OSI. Basic Reference Model of Open Distributed Processing -- Part 3: Descriptive Model. WG7 Committee Draft. June 1993. OMG91 Digital Equipment Corporation, Hewlett-Packard Company, HyperDesk Corporation, NCR Corporation, Object Design, Inc., SunSoft, Inc., The Common Object Request Broker: Architecture and Specification. OMG Document Number 91.12.1. Object Management Group and X/Open, 1991. WoTs91 Wolisz, A., Tschammer, V., Dynamic Binding of Service Users and Providers in an Open Services Environment. Computer Networks, 1991. 23 ---------------------------------------------------------------------------- Annex 1. Dryad project Dryad (Directory Adventure, dryad is also a mythological creature, a fairy living in a tree) is a project in progress at the Department of Computer Science in University of Helsinki. The project will produce a prototype trader service running in a distributed heterogeneous environment. Also a network monitor system is planned that will use the trader. Cooperating partners in Finnish industry are Helsinki Telephone Company, State Computing Centre, ICL Personal Systems Oy, Finnish PTT TELE and Technology Development Center TEKES. The project was started in the autumn of 1992 and has financial support for a working period ending at 31.3. 1994. The project is supervised by professor Martti Tienari. The project group consists of two undergraduate and two postgraduate students and a system analysts. Involved in the project are: Liisa Marttinen, Liisa.Marttinen@cs.Helsinki.FI Leena Tirkkonen, Leena.Tirkkonen@cs.Helsinki.FI Tero Venetjoki, Tero.Venetjoki@cs.Helsinki.FI Petri Kutvonen, Petri.Kutvonen@cs.Helsinki.FI Lea Kutvonen, Lea.Kutvonen@cs.Helsinki.FI Department of Computer Science P.O. Box 26 (Teollisuuskatu 23) FIN-00014 University of Helsinki Finland phone: +358 0 708 51 fax: +358 0 708 4441 24 ----------------------------------------------------------------------------