Christian Salzmann1, Bernhard Schätz [salzmann|schaetz]@in.tum.de
Software & Systems Engineering Technische Universität München Arcisstrasse 21 80290 München, Germany
Abstract. Nowadays the term of a “service” is frequently used in the discipline of modelling distributed system. However, it seems that the meaning of a service varies, depending on the domain it is used in. In this article we describe what various perceptions of the term “service” have in common and derive a formally founded definition of services that helps to specify services precisely in the context of components. We furthermore point out the differences between common terms like services, components and interfaces, describe some advantages of services and define a foundation for service based specification.. We close with a small example how services are defined and used.
Introduction
Today’s pervasive network infrastructure as emerging through the internet and wireless networks like GPRS, UMTS, and HiperLANs are enabling distributed systems to dynamically evolve during runtime. Those systems consist no longer of a fixed component set that concretely specifies communication relations, but are dynamically composed. The components are not allocated via a certain class or type but via a specific functionality that is needed for the complete functionality of the system. These functionalities are often designated as a service.
There are plenty of different definitions of such services. However, this term of service seems to be quite overloaded. There is no precise definition to be found that covers a critical mass. Nevertheless, various terms of services exists. Some precisely founded, some more or less pragmatically emerged. The web service definition language (WSDL) of the W3C consortium defines a service “as collections of network endpoints, or ports“ [CCM+], which basically is an interface or signature description. Another popular use of the term service is found in the area of cellular networks, short messaging service (SMS). In the Open Systems Interconnection-Reference Model (OSI-RM) a service is defined as, “a capability of a given layer, and the layers below it, that (a) is provided to the entities of the next higher layer and (b) for a given layer, is provided at the interface between the given layer and the next higher layer.“. The most general term might be “A service is an abstract protocol”
[BL01], which is the definition of Tim Berners-Lee. Inexplicitly there might be a common idea behind all these definitions on a highly abstract level, but it is obvious that these definitions are quite diverse. However, all the above-cited definitions have some aspects in common: interfaces, interactions but no structure.
Several questions arises when looking at the various definitions of the term service: What exactly is a ‘service’ good for and what distinguishes a service from, e.g., an interface as it is common in object oriented programming languages like Java or C++? What does it differentiate from a component or a combination of interfaces and components?
After covering these questions in the first sections of this paper, we prepare our definition of the term ‘service’ by first analysing and modelling the most basic ideas of a service. Afterwards we present a precise notion of services applicable in the domain of distributed systems and wide area internet applications (web services). We begin this by explaining first the formal model we use and then explain how to embed the idea of services into it. In the following section we describe shortly how a development process could make use of this service notion and what advantages this would imply. Finally we explain our idea of services by specifying an example of the usage of services.
The aim of the paper is to clarify notions raised but not sufficiently dealt with in the area of service-based engineering by use of a simple formal model. The basic techniques introduced are not specific to the model of stream relations used here but can be easily transferred to I/O-Automate [LT89] or TLA [Lam93]. The contribution of the formalization therefore rather lies in the transfer of the formal techniques than in the introduction of new formal concepts. Basic principles behind this formal model have been applied in a service-engineering environment [Sal02] and in a model-checking approach to detect feature interaction [Sch02].
Services vs. Components and Interfaces
As mentioned above, when specifying the notion of a service, several questions arise: Is there a difference between the notion of a component and a service? What are the differences? Why is it important to distinguish between services and components and what are the advantages of a service based approach?
Components are defined as reusable units of behaviour specified by their behaviour and structure [BS01, Müh96]. Structure is defined by assigning subcomponents including their behaviour to a component. A component therefore specifies behavioural and structural attributes, whereas a service represents a more abstract behavioural specification without internal structural constraints.
Components and services own interfaces, which are the signatures that define the types of messages that flow via this interface. Popular examples for interfaces are the concept of interfaces in programming languages like Java or the interface of a hardware component.
We finally see a service as a structureless, reusable unit of behaviour that specifies its behaviour depending on certain assumptions to the environment. These assumptions about the environments are specified as services as well, namely as a set of needed services.
So our idea of a service differs from the concept of a component by the fact that a service does not define any structural constraints but the interface. In contrast to a component this defines the internal structure in term as of a glass box view. A service is therefore a clipping of a component behaviour that is underspecified concerning the internal structure and is defined using assumptions about the environment, leading to a partial behaviour.
Service Formalization
In this section we present the formalization of our service idea. We start with a general introduction of the used model FOCUS, a mathematical model that builds upon the relation between input and output streams of messages. Then we explain how to integrate the concept of services into this model.
FOCUS
For the mathematical model, we use an adapted version of the general model introduced in [BS01]. Basically, the mathematical model of a component (or service) consists of its externally observable behavior, i.e. the messages received from the environment or sent to it. Messages are sent and received via channels. We use a timed model, splitting the observable behavior into time slots; during each time slot, an arbitrary (but finite) number of messages can be received or sent via each channel. The behavior of a component or service can then be described by channel histories, assigning a sequence of messages to each channel and time slot. In the following, we introduce stream relations to model those forms of behaviors.
For a given set of messages M, the set M* defines the set of finite sequences of messages; <> defines the empty sequence consisting of no messages. For two sequences m1, m2 of messages, we define the relation m1≺m2 to hold iff m1 is a subsequence of m2.
To model an observed interaction of exchanged messages from the set M, we use the set of possibly infinite streams of finite sequences, with notation Mω. Complete observations are modeled by infinite streams M∞.
Since infinite streams of finite sequences can be identified with functions from the natural numbers Nat to finite sequences M*, i.e. Mω ≡Nat→M*, we use the notion s(t) for the finite message sequence assigned to time slot t∈Nat of a stream s∈Mω. For both finite sequences and possibly infinite streams, m1 m2 defines their concatenation, m1≤m2 the prefix relation.
To combine observation with channels, we introduce the notion of a channel history. Given a set C of channel identifiers, a channel history is a mapping from those identifiers to message streams M∞. The set of all channel histories for a given set of channel identifiers is described by C , i.e., C≡C→M∞. For a channel history
h∈C , we define the notion of a message occurring during an interval of time slots: m@[start,end ]h= ∃t∈[start,end ]. m≺h(t)
Furthermore, we define the restriction h↑C′ of a channel history h to subset C′ ⊆C
by standard function restriction. Concatenation is extended to histories h1 h2 by concatenating their messages streams, and the prefix relation is extended similarly.
Finally, using channel histories, we define the behavior of a component or service with a given interface by a relation of channel histories. For a given set of channel identifiers, interfaces are defined as pairs (I,O) of channel identifiers with disjunctive sets I and O:
I⊆C∧O⊆C∧I∩O= ∅.
Given an interface (I,O), a stream relation s over this interface is defined as a (partial) function s :I →℘(O) .2For stream relation s, we define the domain
dom(s)={i∈I | s(i)≠ ∅}.
For a stream relation with interface (I,O), we define its restriction s↑(I′,O′) to a sub-interface (I′,O′) with I′ ⊆I,O′ ⊆O by
s↑(I′,O′)={(i↑I′,o↑O′) | (i,o)∈s}
using restriction of channel histories. Restriction corresponds to the hiding of channels.
Note that – since we focus on the introduction of a service notion - in this short introduction we did not impose additional requirements to be fulfilled by a stream function or relation to be realizable or implementable, e.g. a weak causality constraint or a strong realizabilty constraint as defined in [BS01]. In the following, we use the notation I ℘(O) for total stream functions respecting those additional properties. Note that the properties defined in [BS01] are union stable, i.e. for functions
s1,s2:I ℘(O), also s1∪s2∈I ℘(O) . Therefore, for a total function
s:I →℘(O) we can define ( ) [ ] s I O s s s s ′∈ ℘ ∧ ′⊆ =
∪
′as the most general causality respecting function implementing s .
For two total stream relations s1,s2 with interfaces (I1,O1) and (I2,O2) , resp., we define the composition s1⊗s2 to be the stream relation with interface
(I,O)=(I1∪I2\ (O1∪O2),O1∪O2) and behavior
1 2 { ( ) | ( ,1 1) 1 ( ,2 2) 2}
s ⊗ ≡ ∈s s I ℘O s↑ I O = ∧ ↑s s I O =s
given the syntactic compatibility O1∩O2= ∅. Compositions of stream relations correspond to combing components by connecting their common channels.
Interfaces vs. Components vs. Services
An interface
if
∈
IF
consists of two disjunctive sets of messages types I, O that represents the directed input and output channels of the interface. Each channel is defined by the set of messages that can flow via the channel.2Instead of functional notation for this set-valued function, we will also use relational notation for the ease of reading.
Based on the definition of an interface, we introduce the notion of acomponentas well as aservice.
Definition: A component can communicate with its environment by exchanging
messages over an interface. The behaviour of a component with an interfaceif = (I,O) is characterized by the atotalfunction c:I ℘(O) with dom(c)=I.
As mentioned in Section 0 a component also has a defined structure: it is either an atomic component or it has sub-components with their associated behaviors. Since we do not treat the structural aspects of service architectures here, no formal definition of structured components is introduced (the aspects of structured components and their behavior in the FOCUS model is treated, e.g., in [BS01] or [HS99]). The functionc describes the interaction behaviour of the component, i.e. the behaviour observable at its interface. Since a component might behave non-deterministically, different output reactions are possible for the same input. Since a component must however always react to input presented by its environment, totality of the function is expected, i.e. the condition
dom(c)=I
must hold for the component. This condition is equivalent to
∀i∈I. c(i)≠ ∅
capturing the intended intuition. In contrast to a component, a service behaviour needs not to be total.
Definition: A service s with the interface if = (I,O) is a partial function
s :I →℘(O) .
A service describes partial interaction behaviour. By allowing arbitrary behaviour (i.e. partiality), we can use services to describe only a partial behaviour offered by a component. According to these definitions a component’s behaviour is a special kind of service’s behaviour.
Note that there is a substantial difference between the definition of a component and a service: whereas a component is a total function that has a well defined result for all inputs a service is a partial function that is only defined for a subset of the domain. This means there are some inputs of a service where the definition of the service does not make any assertion how the service behaves.
To relate components and services we define the notion of provided services and subinterfaces. A service interface ifs=(Is,Os) is said to be a subinterface of an interface ifc=(Ic,Oc) if
Is⊆Ic∧Os⊆Oc
i.e. if the subinterface is a subset (of the channels) of the second interface. Since the notion of subinterfaces is only a syntactic notion, we must furthermore relate services and components considering their behaviour.
Definition: A component with interface ifc=(Ic,Oc) and corresponding behaviour
c :I ℘(O) provides a service with subinterface ifs=(Is,Os) and behaviour s :I →℘(O) if dom(s)⊆dom(c)↑Isand
∀i∈dom(c). (i↑Is)∈dom(s)⇒s(i)=c(i)↑Is
Intuitively, a component providing a service reacts as the service on the channels and inputs taken into account by the service. Note that from a formal point of view there is no difference whether a service is provided by an atomic component or by a network of components, since the latter can be substituted by the combined component as defined in Section 0.
We may furthermore specify the fact that a component requires a service to provide services in turn. A required service formally does not differ from a provided service besides the direction of the communication and the role it participates in the communication (e.g. sender, receiver).
Definition: A component requires a service with interface ifs=(Is,Os) and behaviour
s :I →℘(O) if it provides the complement service ifs=(Os, Is) with s :O→℘(I ) ,
Note that s denotes the complement function (relation) of s.
If a component c provides and requires a set of services si...sj, we demand that these services fulfil additional compatibility constraints. The simplest form of compatibility is called interface compatibility, defined by
∀
m, n
∈
{i,
…
, j}.m
≠
n
⇒
(I
m∩
I
n= ∅∧
O
m∩
O
n= ∅
)
This means that the input channels of the services as well as the output channels are pairwise disjoint. Further forms of compatibility are discussed in the following section.
Service Combination
An important issue when dealing with the combination of services is the problem of feature interaction. Feature interaction stands for the interaction and cooperation of two or more independently specified behaviours. Each function or behaviour may expose the intended behavior if used separately, however when combined unforeseen interaction patterns may show up. One separates between feature interaction (which denotes any patterns, also the purposed) and bad feature interaction (which denote those patterns that are unforeseen and not wanted). Feature interaction is a common and well-known problem that shows up in various disciplines, i.e. telecommunications. In this section we investigate how the explicit representation of the domain of a service helps in combining services and constructing complete component behaviour.
The combination of services is linked to the concept of compatibility of services: A compatible collection of services can be combined without exhibiting unwanted behaviour (like some form of unwanted feature interaction). Therefore, a notion of
compatibility of services is needed to combine services to form a component. In formal approaches dealing with the combination of features or services (e.g., [KB00] or [Sch02]), compatibility of services is defined in terms of consistency of the (specifications of) services. As usual, consistency of a set of specifications is interpreted as the property of having a model satisfying all specification. Analogously, we are therefore interested in a notion of compatibility for a set of ensuring the existence of a component providing these services.
To define such a notion, we will therefore first define a general combination
S{sm,…,sn} of services {sm,…, sn}.
Definition: For a set {sm,…, sn} of services, the interface of the combined service
S{s
m,…,sn} is defined as ifS{sm,…sn} =( Is s∈{sm,…sn}
∪
, Oss∈{sm,…sn}
∪
) . The combined service behaviour is defined asS{s
m,…,sn}(i)={o |∀s∈{sm,…, sn}. i↑Is∈dom(s)⇒o↑Os∈s(i↑Is)} . Note that be this form of combination, partial service behaviours are treated as underspecifications.
Definition: A combination of services {sm,…, sn} is called consistent if the
behaviour of the combined service
S{sm,…,sn} is partial only where all services are: { ,m , }.n ( ) ( { ,m , })n s
s s s dom s dom S s s I
∀ ∈ … ⊆ … ↑
Structured Specifications
In the previous sections, we used the general model of stream functions (or relations) to describe services. A service (or component) is described by relating complete input and output histories. However, this basic model is not generally suited to specify services. Generally, more structured forms of specifications are used, for example stepwise computations. In stepwise computations, the output of a service is computed stepwise: at each step (corresponding to a time slot) an output is computed, depending on the current input received at that step and the previous input. Using this structure, a service definition s is based upon an output function os depending on the current input ci and the previous input ih. Using a generic function hs splitting of the current input from the remaining input is, the service is then defined as
s(i)=<> hs(i,<>)
hs(ci is,ih)=os(ci,ih) hs(is,ih ci)
Using such a structure, a service is then completely defined by the output function. A typical example of stepwise computation is the state-based description of services. The simple structure defined above can of course be generalized to set-valued output functions to model nondeterminism, or to functions depending on the previous output, too.
Hierarchies of Compatibility
As described above, the most general intuitive form of compatibility is defined by consistency of services (i.e., the existence of a combined service). Since this form of compatibility is an existential property of the semantics, it is a rather sophisticated notion to be checked. On the other hand, the introduced notion of interface compatibility is a rather restricted notion leading to non-interacting services. Using such a strict form of compatibility notion for services has the advantage that compatibility is guaranteed by a design rule that can be check syntactically. From a methodical point of views, however intermediate forms of compatibility are useful that are accessible to automatic forms of checking as well as support interacting services.
Since the domain of a service describes its assumptions about the environment, we are interested in easier notions of compatibility defined via their domain, similarly to the definition of consistency. Since the explicit specification of the domain of a service generally is less complex than the specification of its behaviour, more efficient automatic proof procedure (e.g. model checkers) can be established.
Definition: A set of services {s1,…, sn} is called weakly compatible, if
∀i, j∈{1,…, n}.i≠ j⇒dom(si)↑Isj ∩dom(sj)↑Isi = ∅
It is called strongly compatible if
∀i, j∈{1,…, n}.i≠ j⇒dom(si)↑Isj ∩dom(sj)↑Isi = ∅ where T ≡{t' | t'≤t∧t∈T } .
As mention in Subsection 0, stream relations of components usually respect additional causality constraints. Therefore, the output of a component providing a service is restricted not only for inputs from the service domain but generally also for other inputs. By adding a prefix closure to the domains of the definition above, the notion of a strong compatibility is defined. A weakly compatible set of services {sm,…, sn}
ensures that this set is also consistent and thus the combined service S{sm,…,sn} exists. If furthermore the set is strongly compatible and the services respect the above mentioned causality properties, there exists a component c :I ℘(O) providing the
combined service with interface ifS{sm,…sn} =(I,O).
A – compared to interface compatibility - less restricted syntactic condition ensuring strong compatibility is output interface compatibility: Since a service specification only describes interactions of the component offering the service, it is sufficient to restrict the disjointness to the output channels: for services s1, s2, their output interface has to be disjoint, i.e. Os1∩Os2 = ∅.
For more restricted forms of service specification, even less restricted forms of compatibility ensuring consistency like event compatibility can be defined. This form of compatibility is defined for services described by stepwise computation. Here, two services s1, s2 are compatible if their output functions are disjoint, i.e. only react on different input. For example, for services with the same output interfaces and
corresponding output function oss1,oss2, the condition
∀i,ih∈I .oss1(i,ih)∩oss2(i,ih)= ∅must hold. Service Completion
Besides the methodical advantage of an explicit description of the service domain when defining the compatibility of services, the domain of a service is also useful when extending partial behaviour to a complete description as needed in constructing a component specification. To form a component specification out of a (combined) service description, the service description must be extended from a partial to a total specification. From a methodical point of view, different forms of canonical completions ˆs are possible for a service s. Two prominent examples are:
- Chaotic completion: If the combination exhibits some undefined behavior at some time point, in the canonical extension any behavior is possible afterwards. - Operational completion: If the combination exhibits some undefined behavior at
some time point, in the canonical extension no output is produced at that time point.
Chaotic completion is associated with a loose interpretation of a specification. Basically, we use a kind of Assumption-Commitment scheme to construct components from services by chaotic completion (c.f. [SDW93]). The domain part of a service forms the assumption, the service specification forms the commitment part. However, since for a given service s :I →℘(O) , the total function defined by
ˆschaos(i,o)≡i∈dom(s)⇒s(i,o) generally is not a causality-respecting function, a
component for this service is defined by c i o( , )=[sˆchaos( , )]i o as defined in Section 0. Operational completion is associated with an operational interpretation; it is, e.g., used in [HS01]. Using, e.g. a stepwise computation form of description, this completion can be easily constructed by adapting the output function:
oˆs(ci,ih)=
{
<> if oˆs(ci,ih)= ∅ os(ci,ih) if oˆs(ci,ih)≠ ∅.Methodical Issues
Besides giving the term of services a precise meaning the main advantage of the formalization of services is that it makes an (automated) support of services in a development process possible. Although methodology can not be in the focus of this paper we will try to sketch out how a possible process could be structured and what advantages services would bring to the systematic development of software systems.
Services allow modelling of the functionalities of the system without tailoring the structure of the system at the beginning of the development process. The system functionality can be extracted from very abstract specifications of the system, for example UML use cases, which do not narrow the later structure of the system either.
We can define a service architecture that specifies the system functionality by combining different services. In this service architecture the functional dependencies are specified but no structural issues (which component realizes which service).
After modelling the service architecture the different services can be deployed to component networks by composing services into a component type. By doing this structural attributed are added to the system specification. Note that the service architecture itself does constrain the structure of the system very little: a service specification can be realized by many component networks.
This deployment could be automated and therefore makes a formal and unambiguous composition necessary. Only with a precise composition of services and components we can avoid problems as described above concerning feature interaction.
Figure 1 gives a brief impression how a service based development process could make use of the separation of functionality and structural architecture of a system.
Interface Definition (abstrakt) Interface Definition (abstrakt) Iexrface Definition (abstrakt) Usecases (e.g. UML) Komponenten Spezifikation (konkret) Komponenten Spezifikation (konkret) Komponenten Spezifikation (konkret) Isolated Component (Specifications) Service Architecture (Specification) Isolated Service (Specifications) System specification (including structural specification) Service/Component Composition under compliance of feature interaction le ads t o is used by is used by formal foundation needed !
Figure 1: Basic steps of a service based development process
The process would exist of the following large grained steps: 1. Specification of use cases (i.e. UML)
2. Encapsulation of services out of the use cases
3. Modeling of the combination of different services and how they realize the specified functionality (service architecture)
4. Deployment of the services on a given set of components 5. Choice of realization and alternatives.
Note that until step four the system is specified without constraining its structure. The result of the deployment is a set of various possible realizations that offer the same functionality but differ in the structure (e.g. which component provides which service, which gives the development more flexibility and better applicability.
Example: An Instant Messaging System
We present a short example to illustrate the usage of services. For ease of reading we do not cover required services in this example. In our idealized instant messaging system we are able to send messages and instantly receive the status of the message, i.e. if the receiver has received the message. Of course we can also receive messages with the same information for the sender. The system is shown in the following figure as an informal automaton, using the notation c:msg()standing for the occurrence of a messagemsgon channel c. Due to readability we do not include the parameters.
Figure 2: The Instant messaging service
We model now the instant messaging system as a service, being a partial stream processing function. Due to simplicity we only specify a subset of the predicates. The remaining transitions follow analogously or the reader may refer to [BS01] for an algorithm for transferring automata to stream predicates:
' : ( ) { }; { } { , , , } ( ) { } { , } ( , ) .( ( ' . ( , , , ) @ ( , iMsg iMsg iMsg t instMsg I O I in O out
M getReceipt getMsg sendMsg sendReceipt dom instMsg in getMsg getReceipt instMsg i o
t
t t sendMsg id adress sender text o getReceipt adress id
∞ →℘ = = = = → ≡ ∀ ∀ < ⇒ ] ', ] ] , ] ) @ ) ( , , ) @ )) ( , ) @ t t t t t i
getMsg id sender text i sendReceipt sender id +α
∧ ⇔ noMsg sent recieved in:getReceipt() out:sendMsg() in:getMsg() out:sendReceipt()
This means informally that if we receive a message getMsg at the time t with the according parameters we demand that there will be within a timeframe
α
a messagesendReciept on the output channel. The additional first predicate specifies that if we
send a message we will eventually get a receipt message for this sent message (if the receiver has read it).
If we now specify a component that provides this service instMsg, we have to specify a total function:
: ( ); { }; { } ( , ) [ ( ) ( , )] mC mC myClient I O I in O out
myClient i o i dom instMsg instMsg i o
℘ = =
≡ ∈ ⇒
To construct the component from service specification, we use chaotic completion as defined in section Service Completion above.
We now specify two additional services which we will later combine in one component: a forwarding service that forwards all messages to a certain address
FwdAddress and an autoreply service that replies a message ArMsg automatically to
each sender of any received message:
] , 1] : ( ); { }; { } { , } ( ) { } { } ( , ) . ( , , ) @ ( , , , ) @ fwd fwd fwd t t t forward I O I in O out M getMsg sendMsg
dom forward in getMsg
forward i o
t getMsg id sender text i sendMessage id FwdAddr sender text o
∞ + →℘ = = = = → ≡ ∀ ⇔ ] , 1] : ( ); { }; { } ( ) { } { } ( , ) . ( , , ) @ ( , , ) @ aR aR aR t t t autoReply I O I in O out
dom autoReply in getMsg autoReply i o
t getMsg id sender text i sendMsg id sender ArMsg o
∞ + →℘ = = = → ≡ ∀ ⇔ Combining Services
We now specify a component that combines all three services instMsg, forward and
autoReply. One of the most hazardous problems of combining behaviour is the
composing services and component which handle the problem of feature interaction in different ways (from pragmatical to general consistency).
The first problem is to detect if any kind of feature interaction may show up. In our example one may have recognized that both services, forward and autoreply, are defined using the same messages. So if both would be using the same channels this would be a potential candidate for feature interaction. However, since we used a composition with interface compatibility separating the channel sets we have disjoint domains and avoid therefore any kind of feature interaction. Indeed if we combined them with shared channels we would have to specifiy if a message should be auto replied, forwarded or both (which does not make very much sense).
1 2 3 1 2 3 1 1 1 2 2 2 3 : ( ); { } { } { }; { } { } { }; ({ , , },{ , , }) [ ( ) ( , ) ( ) ( , ) ( ) fwd aR iMsg fwd aR iMsg combinedClient I O
I in in in O out out out
combinedClient i i i o o o
i dom instMsg instMsg i o i dom forward forward i o i dom autoreply au ℘ = ∪ ∪ = ∪ ∪ ≡ ∈ ⇒ ∧ ∈ ⇒ ∧ ∈ ⇒ toreply i o( ,3 3)]
As described above, the deployment can assign more than one component network to one service architecture. In our example we mapped the three services forward,
autoReply and instMsg into one component that composed all three services.
Nevertheless the same functionality could also be mapped onto other structures as the following example shows: we map the service architecture onto a network existing of two components, one providing the forward and instMsg services, the other the
autoReply service..
ComponentA :IA ℘(OA);
IA ={infwd}∪{inmsg};OA ={outfwd}∪{outmsg};
componentA({i1,i2},{o1,o2})≡
[i1∈dom(instMsg)⇒instMsg(i1,o1)∧i2∈dom( forward)⇒ forward (i2,o2)]
ComponentB :IB ℘(OB);
IB ={inaR};OB ={outaR};
componentB({i1},{o1})≡
[i1∈dom(autoReply)⇒autoReply(i1,o1)]
Network :INW ℘(ONW);
INW =IA∪IB;ONW =OA∪OB;
Both solutions realize the same functionality but differ substantially in the structure of the system. The following Figure 3 illustrates the two different deployments graphically: In the first case three services are composed into one atomic component
combinedClient ; in the second case the service architecture is realized by a
component network that exists of two different parallelly composed atomic components, componentA and componentB. The first provides the forward and the
autoReply service, the latter the instMsg service.
combinedClient componentB componentA Network in_fwd Service Specification: -instMsg - autoReply - forward deployment deployment in_aR in_instMsg in_fwd in_aR in_instMsg out_fwd out_aR out_instMsg out_fwd out_aR out_instMsg
Figure 3: Two different deployments
Note that this combination totally disenables any kind of feature interaction – good and bad one. [JZ00] shows that the question whether an interaction is undesirable is rather complex leading to hints for a suitable resolution at best; thus the subject of resolving feature interaction is not addressed here. Generally, however, if one wants to avoid bad feature interaction and enable good one, one has to specify which message is consumed by which service explicitly. This could be done by multiplexing the disjoint input- and output-channels to one input and output channel at a splitting component that receives the messages and forwards to the disjoint channels of the services. This can be specified with the above described component combination of FOCUS.
Conclusion
In this article we introduced a formal definition of the notion service and related it to formal model of interacting components. Essential aspects of our service notion are its partiality and its separation between functionality and structure. The introduction of different notions of compositionality and combination as well as the sketched structured specification of services and development process lays a first foundation for a methodical service-based development process.
While the introduced foundation offers the basic elements to construct service architectures and map them onto component architectures, is has to be enriched for application in an engineering process: Since, e.g., state-based descriptions are popular in the service domain, the stepwise computation scheme must be adapted to specify service domain and service behavior in a state-based fashion. Mechanical support for the checking of compatibility of services – especially for those exceeding output or interface compatibility - must be defined as well as support for the solution of conflicts. Finally, based on those techniques, a fine-grained development process must be defined, especially dealing with issues of restructuring and recombination.
References
[BL01] Berners-Lee, T. Are we done yet?. http://www.w3.org/2001/Talks/0501-tbl/ [BS01] Broy, M. Stoelen, K. Specification and Development of Interactive Systems.
Springer, 2001.
[CCM+] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana: Web Services
Description Language (WSDL) 1.1,W3C Note http://www.w3.org/TR/wsdl [HS01] Huber, F. Schätz, B. Integrating Formal Description Techniques. In: FM'99
--Formal Methods, Volume II. Wing, J. Woodcock, J. Davies, J. (eds.). Springer, 1999.
[JZ00] Jackson, M. Zave, P. New Feature Interactions in Mobile and Multimedia
Telecommunication Services. In: Calder, M. et al. (eds.) Proc. 6th Feature Interactions in Telecommunications and Software Systems. IOS Press, 2000. [KB00] Khousomi, A. Bevelo, R. A Detection Method Developed after A Thorough Study
of the Contest Held in 1998. In: Calder, M. et al. (eds.) Proc. 6th Feature Interactions in Telecommunications and Software Systems. IOS Press, 2000. [Lam93] Lamport, L. Specification and Verification of Concurrent Programs. In: de Bakker,
J.W. et al. (eds.). A Decade of Concurrency. LNCS Vol. 803. Springer, 1993. [LT89] Lynch, N. Tuttle, M. An Introdcution to Input/Output Automata. CWI Quaterly
3(2). 1989.
[Müh96] Mühlhäuser, M. (Ed.): Special Issues in Object- Oriented Programming – Proceedings of WCOP 96, dpunkt Verlag, Heidelberg, Gemany, 1997
[Oas02] OASIS Web Page http://www.oasis-open.org/committees/wscm
[Sal02] Christian Salzmann Modellbasierter Entwurf spontaner Komponentensysteme. PhD Thesis Technische Universität München 2002.
[Sch02] Schätz, B. Towards Service-Based Systems Engineering: Formalizing and
mu-Checking Service Specifications. Technical Report TUMI-0602, TU München, 2002
[SDW93] Stoelen, K. Dederichs, F. Weber, R. Assumption/Commitment Rules for Networks
of Asynchronously Communicating Agents. Technical Report TUM-I9303, TU München, 1993.
