SYSTEM AND METHOD RELATING TO GENERIC HANDLING OF DATA

SYSTEME ET PROCEDE RELATIFS A UNE MANIPULATION GENERIQUE DE DONNEES

English Abstract

The present invention relates to a system and a method respectively for
generic handling of data comprising sending a message between and/or within a
number of data handling arrangements (10, 20). Each data handling arrangement
(10, 20) may comprise one or more function handling means (11, 12, 13A-13C,
14; 21, 22, 23A-23C). For a number of function handling means (11, 12, 13A-
13C, 14; 21, 22, 23A-23C) definition data (120, 220) is provided separately
from information data and independently from definition data for other
function handling means. Information data (1, 2) is handled generically and
separately from definition data (120, 220) and information data is transferred
as internal communication messages (1, 2) between different data handling
arrangements (10, 20) and as internal call objects between different function
handling (11, 12, 13A-13C, 14; 21, 22, 23A-23C). Means using the respective
definition data (120, 220). Thus, the system coordinates and modifies messages
towards the data handling arrangements, in order to provide a simple one point
of entry interface for simple messages that are transformed to a larger more
complex set of messages.

French Abstract

Cette invention a trait à un système et à un procédé permettant une manipulation générique de données consistant à faire transiter un message entre un certain nombre d'emplacements (10, 20) de manipulation de données et/ou à l'envoyer à l'intérieur de ceux-ci. Chaque emplacement de manipulation de données (10, 20) peut comporter un ou plusieurs mécanismes de manipulation de fonction (11, 12, 13A-13C, 14, 21, 22, 23A-23C). Des données de définition (120, 220) sont fournies à un certain nombre de mécanismes de manipulation de fonction (11, 12, 13A-13C, 14, 21, 22, 23A-23C) et ce, à l'écart des données d'information et indépendamment des données de définition relatives à d'autres mécanismes de manipulation de fonction. Les données d'information (1, 2) sont manipulées de manière générique et à l'écart des données de définition (120, 220) puis elles sont transférées sous forme de messages internes de communication (1, 2) entre différents emplacements de manipulation de données (10, 20) et sous forme d'objets d'appel internes entre différents mécanismes de manipulation de fonction (11, 12, 13A-13C, 14, 21, 22, 23A-23C) utilisant les données de définition respectives (120, 220). De la sorte, ce système coordonne et modifie des messages destinés aux emplacements de manipulation de données afin de fournir un simple point unique d'interface d'entrée pour des messages simples qui sont transformés en jeu de messages plus grand et plus complexe.

Claims

35


CLAIMS


1. System for sending messages between and/or within a number of
data handling arrangements (10,20;40,50;60,70,80;90A,90B,90C),
wherein at least a number of data handling arrangements)
comprises a number of function handling means (11,1.2,13A-
13C,14;21,22,23A-23C;41,42,43;51,52,53;501,502,503A1-503C5,504A1,
526,527,53A,531;61,...,63B,71-74B;91A-96A,91B-95B)
characterized in
that one function handling means comprises interfacing means
comprising converting means (15,11,14,21;51,63A,63;71,74A,74B;
91A,96A,95B) for converting incoming messages to internal calls
comprising an internal standard call object (100) and at least one
result object or vice versa, at least a number of said data
handling arrangements comprising a number of further function
handling means, in one or more hierarchical layer(s), internal
call objects (100) being sent from one function handling means
within one and the same hierarchical layer to another in a
consecutive way as internal standard call objects (100), each
function handling means (11,12,13A-13C,14;21,22,23A-23C; 41,42,43;
51,52,53;501,502,503A1-503C5,504A1,526,527,53A,531;61,...,63B,71-
74B;91A-96A,91B-95B) providing a number of result objects when
handling an internal call object (100), for at least a number of
function handling means (11,12,13A-13C,14;21,22,23A-23C;41,42,43;
51,52,53;501,502,503A1-503C5,504A1,526,527,53A,531;61,...,63B,71-
74B;91A-96A,91B-95B) a set of definition data (120,220;
410,420,430;522,523,514-520;610,620,720,730) being provided
separately, that internal standard call objects (100) are
converted to internal communication messages for sending between
data handling arrangements (11,12,13A-13C,14;21,22,23A-



36



23C;41,42,43;51,52,53;501,502,503A1-503C5,504A1,526,527,53A,531;
61,...,63B,71-74B;91A-96A,91B-95B), and in that all information
data, e.g. internal call objects (100), are handled generically
and separately from definition data (120,220;410,420,430;
522,523,514-520;610,620,720,730) used for defining the interface
and the behavior of the interface.
2. System according to claim 1,
characterized in
that each set of definition data (120,220;410,420,430;522,523,514-
520;610,620,720,730) is independent of every other set of
definition data belonging to other function handling means.
3. System according to claim 2,
characterized in
that a common syntax is used for the different sets of definition
data (120,220;410,420,430;522,523,514-520;610,620,720,730), unique
identification information and names being used to distinguish
sets of definition data from each other.
4. System according to any one of claims 1-3,
characterized in
that it comprises at least one data handling arrangement, in the
converting function handling means of which incoming messages from
external systems are translated to internal standard call objects.
5. System according to claim 4,
characterized in
that incoming messages are ASCII messages based on a carrier
protocol such as e.g. HTTP, RPC, TELNET etc.



37



6. System according to any one of the preceding claims,
characterized in
that at least one data handling arrangement (10;70;90B) is
arranged to receive messages from another data handling
arrangement and in that internal communication messages received
from said other data handling arrangement are translated to
internal call objects (100).
7. System according to any one of the preceding claims,
characterized in
that an internal communication message sent between data handling
arrangements comprises an ASCII data string and in that the
RPC/HTTP protocol is used.
8. System according to claim 7,
characterized in
that the sending means comprises executing means (43;53,53A;95B)
for adapting the internal call object (100) to a format
supported by the application system, if needed, and for
transferring the adapted call object to the application system
(6;6A,6B;90C).
9. System according to any one of the preceding claims,
characterized in
that each data handling arrangement and/or each function handling
means provides at least one result object when handling a call
object (100) and in that said result object(s) is/are sent to
the preceding data handling arrangement/function handling means.
10. System according to any one of the preceding claims,
characterized in


38



that definition data are being stored in tables or provided as
setup files or via programming.
11. System according to any one of the preceding claims,
characterized in
that at least one data handling arrangement/function handling
means apply load sharing (96A).
12. System according to any one of the preceding claims,
characterized in
that a number of data handling arrangements (20) and/or function
handling means (13A,13B,13C;23A,23B,23C;63A;74A,74B) are
arranged in parallell.
13. System according to any one of the preceding claims,
characterized in
that the interfacing means (51) forms a single access point e.g.
for external client systems, said interfacing means further
comprising a parallell distributor (501) for executing incoming
messages in parallell and a handler switch, said interface means
including protocol converting means for handling different
protocols.
14. System according to any one of the preceding claims,
characterized in
that the converting means of the interfacing means converts
incoming messages to internal call objects (100) at least
comprising mandatory parameters object, action and key-fields
and a number of optional parameters for information.
15. System according to any one of the preceding claims,



39



characterized in
that the handling means (52) of a data handling arrangement (50)
comprises a call handler (502) receiving internal call objects
(100) from the interfacing means and distributing the internal
call objects (100) to service agents for processing the calls in
service agent processes (503A1,...,503C5), a number of service
agent managers (503A,503B,503C) being provided for managing a
configurable number of equal service agent processes.
16. System according to claim 15,
characterized in
that routing tables and/or text files are used for giving
distribution information.
17. System according to claim 15 or 16,
characterized in
that when a new service agent is introduced, a new service agent
manager is created and configured.
18. System according to any one of claims 15-17,
characterized in
that each service agent process comprises a function call handler
(504A1) for analyzing incoming call objects (100) to determine
relevant actions and creating call objects to be sent to serving
means of application systems.
19. System according to claim 18,
characterized in
that the function call handler (504A1)comprises a number of
function handling means cooperating with corresponding,
separately arranged servers (514,...,517,519,520).




40



20. System according to claim 19,
characterized in
that the function handling means support customer developed
program codes (523).
21. System according to any one of claims 18-20,
characterized in
that at least one data handling arrangement comprises adapting
means (53) including one adapter for each type/version of
application system and in that in the adapters internal call
objects (100) are received from the function call handler (504A1)
and adapted to a format receivable by the intended application
system (version).
22. System according to any one of the preceding claims,
characterized in
that at least one data handling arrangement
(10,20;40,50;60,70,80;90A,90B,90C) comprises a number of function
handling means such as one or more of e.g. log handling means
(92A) in which a received call object is logged, e.g. together
with date and time stamp, transaction handling means (93A) in
which a unique transaction identification is added to the
internal call object, routing means (62,73;95A) for routing the
call object e.g. depending on physical location address and/or
functionality, conversion handling means replacing one
identification by another different identification, authority
handling means (92B) for checking user access to data requested
in a call object, validating means (42;94B) for checking data
contained in a call object.




41



23. System according to any one of the preceding claims,
characterized in
that at least two data handling arrangements each comprise a
number of function handling means in one or more hierarchical
layers.
24. Data handling arrangement (10,20;40,50;60,70,80;90A,90B,90C)
for handling messages incoming from a managing system, e.g. a
client system or from another data handling arrangement,
including a number of function handling means such as at least
interfacing means, handling means and sending means,
characterized in
that said interfacing means form a single access point and
comprises converting means (15,11,14,21;51,63A,63B;71,74A,74B;
91A,96A,95B) for translating incoming messages to internal
standard call objects, an internal call object at least
comprising an object field, operation field and key-fields,
distributing means for distributing internal call objects (100)
to said handling means and in that said handling means comprises
a number of function handling means (11,12,13A-13C,14;21,22,23A-
23C;41,42,43;51,52,53;501,502,503A1-503C5,504A1,526,527,53A,531;
61,...,63B,71-74B;91A-96A,91B-95B) with processing means for
processing call objects, each function handling means providing
a number of result objects which are returned to the preceding
function handling means, and in that definition data
(120,220;410,420,430;522,523,514-520;610,620,720,730) for at
least a number of function handling means is provided separately
and independently.
25. Data handling arrangement according to claim 24,
characterized in




42



that the data handling arrangement comprises a number of function
handling means, a set of definition data being provided for at
least a number of the function handling means respectively and
in that a call object (100) is sent from one function handling
means to another in a consecutive way, the definition data of
each function handling means being kept separately e.g. in
tables, text files or being provided via programming.
26. Data handling arrangement according to claim 24 or 25,
characterized in
that the converting means translates messages incoming from
external systems, e.g. a client system, to internal standard
call objects and in that sending means comprises converting
means for translating an internal standard call object to an
internal communication message for sending to another data
handling arrangement and/or converting means for converting an
internal standard call object to a message format receivable by
an application system.
27. Data handling arrangement according to any one of claims
24-26,
characterized in
that adapting means is provided for a number of different
application systems, or versions of one and the same application
system etc.
28. Method for generic handling of data in a configurable number
of data handling arrangements, each of which contains a
configurable number of function handling means,
characterized in
that it comprises the steps of:




43



- for each function handling means providing definition data
separately from information data and independently from
definition data for other function handling means,
- handling information data generically and separately from
definition data,
- transferring information data as internal communication
messages between different data handling arrangements,
- transferring information data as internal call objects between
different function handling means using the respective
definition data to perform the desired functionality of the
respective function handling means,
- in each function handling means providing at least one result
object,
- returning the result objects to preceding function handling
means or data handling arrangement.
29. Method of sending a message from a managing system, e.g. a
client system, to at least one managed system, such as an
application system, through a number of data handling
arrangements,
characterized in
that it comprises the steps of:
- receiving a message from the managing system in interfacing
means of a data handling arrangement,
- converting the external message to an internal standard call
object and a number of result objects,
- distributing the call object to call object handling means
using separately held distribution definition data,
- in the call object handling means creating a transaction
identification and adding said transaction identification to



44



the internal call object using separately held transaction
definition data,
- routing the internal call object to a service agent using
separate routing definition data,
- processing the call object in a service agent process using
definition data information,
- analyzing the operations to be done in a call function handler
of said service agent process,
- providing a number of result objects to the managing system,
- sending/routing the internal call object to an adapter using
separately held definition data,
- in said adapter adapting the internal call object to a format
receivable by the relevant application system, if needed,
- transfering the (adapted) call object to the managed system.
30. Method according to claim 28 or 29,
characterized in
that it comprises the steps of:
- sending a message through a least a first and a second data
handling arrangement,
- converting in the first data handling arrangement the internal
call object to an internal communication message,
- sending the internal communication message to the second data
handling arrangement,
- in said second data handling arrangement converting the
internal communication message to an internal call object,
- sending the internal standard call object through a number of
function handling means of the second data handling
arrangement, for each function handling means using separate



45



- generating and/or modifying or controlling a number of result
objects in each function handling means, and
- returning said result objects to the preceding function
handling means and/or the first data handling arrangement.
31. Method according to claim 28, 29 or 30,
characterized in
that it comprises the step of adding a data handling arrangement
and/or a number of function handling means to one or more data
handling arrangements which includes the step of adding a
service agent and a corresponding manager for said service
agent.
32. Method according to anyone of claims 28-31,
characterized in
that it comprises the step of using client developed program
codes as definition data at least in the service agent process
or for at least a number of function handling means.

Description

CA 02292665 1999-12-03
W O-98/55921 PCTISE98/01060
1
Title
SYSTEM AND METHOD RELATING TO GENERIC HANDLING OF DATA
FIELD OF THE INVENTION
The present invention relates to a system for providing
communication between a number of data handling arrangements of
which at least a number are arranged in different hierarchical
layers. The invention also relates to a communication block which
is re-usable, i.e. which can be used on different levels in a
system and which enables the use of a generic component having the
same interface towards all kinds of functionalities. The invention
also relates to a method of sending messages between data handling
systems and/or function handling means and a method for generic
handling of data in a configurable number of data handling
arrangements each of which containing a configurable number of
function handling means.
STATE OF THE ART
Today a number of telecommunication operation systems exist. User
interfaces are often based on C++ programming language, but in
principle the user interface may comprise anything between a
communication protocol and a programming model. What the operator
needs, is an integration of different underlying interfaces and an
adaptation to his specific unique requirements. The needs of the
operators differ both as far as the data to be presented is
concerned, as to which user interface e.g. WindowsT"', protocol
interface etc., that actually is wanted. User interfaces operating
towards different machines are needed and systems are known in
which it is aimed at providing a definition of underlying
CONt=IRMAT10N
COi'Y


CA 02292665 1999-12-03
WO 98/55921 PCT/SE98/01060
2
interfaces in separate parts and to have a common structure
holding these parts. The distributed databases of today and the
need of flexible interfaces towards them often provide solutions
in which the same kind of components are re-used in another part
of the system, i.e. the "global" system. Examples thereon are e.g.
discussed in 'Microsoft Corporation, OLE 2 Programmers Reference
Vol. 1 and 2', Microsoft Press 1994 and Object Management Group
"The Common Object Request Broker: Architecture and
Specification".
US-A-5 327 529 shows how data is connected to separate
subfunctions.
However, no satisfactory solutions have been found through which a
really efficient re-use of components in a new environment is
provided and through which a simple modification of the interfaces
are supported in a heterogeneous system.
WO 95/11560 shows an application programming interface system for
heterogeneous connectivity and universal and generic interfacing
for distributed applications and processors. The object of the
system relates to a number of applications which should cooperate,
but does not provide an interface to something for which the
protocol is not exactly known. This document does not disclose a
continuously evolving interface. Distribution components of
similar kinds are used in order to ensure that applic~.tions having
these components are able to communicate with each her and they
are not intended for, and do also not provide for, an interface
which is flexible per se. The definition data that is given has a
very strict syntax adapted to the particular application.


CA 02292665 1999-12-03
WO 98155921 PCTISE98/01060
3
SUMMARY OF THE INVENTION
Therefore flexible products are needed which can be adapted to the
particular needs of different operators. An interface, which can
be almost completely completed without the knowledge about the
demanded services, is also needed. Particularly it shall be enough
to configure towards a specific underlying product. Furthermore
products are needed for which the functionality can be enhanced
step by step as the technology and the markets develop. The
interface upwards has to be stable; particularly it has to be
backwards compatible also when underlying interfaces are changed.
Furthermore it is desirable that an operator is enabled to define
the presentation of underlying interfaces. In general terms this
is achieved through simple components transforming data, which
components are flexibly controllable. The components reuse
overlying common functionality to control the translation of data
and for fetching information about how to provide the translation.
According to the present invention data is handled generically, so
that regardless of complexity and of differences between data, all
data is handled in one and the same manner. The protocols that are
used for transfer of data both support a generic handling of data
and structuring and classification of data. There are definitions
which can be changed in a simple way in order to modify the
interface. A separation is done between definition data that is
used to define the interface and its behavior and information data
which is the data that is sent and modified during operation of
the system.
According to the invention, a generic handling of information data
enables the provision of generic components having a uniform
interface, independently of the exact manner in which functions


CA 02292665 1999-12-03
WO 98/55921 PCT/SE98101060
4
are performed. Since information data consequently is handled in
a generic manner, the structured protocols that are used enable
the creation of flexible and re-usable building blocks which as
such contain intelligence to use the appropriate parts of the
information data that it receives and together with definition
data use said information data for different functionalities.
Definition data is structured according to common guidelines
following the division in components and building blocks. The
structuration of definition data in a number of ways is similar to
the structuration of information data transmitted using some
protocol.
According to the invention, definition data is always arranged
separately and it is never introduced into the components. In an
architecture according to the invention, simple generic building
blocks for communication are used on many different locations
within the architecture, and therefore the system can be
distributed in different ways on underlying hardware. A
hierarchical distribution mechanism is used which is controlled in
a flexible manner and the re-usable building blocks can be
combined in different ways. A building block here relates to a
complete functionality, mostly comprising a plurality of
components, a component here e.g. comprising a C++ class and
possibly some subclasses.
For the protocol a common syntax structure is used but all the
details of the syntax for a certain functionality will b~
specified along with the development of the functionality.
Identification on a superior level is included in the syntax
structure but every function then interpreters the specified
syntax. In the architecture different types of functionalities are


CA 02292665 1999-12-03
WO 98155921 PCT/SE98101060
arranged in different layers, c.f. an OSI (Open Systems
Interconnection) stack. This assists in enabling the creation of
simple, delimited building blocks.
5 Thus, a system for sending messages between a number of data
handling arrangements is provided wherein each data handling
arrangements comprises interfacing means and handling means. The
interfacing means includes converting means for translating
incoming messages to internal messages (calls) comprising an
internal call object and a number of result objects. At least a
number of the data handling arrangements comprises) a number of
function handling means and the interfacing means further
comprises) distributing means for distributing call objects to
the appropriate function handling means. A call object is sent
from one function handling means to another in a consecutive way
as an internal standard call object and each function handling
means provides at least one result object upon handling the call
object. Internal (standard) call objects are converted to internal
communication messages for sending between data handling
2o arrangements.
Providing a result object means that a result object is generated,
or, alternatively a result object from an underlying function
handling means is just modified or controlled before it is sent
on. The invention is based on an object oriented framework using
inheritance and the possibility of calling specialized object
without knowing anything but the common properties of a superior
object. In order to provide an interface between re-usable
building blocks which mainly is uniform, merely a few number of
call methods are used through which a call and a result object are
exchanged. A simple protocol is used to define information data


CA 02292665 1999-12-03
WO 98/55921 PCT/SE98/01060
6
e.g. as a name and ASCII-string and it is arranged on top of a
high level (basic) carrier service such as a remote procedure call
(RPC), X.25, Telnet etc. This makes the provision of communication
functionality very simple. Due to the generic handling of
information data, i.e. internal call objects or internal
communication messages, information about exactly which interface
to be built is not needed but calls to a number of underlying
interfaces can be prepared in a number of specific function
handling means which then are called according to what is given in
l0 a separate file or table containing definition data. A common
style for syntax of definition data is advantageously applied, but
unique identifiers and names of definition sets are used.
Therefore sets of definition data belonging to different function
handling means are independent and the independence between
different functional parts is provided through the independent and
separated sets of definition data.
Through the use of a generic communication block (data handling
arrangement; function handling means) which is reused for
different interfaces, the provision of new interfaces for a
system, which has to be distributed in a number of computing
arrangements, is facilitated. Furthermore the testing of
interfaces etc. is facilitated. The same structure that is used
for data handling arrangements is also used for distribution means
which is a function handling means, etc. which illustrates the
reuse of generic communication blocks. In a similar manner, the
same structure is used on "lower-level" or other parallell,
function handling means etc. When for example a user interface is
built, a definition for data translation can be generated which
for example also can be used by a distribution mechanism. In a


CA 02292665 1999-12-03
WO 98155921 PCTISE98/01060
7
particular embodiment a communication block is used which at the
same time serves as an external communication interface.
In a particular embodiment of the invention at least one data
handling arrangement receives messages from external systems which
in converting means are translated to internal communication
messages or standard call objects. Relating to particular
embodiments, incoming messages are ASCII messages based on a
carrier protocol such as for example HTTP, RPC, Telnet etc.
In some embodiments of the invention at least one (second) data
handling arrangement is arranged to receive messages from another
(first) data handling arrangement. In said other (first) data
handling arrangement internal call objects are translated to
internal communication messages before sending to the second data
handling arrangement. Messages are thus sent as internal
communication messages between data handling arrangements. In a
particular embodiment an internal communication message sent
between data handling arrangement comprises an ASCII data string
using the RPC protocol. In other common alternative embodiments
the HTTP protocol is used. In a particular embodiment at least one
data handling arrangement comprises sending means for sending a
call object (as a call operation) to an application system, e.g. a
service management application system (SMAS) . When referring to a
call object, is in the present invention meant an internal
(standard) call object. The sending means then comprises executing
means for translating the internal call object to a message having
a format receivable by the application system. In each data
handling arrangement and/or each function handling means, at least
one result object is provided when an internal call object is
processed and said result objects are sent to the preceding data


CA 02292665 1999-12-03
WO 98/55921 PCT/SE98/01060
8
handling arrangements/function handling means. Particularly all
information data, i.e. internal call objects or internal
communication messages, are handled generically and separately
from definition data used for defining the interface, its behavior
and the relevant functions. The definition data is stored in setup
files, tables or as text files in any appropriate manner. In a
particular embodiment at least one data handling arrangement or at
least one function handling means, apply load sharing, i.e. load
sharing can be applied on different levels either on the data
handling arrangement level or on the level of function handling
means. Alternatively or additionally, a number of data handling
arrangements are arranged in parallel). This also applies for the
function handling means, a number of which also can be arranged in
parallel), which presupposes the use of for example routing
handling means.
The interfacing means forms a single access point for external
client systems as well as for each data handling arrangement. The
interfacing means particularly comprises a parallel) distributor
for executing incoming calls in parallel) and a handler switch.
The interface means may also include protocol converting means for
converting different protocols to an internal communication
message before the convertion to an internal standard call object
is done in the converting means. The converting means of the
interfacing means particularly converts incoming messages to an
internal call object at least comprising the mandatory parameters:
object, action and key-fields and advantageously also a number of
optional parameters for information (call information).
Advantageously the handling means of a data handling arrangement
comprises a call object handler which receives internal call


CA 02292665 1999-12-03
WO 98/55921 PCT/SE98/01060
9
objects from the handler switch of the interfacing means and which
distributes the internal call objects to service agent managers
provided for processing the calls in service agent processes.
Particularly routing tables and/or text files are used for giving
distribution (definition) information. Advantageously, when a new
function handling means is introduced, (or a data handling
arrangement) an additional service agent is introduced and a
service agent manager has to be created and configured for
handling the service agent. Each service agent process
particularly comprises a function call handler for analyzing
incoming internal call objects to determine the relevant action
and for creating call objects to be sent to serving means of the
application system(s). In a particular embodiment at least one
data handling arrangement comprises an adapting part including one
adapter for each type of application system (or each version of
one and the same application system). In the adapters internal
call objects are received and converted to the type of message
receivable by the intended application system (version).
According to different embodiments at least one data handling
arrangement comprises a number of function handling means such as
for example one or more of a log handling means in which received
call objects are logged, for example together with date and time
stamp, transaction handling means in which a unique transaction
identification is added to the call object, router handling means
for routing the call object for example depending on physical
location address and/or functionality, conversion handling means
replacing one identification by another different identification,
authority handling means for checking user access to data
requested in a call object, validating means for checking data
sent in a call object etc. One or more data handling arrangements


CA 02292665 1999-12-03
WO 98/55921 PCT/SE98/01060
may comprise/be provided with one or more of said function
handling means and/or a number of other function handling means
defined or not yet defined, e.g. in the future developed function
handling means. The same applies for "lower level" function
5 handling means or subfunction handling means.
According to the invention a data handling arrangement is thus
also provided for messages incoming from a client system or from
another data handling arrangement. A data handling arrangement
10 includes interfacing means, handling means and sending means. The
interfacing means form a single access point for incoming
messages. The interfacing means further comprises converting means
for translating incoming messages to internal standard call
objects which call objects each at least comprise an object field,
an operation field and key-fields. Still further the interfacing
means comprises distributing means for distributing call objects
to said handling means. The handling means comprises a number of
processing means for processing call objects, at least one result
object being provided when an operation is performed. Each of said
processing means comprises function handling means and when an
operation has been performed in a function handling means, a
result object is returned to the preceding function handling means
(or a preceding data handling arrangement).
According to the invention a method is also provided which relates
to the sending of a message from a client system to an application
system through a number of data handling arrangements. The method
comprises the steps of:
- receiving an message in interfacing means of said data handling
arrangement,


CA 02292665 1999-12-03
WO 98/55921 PCTISE98/01060
11
- converting the message to an internal standard call object and a
number of result objects,
- distributing the internal call object to call abject handling
means,
- in the call object handling means creating a transaction
identification and adding said transaction identification tc the
internal call object,
- routing the internal call object to a service agent,
- processing the call object in a service agent process using a
set of definition data e.g. comprising a customer developed
code,
- in the call function handler analyzing which operations are to
be done,
- providing at least one result object in each step, which is
provided to the preceding step,
- sending/routing the internal call object to an adapter specific
for the intended application system server in which the call
object is adapted, and
- sending the adapted message to the application system.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention will in the following, in a non limiting way, be
further described with reference to the accompanying drawings in
which:
FIG 1 schematically illustrates the inventive concept in common
terms,
FIG 2 schematically illustrates different functional layers
(function handling means) getting definition data for
flexible controlling,


CA 02292665 1999-12-03
WO 98/55921 PCTISE98/01060
12
FIG 3A schematically illustrates a managing system managing a
number of application systems,
FIG 3B schematically illustrates a service agent framework,
FIG 4 schematically illustrates a first embodiment of a data
handling arrangement handling different application
systems,
FIG 5 illustrates the interfacing means of the data handling
arrangement of Fig 4,
FIG 6 illustrates the handling means of the data handling
arrangement as illustrated in Fig 5,
FIG 7 schematically illustrates a service agent process,
FIG 8 schematically illustrates authority handling means,
FIG 9 schematically illustrates routing handling means,
FIG 10 schematically illustrates access handling means,
FIG 11 is an example of an adapter,
FIG 12 illustrates an embodiment comprising three data handling
arrangements,
FIG 13 is a flow diagram for sending a message via two data
handling arrangements to an application system.
DETAILED DESCRIPTION OF THE INVENTION
In Fig 1 first generic communication handling means (converting
means) 15 converts an internal call object to a generic internal
standard communication message 1 which is sent to second generic
communication handling means (converting means) 11 of a data
handling arrangement 10, in which the internal communication
message is converted to an internal standard call object. The
internal call object is received in distributing means and the
call object is routed via function handling means routing table 12
to specific logic function handling means 13A;13B;13C using
definition data 120 in a separate definition file or a table. A


CA 02292665 1999-12-03
WO 98/55921 PCT/SE98/01060
13
result object is returned (not shown) and internal standard call
' objects are sent to another data handling arrangement via first
and second generic communication function handling means 14,21
(blocks) (in which it is converted to/from an internal
communication message). The second data handling arrangement 20 is
for example a generic service adapter in which a similar procedure
as above is performed using definition data 220 in table function
handling means 22 for sending an internal communication message to
specific logic function handling means 23A;23B;23C etc.
Fig 1 illustrates one way of implementing a distribution
mechanism. In alternative embodiments the distribution
functionality is implemented e.g. by two or three independent
function handling means, each having a separate set of definition
data, c.f. the function handling means distributor and router in
Fig 12; a function handling means rearranger (not shown) may also
be implemented between the distributor and the router of Fig 12.
According to the invention the distribution mechanism is
controlled by definition data providing information about which
underlying data handling arrangement/function handling means is to
be the receiver of a particular messages.
According to the invention the definition data can be in the form
of "simple" data, but it may also contain more or less advanced
programming. Particularly a complete specific logic containing
data and intelligence can be exchanged completely in one step.
Fig 2 illustrates how different functional layers fetch definition
data for flexible controlling by a controlling arrangement 40. For
each layer a function handling means 41,42,43 is created and these
function handling means have an external interface which is
uniform, comprising the reception of a call object and a response


CA 02292665 1999-12-03
WO 98/55921 PCTISE98/01060
14
in the form of a result object. In these embodiments the different
function handling means are security handling means 41, validating
handling means 42 and execution handling means 43. Definition data
for each function handling means (security model 410, validation
model 420, config. validation 430) are kept separately and
independently.
One example of a function handling means which is implemented as
an interface to C++ classes is a security function handling means
the interface of which is the class security which only contains
the method handle (call object, result object) and another example
is a function handling block validator the interface of which is
the class validator having the methods:
- validate (call object, result object)
- handle (call object, result object).
Both these function handling means have an important internal
functionality and a considerable internal structure even if they
from the outside seem to be two very simple objects only
supporting a few possible methods.
Fig 3A very schematically illustrates service providers and a
managing system CC BS managing a number of application systems
SMAS, SOG etc. The service providers form the sales
service/customer view. The external (managing) system or the
client system is here supposed to be a customer care and a billing
system {CC BS) or a custo;t~er administrG.-.ion system including a
subscriber database and a billing database. A message is sent by
interfacing means (not explicitly illustrated) as an enhanced
customer administration interface object, here called a CAI+
message. A CAI+ message is a textbased message comprising a number


CA 02292665 1999-12-03
WO 98/55921 PCT/SE98/01060
of CAI+ objects followed by an action. A CAI+ object is an object
name followed by data or a number of object names followed by
data. The message can be sent to a number of different application
systems such as a service management application system SMAS of
5 different versions (e. g. service data point SDP and service
control point SCP) using a man machine interface MMI and an INM
protocol (a TCP/IP based, binary format protocol) respectively.
Using MML (man machine language) a message can be sent to a
service switching point SSP in a mobile communications system, or
10 as an ordinary CAI message (Customer Administration Interface,
which is CMISE-based with ASCII-coded managed objects; CMISE is
described in X.710 (ITU-T) "CMISE, Common Management Information
Service") to a SOG (Service Order Gateway) and further to a home
location register HLR using specific adapters MML, GSA (Generic
15 Service Adapter), CAI, in the data handling arrangement. A SOG is
a device providing an information interface towards a customer
administration system for a mobile communication system. A GSA
service agent framework is a product hiding different subsystems
in the service provisioning area for the client. As illustrated in
the figure there exists a number of different subsystems having
different representation of the subscription data. A service can
have its provision data distributed in different subsystems such
as GSA-SCP and GSA-SDP servers etc.
The Generic Service Adapater (GSA) provides support for
development of communication interfaces, graphical user
interfaces, and batch handling interfaces for IN (Intelligent
Network) Service Provisioning. GSA offers a generic service view
in all interfaces, which hides the implementation of IN Services.


CA 02292665 1999-12-03
WO 98/55921 PCTISE98/01060
16
GSA is based on SMAS which is a system in the TMOS family for
management of IN services. SMAS consists of the Service Creation
Environment (SCE) and the Service Management System (SMS).
SMAS includes functions for creating new IN services and updating
existing ones. It further provides functions for installation of
services into the network elements, and operations to connect
subscribers and subscriber specific data to the services.
Statistics on service usage can be retrieved from the network and
presented to the SMAS user.
GSA provides an environment for development of machine-machine
commuication interfaces or man-machine interfaces for provisioning
of services managed by SMAS. The connection between communication
messages or UI (User Interface) fields and corresponding IN
objects is handled in GSA by a service configuration file. With
this file, GSA interfaces can be developed which provides a
service implementation independent view of IN services.
When the GSA service configuration files and forms have been
developed and tested in a development and test environment, they
must be moved to the operational Service Management and
Provisioning system also includes a GSA installation.
GSA does not have any extra support for storing information about
the subscribers or subscriptions. Thus, its completely transparent
towards SMAS. For each SMAS service or SDP application, a service
configuration file is created. Logic handling relations between
SMAS services or SDP applications are handled outside GSA.
Fig 3B schematically illustrates a {GSA) Service Agent Framework.
The interfacing means comprises a parallell distributor and a
handler switch for distributing/routing call objects. This is
further described under reference to Figs 4 and 5. Adapters are
used for sending a message to different application systems or


CA 02292665 1999-12-03
WO 98155921 PCT/SE98/01060
17
different versions of application systems, such as e.g. GSA 2.1-
SDP, GSA2.2-SDP, GSA-SCP; SOG, GSA-SAF-CUSTOM and SQL (Standard
Query Language)-server. The relevant interfaces to be used are
alsc indicated in Fig 3B. The given application systems/versions
are only given for exemplifying reasons. A standard service agent
is provided for reading "simple" forms of definition data; e.g. a
message can be divided into a number of parts etc., using a
con=iguration file.
For more advanced or specifique tasks a customer service agent is
prow-ided through which the customer can provide for definition
data (e. g. programs) to handle specifique or advanced tasks etc.
A first embodiment of a data handling arrangement according to the
invention will now be more thoroughly explained with reference to
Figs 4-11. The data handling arrangement 50 as referred to above,
c.f. Fig 4, comprises an interface part 51 which will be further
described under reference to Fig 5. The interface function
handling means (interfacing means) forms a single access point for
the client system(s). Different communication interfaces can be
offered.
The data handling arrangement further comprises function handling
means called handling means 52 which takes care of the actual
message (call) processing in so called service agents.
An incoming message is converted to an internal standard call
object in the interfacing means 51. A call object comprises ASCII
coded data, comprising a number of CAI+ objects followed by a
number of actions (generally more objects than actions). A service
agent is called which then invokes its logic to execute the


CA 02292665 1999-12-03
WO 98/55921 PCT/SE98/01060
18
request. A service agent is an object created to support service
provisioning operations and it does not exist in the system
itself. The service agent is what is provided when a configuration
is made at site. For the configuration a number of operations are
defined which effect the service agent object in a standardized
way. The operations are create, set, delete and get. Other
operations can however be implemented within the framework e.g. by
customer programming.
To adapt the internal call object to an existing standard can for
example the HTTP format be used. Each message from a client system
can result in multiple messages to other subsystems or application
systems via adapters in adapting means 53, which also are included
in the data handling arrangement 50 as illustrated in Fig 4. Not
every data handling arrangement includes an adapter part since
some data handling arrangements may only communicate with other
data handling arrangements and not with application systems or
subsystems. However, in Fig 4 it is supposed that the data
handling arrangement 50 communicates with, or sends messages to,
application systems 6A,6B. The adapter part 53 then takes care of
all specific handling including addressing, routing, adaption of
messages, communication protocols and different versions of
subsystems or different application systems. This means for
example that different versions of a service management
application system SMAS 6A can be handled via different adapters
e.g. GSA-SCP, GSA-SDP, GSA-SCP old as well as other application
systems, e.g. SOG 6B. The adapting part 53 also includes a General
Service Agent Functionality (SAF) part including a number of
servers, of which some examples are shown in Fig 4, e.g. a lock
server, a transaction server, setup/validation serving means etc.
The handling means 52 will be further described under reference to


CA 02292665 1999-12-03
WO 98/55921 PCT/SE98/01060
19
Fig 6 and the adapting means 53 will be further described with
reference to Fig 11 in which a specific adapter is illustrated for
exemplifying reasons.
In Fig 5 the interfacing means 51 according to a first embodiment
is illustrated. Messages are incoming from one or more client
systems e.g. via a customer administration interface CAI, some
other interface or as an internal communication message (for
example from another data handling arrangement?. The interface
part, i.e. the interfacing means 51, includes a parallell
distributor 501 which is able to execute incoming calls in
parallell. The parallell distributor 501 has one port or access
point for all calling clients (and adapters). In a particular
embodiment the interface format from the parallell distributor is
HTTP (or RPC). A call object 100 is the standard internal
interface between different handlers and objects. The internal
standard call objects 100 are used as arguments between internal
interfaces and they contain the field information. The internal
call object 100 is sent for example via HTTP or RPC. The interface
part thus comprises converting means for translating an input
message sent via RPC or HTTP to a call object 100. The call object
100 comprises a number of parameters of which the parameters
object, action and key-fields are mandatory. However, there are
also optional parameters with information. "Object" defines the
service feature object to be managed and "action" defines the
operation. Key-field parameters are defined in a validation
profile for the "object". An example of a call object comprising
a CAI+ object and an action is given below:


CA 02292665 1999-12-03
WO 98/55921 PCT/SE98/01060
Object=VPNl.l VER1 COMPANY
TransID=12231 (generated from a higher level system)
SubscriberNumber=12345678
5 DDNl=5678967
DDN2=567867567556
Action=Create
TransID is an optional parameter set by the calling system and it
10 is not modified but used for identification of the call in logs.
The result of the operation (action) is sent back with a result
obj ect .
An example of a call object comprising three CAI+ objects and two
15 actions may be as as follows:
Object=VPN1.1 CAI+(1)
TransID=...
20 DDN1=...
DDN2=...
Object=VCC... CAI+(2)
DDNl=...
Action=Create
Object=VPN2.2 CAI+(3)
TransID=...
Action=Set


CA 02292665 1999-12-03
WO 98/55921 PCT/SE98101060
21
The protocol converting means adapting messages acts a server for
the client system. Internally the converting means may act as a
client. Examples of converters are CAI-CAI+converters and RPC-HTTP
converters. The converting means may also comprise a CAI to Telnet
protocol converter and a RPC to HTTP protocol converter. A
multithreaded (builds applications with multiple threads) RPC
server converting from RCP format to HTTP format can also be
provided. The converting means may also in a particular embodiment
route a HTTP message to two different URL addresses (w.w.w.
addresses) such that if a first URL address is not available, the
next address will be called instead. From the interfacing means
51, via the parallell distributor 501, or separate switching
means, the call objects 100 are transferred to the handling means
52.
In Fig 6 the handling means 52 according to the embodiment of Fig
4 are illustrated. It is supposed that a call object 100 (i.e. an
internal standard call object) is received from the interfacing
means 51. The call object is received in a call handler 502 which
creates and adds a unique TransID, e.g. a GSA TransID to the call
object. The call handler sends the call object 100 to the relevant
service agent manager 503A via a routing functionality. Routing
information (i.e. definition data) is advantageously set up in a
table (not shown). Which service agent manager that is chosen,
depends on the call object. In a particular embodiment there is
one standard service agent and a number of customized service
agents. A service agent manager 503A,503B,503C acts as a manager
for a number of service agent processes
503A1, . . . , 503A5, 503B1, . . . , 503C5. Each service agent manager
503A,503B,503C can only handle one type of service agents. The
service agent manager can be configured for the number of


CA 02292665 1999-12-03
WO 98/55921 PCT/SE98/01060
22
processes to be running. In an advantageous embodiment the manager
includes a functionality of error reporting if a service agent
fails. In an advantageous embodiment the service agent manager
includes a functionality for supervision of load and resource
utilization etc. When a new service agent is introduced into the
service agent framework, a new service agent manager has to be
created and configured.
Fig 7 illustrates the reception of a call object in a service
agent process 503A. In a particular embodiment the service agent
process is written in JavaTM of Sun Microsystems and the process
is started/restarted and stopped from its call handler 502. The
service agent process comprises a function call handler 504A, also
denoted a message handler, which is a central object in the
service agent framework. The function call handler 504A1 analyses
incoming messages (call objects) 100 to decide which actions are
to be performed. The function call handler 504A1 creates a number
of call objects which are sent to other servers via adapters which
will be more thoroughly described below.
The function call handler 504A1 comprises a number of function
handling means, in this particular case a lock handler, a log, an
authority handler, a message validation handler in addition to the
call object handler (handle messages) itself. Of course this
merely constitutes one particular embodiment and fewer as well as
more function handling means can be provided, and of course the
invention is not limited to include these particular function
handling means but a wide variety of other alternatives are
possible. For exemplifying reasons the illustrated function
handling means will be more thoroughly discussed below.


CA 02292665 1999-12-03
WO 98/55921 PCT/SE98/01060
23
Since working with messages or call objects in parallell from
clients has to be done in a controlled manner, a lock handler is
provided. Therefore locks are introduced per managed object (call
object) identity and the call objects are identified by the key
fields contained in the object. The lock handler checks if an
object is locked, and if not, the call object will be introduced
into a lock server 514 as locked. The lock server is arranged
externally in the shown embodiment.
Definition data SETUP FILE 522, PROGRAM CODE 523 as well as lock
server 514 etc. is kept externally.
When the execution is ready, the lock handling function unlocks
the call object by deleting it from the lock server 514.
Advantageously the number of locked objects in parallell is low,
for example less than 50. Advantageously the lock handling
functionality is configurable so as to be possible to switch
on/switch off.
Advantageously the function call handler also contains a
transaction handler. A transaction ID is then created for each
call object. The identity is used to identify the call in logs
etc. and it is added as one parameter in the call object. The
handler can use a transID in outgoing calls with an extra
extension per call and for example two extra digits for outgoing
calls. Transaction ID handling is performed using a transaction
server 515.
Input call objects as well as result objects are both logged in an
event log server 519.


CA 02292665 1999-12-03
WO 98/55921 PCT/SE98/01060
24
The authority handler handles authority profiles. Different users
are connected to the profiles which describe what operations a
user is allowed to do for different call objects. The authority
handler deals with access control to different objects. The
authority handler as such is not essential and can be switched off
which means that all access requests are granted. The authority
handler is able to retrieve which key-parameters that belong to a
particular call object which means that the authority handler must
have access to the setup-files (text files or tables). At start up
the authority handler reads all setup-files which are present by
calling a setup/validation server 516 in order to be able to
conclude which parameters of the call objects that are considered
as key parameters for the different call objects. The access
control is handled by an authority server 517 which is called by
the authority handler. The authority server either returns "grant
access" or "deny access" depending on if a call object matches an
existing authority profile in the authority database or not. This
is illustrated in Fig. 8. The authority handler in one embodiment
works within the function call handler although it is not
necessary and access to the authority server 517 is provided with
object identifier parameters, user identity and action.
The message validation handler validates input call objects and
checks mandatory parameters and parameter limitations by calling
setup/validation server 516. Of course also other validation
requirements can be implemented by a program code in the function
call handler which alternatively can be done by the client.
The handling means also includes a standard message handler for
rearranging messages (handle messages in the figure) which is the
core functionality of the standard service agent handler (cf. Fig


CA 02292665 1999-12-03
WO 98/55921 PCTISE98/01060
4). It creates messages (call objects), calls an adapter to send
the call object (if the data handling arrangement includes
adapters which however is the case in the shown embodiment),
analyses the result, determines the next action to be done and
5 provides/creates a result object to be sent back to the calling
client. For simple tasks "single transaction" can be used for
example applying best effort which means that the transaction will
continue with remaining messages even if the previous failed. In
an alternative embodiment atomic synchronization is used, which
10 means that if the transaction is not successful for all objects,
the whole transaction will be undone. According to different
embodiments parallell execution is applied or not. As discussed
above each input message or a call object has fields named
"object" and "action". This combination points out the call
15 objects to be sent to the underlying servers. A batch of messages
or call objects are written in the setup file per action and the
batch is then executed by the handler after preprocessing. In an
advantageous embodiment free programming of service agents is
provided for. This is particularly advantageous for cases when the
20 tasks to be performed are complex or when the standard operations
are not sufficient. The service aqent proqrams are in an
advantageous embodiment written as JavaT"' objects. The handle
message code is the only code that needs to be written for each
new service agent. When programming is applicable a program name
25 is given in the file. The actual object, i.e. the service agent,
is given a number of start up parameters such as the input
message, send message function, call and result collection class,
log functions, error reporting capabilities etc. from the standard
service agent handler.


CA 02292665 1999-12-03
WO 98155921 PCT/SE98/01060
26
Information relating to locked objects authority profiles, routing
tables etc. is stored in data base 518. A send handler 526 is also
provided which includes a number of function handling means such
as lock handler, transaction, log and send (in this particular
case). The send handler hides a number of functions to the
function call handler or the message handler which the latter is
not to be concerned with. This function handling means functions
substantially in the same manner as the function handling means of
the function call handler as discussed above. For routing a call
20 object to different server subsystems advantageously a routing
table is used. Internal standard call objects uses routing (e. g.
RPC based) without adaptation. If however adaptation is required,
this is implemented in adapters for the particular service
subsystem or the particular application system (version).
In the call and result (C&R) store 529 incoming and sent messages
(calls) are stored as well as the results. Connection pool and
routing function 525 is an object combining open connections for
the transaction. The routing function is involved when a new
connection is created. A setup file (i.e. definition data)
specifies key fields (mandatory fields) and how the parameters
shall be converted if applicable. The setup file also specifies
operation mode, single transaction or programming. If programming
is applicable, a program name is also given in the file as
discussed above.
The service agent process also includes a result handler 527 which
in turn also comprises a number of function handling means; in
this particular case translate message, reset connections, reset
call and result store and return result. The result object created
by the handler is to be returned to the client system. This can be


CA 02292665 1999-12-03
WO 98/55921 PCT/SE98/01060
27
done in different ways. Before the result object is sent back, all
data in the call and result store 524 are deleted for the
transaction.
Connections in the connection pool 525 are also closed. This is
done in order to make the service agent process ready to execute
the next call object in a subsequent transaction. In the call and
result store 524 a collection of calls and results for the actual
transaction are stored. The store is provided with a copy of each
call object and result objects and all outgoing call objects are
stored together with the transaction sub-identification which is
the outgoing call object number.
Advantageously each outgoing CAI+object is on the same format
whereas the objects are modified in the adapters, if so required
by the receiving system. The definition data included in the
database DB 518 among others comprises locked objects, authority
profiles and routing tables etc.
As can be seen definition data, particularly setup file 522 and
program code 523 is always kept separate from the information
data, e.g. the call objects.
In Fig 9 call object server routing is schematically illustrated
for various servers (GSA1SCP, GSA2SCP, GSA1SDP, SOG-AD) of service
management application systems indicating the RPC-hostname and the
RPC-ports to be used. The adapters here adapt the call objects to
messages receivable by the application systems. An Application
Programming Interface (API ) of a Generic Service Adapter for RPC
communication is e.g. used for sending.


CA 02292665 1999-12-03
WO 98/55921 PCTISE98/01060
28
In Fig 10 the granting of access procedure via the authority
server 517 is schematically illustrated. The database 518 includes
an object table 518A and an access table 518B. From the call
object, the object type and the key parameters are used to
retrieve the call object ID. The user ID, the action and the
object ID select a distinct row in the access table and if the row
exist, the access is granted. Otherwise the access is denied. In
the figure the section between the call and the database relates
to the storing procedure. The underlined parameters are the keys
for the respective table. Particularly there are at least three
stored procedures, one for the access control, one for the
creating of new authority profiles and one for deletion of
authority profiles. For performance reasons it is necessary to
have memory enough to e.g. a database cache to minimize the need
for disc access for the handling of requests.
The data handling arrangement as illustrated in Fig 4 includes an
adapter part 53 since the data handling arrangement communicates
with application systems 6A,5B. In Fig 11 a so called GSA-SCP 53A
adapter is illustrated which is a generic service adapter-service
control point adapter relating to the SCP version of a SMAS.
Generally a number of different adapters can be provided and
developed. In Fig 4 GSA-SCP 53A, GSA-SDP 53B and SOG 53C adapters
are illustrated. However, other adapters can also be provided such
as for example SQL adapters. Advantageously the adapters support
call objects based on RPC (or HTTP) but also other alternatives
are possible as discussed earlier in the application.
The adapter 53A is called by the handler, i . a . the function call
handler (message handler) 504Az. The handler 504A1 has specified
the parameters to be sent and the adapter 53A adapts them for the


CA 02292665 1999-12-03
WO 98/55921 PCT/SE98101060
29
actual server (here GSA-SCP) and then sends a call object to the
GSA-SCP subsystem. The adapter also converts the returned result
object to a CAI+ format before it is returned to the call handler.
Generally an adapter internally can be implemented in a number of
different ways depending on the supported system. Furthermore new
adapters can be added without requiring any modification of the
service agent framework product. In an advantageous embodiment the
adapters are developed as separate server processes. In this way
development and testing gets easier and do not depend on one
another.
As can be seen from Figure 11 the GSA-SCP adapter 53A here
comprises a parallell distributor 531 for load sharing purposes
and the_call object is sent to the adapter itself which includes a
routing table 532. Load sharing relates to an advantageous
implementation of the invention which however is not necessary. In
an advantageous embodiment resource sharing is provided so that
the message can be sent to a free subsystem. This is also not
necessary for the functioning of the invention but merely
describes an advantageous embodiment. In this particular
embodiment the adapter converts a call object to a GSA-SCP server
message. Advantageously the adapter is multithreaded in order to
cooperate with multiple GSA-RPC servers. Since a GSA-SCP server
using the RPC-protocol is single threaded, the server only
2S executes one request at the time. Advantageously multiple servers
are running in one and the same application system (SMAS). A
resource pool 533 for distribution to different servers within the
same application system is then needed. To provide for load
sharing between different servers in the resource pool, an
algorithm is needed and a central data area is provided for the
algorithm data. The algorithm is executed by multiple GSA adapters


CA 02292665 1999-12-03
WO 98/55921 PCT/SE98/01060
simultaneously and for indication of the number of the respective
GSA servers and their addresses, a parameter list is provided.
For routing purposes a routing table as illustrated in Fig 11 can
5 be used. In an advantageous embodiment an SCP specified in an
incoming call object can be replaced by the actual SCP name as
used in the application system (SMAS). This is an advantageous
functionality which can be implemented to support the possibility
of late integration and the service agent can be setup and
10 delivered to a customer site in complete without requiring any
modifications, the only adaption required in the Service Agent
Framework SAF being to update the routing table in the adapter.
In a similar manner a GSA-SDP server adapter can be provided which
15 converts incoming call objects to GSA-SDP server messages using
RPC. Similar to the adapter illustrated in Fig 11, a routing table
is provided. However, this adapter does not have to be
multithreaded since no SDP requests are executed in parallell.
20 In an advantageous embodiment a SOG adapter service order
gateway) can be provided for converting call objects to CAI
messages for a Telnet based SOG. Also this adapter comprises a
routing table.
25 As referred to above also other adapters can be provided.
In Fig 12 an embodiment comprising three data handling
arrangements 60,70,80 is illustrated, showing the reuse
possibilities. The first data handling arrangement 60 comprises
30 three function handling means, namely distributor 61, router 62
and communication 63A,63B. The definition data relating to the


CA 02292665 1999-12-03
WO 98/55921 PCTISE98/01060
31
distributor 61 is separately arranged in a table 610 showing which
types of services e.g. Virtual Call Center, (VCC), Virtual Private
Network (VPN), Universal Personal Telecommunications (UPT) that
are to be distributed to which physical locations, e.g. SMAS A1,
SMAS A2, SMAS A3; A1, A2, A3 e.g. being different towns.
To the router function handling means 62 a set of definition data
is provided comprising a table 620 for routing to the appropriate
computer address. The communication function handling means
63A,63B provides for a conversion of an internal call object to an
internal communication message as discussed under reference e.g.
to Fig 1.
The second data handling arrangement 70 also comprises a number of
function handling means 71,72,73,74A,74B. The communication
function handling means 71 provides for conversion of an incoming
communication message to an internal call object. The definition
data of the distributor is provided in a table 720 giving the
handler process to which a given service object (e. g. subscriber,
VCC queue, VCC prompt; i.e. different CAI+ objects) is to be
distributed.
The router definition data is kept in a table 730 indicating which
computer ports (addresses) given handler processes are to be
routed to. The communication function handling means 74A,74B
provides a conversion as discussed above. Thus, the first data
handling arrangement 60 can distribute a message to different
physical locations depending on which type of service is
addressed. The second data handling arrangement 70 distributes to
different processes depending on which object that should be
modified and the third data handling arrangement 80 executes the
modification.


CA 02292665 1999-12-03
WO 98/55921 PCTISE98I01060
32
A reuse of exactly the same function handling means can be
achieved between the first and the second data handling
arrangement since the distributor and router function handling
means are exactly the same but the definition data make them serve
different purposes.
In Fig 13 a flow diagram is illustrated in which a message
incoming from an external system is received in a first data
handling arrangement 90A. The flow diagram both illustrates the
sending of call objects (i.e. internal standard call objects)
between function handling means within a data handling arrangement
and the sending of objects or messages as internal communication
messages between data handling arrangements or from a data
handling arrangement to an application system 90C (adapted if
needed). It should however be clear that this merely relates to
one particular implementation of the inventive concept.
The first data handling arrangement 90A comprises a number of
function handling means here a receiver 91A, a log 92A, a
transaction handler 93A, a lock handler 94A, a router 95A and a
sender 96A. A message is received from an external system, in the
receiver 91A, which for example can receive ASCII messages based
on some kind of carrier protocol such as HTTP, RPC, Telnet. The
receiver 91A includes translating means for translating the
incoming message to an internal standard call object. The internal
standard cG~l object is sent to the log 92A in which it is logged
together w~~h a date and a time stamp. The receiver 91A, on
processing the object, provides a (empty) result object which is
returned to the external system. The log 92A in turn provides or
generates or provides a result object which is returned to the


CA 02292665 1999-12-03
WO 98/55921 PCTISE98101060
33
receiver 91A. From the log 92A, the call object is sent to the
transaction handler 93A in which a transaction ID is added to the
call object. Also the transaction handler 93A generates/provides a
result object which is returned to the log 92A. The call object is
then sent to the lock handler 94A, the functioning of which has
been described earlier in the application which also provides a
result object etc. In the router 95A the call object is routed
depending on for example the physical location e.g. for purposes
of load sharing and call objects are generated and can be sent to
three systems. The sender 96A includes translating means for
translating an internal standard call object to an internal
communication message, and the internal communication message, for
example an ASCII data string sent using the RPC protocol, is sent
to the second data handling arrangement 90B, which also comprises
a number of function handling means, here receiver 91B, authority
handling means 92B, converting means 93B, validating means 94B,
executing means 95B. In the receiver function handling means 91B
the internal communication message is converted to an internal
standard call object and a result object is provided which is sent
back to the first data handling arrangement 90A. The standard call
object is sent to the authority handling means 92B in which a
check is done to see if the user is allowed to use the data that
as requested in the call object. The result of the operation is
returned to the receiver 91B. In the conversion handling means
(converter) 93B a data conversion is performed. An example thereon
is the replacement of one identificator by another. Again a result
object is provided, which is returned to the authority handling
means 92B. In the validating means 94B the data contained in the
call object is checked, for example the length of data string of
the call object is checked. Again a result object is returned. The
execution handling means 95B performs the actual method call


CA 02292665 1999-12-03
WO 98/55921 PCTISE98/01060
34
towards the underlying subsystem, i.e. the application system. An
example thereon is a call of C++ class method that sets data in
database. An adapted message is then provided to the application
system 90C which may comprise a database interface library of a
relational database.
Thus, the system coordinates and modifies messages towards the
data handling arrangements, in order to provide a simple one point
of entry interface for simple messages that are transformed to a
larger more complex set of messages.
It should be clear that the invention is not limited to the shown
embodiments but that it can be varied in a number of ways within
the scope of the claims. Particularly it should be clear that the
same procedure can be implemented on different hierarchical
layers, using the conversion to an internal call object, and
always keeping definition data separately and independently
meaning that additional functions etc. can be added, modified etc.
in different systems, on different levels without affecting
overlying interfaces.

Representative Drawing