Dynamic Service Identification in a CORBA-like Environment - CiteSeerX

Dynamic Service Identification in a CORBA-like Environment P.Bosc(°),E. Damiani(+), M.G. Fugini(++) (°) ENSSAT, Université de Rennes, Lannion (+) Università di Milano, Polo Didattico e di Ricerca di Crema (++) Politecnico di Milano, Dipartimento di Elettronica e Informazione

Abstract Dynamic invocation of services in O-O execution environments requires identification of server objects which are “fit” to a certain task on the basis of available functional and non-functional information. CORBAcompliant environments store such information in a Trader system which can be browsed or queried by client objects. In this paper a fuzzy data model is proposed as the basis of the design of a Trader system. A fuzzy query algebra is described allowing for choosing query execution mechanisms at run time, on the basis of user-selected semantics.

1. Introduction The past few years have witnessed a tremendous increase of the interest in objectoriented client/server applications and, in general, in distributed computing, which has made significant advances due to the diffusion of the World Wide Web technology. To encourage a tight coupling of distributed objects and the Web, the Object Management Group (OMG) decided to promote the CORBA (Common Object Request Broker Architecture) object-oriented distributed software architecture [Yan96]. Using CORBA, a client can transparently (i.e., without knowing servers implementation details) invoke a method on a server object by two different ways: static invocation or dynamic invocation. With dynamic invocation, the server is chosen at run time, according to the features of its interface (e.g., using methods signatures provided by servers’ interface). CORBA also provides a Trading Service that identifies an object offering services requested by the client on the basis of functional information: it contains descriptions of services and offer properties provided by the servers, such as what servers exactly do, how and where they do it. However, the client may also want to get non-functional information about the servers in order to make the correct choice, e.g., the server’s price or performance, or its transmission delays. Since non-functional information is not part of servers interfaces defined by CORBA standard definitions, the idea of this paper is to add this information in the network environment. Then, clients can define at run time their needs and have more control over the selection of the server. Standard CORBA systems work on the basis of Boolean logic: a server either totally satisfies a client’s needs, providing the desired services, or it does not. It seems then necessary to compensate this lack of flexibility taking into account the notion of imprecise queries. Many approaches have been proposed to deal with imprecise queries; in this context we adopt a model based on fuzzy sets theory [Bos92, Bos95] which includes a fuzzy data model and a fuzzy query algebra as the basis of the design of a CORBA Trader system.

In this model, each server property has an associated numerical value, called weight for which various semantics can be selected. Moreover, the user can choose among these semantics when formulating a query. The query constructed by the user is a list of weighted offer properties associated with a semantics; seen as a whole, it can be considered as a fuzzy request. Through an operation of fuzzy division on the basis of this request, the Trader then yields, for each available server, its degree of satisfaction relatively to the query. Hence, the client is provided with a set of discriminated answers, and can choose the best fit among the available servers. The paper is organized as follows: in Section 2, an overview of CORBA architecture is given, showing how Java and CORBA object models complement each other. In Section 3, the fuzzy data model for a Trader, and the associated semantics, is presented. In Section 4 a sample implementation of a Trader dealing with fuzzy retrieval of images and pictures is described. Finally, in Section 5 conclusions and elements for future developments of this work are given.

2. CORBA Object Management Architecture The OMG has developed a conceptual model, known as the core object model, and a reference architecture, called the Object Management Architecture (OMA) upon which applications can be constructed. OMA attempts to define at a high level of abstraction, the various facilities necessary for distributed object-oriented computing. It consists of four components: an Object Request Broker (ORB), Object Services (OS), Common Facilities (CF), and Application Objects (AO). Objects Services specifications define a set of objects that perform fundamental functions such as naming services, life cycle services, transaction services or Trader services. Generally speaking, they augment and complement the functionality of the ORB, whereas CORBA Common Facilities provide services of direct use to application objects. The core of the OMA is the ORB component, which is a transparent communication bus for objects that let them transparently make requests and receive responses from other objects located locally or remotely. In other words, the ORB allows client and server objects, that can be written in different languages, to interoperate. It intercepts calls and is responsible for finding an object that can execute them, pass it the parameters, invoke its methods and return the results. Moreover, operation invocations can be done either statically at compile time or dynamically at run time with a late binding of servers. The client side is composed of IDL stubs, a Dynamic Invocation Interface (DII), an Interface Repository and an ORB Interface (see Fig. 1). The client-side IDL stubs provide the static interfaces to object services and define how clients invoke corresponding services on the servers. On the other hand, the DII allows clients to construct and issue a request, whose signature is possibly unknown until run time, using information from the Interface Repository. As for the ORB interface (the only component of the architecture shared by both sides), it allows functions of the ORB to be accessed directly by the client code.

Figure 1: Structure of ORB interfaces

The implementation side interface consists of server IDL skeletons that provide static interfaces to each service exported by the server, a Dynamic Skeleton Interface (DSI), an Objet Adapter, an Implementation Repository and the ORB interface. The DSI (the server equivalent to the DII) looks at parameters values in an incoming message to determine a target object and method. The Object Adapter is on top of the ORB’s core communication services and accepts requests on behalf of server’s objects. It provides the run time environment for creating instances of server objects, passing requests to them and registering their classes in the Implementation Repository. As said previously, in addition to static method invocation, CORBA also provides a dynamic distributed invocation mechanism. Using CORBA’s Dynamic Invocation Interface, Naming Services, Trader Services and the Interface Repository, a client application can discover new objects at run time and dynamically invoke its methods, with a late binding of servers. Clearly, the DII provides a very dynamic environment that allows systems to remain flexible and extensible. In CORBA, the dynamic identification system of an object is made in 4 steps: 1. The Trader identifies an object offering the needed service requested by the user on the basis of its functional properties. 2. Using the Interface Repository, the Trader Service retrieves the object interface, as well as a reference to it (an IOR or Interoperable Object Reference). 3. According to the description of the signature of the method (number and types of arguments), it constructs the invocation. 4. Finally, it invokes the object’s method with adequate parameters and receives the results. CORBA provides the missing link between the Java portable application environment and the world of services [Orf97]. Currently, Java applets cannot communicate alone across address spaces using remote method invocations. CORBA allows applets to invoke methods on remote objects. Moreover, CORBA provides a rich set of distributed services that enlarge Java possibilities, such as transaction services, security services, naming services or trading services. On the other hand, Java simplifies the code distribution in CORBA execution environments because its code can be easily managed from one server, and most of all, it provides a portable object-oriented infrastructure that nearly runs on every operating system.

The Remote Method Invocation (RMI), which is part of Java Development Kit, was designed to support remote method invocations on objects across Java virtual machines. Its main characteristics are: • It lets programmers move code in addition to data, • As it is based on Java, it ensures that the downloaded code is safe, • It uses Java both as an interface definition language and as an implementation language. RMI integrates a distributed object model into the Java language. Like CORBA, RMI lets the user invoke methods on a remote object as if it were on a local object, and let also pass a reference to a remote object in an argument or return it simply as a result. Moreover, RMI provides interfaces and classes to find remote objects, load them, and then run them securely. Currently, it also provides a primitive naming service to help locate remote objects, and a class loader to let clients download stubs from the server. Furthermore, even if RMI does not propose a dynamic invocation interface as specified by CORBA standard definitions, it provides a dynamic stub loading, which allows clients to dynamically download stubs that reference remote objects from the server. Although RMI provides ORB-like facilities from the Java object model, it is impossible to use it to invoke objects written in other languages. CORBA standard presumes a heterogeneous and multi-language environment and accordingly a language-neutral object model. On the contrary, RMI’s system assumes the homogeneous environment of the Java Virtual Machine. Fur the purposes of this paper, we will consider RMI as a CORBA-light solution for remote services invocation.

3. A Fuzzy Data Model For A Trader In this Section, we present the design a Trader which employs a repository storing fuzzy descriptors of the services available on the network [Rin91]. The repository is a structured collection of descriptors providing semantics-aware descriptions for servers’ properties [Dam97, Dam97-2]. We consider that each Trader is associated with an application domain or to a specific theme, such as, for instance, image processing, hypermedia applications, cartographic systems). Although beyond the scope of this paper, it is interesting to observe that the Traders on the network can be organized according to evolvable taxonomies, like the one proposed by the CommerceNet Consortium for Electronic Commerce [Ham97]. In our approach, the internal operation of a Trader is based on fuzzy techniques in order to allow clients to use also those servers which do not perfectly match the characteristics of the server they have required. The well-known concept of fuzzy-set allows us to consider classes, whose boundaries are not clearly determined, by the use of a characteristic function taking values in the interval [0,1], unlike crisp sets for which the characteristic function only takes values 0 and 1. The problem of the availability of program databases for application development and maintenance has been explored in the context of the relational data model [San96]. Here, we shall use a model based on fuzzy relation defined by applying an imprecise criterium through a fuzzy predicate on a crisp relation. For such a fuzzy relation, built on a set of

domains Di, every tuple is supplied with a membership degree µR, from 0 to 1, interpreting how this t-uple satisfies a fuzzy predicate P applied to the relation R. In our case, the Trader’s repository is a single fuzzy relation whose attributes are: object identification, offer property, fuzzy element, weight. Each offer property corresponds to several possible fuzzy elements, and to an offer property and each fuzzy element is associated with a weight, describing to which extent the corresponding property (functional or not) is offered by the object. From a syntactic point of view, properties are expressed by nouns whereas adjectives describe fuzzy features. The example of Fig. 3 shows a fuzzy relation describing the properties of two audio/video servers (here, for the sake of simplicity we consider only functional properties).

Object Id 1 1 1 2 2

Offer Property video service video service audio service video service audio service

Fuzzy Element good average good good average

Weight .8 0 .4 1 .5

Figure 3 : An example of fuzzy descriptor relation

As an example, Fig. 4 shows three fuzzy predicates describing a video service property through a fuzzy linguistic variable according to the frame rate that the corresponding server provides.

po or

F ra m e ra te 10

13

15

18

20

23

28

Figure 4 : Sample fuzzy elements for the video service property

Here, we assume the availability of a Thesaurus allowing both functional and nonfunctional information to be uniformed through a naming discipline, in order to deal with a standard context-dependent vocabulary [Dam95]. This allows both servers and clients to use a domain-specific language to express offer properties, without any explicit reference to the fuzzy model. Fuzzy elements and membership values are only computed and dealt with inside the Trader. The Trader’s role is to help the client to choose among the available offer properties. The client selects a fuzzy context-dependent predicate for each property, as well as an absolute value in the definition universe of the selected predicate. According to

predicates definition, the Trader transforms all absolute values into weights. It is important to observe that this computation can take place both when the servers sign up, i.e., communicate to the Trader the availability of their services, and periodically, as a consequence of new load or network traffic conditions. Our fuzzy Trader system proposes two main types of semantics: importance and fulfillment. The first one simply means the relative importance of offer properties: the user only has to give a percentage of importance for each property he has selected. As far as the semantics of fulfillment is concerned, we have two alternatives: • Price fulfillment (or ideal value vision) that signifies one expects a minimum distance between the query weight and the offer one. • Performance fulfillment that stands for a threshold vision: the query weight has to be superior to the offer one, but in the meantime as close as possible to it. For both visions of fulfillment, the client can possibly ask for absorption. This means rejecting any server which does not offer even one of the desired properties. Considering the previous examples and according to the semantic definitions above, a user can for instance request for a server having the following features: a good video service with a rate of 30 frames per second and an average audio service with a sampling rate of 16KHz, with a price fulfillment semantics with absorption. This list of properties, each one associated with a certain fuzzy predicate and weighted by a value between 0 and 1 (obtained by transformation of absolute values according to the linguistic variable definition) defines a fuzzy request to the Trader, which is nothing but another fuzzy relation shown in Fig. 5. video service audio service

good

1

average

0.5

Figure 5 : A fuzzy query relation Getting the list of servers satisfying the requested properties can be achieved by computing the fuzzy relational division by the query table [Bos95, Dub94]. As we shortly outline below, various fuzzy operators are available to compute this division, among which the user can perform a choice in order to obtain the desired semantics..

3.1 The division operation Let us consider two relations R(X,A) and S(Y,A) where A, X, and Y point out sets of attributes. The division of R by S, denoted R[A/A]S is a relation on X, which can be defined as follows: x ∈ R[A/A]S if ∀a ∈ S[A], (x,a) ∈ R. Following [Bos97] we examine the extension of the division to fuzzy relations. The operation of division of R by S can be considered as a set inclusion: x ∈ R[A/A]S ⇔ S[A] ⊆ Γ-1(x) , with Γ-1(x) = {a, (x,a) ∈ R}.

This inclusion, in the case of the extension of the division to fuzzy relations, can be interpreted either using the concept of cardinality of a fuzzy set or using a fuzzy implication, as follows: Inc(S ⊆ R) = minS (µS(a) → µR(x,a)). The second type of division operation based on fuzzy implications is more appropriate in our case since it retains the logical aspect we are interested in. Among the main families of fuzzy implication connectives, only three are appropriate for this subject: • R-implications, denoted a → b = sup {c ∈ [0,1] , a*c ≤ b}. • Goguen implication a → b = 1 if a ≤ b, b/a otherwise, if we associate T with the multiplication operation. • Gödel implication a → b = 1 if a ≤ b, b otherwise, if we associate T with minimum. • S-implications, namely a → b = n(T(a, n(b))), where n is an involutive order reversing negation operation, and T a conjunction operation modeled by a triangular norm. This norm has to respect several properties such as associativity, commutativity, monotonicity and 1 as neutral element. We get: • Dienes implication a → b = max (1-a,b), if we associate T with min. • Gödel reciprocal n(b) → n(a) = 1 if a ≤ b, 1-a = n(a) otherwise. As known, S-implications are their own reciprocals [Kli88]. • R&S-implications such as Lukasiewicz one, defined by: a → b = 1 if a ≤ b, 1-a+b otherwise, obtained with Lukasiewicz norm T = max (a+b-1, 0). 3.2 Selecting Query Semantics By selecting an implication, the user assigns the intended meaning of µS degrees in the fuzzy division R[A/A]S, i.e. the semantics of the query submitted to the Trader. If µS(a) values are considered as weights (i.e., we are interested in their importance), any element x will completely satisfy the query if, for each element a of S different from 0, we have a maximum membership degree for the corresponding tuple (x,a) of R. µR[A/A]S(x) = 1 ⇔ (∀a, µS(a) > 0 ⇒ µR(x,a) = 1). In the same way, an element x will not satisfy at all a condition if there exists any element a of S which is completely important, or the tuple (x,a) has membership degree equal to 0. µR[A/A]S(x) = 0 ⇔ (∃a, µS(a) = 1 ∧ µR(x,a) = 0). This desired behavior leads to define the quotient operation by using Dienes implication. Then, we have: µR[A/A]S(x) = minS µS(a) → µR(x,a) = minS max(1-µS(a), µR(x,a)).

where S is a fuzzy normalized operation (i.e. ∃a ∈ S, µS(a) = 1) in order to have a complete scale of importance levels. For example, considering the R and S fuzzy relations of Fig. 7, the result of the division, with Dienes implication is {x1/.7 , x2/.5 , x3/.5}. R

x1 x1 x2 x2 x3

a1 a2 a1 a2 a2

1 .4 .4 .2 .6

S

a1 a2

.5 .3

Figure 7 : Examples of fuzzy relations

In the case of fulfillment, µS values are considered as fulfillment degrees to be reached, i.e., thresholds. For this semantics, we need: µR[A/A]S(x) = 0 ⇔ (∃a, µS(a) > 0 ∧ µR(x,a) = 0) and µR[A/A]S(x) = 1 ⇔ ∀a, µS(a) ≤ µR(x,a). The major interest is in investigating what can be done when a tuple (x,a) exists which satisfies the current property to a degree less than the required one (i.e. if ∃a, µS(a) > µR(x,a)). One can take Gödel implication, whose use ensures that an element x will be retrieved with a degree as higher as µR(x,a) when µS(a) is larger than µR(x,a). Obviously, in this case, the result does not depend at all on µS(a). As an alternative, we could take Goguen implication. This alternative, that gives the ratio between µR(x,a) and µS(a), yields the relative level of fulfillment of the considered property. In the case of our previous example, the result of the quotient operation is {x1/1 , x2/.2 , x3/0} for Gödel implication and {x1/1 , x2/.8 , x3/0} for Goguen implication. For fulfillment semantics with non-absorption, following the same empiric reasoning, we note that, using Lukasiewicz, the closer µR to µS, the higher the result. Then, it seems obvious that Gödel reciprocal implication feels the threshold vision more than Lukasiewicz. In conclusion, we have the summary depicted in Fig. 8. Absorption Importance Price Fulfillment Performance Fulfillment

NonAbsorption Dienes

Goguen Gödel

Lukasiewicz Gödel reciprocal

Figure 8 : Matching implications and query semantics

Whatever implication is chosen to perform the division, we can give the following naive algorithm, that sequentially seeks for each element x of the divided relation R, the tuple (x,a) for each element a of the relation S. for each x of R do µR/S(x) := 1.0; for each a of S do seek sequentially (x,a) in R; if found then µcurrent(x) := µS(a) → µR(x,a); else µcurrent(x) := µS(a) → 0; end; µR/S(x) := min (µR/S(x), µcurrent(x)); done; done;

This algorithm is very costly in terms of memory accesses (when the tuple (x,a) does not exist the algorithm examines the whole relation R). Improvements, based on heuristics and indexes, are necessary. For example, supposing the existence of a threshold l that the servers final weights must reach in order to be selected, the following heuristics can be used: • A heuristic of failure valid for any implication: element x will not be retrieved if ∃a ∈ S, µS(a) → µR(x,a) < l, since the division compute a minimum value. • The second heuristic concerns the implications of Dienes and Lukasiewicz, as well as the reciprocal of Gödel implication. If we assume that S is sorted on decreasing µS degrees, one can stop the computation as soon as the current degree µR/S(x) is lower than 1- µS(a). Indeed, in this case, if the values 1-µS(a) are increasing then the degree of satisfaction for the considered element x can not decrease anymore. The element x will only be included in the division if µcurrent(x) ≥ l. • Finally, dealing with Gödel and Goguen implications, for a given element x, if there exists an element a in S such that the tuple (x,a) does not exist in R, then we have µR(x,a) = 0, and µS(a) → µR(x,a) = 0. This heuristic is used whenever the number of tuples of any partition of the relation R is inferior to the number of tuples of the relation S.

4. A Sample Trading System Architecture In order to explore the feasibility of our approach, this section presents a sample implementation of a trading system. The overall architecture is composed of four main elements: • A user connected to Internet from a certain machine, who requires a service from the trading system. Without dealing here with the classification technique used for organizing the objects dealt with by the Trader, we could assume that the client has previously contacted a “Master Trader”, which contains lists of various URL of known Traders in the domain under consideration. However, CORBA provides the needed functionalities for a transparent interconnection of Traders.

• A Trader site where all classes defining the GUI interface are stored, together with the RMI Trader System itself and data files that describe the features of the servers, toghether with the characteristic values of the various fuzzy predicates. The Trader receives fuzzy requests from users, and on the basis of this information, performs the division (according to the fuzzy predicates) on the repository and returns the best matching server to the user. • An Adapter site that supports a fuzzy adapter system whose role is to dialogue with servers and maintain a coherent view of fuzzy predicates according to servers’ properties. Whenever a server’s features change, the adapter RMI server updates the repository of the RMI Trader dynamically (i.e., adds or removes a server, or partially updates its properties) and, if necessary, updates also the functions describing the fuzzy predicates. • Several RMI servers that actually provide the services described in the Trader base. No fuzzy issue characterizes these sites: the server programmer or installer only specifies the absolute values of properties (e.g., the current price of a service) that will then be interpreted by the Adapter site. As an example, let us consider a the Trader dealing with image processing servers. Three non-functional properties are supported: the price of a picture, its date, and its size. Accordingly, the fuzzy repository is a single fuzzy relation (see Fig. 9). In order to keep the system as simple as possible, our servers are each in charge of a picture file, and the only service they offer is sending the picture to the client. Thus each property tuple represents a picture file retrieval service, characterized by the name of the picture and by the URL of the server where it is stored. The attribute available states if the picture is currently available. If not, it will not be taken into account for the division. Fig. 9 gives the crisp data available about one of the servers.

File Name

URL

Subject

Available

Florence1. gif

159.1 49.70. 110

Florence

1

P r i c e 1 0

D a t e

S i z e

1 9 8 5

2 3 4

Figure 9 Crisp data about a picture server

In our example, each service is described by three offer properties, corresponding to the linguistic variables: price, date and size. These variables are defined via their fuzzy elements and pairs (linguistic variable, element) are indeed the tuples in the Trader fuzzy relations. The membership degrees of these tuples are calculated using the crisp data and the linguistic variable definitions to compute the membership value corresponding to each fuzzy element. Fig. 10 shows the linguistic variable price and its fuzzy elements.

lo w

m ed iu m

high

$

Figure 10 : Example of characteristic functions for the linguistic variable price

Fuzzy predicates used by the Trader in this example are stemmed from primary fuzzy terms, describing imprecise properties corresponding to adjectives of the natural language. For instance, we could introduce the following fuzzy terms: low, medium and high for the price offer property (see Fig. 10); very old, old and recent for the date one; and medium, small and large for the size.

These terms, modeled by fuzzy sets, are associated by the Trader to the corresponding linguistic variables:

Server ID = FileName +URL Florence1 159.149.70. .gif 110 Florence1 159.149.70. .gif 110 Florence1 159.149.70. .gif 110 Florence1 159.149.70. .gif 110 Florence1 159.149.70. .gif 110 Florence1 159.149.70. .gif 110

A 1

OP1 Price

OP2 low

µ 0.8

1

Price

0.1

1

Date

mediu m old

1

Date

recent

0.6

1

Size

small

0.7

1

Size

mediu m

0.1

0.4

Figure 10 : Fuzzy offer properties stored by the Trader

In our example, the linguistic variables have three fuzzy elements each, but (as is usually the case) the superposition in their definition involve the fuzzy elements two by two. Thus, in this case the maximum amount of fuzzy offer properties having non-zero membership for each server is 6.

It is interesting to note that the linguistic variables used by the Trader for computing the fuzzy offer properties can also be provided by servers themselves when signing up to the Trader . 4.1. A Sample Invocation Our current prototype of the Trading System has been developed in Java (using Java Development Kit 1.1 that includes the RMI package). The browser used to download the HTML pages and Java classes is HotJava for Windows, since it supports RMI. In order to process a query with the Picture Trader system, we assume that the various servers, i.e., the Trader server (Trader.java for the interface and TraderImpl.java in the implementation), and the pictures servers (ImageServer.java and ImageServerImpl.java) are running. When bound on the registry, whereas picture servers only wait for requests, the Trader begins by reading its data files (repository and characteristics of fuzzy predicates) to be ready for any query. On the client side, the user must first connect to the fuzzy Trader site. His browser then downloads an HTML page including two Java applets (TraderInitApplet.java and BestResult.java), that is, Java classes implementing the predefined interface java.applet.Applet, together with the other classes directly called by these two applets (these are considered as local invocations as opposed to the RMI mechanism).

Figure 11 : Selection window for thematic areas

Figure 12 : Selection window for semantics

Since the purpose of this fuzzy Trader is to help the client to select a picture through a GUI interface, the applet TraderInitApplet first displays the window enabling the user to select the town of which he is interested in seeing pictures. In Fig.11, the user can choose between Florence, Milan, Rome, and Venice. Clicking on the Confirm button, the user discovers a frame (see Fig.12), described in SemanticsFrame.java, that allows him to choose one of the semantics for the retrieval of servers, according to what described in Section 3. Once the applet has recovered the selected semantics, it determines the implication (according to the classification given in Fig.8) that the Trader will use to perform the division. Then it displays the second frame of Fig.12 (corresponding to the file PropertiesFrame.java) to let the user make his selection over offer properties. For any of these choices, the applet displays an object of the InputFrame class, which proposes three fuzzy features, whose definition depends on the given property. An input frame is then proposed to users for the price property (bottom, medium or high): by clicking on one of the three fuzzy elements, the boundaries (obtained from the RMI Trader) of the characteristic function describing the corresponding fuzzy predicate are edited in text fields. This information helps the client in giving a value: a percentage in the case of “importance” semantics, or an absolute value for any “fulfillment” semantics. Whereas percentages directly give weights, absolute values in the second case need to be transformed into weights by the Trader according to the selected fuzzy predicate. All this information (i.e., the city, the semantics and the corresponding implication, the selected properties and the weights) compose a fuzzy request, that the TraderInitApplet passes on to the RMI Trader to compute the division, after having contacted it using the naming service of the RMI package. For each picture regarding the subject, the Trader computes its degree of satisfaction relatively to the fuzzy query (using the FuzzyCalc

class). Finally, it returns the BestResult applet information on the best matching service: the address of the server where the picture can be found, its name, and its final degree (see Fig.13). The client browser then connects to the target site to see the retrieved picture, by means of a third applet, TraderImageViewer.

Figure 13: Information on the retrieved server 5. Conclusions and Future Developments We have presented a fuzzy data model for a Trader System which supports dynamic selections of distributed services on the basis of a user-selected query semantics. Moreover, we have given an example of a Trader, showing how it is possible to invoke also servers that do not match the required service perfectly. From this first step, a series of developments can be made. First of all, the mechanism of retrieval of servers can be enlarged on the basis of features the servers should not have, in order to eventually decide between those that would have a same level of fitness after the query execution. Indeed, the phase of division involved in the query searches in the repository for servers that have as many as possible of the desired requirements. On the contrary, the optional phase of differentiation, through a measure of comparison, should compute an object similarity measure to discard servers that have properties the user did not ask for. Many measures of comparison of descriptions of objects have been proposed and studied in given domains of applications. B. Bouchon-Meunier, M. Rifqi and S. Bothorel [Bou96] proposed a general classification consisting in four main kinds of measures of comparison, depending on the purpose of their utilization. In a future release of our system, a general measure of similarity will be used to help the user in choosing objects that are closer to the searched one than the others. Secondly, as far as the design of the architecture, a complete specification is being given using OMT. Moreover, we are currently working on the servers-to-Trader dialogue in order to support intelligent load balancing techniques and on the Trader-to-Trader communication to exchange information about different domains of interest. Finally, our prototype has been ported under a full-fledged CORBA environment taking advantage of the capabilities of Java JDK 1.2. References [Bos92]

P. Bosc, O. Pivert, “Some Approaches For Relational Databases Flexible Querying”, Journal of Intelligent Information Systems, vol. 1, 1992.

[Bos95] [Bos97]

[Bou96] [Dam95]

[Dam97]

[Dam97-2]

[Dub94] [Ham97] [Orf97] [Rin91] [San96] [Sie96] [Yan96]

P. Bosc, O. Pivert, “SQLf: A Relational Database Language For Fuzzy Querying”, IEEE Transactions on Fuzzy Systems, vol.3, n.1, 1995 P. Bosc, D. Dubois, O. Pivert And H. Prade, “Flexible Queries In Relational Databases - The Example of The Division Operator”, Theoretical Computer Science, vol.171, 1997 B. Bouchon-Meunier, M. Rifqi, S. Bothorel, “Towards General Measures of Comparison of Objects”, Fuzzy Sets and Systems, vol.84, 1996. Damiani, E., Fugini M.G., “Automatic Thesaurus Construction Supporting Fuzzy Retrieval of Reusable Components’’, Proc. 10th ACM Annual Conference on Applied Computing, (SAC’95), Nashville, February 1995 Damiani, E., Fugini M.G., “COOR: A Descriptor-Based Approach to OO Code Reuse’’, IEEE Computer Magazine, Special Issue on OO Development and Reuse, October 1997 Damiani E., Fugini M.G., “Fuzzy Identification of Distributed th Components’’, Proc. of the 5 Fuzzy Days Intl. Conf., Dortmund, 1997, LNCS 1226 D. Dubois, H. Prade, “Quotient Operators in Fuzzy Relational Databases”, Proc. of The 2nd European Congress on Fuzzy and Intelligent Techniques (EUFIT’94), Aachen, , 1994 Hamilton S., “E-Commerce for the 21st Century”, IEEE Computer Magazine, vol. 30, n. 5, May 1997 R. Orfali, D. Harkey, “Client/Server Programming with Java and CORBA”, John Wiley Computer Publishing, 1997. D. Rine, “Design of Fuzzy Object-Oriented Software Components Databases”, Cybernetics and Systems, vol. 22, 1991. P. Santanu, P. Atul, “A Query Algebra for Program Databases”, IEEE Transactions on Software Engineering, vol.22, 1996 J. Siegel, “CORBA Fundamentals and Programming”, John Wiley Computer Publishing, 1996. Z. Yang, K. Duddy, “CORBA: A Platform for Distributed Object Computing”, ACM Operating Systems Review, vol. 30, 1996.