 |
Description  |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to techniques for integrating
different telecommunication systems and services. More particularly, the
present invention relates to a standard interface which permits
telecommunication services created in one Service Creation Environment
(SCE) to be used in a number of different Execution Environments (EEs).
2. Description of Prior Art
Telecommunication services may be provided by executing machine-level code
in telecommunication hardware such as telephone network switches and
computers. The telecommunication hardware which executes the machine-level
code may be more generally referred to as an Execution Environment (EE).
The EEs may serve to, for example, route data packets in a data
communication network or direct calls in a telephone network switching
system. A group of EEs can provide interactive services to network users,
and transmit data, documents and video through the network. Exemplary EEs
include Service Switching Processors (SSPs), Service Nodes (SNs),
Intelligent Peripherals (IPs) and Service Control Points (SCPs), all of
which may be elements of an Intelligent Network (IN) architecture. Further
detail regarding INs can be found in, for example, O. Mizuno et al.,
"Service Specification Description and Service Logic Program Generation
for Intelligent Networks", Proc. of the International Council for Computer
Communication Intelligent Networks Conference, May 4-6, 1992, pp. 430-440,
which is incorporated by reference herein.
Under current practice, the telecommunication services provided in each EE
are typically programmed using a specific development tool in a high-level
programming environment. The high-level programming environment may be
more generally referred to as a Service Creation Environment (SCE).
Exemplary development tools include decision graph editors, spreadsheets,
computer-aided systems engineering (CASE) tools, and Finite State Machine
(FSM) editors. One exemplary type of FSM editor uses the standard CCITT
Service specification Description Language (SDL), which represents
telecommunications services in a graphical format to facilitate service
development. The service to be provided in each EE is generally developed
using a dedicated SCE, which runs on a computer workstation and provides a
set of service development tools based upon a particular user paradigm.
The SCE typically produces a service description file in a proprietary
format developed by the SCE vendor. The proprietary service description
file is then translated into a lower-level code suitable for directing an
EE to provide the desired service, and therefore can usually only be used
with a corresponding EE from the same or a related vendor.
The close coupling between SCEs and EEs under current practice presents a
number of problems. One problem is that network services developed in one
SCE can typically be used only in a corresponding EE and cannot be reused
in different EEs. Another related problem is that the SCEs and EEs of one
vendor generally cannot be interfaced to those of other vendors. In order
to provide an interface between currently existing network services and a
number of different EEs, it may therefore be necessary to redesign
existing services to incorporate the interface. As a result of these
problems, network providers, such as Local Exchange Carriers (LECs),
long-distance carriers and foreign Postal, Telephone and Telegraph
companies (PTTs), may have difficulty supplying telecommunication services
in a timely and reliable manner. These problems are described in, for
example, D. Singh and D. Garrison, "Requirements for Service Creation
Platforms in an Open Systems Environment", Proc. of the International
Council for Computer Communication Intelligent Networks Conference, May
4-6, 1992, pp. 162-174, which is incorporated by reference herein.
Several different approaches to the SCE-EE interface problem have been
identified. One possible approach involves using a universal
application-oriented language (UAOL) to program services in all SCEs. A
related approach could involve using a standardized service execution
processor (SEP). An exemplary standard SEP is disclosed in S. Esaki et
al., "Service Logic Execution of IN Multi-vendor Environment--Introduction
of SLP Execution Processor", Proc. of the International Council for
Computer Communication Intelligent Networks Conference, May 4-6, 1992, pp.
441-450, which is incorporated by reference herein. Although either of
these approaches may have been feasible if the telecommunication industry
had initially settled upon a standard UAOL or SEP, no such standards are
currently in widespread use. In addition, a UAOL capable of accommodating
multiple service applications will generally be a complex high-level
language, and will therefore not be easy to use. Implementing either the
UAOL or standard SEP approaches at the present time would probably require
redesign of existing network services programmed using non-standard
languages or processors.
An alternative interface may translate object code between different SCEs
and EEs. Object code translation typically involves translating source
object code into a generalized assembly language, and then generating
target object code from the assembly language. Object code translation has
the advantages of being generally transparent to service users and an
efficient means for generating the lower-level code required in a
particular EE. However, this approach is inflexible to changes in service
applications, and may not be well suited to programs which utilize
run-time interpretation.
A technique presently used in prior art telecommunication system interfaces
is cross-compilation. In general, cross-compilation involves designing a
different compiler for translating code between each SCE and each EE. By
using separate compilers for each interface, the services developed in any
SCE may be used on any other EE, and therefore many of the above-noted
problems are avoided. However, this approach may be prohibitively
expensive in applications which include a large number of SCEs and EEs.
The compiler development cost is generally a quadratic function of the
number of SCEs and EEs. For example, if a telecommunication system
includes m SCEs and n EEs, the cross-compilation approach will generally
require the development and support of m.times.n compilers. An interface
technique currently used in the context of higher-level programming
languages is based on a common intermediate language. This approach was
used in 1961 to develop a Universal Computer Oriented Language (UNCOL).
See T. Steel, "A First Version of UNCOL", Proc. Western Joint Comp. Conf.,
pp. 371-377, 1961. Common intermediate languages typically include n front
ends, each translating high-level code in one programming language to the
intermediate language, and m back ends, each translating programs in the
common intermediate language to a specific machine-level language, or
target code. As a result, only n+m compilers must be written to interface
each of the n SCEs to each of the m EEs, as opposed to n.times.m compilers
in the cross-compilation approach. See, for example, A. Tanenbaum et al.,
"A Practical Toolkit For Making Portable Compilers" , Communications of
the ACM, Vol. 26, No. 9, September 1983 [hereinafter "Tanenbaum"]. A
similar approach is utilized in U.S. Pat. No. 4,667,290, issued to Goss et
al., entitled "Compilers Using A Universal Intermediate Language"
[hereinafter "Goss"].
Existing common intermediate language techniques, however, suffer from a
number of significant problems, and therefore have limited utility in
telecommunication service applications. A major problem with the Tanenbaum
approach is the loss of original input information when the interface
input code is translated to an intermediate language. The original input
information is lost because Tanenbaum uses an intermediate language which
is basically an assembly language for a simple stack machine. The Goss
patent is primarily directed to interfacing high-level programming
languages, of a strongly-typed or procedural form, to different data
processors. Goss uses a "quad", with four operative fields, as the basic
code structure for the intermediate language. See Goss, col.5, line 60 to
col.6, line 38. This inflexible structure may not adequately represent
certain SCE outputs, such as non-procedural types of programming code. In
addition, the intermediate language in Goss is designed for use with
top-down parsing of the high-level programming language code. See Goss,
col.5, lines 34-36. The Goss approach therefore may not be well-suited for
generating intermediate code to represent typical SCE output code. For
example, the Goss intermediate code generated from an SCE output code may
not preserve enough SCE output code detail to permit efficient
intermediate code optimization. The Goss patent thus does not suggest an
appropriate intermediate language structure for use in interfacing, for
example, SCEs and EEs in a telecommunication services context.
As is apparent from the above, a need exists for an efficient and flexible
telecommunication system interface which permits services developed in
different SCEs to be utilized in different EEs, without requiring a
separate interface between each SCE and each EE, and without the problems
of existing intermediate language techniques.
SUMMARY OF THE INVENTION
The present invention provides a method and apparatus for interfacing
different SCEs and EEs in a telecommunication system. The method of the
present invention includes the steps of defining a set of intermediate
code operations suitable for representing telecommunication services
developed in the selected SCEs; parsing output code from one of said
selected SCEs to form a parse tree having a plurality of nodes, said parse
tree representing one of the telecommunication services developed in the
SCE; generating from the set of intermediate code operations and the parse
tree an intermediate code representing the nodes of the parse tree, such
that the intermediate code preserves substantially all information
contained within the SCE output code; and generating from the intermediate
code a target code for each of the EEs, such that the telecommunication
services developed in the selected SCEs may be provided in each of the
EEs.
In accordance with one aspect of the present invention, a telecommunication
system interface is provided which includes at least one SCE to be
interfaced to a plurality of service EEs; a parser for parsing output code
from the SCE to form a parse tree representing a telecommunication service
developed in the SCE; an intermediate code generator for generating an
intermediate code representing nodes of the parse tree such that
substantially all the information contained within the SCE output code is
preserved in the intermediate code; and a target code generator for
generating a target code for each of the EEs from the intermediate code,
such that the telecommunication service developed in the SCE may be
provided in each of the EEs.
In accordance with another aspect of the present invention, the
intermediate code may preserve substantially all the information contained
in the SCE output code by using a single line of intermediate code,
referred to herein as a tuple, to represent each node of the SCE output
code parse tree. The telecommunication system interface of the present
invention thus includes an intermediate language which is capable of
representing, for example, both statement and declaration nodes of an SCE
output code parse tree, and therefore provides sufficient information for
generating an optimized intermediate code.
As a feature of the present invention, telecommunication services developed
in a particular SCE may be utilized in a variety of different EEs. The
close coupling between SCEs and EEs is eliminated, and it is therefore no
longer necessary to design a separate interface between each SCE and EE.
Service interface design, operation and maintenance costs become a linear
function of the number of SCEs and EEs, rather than a quadratic function
as in the currently used cross-compilation approach.
As another feature of the present invention, the system interface provided
does not place operational constraints on the SCE, and does not utilize a
proprietary format, so SCE and EE selection is made vendor-independent.
The interface permits a vendor to design a single service which may be
utilized in parallel on a number of different EEs, and allows a vendor to
efficiently maintain and update their services.
As an additional feature of the present invention, an interface is provided
which permits reuse of currently existing services on different EEs,
without redesigning or otherwise altering the existing services. The
intermediate code may be designed to accommodate a number of
currently-used SCE output languages. A service repository may then be
maintained such that it is no longer necessary to redesign services when,
for example, a different EE is developed.
As a further feature of the present invention, an application-oriented
programming language (AOPL) is provided which includes an intermediate
code structure well-suited to representing the output code of many
different SCEs. The intermediate code structure in accordance with the
present invention is based upon a flexible AOPL code line, referred to
herein as a tuple, which has a variable number of fields. The structure is
more flexible than, for example, the Goss quad structure, discussed above,
which generally requires four fields. The tuple structure of the present
invention is particularly well-suited to representing the parse trees of
SCE output code, which may often be in a non-procedural type of
programming language. The present invention thereby provides a number of
advantages over existing intermediate language compilers, such as improved
intermediate code optimization and more efficient target code generation
for a wide variety of EEs.
The above-discussed features, as well as additional features and advantages
of the present invention, will become more readily apparent by reference
to the following detailed description and the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is an exemplary block diagram of a telecommunication system in
accordance with the present invention.
FIG. 2 is a more detailed block diagram of a telecommunication system
interface in accordance with the present invention.
FIG. 3 is a block diagram illustrating an exemplary set of code processing
steps within a telecommunication system interface in accordance with the
present invention.
FIG. 4 is a flow diagram of a portion of an exemplary service application
developed in the SDL graphical notation.
FIGS. 5, 6a-c, 7a-7e and 8a-8d illustrate the SDL graphical notation for an
exemplary televoting service application, which may be interfaced to a
variety of different EEs in accordance with the present invention.
DETAILED DESCRIPTION
The present invention provides a method and apparatus for interfacing
different SCEs and EEs in a telecommunication system. Although the
following description illustrates the use of the telecommunication system
interface in the context of specific SCEs and EEs, it should be understood
that the present invention may also be utilized in a wide variety of other
telecommunication system applications. Furthermore, although a number of
simple programming language examples are used herein for illustrative
purposes, it should be understood that the present invention is
particularly well-suited for telecommunication system applications.
FIG. 1 shows a block diagram of a telecommunication system in accordance
with the present invention. The exemplary system includes a Service
Creation Environment (SCE) 10 with a number of different development
tools. The exemplary development tools in SCE 10 include a decision graph
editor 12, a spreadsheet tool 14, and a Finite State Machine (FSM) editor
16. The decision graph editor and FSM editor may be referred to more
generally as graphical editors. The SCE may also include other types of
development tools, such as Computer-Aided Systems Engineering (CASE)
tools. In general, each of the development tools 12, 14, 16 may be
utilized by a different system vendor to develop telecommunication
services. The telecommunication services developed in the SCE 10 using the
different development tools are executed in a group 20 of different
Execution Environments (EEs). The exemplary EEs in the EE group 20 include
a service switching processor (SSP) 22, a service control processor (SCP)
24, and an intelligent peripheral (IP) 26. The SCP 24 will generally be
accompanied with, or used in conjunction with, a service node (SN). The IP
26 may be, for example, a computer, a fax machine, a video terminal or a
text-to-speech convertor. The EEs 22, 24, 26 are generally referred to as
intelligent network (IN) elements. Additional detail regarding INs may be
found in, for example, M. Morgan et al., "Service Creation Technologies
for the Intelligent Network", AT&T Technical Journal, Vol. 70, Nos. 3-4,
Summer 1991, and G. Wyatt et al., "The Evolution of Global Intelligent
Network Architecture", AT&T Technical Journal, Vol. 70, No. 5, Summer
1991, both of which are incorporated by reference herein.
In prior art telecommunication systems, a separate interface is typically
developed to integrate services developed using each development tool 12,
14, 16 in SCE 10 with each EE 22, 24, 26. For example, decision graph
program 12 may be designed with an interface that allows it to operate
only with SSP 22. It is not possible, under the current system interface
approach, to use, for example, a decision graph program 12 from one
telecommunication system vendor with an SCP 24 designed by another vendor.
The present invention avoids these problems with the prior art
implementations, in part by utilizing a system interface 30 which is based
upon an application-orientated programming language (AOPL). The AOPL of
the present invention has been structured in a manner which facilitates
integration of services created using different SCE development tools with
a variety of EEs. The term "AOPL" as used herein refers to a type of
common intermediate code defined in a suitable manner to represent SCE
output code parse trees.
FIG. 2 is an exemplary embodiment of the telecommunication system interface
30 of the present invention. The interface 30 includes an SCE side 42 and
an EE side 44, and is used to interconnect an SCE to one or more EEs. The
SCE side 42 may represent, for example, the output of the decision graph
program 12 shown in FIG. 1, while the EE side 44 may represent, for
example, the input of the SSP 22. The decision graph program 12 may be
also be referred to as a graphical user interface (GUI) within the SCE
side 42. The SCE side 42 and the EE side 44 of the interface 30 are
interconnected via a common intermediate language designated as AOPL 46.
In general, the SCE side 42 may create a service description file in AOPL
code based upon the SCE output code received on line 48 from an SCE. The
translation from SCE output code to AOPL code is performed in a parser 50
which is present within the SCE side 42 of the interface 30. The parser 50
translates the high-level SCE output code of the decision graph program 12
into an appropriate AOPL code. The AOPL code is then transferred through
the interface 30 to the EE side 44 of the interface. On the EE side 44,
the AOPL code drives a code generator 52 which translates the AOPL code
into a desired target code. The target code is then supplied via line 54
to an appropriate EE.
In general, a different parser 50 may be used to translate the operating
code of a particular SCE into the common intermediate AOPL code.
Similarly, a different code generator 52 may be used to receive the AOPL
code and generate an appropriate target code for each EE. The SCE side 42
and EE side 44 of the interface 30 may therefore be implemented within the
SCEs and EEs, rather than in, for example, an independent interface unit.
For existing SCEs and EEs, however, it may be desirable to include the
parsing and code generating functions within an independent interface
unit. By using the system interface 30, services developed in SCE 10 using
each of the development tools 12, 14, 16 may be interfaced to each of the
EEs 22, 24, 26, as shown in FIG. 1. Furthermore, existing services which
have been previously developed in a high-level language SCE, may be
translated via parser 50, AOPL 46 and code generator 52, into a desired
target code for a particular EE. In this manner, telecommunication
services created in different SCEs may be reused in a variety of different
EEs without redesigning the SCE. Existing telecommunication services, such
as those already developed in a particular SCE for execution in a
telephone network SSP or SCP, may be reused by simply translating the
service description files for the particular SCE into AOPL code, using an
appropriate parser 50. The AOPL 46 shown in FIG. 2 will be described below
in greater detail.
The telecommunication system interface of the present invention uses an
application-oriented intermediate language, AOPL, which has a structure
particularly well-suited to certain telecommunication applications. In
general, AOPL is a language designed for efficient depiction of SCE output
code parse trees. Parsing of programming code to generate parse trees is
well-known in the art, and described in, for example, pp. 40-42 of A. Aho
et al., "Compilers: Principles, Techniques, and Tools", Addison-Wesley,
March, 1988, which are incorporated by reference herein. The interface of
the present invention uses an intermediate code structure which represents
nodes of an SCE output code parse tree for a given telecommunication
service. By representing the parse tree nodes, the intermediate code
preserves substantially all the information within the SCE output code.
The term "substantially all" in the context of SCE output code refers to
information which is typically found in an output code parse tree, such
as, for example, the structure, declarations, statements, and operations
of the SCE output code.
A number of different SCEs may be selected for a given interface, and a set
of intermediate code operations is then defined which is suitable for
representing the telecommunication services developed in the selected
environments. A substantial number of SCEs may be accommodated by defining
an appropriate set of intermediate code operations. Several examples of
intermediate code operations will be given below.
The AOPL of the present invention includes a general syntax, constructs,
and design guidelines. Although the specific embodiment of AOPL used in a
given application will typically vary depending upon the SCEs and EEs
which are interfaced, the general structure of the language may be
described as follows. An exemplary AOPL file generally includes a number
of different code lines, referred to herein as tuples, which represent the
parse trees of the SCE output code. Each AOPL tuple is delimited by a
semicolon, and includes a number of different fields separated by commas.
An exemplary AOPL tuple may include three fields, corresponding to the
label, type, and operation of the tuple, respectively. The label field
includes any sequence of printable characters other than commas or
semicolons, and provides a convenient means for identifying a particular
tuple. The type field, in accordance with the present invention, may be
either P.sub.-- node or S.sub.-- node. The type field indicates the type
of parse tree node which is represented by that particular tuple. Tuples
of the P.sub.-- node type may include declarations, expressions, and
statements, while S.sub.-- node type tuples generally include longer
programming sequences, such as data structures. The operation field of the
AOPL tuple includes an operator, which may indicate, for example, the
operation performed at a node of the SCE output code parse tree. The
operation field may also indicate a number of operands used in that
operation. Exemplary AOPL operators include, for example, LEAF, VARREF,
CONSTREF, and SEQUENCE.
An AOPL tuple may also include a number of additional fields. For example,
the tuple may include an additional field for each operator identified in
the operation field. These additional fields will be referred to herein as
operand fields. The operand fields may be used to identify, by label,
different tuples which correspond to, for example, other nodes in the SCE
output code parse tree. The operand fields represent the other tuples
which are operated on by the operator specified in the operator field.
Other additional fields which may be included in a particular AOPL tuple
are name and value attribute fields. The name attribute field generally
includes a character string, which may correspond to a token in the SCE
output code. The value attribute field will typically contain an integer
value indicating, for example, the size or the address of the data which
is operated on within the tuple.
The AOPL of the present invention recognizes three different kinds of
tokens. Tokens are sequences of characters having a collective meaning in
the SCE output code. The tokens recognized by AOPL include identifiers,
literals and separators. An identifier may be an arbitrary sequence of
letters, digits, and/or special characters. The first character of the
identifier may be any character other than a digit. The operators used
within the above-described operator fields are reserved as AOPL keywords
and therefore may not be used as identifiers in the SCE output code. The
literals may be one of two types, either character strings, also known as
string-literals or integer literals. A third type of token recognized by
the AOPL of the present invention is a separator. The separators may
include certain predefined characters such as, for example, ";", "," "(",
and ")". AOPL identifies these tokens in the high-level language, or
output code, of the SCE, and generates a parse tree which represents the
functional interconnection of the tokens. Tokens are identified in the SCE
output code by taking the longest string of characters associated with any
particular token. Certain portions of the SCE output code, known as "white
spaces", are not recognized as tokens. These white spaces include blanks,
tabs, newlines, and formfeeds.
The above described AOPL grammar is summarized in the following language
template:
______________________________________
<AOPL-program>: <AOPL-node>
<AOPL-program> <AOPL-node>
<AOPL-node>: <node-head> <node-tail>;
<node-head>: <label>, <node-type>, <opcode>, <node-list>
<label>: identifier
<node-type>: P.sub.-- node
S.sub.-- node
<opcode>: <AOPL.sub.-- opcode> (integer-literal)
<AOPL.sub.-- opcode>: keyword
<node-list>: <label>
<node-list>, <label>
<node-tail>: empty
<attribute-list>
<attribute-list>: <list-entry>
<attribute-list>, <list-entry>
<list-entry>: <name-attribute>
<value-attribute>
<name-attribute>: string-literal
<value-attribute>: integer-literal
______________________________________
In the above language template, the symbols "<>" surround certain elements
of each exemplary tuple shown, and the symbol " " designates the logic
"or" operator.
The AOPL of the present invention may be illustrated using a simple C
program. It should again be emphasized, however, that the AOPL structure
is particularly well-suited to telecommunication system applications, and
the exemplary C programs used to illustrate AOPL herein are shown
primarily for illustrative purposes. In this C language programming
example, one of the development tools used in SCE 10 provides output code
of the form shown below:
______________________________________
main()
{
int x;
int Y;
y = 2;
x = y*y + 2;
printf("%d", x);
}
______________________________________
Using the AOPL structure of the present invention, as described above, the
exemplary C program shown above may be represented in an intermediate AOPL
code as follows:
______________________________________
main, P.sub.-- node, SEQUENCE(5), x.sub.-- decl, y.sub.-- decl, stm1,
stm2, stm3;
x.sub.-- decl, P.sub.-- node, INTDECL(1), x.sub.-- var;
x.sub.-- var, P.sub.-- node, VARREF(2), x.sub.-- leaf, x.sub.-- decl;
x.sub.-- leaf, P.sub.-- node, LEAF(1), int, 'x';
y.sub.-- decl, P.sub.-- node, INTDECL(1), y.sub.-- var;
y.sub.-- var, P.sub.-- node, VARREF(2), y.sub.-- leaf, y.sub.-- decl;
y.sub.-- leaf, P.sub.-- node, LEAF(1), int, 'y';
stm1, P.sub.-- node, ASSIGNMENT(2), y.sub.-- var, 2.sub.-- const;
2.sub.-- const, P.sub.-- node, CONSTREF(1), 2.sub.-- leaf;
2.sub.-- leaf, P.sub.-- node, LEAF(1), int, '2';
stm2, P.sub.-- node, ASSIGNMENT(2), x.sub.-- var, r.sub.-- stm2;
r.sub.-- stm2, P.sub.-- node, PLUS(2), expr1, 2.sub.-- const;
expr1, P.sub.-- node, MULT(2), y.sub.-- var, y.sub.-- var;
stm3, P.sub.-- node, FUNCTION(2), printf, printf.sub.-- arg;
printf, P.sub.-- node, LEAF(1), int, 'printf';
printf.sub.-- arg, P.sub.-- node, ARG.sub.-- LIST(2), arg1, x.sub.--
var;
arg1, P.sub.-- node, CONSTREF(1), %f.sub.-- leaf;
%f.sub.-- leaf, P.sub.-- node, LEAF(1), string, '%d';
______________________________________
In the above AOPL code, the tuple "main" represents the root node of a
parse tree of the exemplary C program. The AOPL code also includes a
number of different operators, which are shown in capital letters. One
exemplary operator is the SEQUENCE operator. The SEQUENCE operator directs
the AOPL interface to generate sequential code for the five exemplary
operands which follow it. As noted above, the operands following an AOPL
operator also correspond to various nodes in a parse tree of the SCE
output code. In the exemplary program shown, each of the operands of the
sequence operator are either declarations or statements within the C
program. Each of these operands therefore represent a node of the output
code parse tree. Each will also correspond to a different tuple, or basic
code line, within the intermediate AOPL code. The tuples which include
operators of the form LEAF represent terminal nodes in the SCE output code
parse tree, whose operands are predefined in a particular embodiment of
the AOPL language. In the exemplary AOPL code shown, the predefined
operands are shown in italics, and represent primitive data types, such as
integers and strings. In general, the operators and predefined operands
will vary depending upon the functionality of the SCEs and development
tools used.
The above example utilizes only P.sub.-- node-type tuples. A second
exemplary C program, having an AOPL code representation which includes
S.sub.-- node-type tuples, is as follows:
______________________________________
struct date {
int day;
int month;
int year;
} due.sub.-- date;
______________________________________
Exemplary AOPL code corresponding to the second C program is shown below:
______________________________________
due.sub.-- decl, P.sub.-- node, RECDECL(1), due.sub.-- var;
due.sub.-- var, P.sub.-- node, VARREF(2), due.sub.-- leaf, due.sub.--
decl;
due.sub.-- leaf, P.sub.-- node, LEAF(1), date.sub.-- record, 'due.sub.--
date';
date.sub.-- record, S.sub.-- node, RECORD(4), field1, field2, field3,
date.sub.-- leaf;
field1, P.sub.-- node, RECFIELD(2), day.sub.-- leaf, date.sub.-- record;
day.sub.-- leaf, P.sub.-- node, LEAF(1), int, 'day', 4;
field2, P.sub.-- node, RECFIELD(2), month.sub.-- leaf, date.sub.--
record;
month.sub.-- leaf, P.sub.-- node, LEAF(1), int, 'month', 4;
field3, P.sub.-- node, RECFIELD(2), year.sub.-- leaf, date.sub.--
record;
year.sub.-- leaf, P.sub.-- node, LEAF(1), int, 'year', 4;
date.sub.-- leaf, P.sub.-- node, LEAF(1), date.sub.-- record, 'date',
______________________________________
12;
In the above exemplary AOPL code, the operator RECORD specifies the name
and size of the record itself, while the operator RECFIELD(2) indicates
the name and type of each field in the record. The operands corresponding
to the RECORD operator specify the record fields. Each of the terminal
nodes, corresponding to operator LEAF, include a value attribute field
which identifies the size of the terminal node.
In order to efficiently construct AOPL code such as that shown above, the
present invention may utilize a multi-level architecture, as shown in FIG.
3. The system interface 60 may be divided into several different code
translation operations, or passes. Each pass may contain a distinct
operation set for performing code translation. SCE output code, which may
be, for example, from any of the development tools 12, 14, and 16, is
provided on line 64. In a first pass 66, the SCE output code is translated
into a first pass code which is supplied via output 68 to a second pass
70. The first pass 66 is used to translate the SCE output code from a
particular SCE into a language which may be more readily converted into a
common intermediate language. The operation set used within the first pass
66 may therefore be defined such that it closely reflects the
characteristics of the SCE on which the SCE output code was created. It
will then be easier to alter the interface to accommodate any changes in
the SCE, and to identify and report errors at the SCE code level, prior to
generating the common intermediate AOPL code. An exemplary first pass
operation set will be shown below for an SDL representation of a
televoting service application. The operation set used in first pass 66
may be stored within the service creation environment itself.
The second pass 70 receives the first pass code generated in the first pass
66 and generates second pass code in a common intermediate language which
will be used for all of the SCEs. The second pass 70 will typically
include an operation set which is broader and more generic than the
operation set used in first pass 66. It will therefore be possible to
introduce new operations in first pass 66 without affecting second pass
70. A second pass database 72 may contain, for example, second pass macros
which may be used to expand certain nodes in the first pass code. The
second pass 70 provides common intermediate AOPL code on output 74 which
is then processed in a third pass 76. The third pass 76 is designed to
simplify target code generation for each EE. The operation set defining a
third pass code in general more closely reflects the attributes of a
particular EE. In the third pass, a group of third pass macros stored in a
third pass database 78 may be used to expand certain nodes in the second
pass code. The resulting target code is supplied via line 80 to a
particular EE such as, for example, an SCP or SSP within a telephone
switching network. Although FIG. 3 illustrates an exemplary three-level
hierarchy for implementating the interface 60, it should be understood
that additional levels may be included within the interface to translate
SCE output code to EE target code in a given application.
The three passes shown in FIG. 3 may be distributed across an SCE and an
EE, with a first pass code generator in the SCE and a third pass code
generator in the EE, such that the SCE generates, and the EE receives, the
common intermediate code generated in second pass 70. The first pass 66
may thus be performed within each SCE, while the third pass 76 is
performed within each EE. In order to generate the common intermediate
code, an output portion of the SCE uses a first pass program and a
predefined operation set. In the second pass, an intermediate code
generator is used to generate and optimize a common intermediate code.
Finally, an EE may receive the intermediate code and generate appropriate
target code. Each pass typically involves translating the code of the
prior pass into a more appropriate code. The first, second and third
passes in the three-level hierarchy of FIG. 3 may therefore correspond to
the operations performed by the parser 50, the AOPL code generator 46, and
the target code generator 52, respectively, of FIG. 2. In some cases, it
may not be necessary to perform translation at each pass. Instead,
templates representing typical programming constructs such as "case" and
"if" can be used for direct substitution. The stored operation sets in
databases 72 and 78 may then include simple macros for translating nodes
of the SCE output code parse tree from high-level SCE output code to
low-level EE target code.
The telecommunication system interface of the present invention has been
applied to a variety of different SCEs and EEs. FIG. 4 illustrates a flow
diagram of an exemplary service state machine which uses the CCITT Service
specification Description Language (SDL). The SDL language is referred to
as SDL/GR when used in its graphical representation form and SDL/PR when
used in its literal, or textual, representation form. Programs may be
created in the SDL/PR form by using general-purpose text editors. SDL/GR
programs, however, are typically developed using, for example, a graphical
editor specifically designed for manipulating SDL/GR symbols. In FIGS. 4
through 8, the SDL/GR graphical notation is used. The SDL/GR graphical
notation generally provides a means for representing telecommunication
service functions in a graphical symbol format, and is described in more
detail in, for example, CCITT Blue Book Vol. X, Fascicle X.1, "Fuc | | |
