WO2000033154A1

WO2000033154A1 - Method and arrangement relating to message handling in communications networks

Info

Publication number: WO2000033154A1
Application number: PCT/SE1999/002241
Authority: WO
Inventors: Jan Bornstein
Original assignee: Telefonaktiebolaget Lm Ericsson
Priority date: 1998-12-01
Filing date: 1999-12-01
Publication date: 2000-06-08
Also published as: SE9804189D0; AU2015400A; SE521504C2

Abstract

The present invention refers to a messaging arrangement in a communications network including one or more clients (11) and a set of servers (12). A client (11) is arranged to send a message to access at least one server for executing different types of actions whereby said client message initiates a transaction between the servers. The transaction further generates at least one event in at least one server, information on which event is stored at least in said interserver messages.

Description

Title

METHOD AND ARRANGEMENT RELATING TO MESSAGE HANDLING IN

COMMUNICATIONS NETWORKS

TECHNICAL FIELD OF THE INVENTION

The present invention relates to a method and messaging arrangement in a communications network including one or more clients and a set of servers. A client is arranged to send a message to accesses at least one server for executing different types of actions whereby said servers generate inter-server messages.

The invention also refers to a network.

BACKGROUND OF THE INVENTION

In a network including communication apparatuses, such as computer networks or telecommunication networks, usually one or several clients (e.g. workstations, subscribers etc.) are connected to one or several service provider stations (servers, base stations etc.). The client sends messages to one or several service provider stations to request resources or a specific action.

The message usually contains information about the type of the request and a number of parameters. The client request can result in a number of servers to server messages.

Presently, the server which receives the messages is provided with tables including information about all requests in the system and also the resources allocated and their state. The receiving server then sends the request to another server, asking the other server to take an action and then notify the originating server. To carry out this solution, the servers are implemented with sophisticated logic for identifying and synchronising incoming server-to-server notification means with a previously sent request. A resource may be any kind of software or hardware resource, such as procedures or functions controlling specific routines, switching functions etc. belonging to first category, and print services, network facsimile services, CD-ROM racks/Jukeboxes, communication ports/boards/paths etc. belonging to the second category.

US 5,548,723 relates to object-oriented client-server facility (CSF) and networking service facility (NSF) interfaces, which implement communication between application programs residing in client and server nodes of a distributed services network. The CSF interface includes remote procedure call (RPC) objects for invoking and responding to service requests at the nodes, and application programming interface (API) objects for transporting those requests between the nodes. However, the API objects only provide communication transports within a node. Accordingly, the API and RPC objects interact with dynamically-configurable protocol stacks within the NSF interfaces to complete the transport mechanism needed by an application program on the client node when accessing services on a remote server node.

US 5,101,348 concerns a communications network, each network node can maintain its own list of network resources in a topology database. When the state of a resource "owned" by a particular node changes, that node broadcasts a topology database update (TDU) message to adjacent nodes. Each adjacent node updates its own topology database and rebroadcasts the message. To minimize the amount of information that must be included in TDU messages when two nodes are reconnected after an outage, each node assigns flow reduction sequence numbers (FRSNs) to TDU messages and keeps a record of the FRSN for the last TDU message sent to an adjacent node. The node also records, for each resource in its database, the FRSN of the last TDU message including that resource. When two nodes are reconnected, the sending node includes in the TDU message only those resources having a FRSN greater than the FRSN assigned to the last TDU sent to the adjacent node to which the TDU message is directed.

Non of above documents relate to storing event infonnation in inter-server messages which are generated according to the invention. Hence, according to US 5,101,348 databases must be arranged in at each node, which contests the teachings of the present invention. SUMMARY OF THE INVENTION

There is a need for an arrangement in communications networks, which overcomes the above- mentioned problem and introduces a simple way to handle messaging traffic, specially the messaging between servers in the network.

What is needed is an arrangement that allows the servers in the network avoid information storing in tables or databases containing ongoing requests from the clients. Therefore it is also an object of the invention to present an arrangement that allows simple allocation of resources for message handling by placing request messages either in read message queues or processing them.

There is also a need for an arrangement that provides safe message handling without risk for loss of information.

For this reason the transaction according to the preamble further generates at least one event in at least one server, information on which event is stored at least in said inter-server messages.

Preferably, said event is allocation of a resource and messages include a resource request.

Moreover, the information includes context information comprising information about in which server the different resources are located.

In one preferred embodiment the network arrangement further includes a part, preferably a client API, arranged to control the communication between the client and the server. The part includes an updateble database (XSCU Context) for storing information at least about said resource/service and corresponding server. Furthermore, to provide a robust network, it includes error handling based on the "graceful degradation" paradigm, where an error just affects the functionality close to the failure.

Preferably the resource/service is a specified and identified with a Globally Unique IDentifier (GUID). Preferably, said database contains information about all resources used by all clients and also their location. The invention also refers to a communication network, preferably a computer-based network, e.g. for providing distributed and redundant functionality for switching, control and coordination of different communication protocols interfacing external and/or internal networks. The communications network includes at least one set of server units and means for client stations interfacing the server units. The communication network further comprises a messaging arrangement. A client is arranged to send a message to accesses at least one server for executing different types of actions. Each server is arranged to communicate with another server by means of inter-server messages. The client message initiates a transaction between the servers, and said transaction further generates at least one event in at least one server, information on which event is stored at least in said inter-server messages. Preferably, said event include a service and/or resource allocation. The messages include service and/or resource request and the messages contain context information about the request.

Advantageously, each server unit is arranged to pass client requests between each other without saving any information related to the actual request. Each server unit retrieves a message from another server unit and takes appropriate action depending on the message context included in the message itself. An identification of actions and connections, locally and/or distributed in the network, is represented by corresponding Globally Unique Identifiers. The resource modules include at least one of ISDN Resource module, for handling ISDN (Integrated Services Digital Network) protocol, S-Connect Resource module, for handling analogue operator interface (S- connect), DSP Resource module, for handling DSP (Digital Signal Processing) handling for signalling and messaging, and Conference Resource module, for handling conference devices for conference switching. In the most preferred embodiment the network is an Exchange System (20).

In accordance with a method for executing an action required by a client in a communications network including servers managing said actions, the method comprises the steps of: transferring a message to the servers by said client requiring said action, generating transactions including inter-server messages between said servers in respect of events carried out by said servers, arranging at least said inter-server messages with a table comprising information on said transactions and updating the table at least by means of each server receiving the messages, and routing the inter-server message until the required action is executed. Moreover, an inter- server message results in a number different actions: the message will be received and processed by a server, whereby a message originating server will receive a acknowledgement; if a server fails to read a message, then the message queue will generate a timeout, which will be handled by the message sending server; if a receiving message-queue system is corrupt, the message cannot be sent and the sending server will be notified by the message queue service and will proceed with a proper action.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will become more fully apparent from the claims and the description as it proceeds in connection with the drawings, in which:

Fig. 1 is a very schematic block diagram showing the main elements of a network involving an arrangement according to the invention; Fig. 2 illustrates schematically a network embodiment including the invention; Fig. 3 is a more detailed but still schematic illustration of the elements of the network arrangement according to fig. 2; Fig. 4 illustrates the system architecture of the embodiment shown in fig. 2; and Fig. 5 is a schematic view of a connection establishment example.

DETAILED DESCRIPTION OF AN EMBODIMENT

According to a preferred embodiment, shown in fig. 1, in a communication network 10, preferably a multi client 11/multi server 12 environment, a client (station) 11 requiring a specific resource 13 sends a message referring to said specific resource, which preferably is identified with a Globally Unique IDentifier (GUID). Preferably, the request does not refer to any specific server 12 in the network. Consequently, the client does not need to have any special knowledge about the servers in the network. Preferably, the messages are queued in message queue systems 14. The queue systems 14 will be described later. According to the invention, in a network, preferably a message queue based network, a message sent from a client to one or several servers includes a request for some action or service. Preferably, the message includes information on the type of the request and some parameters or a set of data. The client request probably results in a number of server-to-server (inter-server) messages. To avoid implementation of complex message handling in the servers, at least the inter-server messages are arranged to include information on requests, allocated resources/services and server transactions due to the received request. Consequently, the servers do not need to contain any tables on ongoing requests. All current requests are either in a message queue waiting to be processed or in a server where they are being processed. An inter- server message results in a number of different actions:

- the message will be received and processed by a server, whereby the originating server will receive an acknowledgement;

- if a server fails to read a message, then the message queue will generate a timeout, which will be handled by the message sending server; - if a receiving message-queue is corrupt, the message cannot be sent and the sending server will be notified by the message queue service and will proceed in another way.

Accordingly, upon receipt of a message, all information required to process the request is stored in the message together with the request. Thus, no information must be stored in an external table or database.

In the following, the invention will be described in more detail in connection with a non- limiting embodiment given merely to facilitate the better understanding of the invention.

The embodiment, schematically shown in fig. 2, relates to an Exchange System (XS) 20, which is a computer based communications platform providing distributed and redundant functionality for switching, control and coordination of different communication protocols interfacing external (or internal) networks 21. The external et works can for example be any of PLMN (Private Land Mobile Network), PSDN (Public Switched Data Network), PSTN(Public Switched Telephone Network) etc. The XS architecture is substantially a decentralized distributed system and can be based on a varying number of XS servers 12 connected to each other, for example via an IP network such as an ethernet LAN (Local Area Network) 22.

The XS severs 12 may also be connected to each other via a network 23, for example through MCI bus, to achieve switching between the servers.

The XS 20 can be configured using one XS server with a varying number of clients 11 , or as a distributed multi-server system, that provides a varying number of clients, to be connected to a varying number of XS servers.

In the system, the Hardware (HW) interfaces are handled as resources, and can be encapsulated under a generic resource interface XS Resource Manager within a XS server 12. Preferably, different, e.g. protocol specific, resource modules are encapsulated and handled as subsystems under the resource interface. The XS is therefore extendable to handle new types of resources, e.g. communication protocols and networks in future versions, e.g. IP -telephony and different radio system protocols.

Mainly, the XS has the following functions: - Switching, which covers the generic, protocol independent switching.

- Call Control, which covers protocol independent call control functionality.

- Signalling, which covers signal independent tone sending/receiving.

- Messaging, which covers message independent message handling, such as playing/recording.

To obtain these functions, there are some additional functional areas:

- Server connection, which handles the connection between the CL (clients) and XS.

- Resource handling, which handles resource allocation, e.g. conference allocation.

- Status notification, which handles asynchronous XS and external network status information to the clients.

- System management, which handles XS configuration, monitoring, control etc. The XS is based on implementation of a number of resource modules, such as:

- ISDN Resource module, which handles the ISDN (Integrated Services Digital Network) protocol. - S-Connect Resource module, which handles the analogue operator interface (S- connect).

- DSP Resource module, which handles the DSP (Digital Signal Processing) handling for signalling and messaging.

- Conference Resource module, which handles the conference devices for conference switching.

A DSP is a resource that can be allocated/deallocated and used for tone and message sending/receiving. A conference resource provides functionality to set up a set of participants represented as seats into a forum, where the participants are connected. The connection to a conference seat can be a simplex or a duplex connection represented.

The XS Connection Unit (XSCU) API 24 is the name of the XS service access-point. Preferably, it is implemented as a distributed, asynchronous, telegram-based client API.

The XSCU API includes among others the XS server configuration and allows multi-node switching, load-sharing and error handling, for example based on the "graceful degradation" paradigm, where an error just affects the functionality close to the failure.

The Client Logic (CL) Interface to the XS is the XSCU API, which is included in the client application. The XSCU handles the communication between the client and the XS and includes functionality to distribute client requests to the XS servers, by managing client context information.

Fig. 3 shows the components involved in the system. The XS server 12 mainly includes a XS Request Manager Unit (XSRMU) 30, XS Switch Manager (XSSM) 31 , XS Resource Manager XSRM 32, XS Main Manager (XSMM) 33 and resource connection 34. In the XS server 12, the client 11 requests are received by the XSRMU 30, that handles the server communication part. Depending on the type of the request, the XSRMU 30 will distribute the requests to the XSSM 31 or the XSRM 32 via a XSMM 33 synchronized main queue. The resource connection 34 connects resources, such as ISDN Resource, DSP Resource, S-connect Resource, Conference Resources etc.

The XSRM 32 functional block provides functionality to manage, synchronise and co-ordinate HW resources. It provides a generic high level interface to the HW resources. Preferably, it abstracts the handling and configuration of HW boards, which interfaces the communications networks. Asynchronous events from the HW interfaces are passed by to the XSRMU 30 via the XSMM 33 synchronized main queue. It has for example mechanisms for allocating, deallocating and translation of switching information related to HW resources. XSRM 32 also provides a high level interface to the HW and is a single service access point to the external communications network interfaces. The XSRM 32 handles the physical switching and the coordination of the HW.

The XSSM 31 handles the resources in a logical level. It manages the relations between the resources and uses the XSRM 32 to access them. It also uses the XSRMU 30 to pass requests to other XS servers in the system, regarding handling of resources outside a local machine. The single node switching is solved only by using the local XSRM.

XSMM 33 is the main functional block in the XS. It contains the main application and it initiates and synchronises other units in the system, for example by managing a multi thread- based architecture. It provides functionality to send and receive messages between the different functional blocks, e.g. by controlling a thread secure synchronised queue, and invokes each functional block's Request in the order the queue items are received.

The main functions of XSSM 31 are to:

• make connection and disconnections, • allocate, release and reset specific resources, and

• remove connections as a result of certain events, such as external hangup. Preferably, the XSSM uses resource tables for executing its tasks. Requests from the XSRMU 30 are sent to XSSM through a queue managed by the XSMM. In order to perform a task for example making a connection, the XSSM 31 and the XSRM work very intimately. The tasks are divided so that the XSSM 31 handles the logical part of the switching, which means the part where information on resources, e.g. a Bus table, Connection Table and Conference Table must be updated in order to provide correct information about the actual physical connections. In other word, XSSM 31 logically connects two connection points, which represents a access point to a call, a conference, a DSP or a Logical Address, to each other (through a connection table, preferably arranged in XSSM 31) and sends commands to XSRM 32 in order to accomplish the physical connection.

The distributed switching uses the MCI bus for transferring media streams between the XS servers.

The XSRMU 32 function block provides functionality to handle the communication in the distributed environment. The communication paths are:

• XSCU (Client) to XS server communication;

• XS server to XSCU (Client) communication; and • XS server to XS server communication.

The multi-node switching is provided in a three-stage process:

- the first stage includes allocation of a MCI bus resource and sending a XS Server Message (XSMSG) to the other server requesting an execution of a service and all information needed by the other server to fulfill its part of the switching. The

XSMSG is the XS server to server interface message which contains request and notification data from one XS server to another.

- The second stage is when another server receives a XSMSG. Upon reception it will connect the input from the MCI -bus to the output on the relevant connection point via the internal telephony bus. When this is completed, it will send a

XSMSG containing a service execution message and all information needed by the originating server to fulfill the second part of the switching. - The third stage is when the originating server receives the Service Execution

Message. It will then connect the input connection point to the output on the MCI bus via the internal telephony bus. If this would fail, it will send a rollback request to the other server asking it to remove the previous connection.

XS further consists of a set of message queues and queue managers. XSCU is the part that exposes the XS API to the clients and communicates with the XS Servers. Each CL 35 communicates with the XS through the XSCU interface using the XS API 24.

Essentially, each instance of XSCU has information substantially about all the resources used by all CL and also their location (connection to a certain XS Server(s)). XSCU receives information from each XS Server when a resource is instantiated or deleted. Based on said information, the requests can be routed to the XS Server best suited to handle a request. The information is also useful when a XS Server is out of order or not reachable. In the following, this information is called the XSCU System Context (XSSC).

Requests that create new resources (for example Make Call, Allocate Conference or Allocate DSP) are arranged in an arbitrary server queue to distribute the workload over the XS Servers. If these request contains a "pointer", the request will be transferred to a server pointed out by the pointer. The requests that relate to the entire XS (e.g. commands such as Logout, Reset, Shutdown) are sent to all servers.

The XS Server sends notifications to the XSCU entity that sent the request. If a resource is created or deleted, a Resource Info Notification will be sent to all other XSCUs, to update their XSSC. Some notifications can also be sent to the CLs.

If the request is an operation on two resources residing in different locations (apparatuses), the XSCU will send the request to one of them, and fill in the logical address of the other resource from its XSSC (if it is represented by a GUID and not a logical address already). The logical address identifies a low-level connection point within the XS server, which allows one input connection and several output connections.

Preferably, each XSCU entity includes information about essentially all the resources and to which XS Server they are associated to. The information includes all calls, connections, conferences, DSPs created by any CL and their identity (GUID), which implicitly points out in which location they reside. Each XS CU has interfaces towards its client and towards the XS Servers. Some messages travel transparently through the XSCU and some are XS Server/XSCU internal messages not reaching CLs.

Client requests for a resource in the form of a XS Message are sent from CL to XSCU.

Preferably, the XS Messages do not contain any information about the server the message is supposed to be sent to. This is actually handled by the API. When the client sends a message, the XSCU will look up any resource reference in the message in XSSC to determine in which server the resources are located. If the request involves resources in different servers, information will be added in the XS Message, helping the receiving server to handle the request. The Messages to XSCU received from XS Server are analysed and the XSSC is updated accordingly.

Advantageously, the XSSC contains tables for all resources and methods for adding, deleting and finding resources.

The XSCU provides functions to handle the interface to the XS server system through a distributed API. This functionality is based on handling of instances of messages, XS Message, which is, as described above, the XSCU API message containing request data from CL to XS or notification data from XS to CL. The XS Message contains substantially all APIs.

This handling includes instantiation, sending and receiving XS Message instances. The XSCU can be the complete API and the single service access point to the XS. The general concept of the API is an asynchronous telegram based solution. The physical HW configuration of the server is hidden from the client. The Microsoft ® MessageQueue system (MSMQ) is for example used for network communication. Obviously, other systems for network communication can be used.

The XSCU API structure is divided into several logical parts, for example:

- Server Connection: handles system related functionality, e.g. the connection between CL and the XS Server system;

Switching: handles connections between XS connection points within the XS Servers;

- Resource: handles allocation and deallocation of specified resources within the XS Servers; - Call Control: manages call control functions within the XS Servers.

- Status: messages sent asynchronously from the XS to the CLs informing the affected CL about status changes.

- Signalling: message sending and signal retrieving using a DSP; and

- Messaging: for example playing and recording messages using a DSP. Messages can be read, deleted and also be shared between concurrent CLs.

The XS also includes an interface 36 to external networks, e.g. PSTN, which for example uses the ISDN protocol. The ISDN interface is implemented in the ISDN resource module within the XS server. The system may also include interfaces to telephony operators based on an analogue telephone interface. This interface is also called S-Connect, and it is implemented in the S- Connect resource module within the XS server.

The XS provides basic client/server connection via login/logout, where every client has there own specified ID (CLID).

The client server communications, which is based on the transaction of XS Messages, is divided into requests and notification, where the requests represent the messages from the CL to the XS and the notifications represent the messages from the XS to the CLs.

To obtain server connection the CL must make an instance of the XSCU API, which handles the asynchronous communication between the client and the XS server locally or over a network, e.g. the LAN.

A login request will result in retrieving notifications for all incoming calls retrieved by the XS, and it will enable the client to send requests to XS. If the login fails, a negative status notification message will be received.

Due to the fact that the XS is able to handle the event of one XS Server that is out of function, which will result in loss of resources and possibly loss of unserviced requests, the XSCU is able to inform the clients about which resources that were lost.

The XS provides functionality to allocate and deallocate defined XS resources: for example Conference and DSP.

To minimize network load, the "pointer" mechanism is implemented, which means that the resource can be allocated in the same XS Server and the same interface board as the XS

Connection Point which it will be connected to, if the optional XS Connection Point is set in a resource allocation message.

A conference resource can be allocated with a guaranteed (fixed or varying) number of participants. A conference participant, is represented by a XS Connection Point, which can be a resource connected with a simplex or duplex connection.

A DSP can only be either a receiver or a transmitter at the same time. A connection to a DSP can be duplex, but you can only use the DSP in one direction at the time.

Additionally, the XS provides functionality to handle the events of one or many system components going down. The basis for this functionality is a completely distributed and decentralised architecture. The system is able to handle the event of one XS Server that goes down or is not reachable. This situation will result in loss of resources and possibly loss of unserviced requests. The loss will be limited to the resources directly connected to the failing node. XS informs the clients about which resources that were lost. The distributed system architecture is shown closer in fig. 4, in which all node elements are connected to each other in a decentralised structure. In the drawing, same parts are denoted with same reference signs as in foregoing drawings. AUX refers to parts which can be implemented depending on the different applications.

To achieve this totally decentralised structure and architecture the "fire and forget" paradigm combined with a "context" paradigm is applied in the design of the system. However, it is obvious that both paradigms can be implemented separately.

The paradigms and the system architecture are the messaging events between the XSCU 24 and the XS servers 12, and internally between the XS servers 12.

The messaging between XSCU 24 and the XS servers 12 are solved by that the XSCU has context information that includes information about in which XS server the different resources are located. This mechanism eases the distribution of client requests.

The messaging between the XS servers is based on the "Fire & Forget" paradigm, which means that the message contains context information about the request. This mechanism allows the XS servers to pass client requests between each other without saving any information related to the actual request. The XS server retrieves a message from another XS server and takes appropriate action depending on this message context included in the message itself.

An identification of resources and connections, locally and distributed, in the XS environment is required. Therefore every resource, e.g. a call, conference device or a DSP, and every connection, which represents the relation between the resources, are represented by GUID.

In an embodiment, XSSM 30 also handles conference allocation. If the XS server does not have any free conference resources available, it will pass the request further to the next XS server in the system. The "next" server is selected by the one that has not read the message from its queue. This process will end when any XS server takes care of the request or if there is no XS server left to send to (that has not read the message from its queue). If there are no conference resources available in the entire system, the last XS server will send a "failed" notification to the requesting CL.

Generally, the connection is made through the following process:

- CL makes a XSConnect request to the XSCU, which distributes it to the proper XS server.

- The XS server makes a local allocation of a resource, and transfer the request including an INPUT address and resource address to the next affected XS server. - That XS server makes the local switching and transfers the request in a notification, including an OUTPUT address, back to the first XS server.

- The first XS server now makes the local switching and sends a notification to the CL via XSCU.

Back to fig. 1, a Message Queue Handler provides functionality to send and receive messages to/from message queues and to locate, create and destroy message queues. A Message Queue Handler has its own queue where all incoming messages are read. All outgoing messages are sent to other queues, associated with other Message Queue Handlers. A Message Queue Handler can be used by a client or a server in the XS. The client users are then the XSCUs and server users are XS Request Managers.

The queues 14 are divided into two categories, server queues and client queues, thus providing a straightforward way to identify if the queues are associated with a server or with a client.

Following non limiting examples, read in connection with above-described drawings and fig.5, describes resource allocations and connection steps, and are given to simplify the better understanding of the invention:

In the first example, the CL1 requests to make a connection between two points A and B in the XS system. The connection can be between two subscribers (A, B) or between a subscriber and a conference resource or any other resource. Said two points can be in the same server or in two different servers (which is the present case).

If they are in the same server, the XSSM connects them using commands in the XSRM and, if they are located in different servers the inter-server connection is used. XSSM creates a new Connection, fills it with detailed information about the two points and stores it in a Connection Table in the XSSM and sends a notification to CL1.

If the points are in different servers, XSSM in the receiving server will allocate a MCI bus resource, create a XSMSG for Server Executing Service Request, supply it with relevant information and send it to the other server (Server 2) involved in the connection asking it to make its half of the connection.

Upon reception of the message, the XSSM in the other server will for example allocate an internal board to board bus resource, make a connection from the Internal bus to its point using XSRM, make a connection from the previously allocated MCI bus to the Internal bus using XSRM, allocate MCI bus, e.g. for a duplex connection, if requested, make the connection, create one (or two if duplex) new Connection, supply it with detailed information about the two end points, store it in the Connection Table, fill the XSSMSG with new information and finally sends it back to the originating server, i.e. Server 1.

Upon reception of the notification message with status Done, the XSSM will make the other half of the connection and send a notification to CL1 If the notification message has status Fail, a notification will be sent to CL with fail status.

If this server fails with its half of the connection, a rollback request will be sent to the other server, to remove its half of the connection.

When disconnecting, if the points are in the same server XSSM disconnects the connection using XSRM, releases any internal resources used, removes the Connection from the Connection Table and sends a notification to the client. If they are in different servers, XSSM will create a XSMSG, fill it with relevant information and send it to the other server involved in the connection asking it to disconnect its half of the connection. Upon reception of the request, the XSSM in the other server will remove its half of the connection, release Internal and MCI resources, remove the Connection from the Connection Table and fill the XSMSG with new information and set the type to notification message and finally send the server message back to the originating server.

Upon reception of the notification message with status Done, the XSSM will disconnect the other half of the connection and send a notification to CL. If the notification message has status Fail, a notification will be sent to CL with fail status.

If this server would fail with its half of the connection, no rollback request will be sent to the other server to restore its half of the connection.

In the following example a conference connection is described.

To create a conference, CL must first of all allocate a conference resource. By allocating conference it is meant that the XS server assures the client that a conference resource is reserved which can handle the a number of participants. The type of participation can be simplex or duplex.

CL gives a unique identifier together with information about the max number of participants in its request.

When XSSM receives an allocate-conference request, it will look for a free conference in its conference table. If a free conference is found, it will be allocated and an Allocate Conference Notification is sent to CL.

If the XSSM cannot find any free conferences in the server it will create a XSMSG of type Service Request, fill it with relevant information and send it to the next servers asking it to try to allocate a conference. When the XSSM fails to send the XSMSG to other servers it means that either the server is alone in the system or that all other servers have already received this message and failed to execute the request. In this case an Allocate Conference Notification will be sent to CL together with a fail status, informing the client that there were no free conferences available.

Upon reception of the Service Request the XSSM tries to allocate a conference. If the operation is successful then a notification is sent to CL.

If CL requests to add a connection point to a conference, the connection point can be represented by a logical address or in the cases where a resource is involved as a GUID. CL may also give a new connection Identity for the connection between the subscriber and conference. The client request will always be sent to the server where the conference is allocated.

XSSM examines the received XSMSG in order to find out if the connection point that wants to be connected to the conference exists in another server. If not then, the XSSM tries to find an empty seat in the conference. If an empty seat is found, the subscriber will be connected to that seat. If the connection was successful, a Notification is sent to CL.

If the connection point is in another server the XSSM will create a XSMSG of type Service Request, fill it with relevant information and send it to the other server asking it to connect the subscriber to MCI bus.

To release a conference, CL makes a request to release an allocated conference. The XS message, which sent by the CL client to XS, contains information about the client's identity and the conference identity. XSSM checks that the conference has no participants connected to it. If so, the conference is released (a status-flag of the conference is changed to free).

Obviously, the invention is not limited to the above-described network arrangement but any kind of networks, such as computer networks, (cellular) telecommunication networks etc., can use the benefits of the invention. The invention is not limited to the shown embodiment but can be varied in a number of ways without departing from the scope of the appended claims and the arrangement and the method can be implemented in various ways depending on application, functional units, needs and requirements etc.

Claims

1. A messaging arrangement in a communications network including one or more clients (11) and a set of servers (12), whereby a client (11) is arranged to send a message to accesses at least one server for executing different types of actions whereby said client message initiates a transaction between the servers, characterised in, that said transaction further generates at least one event in at least one server, information on which event is stored at least in said inter-server messages.

2. An arrangement according to claim 1, characterised in, that said event is allocation of a resource (13) or service.

3. An arrangement according to claim 2, characterised in, that said messages include a resource request.

4. An arrangement according to claim 2, characterised in, that said information includes context information comprising information about in which server the different resources are located.

5. An arrangement according to any of preceding claims, characterised in, that said network further includes a unit (XSCU) (24), preferably a client API, arranged to control the communication between the client and the server (12), said unit (24) including an updateble database (XSCU Context) for storing information at least about said resource/service and corresponding server (12).

6. An arrangement according to claim 5, characterised in, that said network includes error handling based on the "graceful degradation" paradigm, where an error just affects the functionality close to the failure.

7. An arrangement according to claim 2, characterised in, that said resource/service is a specified and identified with a Globally Unique IDentifier (GUID).

8. An arrangement according to any of claims 2-7, characterised in, that said database contains information about all resources used by all clients and also their location.

9. A communication network, preferably a computer-based network, e.g. for providing distributed and redundant functionality for switching, control and coordination of different communication protocols interfacing external and/or internal networks (21), said communication network including at least one set of server units (12) and means for client stations (11) interfacing the server units (12), characterised in, that the communication network further comprises an messaging arrangement (22) whereby a client (11) is arranged to send a message to accesses at least one server for executing different types of actions, that each server is arranged to communicate with another server by means of inter-server messages, that said client message initiates a transaction between the servers, and that said transaction further generates at least one event in at least one server, information on which event is stored at least in said inter-server messages.

10. A network according to claim 9, characterised in, that said event include a service and/or resource allocation.

11. A network according to claim 10, characterised in, that said messages include service and/or resource request and that the messages contain context information about the request.

12. A network according to any of claims 9-11, characterised in, that each server unit is arranged to pass client requests between each other without saving any information related to the actual request.

13. A network according to claim 12, characterised in, that each server unit (12) retrieves a message from another server unit and takes appropriate action depending on the message context included in the message itself.

14. A network according to claim 9, characterised in, that an identification of actions and connections, locally and/or distributed in the network, is represented by corresponding Globally Unique IDentifiers.

15. A network according to any of claims 9-14, characterised in, that network architecture is substantially a decentralized distributed system.

16. A network according to claim 15, characterised in, that the architecture is based on a varying number of server units (12) connected to each other via a Local Area Network (LAN) (22), for example via an IP network such as an ethernet LAN.

17. A network according to claim 9, characterised in, that server units (12) are also connected to each other via a network (23) to achieve switching between the server units.

18. A network according to any of claims 9-17, characterised in, that it is configured using one server unit with a varying number of clients (11).

19. A network according to any of claims 9-17, characterised in, that it is configured as a distributed multi-server system providing a varying number of clients, to be connected to a varying number of server units.

20. A network according to claim 12, characterised in, that Hardware (HW) interfaces are handled as resources, which are encapsulated under a generic resource interface Manager within a server unit (12)

21. A network according to claim 20, characterised in, that different resource modules are encapsulated and handled as subsystems under the resource interface.

22. A network according to claim 21, characterised in, that said resource modules include at least one of ISDN Resource module, for handling ISDN (Integrated Services Digital Network) protocol, S-Connect Resource module, for handling analogue operator interface (S-connect), DSP Resource module, for handling DSP (Digital Signal Processing) handling for signalling and messaging, and Conference Resource module, for handling conference devices for conference switching.

23. A network according to any of claims 9-22, characterised in, that the network is an Exchange System (20).

24. A network according to any of claims 9-23, characterised in, that the it further includes a unit (XSCU) (24), preferable a client API, arranged for controlling communication between the client and the server (12), said unit (24) including an updateble database (XSCU Context) for storing information at least about said resource/service and corresponding server (12).

25. A method for executing an action required by a client in a communications network including servers managing said actions, characterised in, that the method comprises the steps of:

- transferring a message to the servers by said client requiring said action,

- generating transactions including inter-server messages between said servers in respect of events carried out by said servers,

- arranging at least said inter-server messages with a table comprising information on said transactions and updating the table at least by means of each server receiving the messages, and

- routing the inter-server message until the required action is executed.

26. A method according to claim 25, characterised in, that an inter-server message results in a number different actions:

- the message will be received and processed by a server, whereby a message originating server will receive a acknowledgement;

- if a server fails to read a message, then the message queue will generate a timeout, which will be handled by the message sending server;

- if a receiving message-queue system is corrupt, the message cannot be sent and the sending server will be notified by the message queue service and will proceed with a proper action.