We are now at the point where we can introduce formal definitions for profiles, oper- ations, and services themselves, which is done in this order as they build upon each other. We tacitly assume that each of these definitions serve as the basis for declarative descriptions thereof.
Profile
ResumingSection 4.1.5, a profile consists of the five types of properties and is formally defined as follows.
Definition 4.6(Profile). A profile is a 5-tuple Pr= (I, O, P, E, N)where • I is a finite set of input parameters such that∀i1, i2∈ I : id(i1) 6=id(i2); • O is a finite set of output parameters such that∀o1, o2∈ O : id(o1) 6=id(o2); • P is a finite set of preconditions;
• E is a finite set of effects;
• N is a finite set of non-functional parameters such that∀n1, n2∈ N : id(n1) 6=id(n2). We will write Pr.I, Pr.O, Pr.P, Pr.E, and Pr.N to denote respective sets of a profile Pr. Note that each set I, O, P, E, N may possibly be empty; the profile where all sets are empty is correspondingly called the empty profile. The additional requirement on names
23In [Kal06] a black-box approach is described that relies only on a sound and complete reasoner for a particular DL, thus, is independent of the DL used. In addition, a glass-box approach tailored to a particular reasoner and toS HOI N (D)has also been described and implemented.
(identifiers) of input, output, and non-functional profile parameters ensures that they can be uniquely identified even if they are equivalent.
Example 4.3
Recall the find book service and the order & pay service from Section 2.1. Suppose their profile is denoted with Pr1 and Pr2, respectively. Furthermore, suppose there is an ontology (that has been loaded into a KB) consisting of the concepts CreditCardNo, ISBN, BookInfo, Customer, Receipt, and that there is a data range int. The input and output sets (I, O) would then be specified as follows:
Pr1.I= {SEARCHPARAM:BookInfo}, Pr1.O= {ISBN:ISBN},
Pr2.I= {AMOUNT:int,CCNO:CreditCardNo,CUST:Customer,ISBN:ISBN}, Pr2.O= {ACK:Receipt} .
Consequently, all parameters are general except for AMOUNT, which is concrete. Sup- pose the parameters CCNO, ISBN, CUST, and AMOUNT have one representative where
the former two shall be strings, the third an individual, and the latter an integer. If Pr2 is supposed to specify a precondition requiring the credit card to be valid and the book available from stock then it might be expressed by a conjunctive ABox query
Pr2.P= {validity(x, Valid) ∧inStock(y, z)}
where x links to Re[1](CCNO), y to Re[1](ISBN), z to Re[1](AMOUNT), and validity, in- Stock are roles in the domain ontology. Finally, Pr2 might specify an effect stating that the customer owns the book
Pr2.E = {ownsBook(u, y)}
where u links to Re[1](CUST)and ownsBook is yet another role in the domain ontology.
Operation
ResumingSection 4.1.2, an operation is supplemented by a name and formally defined as follows.
Definition 4.7 (Operation). An operation is a 3-tuple Op = (id, Pr, Gr) where id is the name (or identifier) of the operation, Pr is a profile, and Gr is a grounding.
Analogous to a profile parameter, the name of an operation is merely intended for identification purposes (cf.Section 4.2.1). The grounding Gr cannot be defined in more detail at the level of the system model since it is implementation-specific; hence, we abstract from technical details. Also, notice that the definition abstracts from whether an operation is one-way or request-reply; although it should be clear that a non-empty
set of outputs in the profile of an operation implies that it is request-reply. Protocol semantics of operations are addressed in the process model.
If we allow nil at the position of the grounding in Definition 4.7 (i.e., where no grounding is provided) then we can also represent abstract operations. Operations are implemented otherwise.
Definition 4.7 can be extended easily such that one can represent operations with multiple implementations (the motivation of which has been discussed inSection 4.1.2): instead of the single profile Pr and the grounding Gr one defines an operation as a pair Op = (id, PG)where PG is a non-empty set of pairs of the form (Pr, Gr)such that for each pair (Pr1, Gr1),(Pr2, Gr2) ∈ PG, the profiles Pr1 and Pr2 differ at most in their preconditions and non-functional parameters. The additional restriction on profiles is a consequence of the obvious requirement that all implementations of an operation are functionally equivalent (see Section 4.1.3). Since differences are possible for precon- ditions and non-functional properties, implementations may vary regarding required conditions for being operable and may come with differing quality characteristics.
We define the trivial while special-purpose no-op operation, denoted with NOP, that presents the empty profile and has no grounding:
NOP = (“no-op”,({},{},{},{},{}), nil)
According to what we have stated, NOP is abstract. This shall not worry us since an implementation would not do anything anyway. Although NOP rather lacks practical relevance, it is mentioned here because it is used later on as an ancillary tool.
Service
Apart from the elements that we have already formally introduced, a service includes two more elements: a control flow graph and a data flow graph. Both will be introduced afterwards inSection 4.3since they represent the process model of a service, which we shall feature in its own section.
Definition 4.8(Service). A service is a 5-tuple Sc = (id, Pr,U, Gcf, Gdf)where id is the name (or identifier) of the service, Pr is a profile,U is a finite, non-empty set of functional units that the service is composed of, Gcf is the control flow graph over elements in U, and Gdfis the data flow graph over elements inU. Given a service Sc, an instance of Sc is denoted withSc•. A service is atomic if|U | =1 and the single functional unit u∈ U is an operation. Otherwise, if|U | > 1 then it is composite. Finally, given two services Scsuband Sc, Scsubis called a sub service of Sc if Scsub∈ Sc.U.
Because an atomic service consists of a single operation, their profiles are the same. ExtendingDefinition 4.8such that a service can present multiple profiles (the motivation of which has been discussed in Section 4.1.1and 4.1.5) is easily achieved by replacing Pr with a set of profiles, say P, defined to be finite and non-empty. Doing so spawns an orthogonal dimension to the atomic versus composite dimension. IfP contains only one profile then we shall call the service simple and complex otherwise.
Analogous to the no-op operation but by a slight abuse of Definition 4.8 we can also model the no-op service; that is, a service that presents the empty profile only, is composed of nothing, and has an empty control and data flow.