3.5 Service Description
3.5.1 Describing Services
? Matching
&
Tag Generation Service Manager
New Version
Old Version 1
2
4 3 5
Figure 3.5: Service Evolution
returned. The question is how evolution may occur smoothly in this case?
Actually, when a caller evolves, there may be two solutions for making the application evolve correctly: (1) we simply transfer the different service de-scriptions that are currently declared to the new version of the caller and the caller declares them again and waits for the answer, (2) we load an entity that may let others collect data, and particularly returned data.
The first solution is clearly the most natural, but the second one may be an interesting way of using the disconnected aspects and a possible delegation mechanism to collect data. However, the first possibility induces a temporary unavailability of the return service, which may induce in a lost answer if all entities are not programmed carefully. This may cause problems at execution although programmers should always take into account that unavailability may occur from time to time. The second possibility is much more difficult to program and imply to first load this entity, then delegate the answer collection to it and finally make the caller evolve.
3.5 Service Description
3.5.1 Describing Services
Since there is no reference, shared among entities there is no possibility to reference services by name. The philosophy adopted by our model consists in describing accurately the requested service. Focus is put on the service
48 CHAPTER 3. MODEL
? Matching
&
Tag Generation Service Manager
New Version
Old Version 1
2
4 3 5
Figure 3.6: Caller Evolution
and not on the particular entity that will satisfy it. Service description has two main goals:
• Allow the infrastructure to decide which service publication is the one that fits the best the service request;
• Let programmers specify, as precisely as they need, services they re-quest or provide.
In this context, we need to know what kind of service we want, how the answering entity satisfies the service, and how well the entity satisfies the service. Informally, services may then be described in three parts answering these three questions, respectively:
Functionality. This is the semantic part of the message describing the func-tionality of a service by characterizing its kind. An analogy with tra-ditional object programming could be the names of a method, its class name, and its package name. For example, a service allowing to read on a file system has the following functionality, expressed in a pseudo-language:
Functionality: "FileSystem": "Read".
Behavior. This is the information that will guarantee the compliance of the functional check. It contains basically: arguments proposed to the ser-vice to realize its task, and the way the serser-vice has to work (e.g. does it
3.5. SERVICE DESCRIPTION 49 return an answer, if so, is it answering through a particular service or a service built with the communication tag, etc.). An analogy with tradi-tional object programming could be the types of a method and its argu-ments. In the reading files example, the behavior specifies that it takes as a parameter one string and returns the result which is a String, using the communication tag (implicit by the use ofreturn). The Behavior is expressed as follows: Behavior: String: "return": String.
Quality of Service. This is the part of the message that allows to select a particular service from a group of equivalent services by matching most accuratly the quality of service desired with the quality of service proposed. There is no analogy with traditional programming since the choice between methods is not an issue for programmers. The reading file example would then indicates that it should be performed locally.
In the direct line of the previous parts we express the quality of service as follows: QoS: "local".
A service description is made of four fields: one for each aspect - Function-ality, Behavior, and QoS; and a triplet of numeric values [d1,d2,d3], indicating the minimum matching depth of each aspect.
Each aspect is described in two parts: first a preamble, specifying the related aspect: Functionality, Behavior, or QoS; second, aseries of labels.
In the case of the Functionality and QoS aspects, the sequence of labels serve to specify the functionality and the quality of service respectively using an increased level of details. For instance, a service offers the functionality Read in a FileSystem application. In the case of the Behavior aspect two cases occur: either the service description is a service publication or it is a service request. In the first case the labels specify the types of the input parameters, the possible return value and its type. In the second case the labels specify typed values, a possible expected returned answer and its type.
Parameters types are only primitive types, such as String, Integers, etc.
The fourth field of a service description is a triplet of numeric values indicating the required minimum matching depth each aspect must reach when a service publication and a service request are compared. The matching depth of each aspect is the maximum number of consecutive labels that match.
For instance, the following service publication:
(Functionality: "FileSystem": "Read", Behavior: String: "return": String, QoS: "local",
[3,2,1])
50 CHAPTER 3. MODEL means that: the minimal functionality is 3, i.e., the service furnishes a reading file service; the minimal behavior is 2, i.e., the service requires an input parameter but does not necessarily return an answer; and the quality of service is 1, i.e., the service prefers a local interaction, but it is not necessary.
Although in the above example we use a flat structure to represent each aspect, the service description supports a tree-like structure enabling alter-natives [126].
Fields corresponding to Functionality, Behavior, and QoS are defined as a tree, as shown in Figure 3.7. Two branches going out from a node correspond to anOR between the two subtrees, and a branch corresponds to anAND, i.e., a specialization, between the upper level and the associated subtree.
Even though labels are well-known, agreed names, such asReadorlocal, it is important to note that it is not necessarily the actual name of the service that will answer the request. It is simply a way of qualifying the kind of service used in the service description. The feature consisting of having a tree-like structure is intended to capture the fact that different terminologies may be used to describe a unique feature.
As an example we could use Read, Reading, ReadFile, Access or any given keyword as a label, depending on the applications. In such cases an entity designed to be used in these applications should be able to propose for the same service all these keywords.
Behavior QoS
When defining a service description containing alternatives, it is impor-tant to avoid possible mismatches among the diverse branches belonging to different aspects. Therefore, it is recommended that all branches of the Func-tionality aspect be compatible with all branches of the Behavior and QoS
3.5. SERVICE DESCRIPTION 51 aspect (e.g., accept the parameters types); it is the same between Behavior and QoS.