IES990626A2 - A telecommunications controller messaging system - Google Patents

Abstract

A telecommunication messaging system (1) is connected between a client application (2) and a server application (3). It creates a proxy object (10) on-the-fly when the client (2) requests a messaging link with a server application. The proxy operates independently of the client after being requested to establish a messaging link. <Figure 1>

Description

The invention relates to messaging in a telecommunications controller such as ATM 5 routing and switching device.

The requirements of telecommunications systems are rapidly changing both in terms of transaction volumes and in terms of the services and. functionality provided. It is therefore very important that a controller has a flexible message transfer capability which can cope with the changing circumstances. It is also important that message transfer be very fast because real-time performance is required in most situations.

Therefore, the invention is directed towards providing a messaging system to address these requirements.

According to the invention, there is provided a messaging system for communication between clients and servers in a telecommunications system, the messaging system comprising means for creating a proxy to handle a communication link and a messaging layer for transfer of messages.

In one embodiment, the proxy comprises means for operating independently of a client after being requested to establish a messaging link.

In another embodiment, the proxy comprises means for acting upon a client call referring 25 to a server object and an operation on that object. Φ&βϊφίΒα*.

INT CL OPEN TO PUBLIC INSPECTION UNDER SECTION 23 ANO RULE 23 JNL NO<^ OF24 VirSlU»« 8νΖ«ββββββο»»·ββ·'Ββ€βο^ίί*· β-aeeeee· Ί IE990626 [η another embodiment, the messaging system further comprises means for deleting the proxy when a return signal is received from the server to complete a thread.

Preferably, the messaging system further comprises means for creating the proxy in a 5 bind operation and for releasing it in a release operation which may be modified independently. Ideally, the system comprises means for creating the proxy in real-time, “on the fly”.

In one embodiment, the proxy comprises means for performing synchronous, deferred [ synchronous, and one-way messaging calls.

In another embodiment, the system further comprises an object adapter having means for interpreting client requests and transferring them to server objects.

Preferably, the proxy comprises means for encoding a request as a server object method invocation.

In one embodimenq the system further comprises an exception object having means for providing exception information to clients.

L...

The invention will be more clearly understood from the following description of some embodiments thereof given by way of example only with reference to the following drawings, in which:Fig. 1 is a high level schematic diagram of a messaging system of the invention; Fig. 2 is a more detailed diagram showing messaging components; IE990626 -3 Figs. 3 to 5 arc diagrams showing the architecture in more detail: and Figs. 6 to 18 inclusive are message flow diagrams of the system.

Referring to the drawings, there is shown a messaging system 1 connected between a client application 2 and a server application 3. The messaging system comprises means for creating a proxy object 10 on-the-fly when the client 2 requests a messaging link with a server application. An exception object 11 monitors messaging and is queried by the proxy afterwards. The proxy object has a meta-level architecture, which communicates through a messaging layer (ORB) 13 with the meta-level architecture of a server object 15. The server object 15 in tum communicates with the server application 3.

In brief, a call by a client refers to a server object and an operation on that object rather than the server application itself. The client is typically an embedded software module and the server is typically a resource which carries out an operation such as a switching operation. This allows flexibility in how the service is implemented because server objects can be easily switched for others which support the operation. Additional server objects can be easily added. The system de-couples the application level from the low20 level messaging functionality (MHS). This allows seamless replacement of the MHS, if required.

There are two basic message types as follows:25 (a) A request message which encodes a method invocation on a server object together with the required parameters, and (b) A reply message which encodes a reply.

IE990626 -4 In more derail, referring to Fig. 2 the messaging layer 13 comprises a messaging engine 20 and an object adapter 23. The messaging engine 20 is connected to the low-Ievei functionality, namely a MHS engine 21 and hardware 22. Thus the core of the messaging system of the invention comprises the proxy and server objects, the messaging engine 22, and the object adapter 23. As shown in Fig. 3, the proxy object 12 comprises operation, interface, and generic components 30.(31, and 32 at the meta level. The server 14 comprises void-related components 40 and operation and interface components 41 to 44 at the meta level. Meta level architecture interfaces with the proxy, the server and the ORB are shown in Fig. 5.

The messaging system is now described in more detail by reference to Figs. 6 to 18 which show message transfer in different scenarios. In the examples, functions “foo”, “longfoo”, and “shortfoo” are implemented on the server application.

Fig. 6 shows a synchronous call for the method foo, which is a synchronous operation. The proxy method does not return until the server method completes and returns a result to the proxy. The sequence is as follows.

- The client instructs the system 1 to create a proxy X.

- The client calls the function foo on the proxy X.

- The proxy X packages the request as a message and transmits it through to the object adapter 23 which interprets the message and calls function foo on the server X using the server object.

- The return value of foo is passed back to the object adapter which sends the result to the proxy X as a message.

IE990626 - 5 - The proxy X interprets the message and returns the result as the return value from function foo.

A deferred synchronous call may also be made. For example the client may invoke the method longfoo on server X without waiting for the remote sever to execute and return a reply. This allows the client to perform other tasks in the interim, checking periodically in a non-waiting mode for a reply.

As shown in Fig. 7, the client creates a ProxyOperationOn object, specifying that it is on the operation longfoo. The client calls the method sendDeferred, passing it the required parameters, if any. This method packages the request as a message and transmits it throug to the object adapter 23, stores the handle internally and returns to the client. The client calls poIlResponse on the ProxyOperationOn object. This in tum calls isRepyAvailable on the messaging engine 20, but since no reply is available yet, this returns false. The object adapter 23 interprets the message and calls the function longfoo on the server X.

The result of longfoo is passed back to the object adapter 23 which sends the result to the proxy X via a message. The client calls poIlResponse on the ProxyOperationOn object, this time returning true. The response is then retrieved and interpreted by the client.

One way requests are also handled by the system l.The method shortfoo is a one way operation. This method is called on the proxy X as shown in Fig. 8. The proxy X packages the request as before and transmits it through to the object adapter 23. The function shortfoo on the proxy X returns immediately, the object adapter 23 interprets the message and calls the function shortfoo on the server X. The object adapter does not send a reply as it knows that the method is one-way.

Fig. 9 shows the situation where a message is not sent from the message layer. In this case the proxy method clears the proxy’s exception object 11. After attempting to send the message failure Is encountered, upon which the failure is passed back to the proxy. The proxy interprets this as SendFail and set the exception object 11. The proxy IE990626 ·6· method returns a reply, and the client checks the proxy's exception object 11 and detects the exception, and handles it in the appropriate manner.

The system also handles situations where a message is sent but not received, as shown in 5 Fig. 10. In this case, after the operation executes and returns true, the message is never received at the destination. The proxy awaits a response and times out. This is interpreted as a time-out and the exception object is set. This allows the client to detect the exception and handle it as appropriate.

F’g' 1 illustrates the situation in which a message is sent and received, but the client timesout while waiting, Such a scenario may arise if the duration of a remote operation is unpredictabie, or if the remote server is busy. Clearly, the deferred synchronous mechanism should be used if it is anticipated that a timeout may arise. As shown in Fig. 11, while the object adapter calls Iongfoo on server X the proxy has executed a getReplyMsg to retrieve the reply from the server but times out waiting for a reply. The proxy sets the exception object with a timeout and the method returns. The client checks the proxy’s exception object 11, detects‘the exception, and handles it. Later, Iongfoo has completed and returns a reply indicating successful completion, but the message is discarded by the messaging layer.

Referring now to Fig.· 12, the situation is shown where the target operation is not recognised. In this case, the object adapter fails to interpret the message and a reply indicating this is sent to the proxy. The proxy receives the Replymessage from the messaging layer, retrieves the exception information and sets the proxy’s exception object. This allows the client to handle it Fig. 13 shows the sequence if the server operation fails. In this example the method foo is called. When the failure occurs, the foo method retrieves the UserException object and sets an error sratus., causing the object adapter to in tum send a message indicating a user IE990626 -7tevel failure. The proxy in turn sets the exception object !!. again allowing the client to handle the failure.

As described above, the messaging system interacts between an application level and a message delivery layer. The following examples illustrate its operation with a TDM/ATM converter. Fig. 14 shows a situation where a client determines a card state. The client calls getState on a card proxy. The system operates as described above until the getState method is invoked on the server object supporting the IBC interface. This method calls a C function which returns the IBC card state to the object adapter. This is packaged as a method and sent back to the IBC proxy object, which interprets the message and returns the card state to the client.

Fig. 15 shows the sequence to determine the line status. In this case, a DS1 proxy is used and the object adapter locates the DS1 server object and calls its getLineStatus method. The DS1 proxy subsequently receives the reply. Fig. 16 illustrates the situation where an alarm notification of loss of signal on DS1 is transmitted. This is a one-way operation. The EPC software detects a loss of signal on the DS1 line, and retrieves the controller DS1 proxy and calls the commsAlarmOccured method on the proxy, passing it theport identifier. After its operation, the proxy returns without a reply. The commsAlarmOcured method is invoked on the Controller DS1 server.

The deferred synchronous method may be used for a software download, as shown in Fig. 17. The client creates a ProxyOperationOn object, specifying that it is on the operaton startDownload. The client calls the method sendDeferred, passing it the required parameters. After the request is packaged as a message, the message handle is stored by the ProxyOperationOn object. The exception object is cleared, and the message is used to call startDownload on the software download Impl. The controller calls the pollResponse on the Proxy OperationOn object and this in tum calls isReplyAvailable on the messaging layer. As no reply is available, this returns false. On the target card, the software download task has completed and the result is returned to the object adapter IE990626 - 8 which sends a reply message back to the controller containing the result. The controller again calls poIlResponse in the ProxyOpeadonOn object, this time returning true. The controller then calls getResponse. This gets the returned message, checks for and error code in the reply, exracts the result and returns it to the controller. The controller checks the exception object to see if an exception occurred, but finds it clear, indicating that the result is valid.

Finally, referring to Fig. 18 intialisation of a new card is illustrated. An initialise method on the server object is called and it is passed a string through which it can identify itself to the object adapter. The card software processes the generic method initialise(namelD) on the server object. The server object stores the namelD and calls the registerlnterface method on the object adapter, and passes itself to it. This makes the object adapter aware of its presence and allows requests to be passed to it The object adapter indicates whether or not registration was successful.

The invention is not limited to the embodiments described, but may be varied in construction and detail.

Claims (5)

Claims

1. A messaging system for communications between clients and servers in a 5 telecommunications system, the messaging system comprising means for creating a proxy to handle a communication link and a messaging layer for transfer of messages. I

2. A messaging systems as claimed in claim 1, wherein the proxy comprises 10 means for operating independently of a client after being requested to establish a messaging link, and wherein the proxy comprises means for actins upon a client call referring to a server object an operation on that object.

3. A messaging system as claimed in claims 1 or 2, further comprising means for 15 deleting the proxy when a return signal is received from die server to complete a thread, and wherein the system further comprises means for creating the proxy in a hind operation and for releasing it in a release operation which may be modified independently. 20

4. A messaging system as claimed in any preceding claim, comprising means for creating the proxy in real time, and wherein the proxy comprises means for performing synchronous, defened synchronous, and one-way messaging calls, and wherein the system further comprises an object adapter having means for interpreting client requests and transferring them to server objects, and IE990626 -10wherein the proxy comprises means for encoding a request as a server object method invocation, and wherein the system further comprises an exception object having means for providing exception information to clients.

5. 5. A messaging system substantially as described with reference to the drawings.