WO1998055921A1

WO1998055921A1 - System and method relating to generic handling of data

Info

Publication number: WO1998055921A1
Application number: PCT/SE1998/001060
Authority: WO
Inventors: Michael Bratt; Jan Lenander; Konstantin Zervas
Original assignee: Telefonaktiebolaget Lm Ericsson
Priority date: 1997-06-04
Filing date: 1998-06-03
Publication date: 1998-12-10
Also published as: SE9702113L; SE9702113D0; AU8046998A; CN1265203A; EP0986782A1; AU740953B2; CA2292665A1

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.

Description

Title SYSTEM AMD 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. Windows™, 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

CONFIRMATION COPY 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 applications having these components are able to communicate with each other 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. 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 produc . 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 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 be 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 arranged in different layers, c.f. an OSI (Open Systems Interconnection) stack. This assists in enabling the creation of simple, delimited building blocks.

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 comprise (s) a number of function handling means and the interfacing means further comprise (s) 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 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 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 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 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 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 parallell . This also applies for the function handling means, a number of which also can be arranged in parallell, 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 parallell distributor for executing incoming calls in parallell 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 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 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 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 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 , - converting the message to an internal standard call object and a number of result objects,

- distributing the internal call object to call object handling means , - in the call object handling means creating a transaction identification and adding said transaction identification to 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, 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 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 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 customer administration 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 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 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 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 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. 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 , chey 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 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 also 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 configuration file.

For more advanced or specifique tasks a customer service agent is provided 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 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 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: Obj ect=VPNl .1_VER1_C0MPANY

TransID=12231 (generated from a higher level system) SubscriberNumber=12345678 DDN1=5678967

DDN2=567867567556 Action=Create

TransID is an optional parameter set by the calling system and it is not modified but used for identification of the call in logs. The result of the operation (action) is sent back with a result object .

An example of a call object comprising three CAI+ objects and two actions may be as as follows:

Object=VPNl.l CAI+(1)

TransID=... DDN1=...

DDN2=...

0bject=VCC... CAI+ (2)

DDN1=...

Action=Create 0bject=VPN2.2 CAI+(3)

TransID= ...

Action=Set 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 503A_X, ... , 503A₅, 503B_!, ... , 503C₅. 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 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 Java™ 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 504A-_L analyses incoming messages (call objects) 100 to decide which actions are to be performed. The function call handler 504A_], 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 504A_X 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. 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. 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 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 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 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 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 tasks to be performed are complex or when the standard operations are not sufficient . The service agent programs are in an advantageous embodiment written as Java™ 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 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. 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 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 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. 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,6B. 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.e. the function call handler (message handler) 504A-_L. The handler 504A-_L has specified the parameters to be sent and the adapter 53A adapts them for the 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 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 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 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 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 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.

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.

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 three function handling means, namely distributor 61, router 62 and communication 63A,63B. The definition data relating to the 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; Al , 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. 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 call object is sent to the log 92A in which it is logged together with 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 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 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.

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 arrangement (s) comprises a number of function handling means (11,12,13A- 13C,14;21,22,23A-23C;41,42,43;51,52,53;501,502,503A₁-503C₅,504A₁, 526, 527, 53A, 531; 61, ... , 63B, 71-74B; 91A-96A, 91B-95B) c h a r a c t e r i z e d i n 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,503A₁-503C₅,504A₁,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,503A₁-503C₅,504A₁,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- 23C ; 41, 42, 43 ,-51,52,53,-501, 502, 503A₁-503C₅,504A₁, 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, c h a r a c t e r i z e d i n 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, c h a r a c t e r i z e d i n 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, c h a r a c t e r i z e d i n 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, c h a r a c t e r i z e d i n that incoming messages are ASCII messages based on a carrier protocol such as e.g. HTTP, RPC, TELNET etc.

6. System according to any one of the preceding claims, c h a r a c t e r i z e d i n 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, c h a r a c t e r i z e d i n that an internal communication message sent between daca handling arrangements comprises an ASCII data string and in that the RPC/HTTP protocol is used.

8. System according to claim 7, c h a r a c t e r i z e d i n 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, c h a r a c t e r i z e d i n 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/func ion handling means.

10. System according to any one of the preceding claims, c h a r a c t e r i z e d i n 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, c h a r a c t e r i z e d i n that at least one data handling arrangement/function handling means apply load sharing (96A) .

12. System according to any one of the preceding claims, c h a r a c t e r i z e d i n 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, c h a r a c t e r i z e d i n 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, c h a r a c t e r i z e d i n 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, c h a r a c t e r i z e d i n 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 (503A_lf ... , 503C₅) , 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, c h a r a c t e r i z e d i n that routing tables and/or text files are used for giving distribution information.

17. System according to claim 15 or 16, c h a r a c t e r i z e d i n 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, c h a r a c t e r i z e d i n that each service agent process comprises a function call handler (504A_!) 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, c h a r a c t e r i z e d i n that the function call handler (504A_X) comprises a number of function handling means cooperating with corresponding, separately arranged servers (514 , ... , 517, 519, 520) .

20. System according to claim 19, c h a r a c t e r i z e d i n that the function handling means support customer developed program codes (523) .

21. System according to any one of claims 18-20, c h a r a c t e r i z e d i n 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 (504A. and adapted to a format receivable by the intended application system (version) .

22. System according to any one of the preceding claims, c h a r a c t e r i z e d i n 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.

23. System according to any one of the preceding claims, c h a r a c t e r i z e d i n 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, c h a r a c t e r i z e d i n 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,503A₁-503C₅,504A₁,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, c h a r a c t e r i z e d i n 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, c h a r a c t e r i z e d i n 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, c h a r a c t e r i z e d i n 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, c h a r a c t e r i z e d i n that it comprises the steps of: 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 , c h a r a c t e r i z e d i n 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 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, c h a r a c t e r i z e d i n 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 and independent definition data, 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, c h a r a c t e r i z e d i n 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, c h a r a c t e r i z e d i n 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.