|
TU München - Fakultät für
Informatik
Lehrstuhl III: Datenbanksysteme |
|
|
|
TU München - Fakultät für
Informatik
Lehrstuhl III: Datenbanksysteme |
|
In UDDI, every service is assigned to a tModel.2
As a semantic classification, a tModel provides a classification
of a service's functionality and a formal description of its interfaces.
Therefore, a service can be called an implementation or an instance
of its tModel. With dynamic service selection, instead of explicitly stating an
actual access point in a composite service, it is also possible to reference or
``call'' a tModel. Thus, one defines the functionality of the service that
should be called rather than its actual implementation. As an example, see
Figure 1: Three services are assigned to
the tModel ForwardingAgency, namely Service FA_1, Service FA_2 and Service
FA_3. Now, assume that a programmer wants to implement a new service
Negotiator_A which should invoke a Web service assigned to the tModel
ForwardingAgency. Normally, the programmer would search the UDDI repository for
an appropriate service, e.g., Service FA_1, and use its access point in the new
Web service. With dynamic service selection, the programmer will instead develop
the service Negotiator_B. This service will not contain any hard-coded access
point, instead it will contain a call to the tModel ForwardingAgency. At
runtime, the service will query the UDDI repository for an appropriate Web
service and invoke it. If an invocation fails, alternative services are tried
until an invocation succeeds or no more alternative services are available. In
Figure 1, the invocation of Service FA_1
by Negotiator_B fails as well as the invocation of the alternative Service
FA_2. Only the invocation of the second alternative Service FA_3 succeeds.
<metadataPreference> /businessEntity/name="FA" </metadataPreference>A metadata constraint selecting only services free of charge looks like this:
<metadataCondition> /ServiceMetadata/CostsPerCall="0" </metadataCondition>
<locationCondition addressType="Geographical"
serviceType="All">
<center>DE-BY-PAS</center>
<maxDistance>50km</maxDistance>
</locationCondition>
The attribute serviceType defines that the constraint must be applied to
both, static as well as dynamic services. Alternative values are Static
for using only static services and Dynamic for dynamic services,
respectively.
Using the one mode, only one instance out of all tModel instances is called. In case of a failure, e.g., temporary unavailability of the service, an alternative service is tried. Using the some mode, a subset of all services returned by UDDI is called in parallel.5 Its size, i.e., the number of services to be called, is specified as a parameter (either as an absolute value or as a percentage). Services which fail are replaced with alternative services until the demanded amount of services responded successfully or no more services are available. Using the all mode, all returned tModel instances are called. Obviously, no alternative services can be called if failures occur.
The following example shows a mode constraint that specifies that five percent of the available services should be invoked:
<modeCondition modeType="Some" number="5"
numberType="Percentage" />
With property constraints, replies can be selected based on a set of properties of the reply. Properties must be provided either by the service platform or by the invoked service. A service accomplishes this by including corresponding XML elements in its reply. ServiceGlobe supports the following properties: encryption, signature, and age of data. Using the first two properties, it is possible to verify if a reply is encrypted or signed, respectively, and by whom it is signed. The third property can be used to check the age of the returned data. This is important, for example, if the reply was cached, but the invoking service requires up-to-date data. With the following constraint, only replies signed by the given signer would be returned by the service platform:
<propertyCondition>
<signature>
<signatureDN>
CN=Customer, O=University of Passau, C=DE
</signatureDN>
</signature>
</propertyCondition>
Selection constraints are - similar to metadata constraints - XPath
queries which are applied to the reply of a service, including its SOAP specific
parts, e.g., the SOAP header. It is, of course, impossible to query encrypted
parts of the message. Selection constraints which refer to encrypted parts are
counted as not fulfilled. The following constraint, for example, ensures that
all replies contain a child element Tire in their SOAP body with an
attribute type and the value 155/70 R13:
<selectionCondition> /Envelope/Body//Tire/@type="155/70 R13" </selectionCondition>
With a timeout constraint, a maximal waiting time for replies of invoked services can be set. After its expiry, all pending services are aborted and all replies received so far are returned to the calling service. Of course, they must fulfill all other relevant constraints, e.g., reply constraints. The following constraint is an example of a timeout constraint:
<timeoutCondition value="100"
valueUnit="Seconds"/>
With first-n constraints, the call to a tModel can be ended after a
predetermined number of replies was received. The calling service gets only
these replies as result of its call. Services that have not responded until this
moment are aborted. The number of replies to wait for can be set by an absolute
number (attribute numberType="Absolute") or by a percentage
(numberType="Percentage"), depending on the number of services invoked
initially. The following constraint would end the call after ten percent of all
replies have been received:
<firstNCondition number="10"
numberType="Percentage" />
First-n constraints are, just as reply constraints, evaluated whenever a reply
of an invoked service is received. Timeout constraints on the other hand are
processed independent of the reception of a reply. The timeout is set when the
invocation of services starts and processed as soon as the specified interval
expires.
In ServiceGlobe, constraints can be combined using the operators AND and OR.6 There is an XML element for each operator: andGroup for the AND operator and orGroup for the OR operator. With every operator the combination of constraints, so called atomic terms, and already combined constraints, also called combined terms, is possible. That means that operators can be nested within each other. Figure 3 shows an example, an OR combination of two terms. The first term specifies that only dynamic services should be selected and that they should be instantiated preferably on service hosts located in Passau.7 The second term says that arbitrary services in Germany should be selected preferably.
<orGroup>
<andGroup>
<metadataCondition>
/ServiceMetadata/ServiceType="Dynamic"
</metadataCondition>
<locationPreference serviceType="Dynamic"
addressType="Geographical">
<pattern>DE-BY-PA</pattern>
</locationPreference>
</andGroup>
<locationPreference serviceType="All"
addressType="Geographical">
<pattern>DE-*-*</pattern>
</locationPreference>
</orGroup>
|
By the combination of constraints, conflicts can be created which may prevent fulfilling all given constraints. As a consequence, only a subset of the given constraints may be fulfillable, as the following example shows:
<orGroup>
<metadataCondition>
/businessEntity/name="FA"
</metadataCondition>
<timeoutCondition value="100"
valueUnit="Seconds"/>
</orGroup>
Initially, the service platform has two choices: On the one hand, it can invoke
only services of the company FA and wait for their replies
(therewith fulfilling only the first constraint). On the other hand, it can
invoke all services assigned to the tModel. But if a timeout occurs, the
service platform faces the situation that it either must return all replies
received so far immediately (therewith fulfilling only the second constraint) or
that it must ignore the timeout and wait at least for all replies of the
FA services (therewith fulfilling only the first constraint again). In the
latter case, though, it invoked too many services initially. So, in general, the
service platform is unable to fulfill both constraints at the same time.
The combination of constraints from different sources can result in different types of conflicts. It is, of course, also possible that there are conflicts between constraints from the same source because of a wrong composition of the constraints. A service platform must resolve these conflicts or abort the service's execution. The remainder of this section explains how the former can be achieved.
Two types of conflicts can be distinguished. A contradiction occurs if two or more constraints are specified that cannot be fulfilled both at the same time. An example are two mode constraints demanding different call modes. Another example are two metadata constraints, with one constraint demanding the use of dynamic services and the other one demanding only static services. Contradictions can only occur between conditions because preferences need not be fulfilled and, therefore, can always be ignored safely in case of a possible contradiction with another constraint. The second type of conflict was already explained in Section 1.3 . With it, it is not always possible to fulfill all constraints. The service platform must decide which constraints should be fulfilled and which should not. This is a matter of optimization: On the one hand, the service platform should invoke as less services as necessary, on the other hand, it should fulfill as many constraints as possible.
The resolution of conflicts is based on priorities. A priority ranging from 0
(minimum) to 
(maximum) is assigned to every term. An implicit
prioritization is given by the sequence of the terms in their XML
representation. The later a term is defined in the XML document the less its
priority is. There are two ways of assigning an explicit priority to a term:
First, the attribute priority can be used to assign an explicit priority
to a term. Second, the attribute srcKey can be used to specify a reference
to the source of a term. Priorities are assigned to the sources - identified by
an URI. The priority of a source is applied to all terms assigned to the source
and, if necessary, recursively to all their sub terms.
Figure 4 shows an example.
If two terms have the same explicit priority, their implicit priority decides which one has the higher priority.
<dssConstraints>
<locationPreference srcKey="1"
addressType="Geographical">
<pattern>DE-*-*</pattern>
</locationPreference>
</dssConstraints>
<dssConstraintsSources>
<source srcKey="1">
<URI>http://tempuri.org/sg/constraints</URI>
<priority>2</priority>
</source>
</dssConstraintsSources>
|
At first, the constraints from all different sources are combined conjunctively into one single, large combined constraint using the AND operator. This newly created combined constraint is called main constraint. This is the constraint which is passed as input to the tModel call. The evaluation of the main constraint consists of two phases: Firstly, it is transformed into its disjunctive normal form (DNF) and conflicts are resolved. Secondly, UDDI is queried for services assigned to the given tModel and the services are invoked considering the constraint.
··· c1i1)
(c21 ··· c2i2)
···
(cn1 ··· cnin) 
k 
{1 , . . . , n},
j {1 , . . . , ik} :
ckjConstraints, operators, are sorted according to their time
of evaluation. The order is: metadata constraints, location
constraints, mode constraints, reply constraints, and result
constraints. Let the AND terms of the above constraint be already
sorted this way. Thus, the following applies:
| k {1 , . . . , n} : |
ck1 , . . . , ckmk MetadataConstraints |
| ckmk + 1 , . . . , ckmk LocationConstraints |
|
| cklk + 1 , . . . , cklk ModeConstraints |
|
| ckpk + 1 , . . . , ckpk ReplyConstraints |
|
| ckrk + 1 , . . . , ckrk ResultConstraints |
Of course, it is possible that there are no constraints of a certain type in some of the AND terms. If necessary, default constraints are inserted, e.g., an one mode constraint if none is given.
Next, the main constraint is checked for conflicts. Only conflicts within a single AND term are resolved in this phase, conflicts between different AND terms are resolved later, while the invocation phase, as will be explained in Section 2.2 . Within an AND term, a conflict occurs if it either contains more than one mode constraint or more than one result constraint. With mode constraints, it is obvious that two or more mode constraints cannot be fulfilled at the same time, e.g., an one mode and an all mode constraint. With result constraints, there are situations where several result constraints would not make sense, e.g., two first-n conditions with different numbers of replies to wait for, and some where they would. As a consequence, two or more result constraints per AND term are explicitly prohibited, as we see no real benefit from it.8 Of course, conflicts between metadata, location, or reply constraints are possible in principle. For example, an AND term can contain metadata constraints with XPath queries that are contradictory and cannot be fulfilled together by one service and its metadata. Detecting this type of conflict would require a detailed investigation of the XPath queries. This is not the focus of this work and so this kind of conflicts is ignored.
Conflicts are resolved by keeping only the constraint with the maximum priority
and removing all other conflicting constraints. So, there is at most one mode
constraint and one result constraint in every AND term, i.e.,
k {1 , . . . , n} :
lk + 1 = pk
rk + 1 = ik.
At last, identical mode and result constraints which are contained in several AND terms because of the transformation into DNF are merged.9 The resulting terms are called merged AND terms. Figure 5 shows a combined constraint after merging mode constraints c1p1 and c2p2 (assuming they are identical) and result constraints c2i2 and c3i3. Without merging, a service platform would evaluate identical mode and result constraints multiple times which would result in a different result. The following example illustrates this.
Assume the main constraint
m ( d1 d2 )
with m ModeConstraints
a one mode constraint and
d1, d2 MetadataConstraints.
Intuitively, one single service should be invoked
which fulfills d1 or d2. Converting this constraint into DNF results in
the constraint ( d1 m ) ( d2 m ).
Consequently, the service platform would invoke one service fulfilling d1 and one service
fulfilling d2 in parallel, effectively invoking two services and violating
the mode constraint m. By merging identical constraints (after conflicts have
been resolved) which results in the merged constraint ( d1 d2 ) m
this is prevented.
Only mode and result constraints are considered for merging because, unlike the
other constraint types, they are restrictions on sets of services respectively
replies, not on single services or replies. Therefore, the result of the
evaluation of the main constraint is only modified by duplicating them when
transforming the main constraint into DNF.
In the following, services which do not fulfill a condition are removed from a services list. Preferences, on the other hand, are used to sort a services list: Every service (and the information about it) has assigned to it the maximum priority (explicit and implicit) of all the constraints it fulfills. The services list is sorted according to these priorities, with highest priority first. Figure 6 shows an example: Service 1 and Service 2 have the same explicit priority (50), but Service 1 has a higher implicit priority, so it comes first.
Now, metadata constraints are applied to the services list, i.e., to the metadata of the stored services, of their merged AND term, followed by location constraints. Special treatment is necessary for location constraints for dynamic services. For their evaluation, all available service hosts are retrieved from UDDI first. Then, the location constraints are used to filter this list of service hosts and to sort it, the same way it is done with services lists. Again, the list is duplicated for each merged AND term as necessary. Note, that location constraints are probably different in the merged AND terms, so that the service hosts lists will probably be different, too. For each merged AND term, the corresponding service hosts list is assigned to all dynamic services of this term.
Next, all mode constraints of the main constraint are evaluated in parallel, i.e., Web services are invoked as specified by the mode constraints and considering all relevant services lists. As a consequence of the merging of identical mode constraints, services lists from more than one merged AND term may have to be considered (see also Figure 5). Therefore, all services lists from merged AND terms which contain identical mode constraints are merged into one single services list. Duplicates are removed and priorities are recalculated as necessary. Figure 6 shows an example for such a merged list. As a consequence, dynamic service hosts can now have assigned different service host lists.
The invocation of Web services according to a single mode constraint is called a mode call. Thereby the mode constraint specifies how many services have to be invoked and if alternative services must be invoked optionally. For a mode call, the corresponding services list is processed sequentially, starting with the service at the top (which has the highest priority). If the selected service is static, it is invoked and its entry in the services list is marked as processed. If the selected service is dynamic, a service host has to be chosen at which it is instantiated. Therefore, the service host with the highest priority is chosen from the service's service hosts list and the corresponding service host is marked as processed. If the end of a services list is reached, either because current mode call requires still more services to be invoked or because alternative services must be invoked (see Section 1 ), the selection starts again at the list's head, though marked entries are skipped. So, static services are only invoked once, dynamic services can be instantiated and invoked as often as there are service hosts in their service hosts list.
Every time the reply of a Web service is received, all relevant reply constraints are applied to this reply, i.e., the reply constraints of all merged AND terms with an assigned services list that contains the Web service that returned the reply. As the Web service may be contained in several services lists, there can be more than one merged AND term with relevant reply constraints. For every such merged AND term, its reply constraints are applied. If the reply fulfills all of them, it is added to the appropriate entry in the merged AND term's services list. If necessary, the priority of the service is adjusted and the list is reordered.
After every reception of a reply, the service platform must check whether the invocation phase must be ended. It must be ended if the result constraint with the highest priority is fulfilled, i.e., result constraints with lower priorities are not taken into account for this. As a consequence, at the end of the invocation phase, it is guaranteed that the result constraint with the highest priority is fulfilled. Result constraints with lower priorities may be fulfilled, but this cannot be guaranteed. After invocation phase ended, all replies are returned to the calling Web service thereby considering all necessary result constraints, i.e., some replies may now be discarded because of, e.g., a first-n constraint. All outstanding requests are aborted. After that, dynamic service selection for a given tModel is finished.
2 In fact, a service can be assigned to several tModels. But as there is no essential difference to calling a single tModel, calling several tModels will not be considered in the following.
3 A similar classification of conditions of SQL statements in hard and soft constraints is described in [Kie02].
4 The different modes are similar to unicast, multicast, and broadcast communication on networks.
5 It should be noted that one and all mode are obviously special cases of the some mode.
6 Additionally, the operator NOT is currently being implemented.
7 The element pattern is used to define a pattern which must match the geographical information of the service hosts. The character * operates as wildcard.
8 On the other hand, the implementation would be straightforward, although requiring many, even though simple case discriminations.
9 Basically, merging means factoring out identical mode and result constraints.
10 In our implementation, these services lists are not duplicated for efficiency reasons. Instead, only one services list is used in which all necessary data is stored, separated by the merged AND term the data belongs to.
