Hierarchical Service De nition Bernhard Ste en, Tiziana Margaria, Volker Braun Universitat Passau(Germany) Nina Kalt Siemens AGy, Munich (Germany) Abstract
The most innovative feature of INXpress, Siemens' solution to global advanced Intelligent Networks, is its advanced Service De nition environment ASD. In this paper we present a tool for the hierarchical de nition of intelligent network services, which is realized by means of IN-MetaFrame. Technically, hierarchical service structure is introduced by means of a powerful macro mechanism, which allows developers to de ne whole subservices as primitive entities, which can be used just as Service Independent Building Blocks. As macros may be de ned on-line and expanded whenever their interna become relevant, this supports a truly hierarchical service construction. Moreover, as macros have formally the same interfaces as SIBs, this supports the reuse of already designed (sub-) services. The macro concept of IN-MetaFrame goes hand in hand with its formal veri cation and abstract views features.
1 Background: Intelligent Networks By integrating telecommunication and computer technology, the Intelligent Network concept (see [6] for an overview) helps (network) providers to make new and exible telecommunication services available for their customers. Particularly complex examples of such services currently o ered are Universal Personal Telecommunication (UPT) and Virtual Card Calling (VCC):
The UPT service combines personal mobility with the access to and from telecommunication over a unique number and account. Using a personal identi er, a service subscriber can access telecommunication services at any terminal and use those services provided by the network which are de ned in their own service pro le. Personal mobility involves the capability to identify the location of the terminal currently associated with the subscriber. Incoming UPT calls must be routed to the current
Universitat Passau, Innstr. 33, D-94032 Passau (Germany), tel: +49 851 509.3090, fax: +49 851 509.3092, fsteffen,tiziana,
[email protected] . y Siemens AG, ON Business Unit TMN/IN, Hofmannstr. 51, D-81379 Munich (Germany), tel: +49 89 722.35110, fax: +49 89 722.34821 .
1
destination address, and the associated charge may be split between the calling line and the UPT subscriber. Subscribers can use any terminal in the network for outgoing UPT calls, which are charged to their accounts. This requires user identi cation and authentication on a per-call basis. The use of the optional follow-on feature allows one authentication procedure to continue to be valid for subsequent calls or procedures. The service package can be tailored to the subscriber's requirements selecting from a comprehensive service feature portfolio. The VCC service allows subscribers to make calls from every private or public telephone charging their own VCC account. VCC calls are free of charge for the originating telephone line, so that cash or cards are no more needed at public telephones. After dialling the de ned access code, VCC subscribers have to identify themselves by entering their virtual card number, used by the VCC service provider to determine the subscriber's account for billing purposes, and a Personal Identi cation Number (PIN) for personal authorization. If the virtual card number and the PIN are valid and match, the VCC user can dial the desired destination number and will be connected.
Additional services o ered today are Free-Phone (FPH, in the USA also known as 800service), Televoting (VOT, e.g. for selection of Saturday night movies via telephone), Universal Access Number (UAN, where service subscribers can be reached from anywhere under a unique universal, network-independent directory number), Premium Rate Service (PRM, which enables the service subscriber to supply any information under a unique number and against a usage fee), and Virtual Private Network Service (VPN, which allows subscribers to de ne a private number plan based on a public telephone exchange). The underlying intelligent networks are composed of several subsystems that together implement the intended functionality. They form complex distributed systems, which require the cooperation of central computers, of databases, of the telephone network, and of a huge number of peripherals under real-time and performance constraints. In particular, the design of new services must take into account requirements imposed by the underlying intelligent network: e.g., system-dependent frame conditions must be obeyed in order to guarantee reliable execution of the new services. Figure 1 shows an abstract functional decomposition of an intelligent network, which comprehends management, control, switch and service creation units. A more detailed description of IN components and their functions can be found in [2] and [4].
The Service Management Point (SMP) serves as the central component for the
creation, customization and management of services and service subscribers/users. Based on a database system and on an advanced authorization system, the SMP allows the installation and administration of services and service customers by service subscribers and providers using the associated interfaces (Service Creation Environment, SCE). The SMP also provides interfaces for statistic raw data and for mass data entry. 2
3 of an Intelligent Network Figure 1: Global Architecture
The Service Control Point (SCP) controls the Service Switching Point according
to the control parameters provided by the SMP. The SCP also compiles statistical information of the calling activities and other call-related data and makes them available via the SMP for further processing. Information between SCP and SSP is exchanged via the INAP communication protocol. The CCS7 network is used to exchange the signalling information between the SCP and the Service Switching Point (SSP). The SSP sets up the call between the calling party and the called party in conjunction with the underlying telephone network (mobile or public exchange). An Intelligent Peripheral (IP) can be attached to the SSP for playing announcements or for other automatic voice services. The Service Creation Environment Point (SCEP) provides Customer Service Control (CSC), Service Customization (SC) and Service De nition (SD).
{ The Customer Service Control component supports the handling of the sub-
scriber-speci c service data such as parametrization of a subscribed service, modi cation and adaptation of service logic and statistics inquiries. { The Service Customization process serves to de ne which service functions and features the service subscribers are allowed to use according to their needs. { The aim of Service De nition is to establish the logic of a service and the parameters which control the processing of the service. The de nition of a service begins with the creative process of detailed service speci cation, in which various aspects such as market requirements, technical performance (load criteria) and serviceability must be taken into account.
The complexity of the new services and the complexity of the distributed environment in which they must correctly function under strict real-time requirements of availability and performance currently make service de nition intricate and error prone. Thus the introduction of new complex services like the ones mentioned above takes several expert years for development and testing. Service De nition is intended to support a reliable service design and development tailored to the speci ca of the intelligent network in order to shorten time to market by reducing both the development and the testing phase. INXpress, the Siemens solution to Advanced Intelligent Networks, is a commercial product which has been presented at various international fairs (e.g. CeBIT'97), and which is installed at a number of customers (e.g. Deutsche Telekom, South Africa's Vodacom, Finnland's RadioLinja), while further contracts (like Switzerland's PTT and Germany's T-Mobil, Mannesmann, and VIAG) have meanwhile followed. R The implementation of the Service Design Environment is based on MetaFrame (see R 2 1
[16]) . It is currently available for UNIX systems, e.g. the Siemens Nixdorf RM line, and for PCs under LINUX. 1 2
R is a registered trademark. MetaFrame R
UNIX is a registered trademark, licensed exclusively through X/OPEN Company Ltd.
4
Consistency Rules
Control
Modification
Service Logic Libraries
Control
Synthesis Selection
Concretization Executable Prototype
View Abstraction
Compilation
IN-Service
Figure 2: The Service Creation Process In this paper we focus on hierarchical service design within IN-MetaFrame. Technically, this is realized in form of a powerful mechanism for the de nition, parametrization and reuse of macros, which is fully compatible with both formal veri cation and abstract views. This allows developers to de ne whole subservices as primitive entities, which can be used just like SIBs. As macros may be de ned on-line and expanded at need, whenever their interna become relevant, this supports a truly hierarchical service construction. Moreover, as macros have formally the same interfaces as SIBs, this enhances the reuse of already designed (sub-) services. Before concentrating on the new feature, we brie y recall the outline of Service De nition in INXpress [17, 3].
2 Service De nition in
INXpress
The INXpress solution to Advanced Service De nition, realized by means of the INMetaFrame environment, is constructed for the exible and reliable, aspect-driven creation of telephone services in a `divide and conquer' fashion (see Figure 2): initial prototypes are successively modi ed until each component satis es the current requirements. The entire service creation process is supported by thematic views that focus on particular aspects of the service under consideration. Moreover, the service creation is constantly accompanied by on-line veri cation of the validity of the required features and of the executability conditions for intermediate prototypes: design decisions that con ict with the constraints and consistency conditions of the intended service are immediately detected via model checking. The novelty of this SD environment is due the impact of formal veri cation and abstract views on service creation [13, 14]. In fact, 5
Formal veri cation allows designers to check for global consistency of each design step
with implementation-related or service-dependent frame conditions. Being based on model checking techniques [10], it is fully automatic and does not require any particular technical knowledge of the user. This simpli es the service design since sources for typical failures are detected immediately. Abstract or thematic views concentrate on the required global context and hide unnecessary details. They allow the designer to choose a particular aspect of interest, and to develop and investigate the services under that point of view. This supports a much more focussed service development, which concentrates on the design of the aspect currently under investigation. Of particular interest are error views that concentrate on the essence of a detected error as explained in Section 2.2.
Both formal veri cation and abstract views are fully compatible with the macro facility of the environment. This allows developers to de ne whole subservices as primitive entities, which can be used just as SIBs. As macros may be de ned on-line and expanded whenever the interna of a macro become relevant, this supports a truly hierarchical service construction.
2.1 Formal Veri cation
The complexity of the underlying intelligent network leads to certain frame conditions (constraints) that must be met in order to guarantee successful execution of the designed service in the context of the IN architecture. Orthogonal to the prototype animation (red-line tracing), IN-MetaFrame provides automatic veri cation with respect to formal speci cations. We distinguish two kinds of correctness: local correctness, guaranteeing e.g. the correct parametrization of single SIBs, global correctness and consistency of the service prototype, concerning the interplay between the SIBs of a service. While local checks are quite straightforward to implement (cf. [13]) and are also present in other service creation environments, the MetaFrame-based environment is unique in providing fully automatic veri cation of global correctness and consistency conditions of the service logic: vital properties concerning the interplay between the SIBs of a service can be veri ed at any time during the design via model checking in a push-button fashion. A property is global if it does not only involve the immediate neighbourhood of a SIB in the Service Logic graph3, but also relations between graph nodes (SIBs) which may be arbitrarily distant and separated by arbitrarily heterogeneous subgraphs. The treatment of global properties is required in order to capture the essence of the expertise of designers about do's and don'ts of service creation, e.g. which SIBs are incompatible, or which can or cannot occur before/after some other SIBs. Such properties are rarely straightforward, sometimes they are documented as exceptions in thick user manuals, but more often they are not documented at all, and have been discovered at a hard price as bugs of previously 3
I.e., the set of all the predecessors/successors of a node along all paths in the graph.
6
developed services which obstinately did not want to obey the known rules. They build exactly the kind of precious domain-speci c knowledge that expert designers accumulate over the years, which is particularly worthwhile to include in the design environment for future automatic reuse. Global properties are expressed in a user friendly speci cation language (see [14]), and gathered in a constraint library which is automatically accessed by the model checker during the veri cation. The maintenance of the constraint library is supported by the hypertext system. We use the model checker of [10], which is optimized for dealing with large numbers of constraints, in order to allow veri cation in real time. The algorithm veri es whether a given model satis es properties expressed in a modal logic called the modal mu-calculus [7]. In the SD-IN setting:
the properties express correctness or consistency constraints the target IN service
is required to respect. They are expressed in a user friendly, natural language-like macro language, which is based on the temporal logic SLTL (Semantic Linear Time Logic, cf. [18]). This is a linear-time variant of Kozen's mu-calculus [7], which comes together with ecient veri cation tools; the models are directly the service logic graphs, where SIB names correspond to atomic propositions, and branching conditions correspond to action names in the SLTL formulas.
A user-friendly graphical interface, displaying all the relevant data, supports the model checking procedure. Model checking a service, as later shown in Section 4 on a concrete case, may lead to the discovery of paths in the graph violating some global constraints. When the model checker detects such an inconsistency, a plain text explanation of the violated constraint appears in a window. To ease the location and correction of the error, an abstract error view is automatically generated, which evidences only the nodes which are relevant to the error detection.
2.2 Abstract Views and Error Correction
Views are abstract service models. As such, they show aspects of actual, concrete models. They are used to hide any aspect of an IN model which is irrelevant wrt. an intended operation. This is useful during the development phase in order to concentrate on speci c themes, e.g., the billing or the user-interaction contained in a service, while abstracting from all the rest. This is a solution to the problem of the growing size of the services, which may contain several hundreds of nodes, and which are in their whole unmanageable. In the same way, views can also embody a very exible access policy: only the nodes a user is allowed to touch are left concrete, i.e. correspond to a SIB or a macro. Operationally, views do not di er much from the actual IN models. E.g. they can be loaded and edited in the usual way, however, often with quite dramatic e ects: minor modi cations on views may correspond to radical structural changes of the underlying concrete model. In addition, views can be created, corresponding to the application of an abstraction function, and applied to the underlying concrete model, corresponding to 7
the application of a concretization function (cf. Figure 2). Execution of a view means execution of the underlying (temporary) concrete model. Of particular interest are error views, which highlight the essence of a global inconsistency. This supports the detection of the error and simpli es its correction: errors can be corrected directly on the error view, and the subsequent view application transmits the modi cations to the concrete model. While examples have been already discussed in previous papers [13, 14], a concrete case of error correction in a hierarchical service will be discussed in Section 4. Current IN services have reached sizes and complexities which demand for automated support for error detection, diagnosis, and correction. The IN-MetaFrame environment encourages the use of the new methods, as they can be introduced incrementally: if no formal constraints are de ned, the system behaves like standard systems for service creation. However, the more constraints are added, the more reliable are the created services [15].
3 Hierarchical Service De nition. Basic steps of a hierarchical development of systems are component de nition and component reuse, and the integration of hierarchical development into an already existing environment requires a well-de ned interaction with already existing features. We will therefore illustrate our macro facility by showing how macros are created (Section 3.1) and reused (Section 3.2), and how they interact with our formal veri cation and abstract views (Section 4). The following simple Free-Phone (in the US known as 800-) service will be used for the explanation of the more advanced features of our macro concept, showing their interplay with the formal veri cation and abstract views.
Granny's Free-Phone The small service shown in Figures 4 and 5 presents the ow
graph of a simple kind of Free-Phone (800-service). This particular service is designed for people who would like to incentivate friends and relatives to call them by paying their calls if they are done at a convenient time of the day. In essence, the service logic is the following: after a call initialization section common to all services, the caller dials the desired speci c Free-Phone number, then a prompt requires entering a Personal Identi cation Number (PIN) and, if the PIN is correct, depending on the time of the day, the call is either released (in the forbidden time windows) after an announcement, or it is routed to the desired destination number.
3.1 Macro Creation
Services as well as macros are represented in our system as ow graphs, where nodes represent operations and edges branching conditions. In the IN application, operations may be either single Service Independent Building Blocks (SIBs) or whole macros. Branching conditions serve as guards, like in the case of personal identi cation requirements, or implement general run-time decisions, like context-dependent routings of calls or exception handling. Since both nodes and edges have parameters, the de nition of both 8
Figure 3: Macros Creation with SIB Palette operations and branching conditions is completed during the Service De nition by setting the required parameter values. In order to allow a homogeneous treatment of SIBs and macros, the de nition (creation) of macros requires several steps which serve to precise their intended semantics and interface.
De ning the Service Logic of a Macro.
The service logic contained in a macro is in principle an arbitrary service graph. As for any service logic, it may have been
constructed from scratch, by drag-and-drop from the palette of available SIBs (as in Figure 3, where the arrow indicates the highlighted pin SIB, which will be added to the graph next), in the same fashion as usual clipboard architectures support the de nition of services,4 or
4
This is adequate whenever a designer knows the importance of a certain service structure rightaway.
9
omaError1
pin_macro
Figure 4: The Granny's Free-Phone service.
`cut' out of a previously de ned service by using the graphical cut and paste facility of our environment.5
This graph may itself contain previously de ned macros as nodes, thus allowing the de nition of truly hierarchical service structures. E.g. in the Granny's Free-Phone service of Figure 4, frames indicate two levels of macros, the larger macro, omaError1,6 containing a smaller macro, pin macro. Figure 5 shows how the overall service looks when using either of the macros for abbreviation. This is adequate whenever the importance of a certain service structure becomes apparent after it has already been fully coded within an existing service. 6 This name indicates a design error of the macro, which will be discovered using formal veri cation in Section 4. 5
10
2) Level 2 Macro: omaError1
1) Level 1 Macro: pin_macro
Figure 5: Granny's Free-Phone: First and Second Level Macros.
De ning the Connection Points.
The rst macro-speci c de nition step is the selection of a unique start node and of a (non-empty) set of end nodes of the graph. This step is important to allow the de nition of an unambiguous ow of control whenever the macro is reused as a single node in future service logics.
De ning the Internal Control Flow.
The second step consists of the parametrization of all internal edges of the macro graph, which xes the ow of control within the macro. In addition, the user must attribute values to all the internal SIB parameters, i.e., those parameters that are not intended to be parameters of the macro itself. This speci cation of the internal structure of the macros is done via speci c inspector windows, which pop up automatically for each SIB. They show which valid parameters the user can assign to an edge. This is illustrated in Figure 6: the outgoing edge of the fci SIB is being parameterized in the Service 11
Figure 6: Macro's Parametrization Process Con guration window (right).
They present a \list box" of all SIB parameters of the node of interest including
their types and the actual values. Figure 6 (bottom) shows this for the prompt SIB. Here the status of each value is represented by the background colour of the value eld of each entry in the box: { red background indicates that the actual value of the parameter is the default value, { white background shows that the parameter has no assigned value, and { green background means that there is a user de ned value. In Figure 6, the prompt SIB has three unassigned parameter values and the other two are already user de ned, which is indicated by a green background on the screen. All this is in exact accordance with the de nition of edge and SIB parameters for full services as described in [13].
Completing the Macro Interface.
SIB parameters not touched in the previous step are automatically exported, i.e. they will appear as SIB parameters of the macro node. The edge parameters of the macro are the 12
edge parameters of its end nodes excluding their assigned parameters. The system makes sure that all edge parameters of non-end nodes are speci ed in this creation phase. In the last step of the macro creation process the user must complete the macro interface de nition, by eliminating all ambiguities concerning the exported parameters: since exported SIB and edge parameters may come from di erent internal nodes, parameter names are not sucient to individuate them uniquely. A renaming procedure, launched by the Create Macro menu command guarantees an unambiguous parameter naming.7 For every node in the macro logic graph, IN-MetaFrame presents a \list box" window with one row for each SIB parameter of the actual node that has no de ned value yet. In each row, the original parameter name is listed on the left side, and the designer enters on the right side the name he wants use to refer to this parameter in the macro's parameter list. A check of injectivity of the resulting renaming function, which excludes ambiguity, is automatic. Non-injective renamings are rejected. After the renaming of the exported SIB parameters, the user must rename the edge parameters of the macro graph's end nodes in a similar manner. In our example, Figure 7 summarizes the renaming process for the node parameters of the initdp, prompt, and pin1 SIBs, and for the edge parameters of the pin1 SIB, which is the end node.
Documenting Macros.
Finally, the design of the macro is completed by inserting on-line documentation into a pre- lled hypertext card. Each node of a graph has in fact an associated hypertext card, containing compact global information and, if wished, links to external information. The card shown in Figure 8 contains several elds necessary for internal purposes (like the de nition of a short name for display, binding to a speci c icon which will represent the macro in the graphical user interface, and version information), but also textual documentation, which serves as on-line user manual. Further elds (not yet lled in the gure), contain the code (here called HLL Code) which is executed in the trace (or interactive simulation) mode, and code which is executed whenever the macro will be reused within a service to ensure the local correctness of the macro in its new context (e.g., that all the macro parameters have been set), here called Local Check Code. After the hypertext card de nition is completed, the macro is ready to be reused and is from now on available in the SIB palette under the de ned icon and with the de ned short name.
3.2 Using Macros
Operations applicable to (atomic) SIBs are also applicable to a macro SIB with the same modalities. Macros appear in the SIB palette, from which they can be included as nodes of a service logic graph by usual drag-and-drop of their icon. The parameters of the macro can be set in the usual \list box" window, outgoing edges of the macro can be parameterized using the \inspector" window, exactly along the lines of parameter con guration for atomic SIBs. The renaming procedure is sometimes also useful for just changing names, in order to express the more speci c nature a parameter may have in the context of a macro. 7
13
Figure 7: Completing the Interface De nition Two macro-speci c operations show the hierarchical character of macros: Decapsulation zooms into the macro structure. Nested macros are decapsulated level-wise, one level at a time: decapsulation of the omaError1 macro of Figure 5 (right), which is a level 2 macro, results in the graph shown in the same gure on the left, which still contains the level 1 pin macro. Additional decapsulation of this macro yields the ( at) graph of Figure 4. Capsulation is the inverse operation, which folds the service graph according to its macros structure. Capsulation proceeds level-wise relative to a selected node, i.e. by capsulating one node, only the next-level macro containing the node is folded. Both operations are invoked from the node menu, and respect their corresponding renamings: IN-MetaFrame renames the outgoing edges of the macro SIB (resp. outgoing edges of the macro's end nodes) according to the renaming functions de ned in the interface de nition step of the macro creation. Some generic operations on service logic graphs violate the macros' structure when applied to decapsulated macros: changing the value of a internal SIB parameter, which is not in the macro interface, or changing the parameterization of an internal edge, 14
Figure 8: Documenting the Macro in the Hypertext System
removing a node or an edge of the macro graph, adding an edge from a non-end node of the macro or adding an edge into a node which is not the start node.
Clearly, these operations con ict with the design decisions made during the macro de nition, thus their occurrence is guarded by a warning box. If the designer con rms the o ending operation, the structure of this instance of the macro is destroyed. The decapsulated macro graph is no longer a macro, it becomes an ordinary subgraph of the service and cannot be capsulated any more. If the violating operation involves nodes in a deeply nested (decapsulated) macro, all the outer macros are destroyed as well (i.e., transformed into usual subgraphs), since their structure is also a ected. This is the minimal loss which guarantees consistency of the macro concept. In our example, removing an outgoing edge to the pin1 SIB of the service of Figure 4 would violate the de nition of both pin macro and omaError1 macros, which would be both destroyed. Adding an incoming edge to the same SIB would result in the destruction of the omaError1 macro only, since the change a ects the structure of the omaError1 macro, but not that of the deeper nested pin macro, in which the pin1 SIB is the start node.
4 Formal Veri cation of Hierarchical Services The frame conditions (constraints) that must be met in order to guarantee successful service execution in the context of the IN architecture are largely independent of the 15
hierarchical service structuring. To this aim, IN-MetaFrame's automatic veri cation with respect to formal speci cations of these constraints, already introduced in Section 2, must be able to cope adequately with macro structures, without loss of rigour or of eciency. While local correctness checks, guaranteeing e.g. the correct parametrization of single SIBs and edges, can be easily extended to cover macro SIBs on the basis of the macro de nition policy already illustrated, the realization of global correctness and consistency checks of the service prototype need special care for the adequate treatment of hierarchy.
Veri cation in the Presence of Macros.
Model checking has become a standard veri cation procedure for at models. However it is not directly applicable to hierarchical structures like the considered service logic graphs with macros. Following the principle described in [1] in the case of Statecharts veri cation, a preprocessing step transforms the given hierarchical model into an equivalent at model by getting rid of the hierarchical information in a semantics-preserving way. In the IN case, this attening preprocess exploits the de nition of the macros' operational semantics according to Section 3.1, and is therefore much simpler than the conversion needed in order to handle Statecharts, and constitutes a simple instance of the transformations described in the framework of unifying models in [19]. Once the equivalent at model has been obtained, standard model checking wrt. the given temporal logic formula can be applied along the lines of Section 2.1. Thus we are again able to use the ecient model checker of [10]. The fact that hierarchically de ned services are veri ed relative to the fully decapsulated service is coherent with the idea behind the macro concept, namely that it is an (auxiliary) means to structure complex services and it is not meant to have any semantic impact. Thus violation of constraints is independent of the particular structuring in terms of macros. In principle, the same applies to the error views, which are de ned relative to the fully decapsulated service. However, a service designer does not introduce macros by chance. Rather the macro structure is essential for him to better understand the service. IN-MetaFrame therefore preserves as much of the macro structure as possible when generating the error views, i.e. macros are only decapsulated if this is necessary for the error information. Intuitively, this is the case for macros which contain nodes that correspond to di erent nodes of the error view on the fully decapsulated service. Model checking the hierarchical version of the Granny Free-Phone service shown in Figure 9 (top left) results in the discovery of erroneous paths in the graph, which violate the constraint shown in the same gure in the top right window: on each segment (phase) of the call, a bill should be issued before the system can charge for the segment. The problematic part of the paths starts at the prompt node marked by the arrow, whose icon is framed in red on the screen. The corresponding error view is shown in Figure 9 (bottom left). Error views are generated automatically whenever a model checking attempt fails. Although this error view looks identical to the error view obtained when model checking the fully expanded version of the service shown in Figure 4, there is an essential di erence. This becomes apparent when applying e.g. the decapsulate source command, which is a view speci c operation supporting error correction, to the left edge into the zone SIB. This results in the graph shown in 9 (bottom left): the extracted source node is the macro pin macro, 16
Figure 9: The Model Checker Finds a Billing Error showing that the macro structure is preserved as far as possible also in error views. This allows hierarchical error correction, which can be performed along the lines explained in [13, 14] for at services.
17
5 Evaluation and Bene ts Intelligent Networks have changed the world of telecommunication in the last 5 years: today, practically everybody has already made use of IN services. To satisfy the growing expectation on IN services, a exible Service De nition is a must. Service Design Environments for the creation of IN-services are usually based on classical `Clipboard-Architecture' environments, where services are graphically constructed, compiled, and successively tested. Two extreme approaches characterize the state of the art: The rst approach guarantees consistency, but the creation process is strongly limited in its exibility to compose Service Independent Building Blocks (SIBs) to new services. The second approach allows exible compositions of services, but there is little or no feedback on the correctness of the service under creation during the development: the validation is almost entirely located after the design is completed. Thus the resulting test phase is lengthy and costly. The INXpress SD environment does not only allow designers to quickly tailor services of the complexity of Virtual Private Network for the speci c needs of an individual company, but also to provide completely new services in a short time span: using INXpress's SD environment Telecoms were able to considerably reduce the service production time, thus opening a new service-on-demand market. IN-MetaFrame is the rst and only industrial tool8 making advanced formal methods R applicable for non-specialists. In fact MetaFrame , the environment underlying INMetaFrame, has been developed with the goal of bringing automatic synthesis, analysis, and veri cation methods into practice in the same way as type checking entered the program development. The success in the INXpress-context indicates that this goal can be achieved in near future. The market's response to the innovation is very positive too: brought into the market at the beginning of 1996, the rst system deliveries took place in the rst semester of 1996 (e.g. Deutsche Telekom, South Africa's Vodacom, Finnland's RadioLinja). Meanwhile, further contracts (like Switzerland's PTT and Germany's T-Mobil, Mannesmann, and VIAG) have followed. The INXpress ASD with IN-MetaFrame is also Winner of the European Information Technology Prize 1996, the international prize awarded by the European Union through its Esprit-EUROCase organization. As such, it was invited to the ITEA'96 Exhibition, held in Bruxelles, November 25-27th 1996, joint with the European Information Technology Conference'96.
Acknowledgements
The authors are grateful to the members of the Passauer development team, of the Siemens and Siemens Nixdorf IN teams, and the team of GMRS for their precious interaction in the de nition of the characteristics of the system and for their valuable contributions to the realization of the current product. See the Special Issue of the ACM Computing Surveys for the ACM Workshop on Strategic Directions in Computing Research, Formal Methods Group [5], as well as the position statements [11, 12] in the same issue. 8
18
References [1] M. von der Beeck, T. Margaria, B. Ste en: \A Formal Requirements Engineering Method Combining Speci cation, Synthesis, and Veri cation", Proc. SEE '97, 8th IEEE Conference on Software Engineering Environments, Cottbus (Germany) 8-9 April 1997. [2] J. Biala: \Mobilfunk und Intelligente Netze," ISBN 3-528-15302-4, Vieweg, Braunschweig (D), 1995. [3] F.-K. Bruhns, V. Kriete, T. Margaria: \Service Creation Environments: Today and Tomorrow" tutorial, 4th Int. Conf. on Intelligent Networks (ICIN'96), Nov. 1996, Bordeaux (France). [4] B.E. Christensen, D. Underwood: \Kommunikationsnetze werden intelligenter," Telecom Report 14 (1991), Heft 5, pp. 262-265. [5] Ed Clarke, J. Wing: ACM Workshop on Strategic Directions in Computing Research, Position Statement of the Formal Methods group, Boston (USA), June 14-15 1996. ACM Computing Surveys 28A(4), Dec. 1996, http://www.acm.org/surveys/1996. [6] J. Garrahan, P. Russo, K. Kitami, R. Kung: \Intelligent Network Overview," IEEE Communications Magazine, March 1993, pp. 30-37. [7] D. Kozen: \Results on the Propositional -Calculus", Theoretical Computer Science, Vol. 27, 1983, pp. 333-354. [8] J.K. Ousterhout: \Tcl and the Tk Toolkit," Addison{Wesley, April 1994. [9] M. Reitenspie: \Bereitstellung hochzuverlassiger Systeme im Telekommunikationsbereich," Proc. der GI-Fachtagung VIS'95, H. Bruggemann, W. Gerhardt-Hackl (Eds.), Vieweg, Braunschweig (D), 1995, ISBN 3-528-05483-2. [10] B. Ste en, A. Claen, M. Klein, J. Knoop. T. Margaria: \The Fixpoint Analysis Machine", (invited paper) to CONCUR'95, Pittsburgh (USA), August 1995, LNCS 962, Springer Verlag. [11] B. Ste en, T. Margaria: Method Engineering for Real-Life Concurrent Systems, position statement for the Working Group on Concurrency, ACM Workshop on Strategic Directions in Computing Research, Boston (MA) 14-15 June 1996 { appears in ACM Computing Surveys 28A(4), December 1996, http://www.acm.org/surveys/1996/SteffenMethod/
[12] B. Ste en, T. Margaria: Tools get Formal Methods into Practice, position statement for the Working Group on Formal Methods, ACM Workshop on Strategic Directions in Computing Research, Boston (MA) 14-15 June 1996 { appears in ACM Computing Surveys 28A(4), December 1996, http://www.acm.org/surveys/1996/SteffenTools/
19
[13] B. Ste en, T. Margaria, A. Claen, V. Braun, M. Reitenspie: \An Environment for the Creation of Intelligent Network Services", invited contribution to the book \Intelligent Networks: IN/AIN Technologies, Operations, Services, and Applications { A Comprehensive Report" Int. Engineering Consortium, Chicago IL, 1996, pp. 287300 { also invited to the Annual Review of Communications, IEC, 1996, pp. 919-935. [14] B. Ste en, T. Margaria, A. Claen, V. Braun, M. Reitenspie: \A ConstraintOriented Service Creation Environment," Proc. PACT'96, Int. Conf on Practical Applications of Constraint Technology, April 1996, London (UK), Ed. by The Practical Application Company, pp. 283-298. [15] B. Ste en, T. Margaria, A. Claen, V. Braun: \Incremental Formalization: A Key to Industrial Success ", In \SOFTWARE: Concepts and Tools", Vol. 17, No 2, pp. 78-91, Springer Verlag, July 1996. [16] B. Ste en, T. Margaria, A. Claen, V. Braun: \The MetaFrame'95 Environment", (Experience Report for the Industry Day), Proc. CAV'96, Int. Conf. on ComputerAided Design, Juli-Aug. 1996, New Brunswick, NJ, USA, LNCS N. 1102, pp.450-453, Springer Verlag. [17] B. Ste en, T. Margaria, A. Claen, V. Braun, M. Reitenspie, H. Wendler: Service Creation: Formal Veri cation and Abstract Views, Proc. 4th Int. Conf. on Intelligent Networks (ICIN'96), Nov. 1996, Bordeaux (F). [18] B. Ste en, T. Margaria, A. Claen: \Heterogeneous Analysis and Veri cation for Distributed Systems", In \SOFTWARE: Concepts and Tools", vol. 17, N.1, pp. 13-25, Springer Verlag, 1996. [19] B. Ste en: Unifying Models, (invited talk), Proc. 14th Symposium on Theoretical Aspects of Computer Science (STACS'97), Feb. 27 - Mar. 1, 1997, Lubeck (D), to appear in LNCS, Springer Verlag.
20
