Service based Software Specification

Transcription

1 Service based Software Specification Christian Salzmann 1, Bernhard Schätz [salzmann Software & Systems Engineering Technische Universität München Arcisstrasse 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 1 This work was supported by Microsoft Research LTD.

2 2 Christian Salzmann, Bernhard Schätz [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 modelchecking 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.

3 Service based Software Specification 3 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, thesetm* defines the set of finite sequences of messages; <> defines the empty sequence consisting of no messages. For two sequences m 1,m 2 of messages, we define the relation m 1 m 2 to hold iff m 1 is a subsequence of m 2. To model an observed interaction of exchanged messages from the set M, weuse 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, m 1 m 2 defines their concatenation, m 1 m 2 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.Thesetofallchannel 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)

4 4 Christian Salzmann, Bernhard Schätz 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 h 1 h 2 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), astream relation s over this interface is defined as a (partial) function s : I ( O). 2 For stream relation s, wedefinethedomain dom(s) = {i I s(i) }. For a stream relation with interface (I,O), we define its restriction s (I,O ) toasubinterface (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 s 1,s 2 : I ( O), also s 1 s 2 I ( O). Therefore, for a total function s : I ( O) we can define [] s = s s I ( O) s s as the most general causality respecting function implementing s. For two total stream relations s 1,s 2 with interfaces (I 1,O 1 )and(i 2,O 2 ), resp., we define the composition s 1 s 2 to be the stream relation with interface (I,O) = (I 1 I 2 \(O 1 O 2 ),O 1 O 2 ) and behavior s1 s2 { s I ( O) s ( I1, O1) = s1 s ( I2, O2) = s2} given the syntactic compatibility O 1 O 2 =. 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. 2 Instead of functional notation for this set-valued function, we will also use relational notation for the ease of reading.

5 Service based Software Specification 5 Based on the definition of an interface, we introduce the notion of a component as well as a service. Definition: A component can communicate with its environment by exchanging messages over an interface. The behaviour of a component with an interface if = (I,O) is characterized by the a total function c : I ( O) withdom(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 function c 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 if s = (I s,o s ) is said to be a subinterface of an interface if c = (I c,o c )if I s I c O s O c 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.

6 6 Christian Salzmann, Bernhard Schätz Definition: A component with interface if c = (I c,o c ) and corresponding behaviour c : I ( O) provides a service with subinterface if s = (I s,o s ) and behaviour s : I ( O) if dom(s) dom(c) I s and i dom(c). (i I s ) dom(s) s(i) = c(i) I s 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 definedinsection0. 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 if s = (I s,o s ) and behaviour s : I ( O) if it provides the complement service if s = (O s,i s )withs : O ( I ), Note that s denotes the complement function (relation) of s. If a component c provides and requires a set of services s i...s j, 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

7 Service based Software Specification 7 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,,s n } of services {s m,,s n }. Definition: Foraset {s m,,s n } of services, the interface of the combined service S {sm,,s n } is defined as if = ( S{s I s, O s ). The combined service m, sn} s {s m, s n } s {s m, s n } behaviour is defined as S {sm,,s n } (i) = {o s {s m,,s n }. i I s dom(s) o O s s(i I s )}. Note that be this form of combination, partial service behaviours are treated as underspecifications. Definition: A combination of services {s m,,s n } is called consistent if the behaviour of the combined service S {sm,,s n } is partial only where all services are: s { s,, s }. dom( s) dom( S{ s,, s }) I m n m n s 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.

8 8 Christian Salzmann, Bernhard Schätz 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 {s 1,,s n } is called weakly compatible, if i, j {1,,n}.i j dom(s i ) I s j dom(s j ) I si = It is called strongly compatible if i, j {1,,n}.i j dom(s i ) I s j dom(s j ) I si = 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 {s m,,s n } ensures that this set is also consistent and thus the combined service S {sm,,s n } 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 if = (I,O). S{sm, s n } 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 s 1,s 2,their output interface has to be disjoint, i.e. O s1 O s2 =. 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 s 1,s 2 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

9 Service based Software Specification 9 corresponding output function os s1,os s2, the condition i,ih I.os s1 (i,ih) os s2 (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 ŝ are possible for a service s.twoprominentexamplesare: - 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 ŝ chaos (i,o) i dom(s) s(i,o) generally is not a causality-respecting function, a component for this service is defined by c(, io) = [ sˆ chaos (, io)] 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: <> if oŝ(ci,ih) = oŝ(ci,ih) = { os(ci,ih) if oŝ(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).

10 10 Christian Salzmann, Bernhard Schätz 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. Usecases (e.g. UML) leads to Service Architecture (Specification) is used by Isolated Iexrface Interface Service Definition Definition (Specifications) (abstrakt) (abstrakt) formal foundation needed! Service/Component Composition under compliance of feature interaction is used by Komponenten Komponenten Komponenten Isolated Spezifikation Spezifikation Spezifikation Component (konkret) (konkret) (konkret) (Specifications) System specification (including structural specification) 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.

11 Service based Software Specification 11 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 amessagemsg on channel c. Due to readability we do not include the parameters. sent in:getmsg() recieved out:sendmsg() in:getreceipt() nomsg out:sendreceipt() 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: instmsg : I ( O) I = { inimsg}; O = { outimsg} M = { getreceipt, getmsg, sendmsg, sendreceipt} dom( instmsg) = { inimsg} { getmsg, getreceipt} instmsg(, i o) t.( ( t ' < t. sendmsg( id, adress, sender, text)@ o getreceipt( adress, id)@ i) getmsg( id, sender, text)@ i)) sendreceipt( sender, id)@ α t t ' ], t t+ ] ]',] t t

12 12 Christian Salzmann, Bernhard Schätz 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 message sendreciept 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: myclient : I ( O); I = { in }; O = { out } mc mc 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: forward : I ( O); I = { infwd}; O= { outfwd} M = { getmsg, sendmsg} dom( forward) = { in } { getmsg} fwd forward(, i o) t. getmsg( id, sender, text)@ i sendmessage( id, FwdAddr, sender, text)@ o t ] tt, + 1] autoreply : I ( O); I = { in }; O = { out } ar dom( autoreply) = { in } { getmsg} autoreply(, i o) ar ar t. getmsg( id, sender, text)@ i sendmsg( id, sender, ArMsg)@ o t ] t, t+ 1] 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 problem of feature interaction. As described in section 0 we have various ways of

13 Service based Software Specification 13 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). combinedclient : I ( O); I = { in } { in } { in }; O = { out } { out } { out }; fwd ar imsg fwd ar imsg combinedclient({ i, i, i },{ o, o, o }) [ i dom( instmsg) instmsg( i, o ) i dom( forward) forward( i, o ) i dom( autoreply) autoreply( i, o )] 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 : I A ( O A ); I A = {in fwd } {in msg };O A = {out fwd } {out msg }; componenta({i 1,i 2 },{o 1,o 2 }) [i 1 dom(instmsg) instmsg(i 1,o 1 ) i 2 dom( forward) forward (i 2,o 2 )] ComponentB : I B ( O B ); I B = {in ar };O B = {out ar }; componentb({i 1 },{o 1 }) [i 1 dom(autoreply) autoreply(i 1,o 1 )] Network : I NW ( O NW ); I NW = I A I B ;O NW = O A O B ; Network({i 1,i 2,i 3 },{o 1,o 2,o 3 }) componenta({i 1,i 2 },{o 1,o 2 }) componentb({i 3 },{o 3 })

14 14 Christian Salzmann, Bernhard Schätz 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. Service Specification: -instmsg - autoreply - forward deployment deployment Network in_fwd in_ar in_instmsg combinedclient out_fwd out_ar out_instmsg in_instmsg in_fwd in_ar componentb componenta out_instmsg out_fwd out_ar 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.

15 Service based Software Specification 15 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] [BS01] Berners-Lee, T. Are we done yet?. Broy, M. Stoelen, K. Specification and Development of Interactive Systems. Springer, [CCM+] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana: Web Services Description Language (WSDL) 1.1, W3C Note [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, [JZ00] Jackson, M. Zave, P. New Feature Interactions in Mobile and Multimedia Telecommunication Services. In: Calder, M. et al. (eds.) Proc. 6 th Feature Interactions in Telecommunications and Software Systems. IOS Press, [KB00] Khousomi, A. Bevelo, R. A Detection Method Developed after A Thorough Study of the Contest Held in In: Calder, M. et al. (eds.) Proc. 6 th Feature Interactions in Telecommunications and Software Systems. IOS Press, [Lam93] Lamport, L. Specification and Verification of Concurrent Programs. In: de Bakker, J.W. et al. (eds.). A Decade of Concurrency. LNCS Vol Springer, [LT89] Lynch, N. Tuttle, M. An Introdcution to Input/Output Automata. CWI Quaterly 3(2) [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 [Sal02] Christian Salzmann Modellbasierter Entwurf spontaner Komponentensysteme. PhD Thesis Technische Universität München [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.