DE19619803B4 - Service Creation System - Google Patents

Abstract

Service Creation System (SCE), with
a) block objects (SIB), each describing a subfunction of an IN service,
b) service objects (FSL), each of which describes the structure of an IN service on the basis of said block objects (SIB),
c) a creation means (SD), which allows the creation of an IN service by generating said objects (SIB, FSL), characterized by
d) interface objects (STL), which are also generated during the creation of a service and contain a description of the external interfaces of a building block object (SIB), wherein said description comprises the respective parameters of an external interface,
e) a test device that checks the functionality of an IN service by using the said interface objects (STL) checks whether the (input) required by a block objects (SIB) by previous block objects (SIB ) to be delivered.

Description

The The invention relates to a service creation system.

• a) Baustein-Objekten (vgl. 1 i.V.m. Kapitel "2.0 CONCEPT OF SIB"), die jeweils eine Teilfunktion eines IN-Dienstes beschreiben,
• b)Dienst-Objekten, die jeweils die Struktur eines IN-Dienstes anhand der genanten SIBs beschreiben (vgl. Kapitel "3.1 SIB for Service Creation", insbesondere "flexibel service logic")
• c) einem Erstellungsmittel, das die Erstellung eines IN-Dienstes durch Erzeugung der genannten Objekte ermöglicht (vgl. Kapitel "5.2 Creating Service Templates " und Kapitel "5.3 Creating Specific Service "bzw. 7 "Service Editor").

From the document "A Reuse-Driven Service Creation Environment for the Advanced Intelligent Network" [online] SUPERCOMM / ICC'94, Conference Record, Vol. 1, IEEE International Conference, 1-5 May 1994, pp. 263-267 by Bernard S. Ku is particular from the abstract and the 1 . 2 . 5 and 7 In conjunction with the associated figure descriptions, a service creation system of an IN system (see abstract: "Service Creation Environment (SCE) ... to all the participants of the AIN [Advanced Intelligent Network]") is known, namely with

• a) Block objects (cf. 1 in the chapter "2.0 CONCEPT OF SIB"), each describing a subfunction of an IN service,
• b) service objects, each of which describes the structure of an IN service on the basis of the SIBs mentioned (see chapter "3.1 SIB for Service Creation", in particular "flexible service logic")
• c) a means of creation which makes it possible to create an IN service by generating the named objects (see chapter "5.2 Creating Service Templates" and chapter "5.3 Creating Specific Service"). 7 "Service Editor").

At the service logic of an IN service depends on the wishes of the Network Operator, Service Provider, Service Subscriber (Service Subscriber) or service user and the Network conditions a wide variety of requirements, the most diverse and most diverse manifestations lead this service logic can. For this reason, a tool is necessary, which is programmed in memory Switching systems a quick and flexible adjustment or recreation of services.

The said tool with which said objective can be achieved is called "Flexible Service Logic "(FSL), as shaping (Instance) of a service logic or briefly referred to as service logic (Service Logic). The service logic mentioned is a service-specific one Logic structure, whose elements, the so-called service building blocks (SIB), each a logical image of a functional routine, respectively represent a subfunction of the IN service.

A (expression a) service logic is thus determined by the flow of various functional Routines being defined individually can be used, which routines are applied and how logical Sequence is.

One FSL data structure and thus a specific service logic is with Help of a special tool, the so-called service creation system (Service Creation Environment SCE). With the help of this tool will first designed a logic structure and used to generate a service source file.

The contains said service source file a (graph) description of the logic structure of the FSL (description the SIBs and their concatenation within the FSL), a description the transient connection data relevant to the service (CID description) and a description of related needed the service semi-permanent data.

Out the said service source file are using a so-called Service converter, etc. Data structure prototypes and object code of the FSL generated.

The Placement of SIBs within a service logic is technical View only possible at certain points in the path of a service logic, and even only under consideration the entire logic structure. The description of this logic structure but it is very complex.

The admissibility Therefore, a placement of a SIB can so far only by consuming Tests are determined.

Of the Invention is based on the object, the said disadvantage avoid.

These Task is performed by an SCE according to claim 1 solved.

By The addition the parameter in the SIB description (SIB template description Language), the SCE can now determine from a path analysis, whether all parameters are satisfied. This means that without additional elaborate tests when adding SIBs always the completeness checked by the service logic can be.

in the The following will be an embodiment of Invention with reference to the drawing explained.

1 shows the hardware embedding of a service development system SCE (service creation system) within a control system (SCP, SMP) of an intelligent network. The service development system includes a service definition SD, a service management SM, and a cus tomer Service Control CSC. The parts mentioned are implemented on a corresponding development platform SCEP (Service Creation Environment Point), which has correspondingly different operating modes for this purpose.

• – dynamischen, verbindungsspezifischen Daten, die im folgenden Call Instance Data CID bezeichnet werden,
• – statischen Daten, die nur bei spezifischen Administrationsfunktionen geändert werden können und von einem SIB nur gelesen werden können (diese Daten werden im folgenden als Service Support Daten SSD bezeichnet),
• – statischen Daten, die von den SIBs gelesen und geändert werden können. Diese Daten werden im folgenden als Service Data Templates SDT bezeichnet. (Wenn im folgenden von semipermanenten Daten geredet wird, so sind damit beide Typen von statischen Daten, nämlich sowohl SSD als auch SDT gemeint).

Each module SIB of a service logic FSL acts against different data:

• Dynamic, connection-specific data, referred to in the following Call Instance Data CID,
• - static data that can only be changed for specific administration functions and that can only be read by a SIB (these data are referred to below as service support data SSD),
• - Static data that can be read and changed by the SIBs. These data are referred to below as Service Data Templates SDT. (In the following, when semipermanent data is used, it refers to both types of static data, namely both SSD and SDT).

in the Following are the parts (subsystems) of the service development system SCE closer explained.

Of the Part "Service Definition SD "(service creation system) comprises the functions of an editor to design a FSL, the functions a testing device for checking the designed FSL according to certain rules, the functions of a converter for generating object code and data structure prototypes from the source file of a FSL and functions for transferring the files generated from the source file Objects (object code, data structure prototypes) to the corresponding hardware platforms, i.e. to the service management point SMP and the service control Point SCP.

• – die Zuordnung von Service Logic zu einem IN-Service,
• – die Erzeugung von IN-Customers (IN-Provider oder IN-Subscriber),
• – die Zuordnung von Service Logic zu IN-Customers und
• – die Zuordnung von semipermanenten Datenstrukturen zu IN-Customers.

The part "Service Management SD" includes the following functions:

• The assignment of Service Logic to an IN service,
• - the generation of IN-Customers (IN-Provider or IN-Subscriber),
• - the mapping of Service Logic to IN-Customers and
• - the assignment of semi-permanent data structures to IN-Customers.

Of the Part "Customer Service Control CSC "presents for the Customer is a subset of the full features of the Service Development System to disposal. The task of the CSC is the management of IN objects (for example semipermanent Data structures) of the customer. CSC provides a cheap way of access for customer which only have reduced access rights to IN objects. CSC offers the possibility, the for accessible to the customer Manage fields of IN objects.

Of the SMP includes essentially two parts. One part serves to record Data from other IN subsystems (SCEP-SD, SCEP-SM, SCEP-CSC and SCP), where the internal structures are invisible to the SMP. The other part is for execution the central access control for all interconnected IN subsystems.

Of the SCP is for execution calls in the IN system, whereby in particular all routing activities are executed.

2 shows a service module SIB, which represents the smallest configurable software unit for the construction of a service logic using the SCE. A SIB is a generic abstract data type that is converted into a set of abstract data types (object types) by specifying its configuration, in particular its external interfaces. From this, instances (objects, abstract data structures) are again formed by instantiation.

One The template of a service module is thus defined by a set of object types (Data types) that completely describe the service module or set, d. H. its interfaces, its functionality, its graphical presentation and Use, and optional hypertext help information. These object types can as different entities treated and therefore transferred independently (to SCP or SMP) and accessible made for the operator).

3 shows the named object types of a service module.

One Service module is designed by the system designer so that its functionality its entry point (entry point), as well as its starting points (Exit Points) and the data available on these starting points completely independent of the position of the service module within a service logic and also independent from the preceding and following service blocks in the position are.

The external interfaces of a service block are defined by its entry point and its starting points, where there are unconditional and optional starting points. Mandatory exit points must be connected to a follow-up service building. Optional exit points allow the service designer (users of the SCEs) to decide if he has an optional starting point want to connect a successor service module or not. (Each service block must have at least one optional starting point, which leads to a corresponding reaction in case of an error, eg missing input data or an internal SIB error).

Those Service modules that have no connectable starting point (with Exception of the starting point for the error case), termination modules or even sheet service modules called. They form the termination condition of a service logic.

Service modules, which have at least one connectable starting point Called node service modules. You can only use one successor service module at a time at each of their starting points (this rule forces a service logic, from top to bottom (deterministic from top to bottom).

Everyone Service module has exactly one entry point, with at least a predecessor service module or the root point (starting point) of a service logic must be connected.

The Definition of a service module itself does not contain any restrictions over the Formulation of loops within the service logic.

Everyone SIB is provided by the user of the SCE through said external interfaces set or configured. This configuration is made by Interface object (abstract data type) described and in one so-called interface description file (Interface Description File), the description in a special language is formulated, the so-called SIB-Template-Description-Language STL.

By The addition the input or output parameter in the mentioned (configuration) description is it possible that by means of a Path analysis (using a corresponding test equipment) are determined can, if all input parameters (connection data, semipermanent Data) of a SIB are satisfied by previous SIBs. The means new ones SIBs without additional Expenditure checked can be.

In addition to Interface Description File is a service building block Source file assigned to the functionality of the service block describes. The source file is in a high level language (High Level Language HLL, e.g. Pascal).

4 Figure 5 shows the SIBs of an exemplary FSL, their parameters and the resulting possible positions of the SIBs 2, 3 and 4 with respect to the starting points of SIB1 (abbreviated connection abbreviations used: Calling Party Address CgPA, Called Party Address CdPA, Closed User Group CUG).

A basic condition for the functionality a service logic is that all needed at the entry point of a SIB Data through previous service modules or the protocol handler (He leads the SCP dialog with an SSP while running a IN service) stand. This basic condition can be determined by referring to the interface description files already contained during the design phase of a Service logic of the already mentioned test equipment (Component of SCE) checked become.

The test equipment leads the exam by putting it in a loop over in logic (FSL) contained SIBs (eg, SIB1 to SIB4) for each SIB the (concatenation) path from the entrance to the root of the logic and thereby (using the information from the interface objects of the SIBs) the amount of Parameter forms at the outputs of the predecessor SIBs is present. This quantity becomes with the quantity of the necessary input parameters of the test to be tested SIBs compared. If the set of input parameters of the SIB under test completely in the over the exits the predecessor SIBs is formed, the position of the SIB to be tested as technically correct rated or designated.

The Abort criterion for said loop is not necessarily the root of the FSL, but if the subset condition is met. Because all SIBs to be tested in this way is the technical correctness for the whole logic is always ensured. Another essential Advantage of this type of examination is it that new designed SIBs without additional Expenditure to be checked can.

The called examination may be initiated by the user of the SCE, e.g. after this one Service has been created or done automatically.

in the the following will be the already mentioned Macro service module closer explained.

A macro service module is a reusable part of a service logic, just like any normal service module. Unlike normal service modules, macro service modules are composed of normal service modules or other macro service modules that can be executed sequentially. Through the defi nition of a macro service block, no new functionality is introduced in a service logic. Like a service building, a macro service building is characterized by various objects that describe its interfaces, its graphical representation and use, and optional hypertext help information. In contrast to a normal service block, a macro service block does not require a functional object for its functional description, since the functionality of the macro block already exists through the functionality contained in the normal service blocks and their connections within the macro service block.

The Interface objects of a macro block become of the interface objects determines the service blocks contained in the macro block.

5 shows the structure of a macro block, which will be used in the following as an example for determining the interface objects (input and output parameters) of a macro block.

The input interface object of the service block SIB1 is defined by the sum of all its necessary input parameters. These input parameters are necessarily all input parameters of the macro module at the same time. The input parameters of the service block SIB2, reduced by the output parameters at output 2 of the service block SIB1, are necessarily also input parameters of the macroblock. The input parameters of the macro block are generally determined from the remaining set of input parameters of a service block and the intersection of the output parameters of the preceding service block. Input (SIB 2 ) = Input (SIB 2 ) \ (Input (SIB 2 ) ∩Output (SIB 1 (Exit 2 ))) (1)

The identical relation to equation (1) is also for the service module, which is directly connected to the input of the macro module, valid, where However, in this case, no previous service module is available is the input side connected to the aforementioned service block is.

Equation (2) shows how quite generally the additional input parameters that are generated for the macro module due to a service module SIB _i are calculated. AdditionalInput (MSIB (SIB 1 )) = Input (SIB i ) \ (Input (SIB i ) ∩ (Output (SIB v (Exit k )) ∪ .....) (2)

The set of input parameters of a macro block is therefore generally defined by the union of all additional quantities of input parameters of the service blocks included in the macro block (see equation (3)). Input (MSIB) = AdditionalInput (SIB i ) ∪ ..... (3)

The set of output parameters available at a particular output is made by path analysis from the output of the macro to input, as follows: output 1 (MSIB) = Output (SIB 1 (Exit 1 )) ∩Output (SIB 1 (Exit 2 )) ∩Output (SIB 2 (Exit 1 )) (4) output 2 (MSIB) = Output (SIB 1 (Exit 2 )) ∩Output (SIB 2 (Exit 2 )) ∩Output (SIB 3 (Exit 1 )) (5) output 3 (MSIB) = Output (SIB 1 (Exit 2 )) ∩Output (SIB 2 (Exit 2 )) ∩Output (SIB 3 (Exit 2 )) (6)

The review of Interface parameter is during The design of a service logic is done automatically by the development system.

Claims (1)

Service Creation System (SCE), with a) Block objects (SIB), each describing a subfunction of an IN service, b) Service objects (FSL), each of which is the structure of an IN service based on the describe building block objects (SIB), c) a means of production (SD), which is the creation of an IN service by generating the named objects (SIB, FSL), marked by d) Interface objects (STL), which also generated during the creation of a service and a description contain the external interfaces of a block object (SIB), said description being the respective parameters of an external one Includes interface, e) a test equipment that is functional an IN service verifies by checking against the said interface objects (STL), whether that of a building block objects (SIB) needed (Input) parameter supplied by previous block objects (SIB) become.