WO2001022218A1

WO2001022218A1 - A method and a system relating to an application programming interface

Info

Publication number: WO2001022218A1
Application number: PCT/SE2000/001796
Authority: WO
Inventors: Fredrik Axelsson; Magnus HALLENSTÅL; Martin Hänström; Jari Vikberg
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 1999-09-21
Filing date: 2000-09-15
Publication date: 2001-03-29
Also published as: AU7694300A; SE9903394D0; SE9903394L

Abstract

In a method and a system an object oriented and/or transaction based application programming interface to an application programmer/application program in an original non-object oriented computer system is provided. The application programmer/application program is carrying out transactions in the original computer system via an emulated object oriented interface. The method and system involves the steps of creating resource objects corresponding to the original system, and letting the resource objects only live during the time when a transaction is ongoing. Thus, by emulating an object oriented interface, the application programming interface will become much more user friendly.

Description

A METHOD AND A SYSTEM RELATING TO AN APPLICATION PROGRAMMING

INTERFACE

TECHNICAL FIELD

The present invention relates to a method and a device for providing a user-friendly application programming interface

(API) in a computer system.

BACKGROUND OF THE INVENTION AND PRIOR ART

A computer system, which has resources that can be modelled as objects with its own data and operations is usually conceived as quite easy to understand for humans . This is due to that the objects in the system simulates the real-world objects. Examples of such objects in the field of telecommunications are a subscriber number and a line interface device in a telephone exchange. A system with the properties described above is usually termed an object oriented system.

Furthermore, in object oriented computer systems arranged to interact with databases so called transactions are common in the use of the database. A transaction can be described as a unit of work to be carried out within the computer system. Thus, a user starts a transaction, e.g. reads data from the system comprising a database and orders setting of data. There are usually two ways that the user can end such a transaction. Either the user orders to commit the transaction or to rollback the transaction.

To commit the transaction means that the ordered changes are made durable. To rollback the transaction means that none of the ordered changes are executed. In other words, if the transaction is rolled back, the data in the system is put back to the exact state as it was before the transaction was initiated.

A transaction has the following properties .

- It is atomic, i.e. either the entire transaction is carried out or no part of it.

- It is consistency preserving, i.e. the transaction changes the database from one consistent state into another consistent state . - It is isolated, i.e. the transaction does not show the changed data to other transactions until the transaction has been committed.

- It is durable, i.e. when a transaction has been committed, the changed data shall survive later possible database errors.

However, even though object oriented computer systems using transactions are perceived as being much more user friendly, many computer systems, in particular old computer systems, are not object oriented. In such cases it is sometimes desired to make the application programming interface more user friendly. In particular, the application programming interface of such a non-object oriented computer system is desired to be as user friendly as an object oriented application programming interface. In other words, in the case when a human is to interact with a computer system, either directly or indirectly when programming a computer system, which in turn is to interact with a non-object oriented computer system, the computer system should be an object oriented system, or at least behave like such a system in order to be user-friendly.

However, there is sometimes a problem of how to generate an object oriented and transaction based application programming interface in a computer system. One way to add an object oriented and transaction based application programming interface to a system is to add a database to the system. In such a system all data from the original system is extracted and placed in the database. Thus, the same data are found in the database and in the original system.

The application programmer/application program, in the following termed the user, then reads and sets the data in the new database . The database and the original system then cooperate in order to keep the data consistent.

The problem with such a solution using an additional database is how to keep the database consistent with the original system. If the data is found to be inconsistent for some reason then it can be hard to know what data of the two that should be used.

Another problem is if the original system has a lot of data then it takes a long time to extract the data, which is to be transferred to the database.

Also, EP 0 843 259, describes a management system relating to distributed resources.

SUMMARY

It is an object of the present invention to overcome the problems as outlined above and to provide an application programming interface (API) , which is perceived as object oriented and which therefore is more user-friendly than existing interfaces .

This object is obtained by means of a method and a system providing an object oriented and/or transaction based application programming interface to an application programmer/application program in an original non-object oriented computer system, where the application programmer/application program is carrying out transactions in the original computer system. The method and system involves the steps of creating resource objects corresponding to the original system, and letting the resource objects only live during the time when a transaction is ongoing.

Thus, by in this manner emulating an object oriented interface, the application programming interface will become much more user friendly, and the problems associated with the prior art will be avoided.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described in more detail by way of non-limiting examples and with reference to the accompanying drawings, in which:

- Fig. 1 illustrates an association between a subscriber number and a subscriber line. - Fig. 2 illustrates the association between resource objects and factory objects.

- Figs . 3 - 5 illustrates different examples of a two-phase commit protocol.

- Fig. 6 illustrates transaction handling in a telecommunications system.

- Fig. 7 illustrated the objects used in the telecommunication system shown in Fig. 6.

- Figs 8 - 11 illustrates different examples of transactions carried out in the system shown in Figs . 6 and 7.

DESCRIPTION OF PREFERRED EMBODIMENTS

As stated above it is desired to obtain an object oriented interface. All the resources in the system for which an object oriented interface are desired must therefore first be modelled as objects. The objects have data and operations. In this example, all the real resources lies within the non objected oriented system. However, a user of the system is going to see and have an interface to this new object oriented interface. In the example given below the user will be a human. However, in many applications the user will be a machine. Also, below the objects in the object model are called resource objects.

For example, a PSTN (Public Switched Telephone Network) subscriber number (SNB) and its corresponding physical subscriber line, which here is represented as a line interface device (DEV) can, in a simplified manner be modelled as follows:

SNB operations: ConnectSubscriberToDevice,

DisconnectSubscriberFromDevice & ReadSubscriberClassValue DEV operations : ReadDeviceState

At successful completion of ConnectSubscriberToDevice, an association is done between the subscriber number (SNB) and the subscriber line (DEV) . In other words, the system now knows what subscriber line the subscriber number belongs to. Figure 1, using Unified Modelling Language (UML) notation, shows that each SNB 101 has zero or one DEV 103 association and vice versa. In order to avoid the problems associated with previously known techniques for adding an object-oriented interface, such as using an additional database, the resource objects are created dynamically and only when the user needs to get hold of them. The user therefore has an interface to another object called a factory. A factory object is responsible for creating and deleting resource objects. A factory object is static, i.e it is always visible to the user of the system. There is one factory object for each resource object type.

In this example each resource object type (SNB and DEV) are given a factory object (SnbFactory 105 and DevFactory 107) . The factories inherit from the base class ObjectFactory 109. In Figure 2, it is shown that the resource objects has an association to one and only one factory object and that each factory object has zero or more associations to resource objects. The user creates the desired resource object by calling method getRefOf at the factory object. How the deletion of the resource object is done will be described in more detail below.

A transaction, as defined above, can be rolled back by the system itself after that application programmer/application program has ordered the transaction to commit. This can happen if some part of the system cannot commit the transaction. The system then takes care of rolling back the transaction. The mechanism for doing this is the so called two phase commit protocol. Thus, the application programmer/application program is not directly involved in the two phase protocol, it simply asks the transaction service, which is a part of the system, to commit the transaction and then the transaction service handles the completion of the transaction.

The two phase commit procedure can be executed in the following manner with reference to Fig. 3. First the user orders the transaction service to commit the transaction, step 1. Then the transaction service asks every resource it has registered as part of the transaction if it can commit, step 2. This is done by calling prepare on all the resources. The resources answers with a vote, in this case rollback, readonly or commit, step 3. If all resources vote commit as is shown in Figure 3 the transaction service tells every resource to commit, step 4. However, if one or more resources votes rollback as is shown in Figure 4, the transaction service tells all the resources to rollback the transaction, step 5.

The readonly vote is used when a resource has not been affected by the transaction. Therefore it does not need to be told to commit the transaction since that will not affect the resource. As far as the resource is concerned the transaction is ended directly after it votes readonly, step 6. This is shown in Fig. 5.

Furthermore, as shown in Fig. 6, there might be multiple systems involved in the same transaction. An example of this is a telecommunications network where an OSS (Operation Support System) 201, handles many network elements 203, such as telephone exchanges. In this case there must be some transaction service implemented at a top level. Such a top level transaction service entity can be termed a transaction manager 205. In the individual systems there is a subcoordinator 207, which handles the transaction on behalf of the whole individual system and is the interface towards the main transaction manager 205.

The user 209 in the OSS 201 starts and ends the transaction at the main transaction manager . It can after the start of the transaction invoke operations at the created resource objects. The resource objects in its turn accesses the original system via the old machine-machine interface as is described below.

When the user ends the transaction the transaction manager starts up the two phase commit protocol towards the subcoordinators and which continues it towards its registered resources, in this case the SNB 211, 213 and DEV 215, 217, respectively.

The transactional behaviour in this description follows the architecture of a CORBA (Common Object Request Broker Architecture) service for transaction handling specified in OMG (Object Management Group) . It is called Transaction Service or more commonly the Object Transaction Service (OTS) , see CORBA Transaction Service Specification (OTS) version 1.1 November 1997, Sean Baker, CORBA distributed objects Using Orbix, Harlow, England: Addison-Wesley, 1997 (pages 394-405 deals with OTS) .

Thus, in the example described above, OSS handles many network elements, such as telephone exchanges. Here, in this example, the resource objects are SNB and DEV and they are located in two different exchanges. The application program is an OSS application and the Transaction Manager is located in the OSS as well .

In Figure 7, objects being part of the main Transaction Manager are shown. Thus, these comprise TransactionFactory, Control, Terminator and Coordinator. The individual systems have objects SubCoordinator, Resource and ResourceFactory. There will be other objects required to implement the system, but here only the main objects are described. There are also messages sent between objects that are not in this description either. In the individual systems the resource factory objects are the only visible objects to the user when there is no ongoing transaction.

Also, important operations are included using UML notation are shown in Fig. 7. Here SnbFactory, DevFactory, SNB and DEV are resource factories and resource objects. So SnbFactory and DevFactory are static objects. In the Transaction Manager the TransactionFactory is the only visible static object.

In order to avoid the problems associated with the prior art, the resource objects are created within the transaction and they only live as long as the transaction is ongoing. Also, the resource objects correspond to resources which really belong to the original system.

Further, data is only set in the resource object during the transaction and the system is left unaffected. In other words new data is only visible within the transaction and it is not made durable. This way the isolated properties of the transaction as defined above are followed. The resource object updates the system via the original machine-machine interface, see Figure 6 when it receives the commit call (end of transaction) . After this procedure, the resource object is deleted. If it receives a rollback call (end of transaction) the system is not updated. The resource object can just be deleted and the transaction leaves no trace.

When reading data, there are^' two major cases.

1) The data has not been changed during the transaction.

The resource objects then fetches the data from the original system via the original machine-machine interface, see Figure 6. They return the data to the user upon request. If the data is supposed to not change within the original system during the transaction then the data can be fetched from the system at creation of the resource objects. Otherwise, it is fetched at the arrival of the request .

2) The data has been changed during the transaction.

The resource objects returns the new data to the user upon request. Since this data is only valid in this transaction the data is not fetched from the original system.

The resource object factories will prevent any user from creating an exact duplicate of the resource objects as long as they exist. This will prevent data inconsistency.

Another type of lock is needed if there is some other way to set data in the original system than via this object oriented interface. For example there might be a need to keep the old I/O interface and that might lead to inconsistent data in the system. Therefore the resource objects must lock the resources in the system so that no other I/O system can set this data. This lock will only be effective during the transaction. Furthermore, if multiple systems are not involved in the same transaction there is no need to have a top level transaction manager and a SubCoordinator, see Figure 6. In this case the transaction manager can be removed and the user starts and ends transaction at the SubCoordinator instead.

Finally, in Figs. 8 - 11, examples of transactions carried out in the system as described above are shown. Thus, in Fig. 8 an example of a successful completion of a transaction is shown. In the example the transaction carried out is the connection of a DEV to an SNB.

Thus, first, in a step 301, the user starts the transaction. Then, the object reference to the control object is returned, step 303. This object uniquely identifies the transaction. At the same time three objects are created in the SnbFactory, i.e. Control Terminator and Coordinator, step 302.

Thereupon, the user creates the desired objects, in this case the user wants to create one SNB object and one DEV object, steps 305 and 313, respectively. The parameter of the operation as shown in the figure indicates what kind of object that is to be created, for example DEV and SNB. Two objects, Sub- coordinator and DEV, are then created, step 306, and the DEV object reference is returned, step 307. As a response to this request the Control returns an object reference, step 311. Also one object, SNB, is created, step 308, and its object reference is returned in step 315. The Sub-coordinator registers resources in the coordinator, step 312.

Thereupon, the user issues a request to verify subscriber data, step 317, and the device state, step 319. Further, if it is required to set subscriber service classes, such an operation is performed in a step, 321. The subscriber is then connected to the device, step 323.

Thereupon, the user wishes to commit the transaction. In order to perform a transaction, the user needs to obtain an object reference to the object of the terminator. Therefore, the user requests the object reference from the control, step 325, which is returned in a step 327. Next, the user commits the transaction, step 329. In response to the commit call issued from the user, the control calls prepare to the SubCoordinator step 331, which in turn calls prepare to the SNB. The SNB returns a vote, step 335. Next, the Sub-coordinator calls prepare to the DEV, step 337, which returns a vote, step 339. The vote is then forwarded from the Sub-coordinator to the Control, step 341.

In this case it is assumed that all the objects returns a vote that they can commit, so that the answer from the Sub- coordinator is that the entire Sub-system can commit. In such a case the controller calls commit, step 343 to the sub- coordinator, which in turn calls commit to the SNB and the DEV, step 345 and 347, respectively. Finally, in a step 349, all dynamically created objects are deleted. Also, all required updates in the original system are performed.

In Fig. 9, the steps carried out if a user wants to roll back a transaction are illustrated. Thus, in order to perform this, the user issues a request to the terminator, step 403. Also the control will be informed and will return the object reference, steps 401 and 402. Next, the Control will call rollback on all its registered resource objects. This is performed by calling rollback to the sub-coordinator, step 405, which in turn calls rollback to the resources, in this case the SNB and the DEV, steps 407 and 409, respectively. At the same time all dynamically created objects, i.e. in this case the objects created in the steps 302, 306 and 308 in Fig. 8 are deleted, step 411. In this case no change has been made in the resource objects, so the SNB and DEV objects can be deleted without updating the original system.

In Fig. 10, an example of an resource initiated rollback transaction is shown. Thus, if one of the resources returns a vote that it cannot commit the transaction, the transaction must be rolled back. In such a case, first the control calls rollback to the sub-coordinator, step 501. The SubCoordinator then calls rollback to its resources, in this example SNB and DEV, steps 503 and 505, respectively. At the same time all dynamically created objects, i.e. in this case the objects created in the steps 302, 306 and 308 in Fig. 8 are deleted, step 507. In this case no change has been made in the resource objects, so the SNB and DEV objects can be deleted without updating the original system.

In Fig. 11, an example where a DEV has voted readonly and an SNB has voted commit is shown. In this case the sub-coordinator does not need to tell DEV to commit since this will not affect its state. Thus, first the control calls commit to the sub- coordinator, step 601, which in turn calls commit to the SNB, step 603. In this case the SNB will update the original system. At the same time all dynamically created objects, i.e. in this case the objects created in the steps 302, 306 and 308 in Fig. 8 are deleted, step 605.

By using the interface as described herein, there is no need to add an additional database to a computer system, which is to offer an object oriented and transaction based application programming interface (API) . Thus, the complex problem of synchronizing the database and the original system is avoided.

Claims

1. A method of providing an object oriented and transaction based application programming interface (API) in an original computer system having a non-object oriented interface, where the application programmer/application program is carrying out transactions in the original computer system, characterized by the steps of:

- creating resource objects corresponding to the real resources in the original system,

- making the resource objects use the original non-object oriented interface of the original system, and

- letting the resource objects only live during the time when a transaction is ongoing.

2. A method according to claim 1, characterized in that during the transaction data is set in the resource object, while leaving the original system unaffected until the completion of the transaction.

3. A method according to claim 1 or 2 , characterized in that the resource objects lock the resources in the system during the transaction, so that other transactions cannot access the resources in the system during an ongoing transaction.

4. A method according to any of claims 1 - 3 , characterized in that the factory objects are arranged to check that more than one identical resource object is not created.

5. A method according to any of claims 1 - 4, when a transaction is committed, characterized in that the original system is updated by the resource objects via the non-object oriented interface of the original system.

6. A method according to any of claims 1 - 4, when a transaction is rolled back, characterized in that the original system is kept in the same state as before the initiation of the transaction.

7. A method according to any of claims 1 - 6, when the original computer system is a system comprising multiple systems, characterized in that a central transaction unit is provided for coordinating all transactions in the different systems.

8. A method according to any of claims 1 - 7, characterized in that the transactions are performed in a telecommunication system.

9. A method according to any of claims 1 - 8 , characterized in that, if at least one of the created resource objects votes rollback when performing the transaction, all parts of the transaction are rolled back.

10. A computer system comprising an object oriented and transaction based application programming interface (API) in an original computer system having a non-object oriented interface, where the application programmer/application program is arranged to carry out transactions in the original computer system, characterized by

- means for creating resource objects corresponding to the real resources in the original system,

- means for making the resource objects use the original non- object oriented interface of the original system, and

- means for letting the resource objects only live during the time when a transaction is ongoing.

11. A system according to claim 11, characterized by means for during the transaction setting data in the resource object, and means for leaving the original system unaffected until the completion of the transaction.

12. A system according to claim 10 or 11, characterized in that the system is programmed so that the resource objects lock the resources in the system during the transaction, so that other transactions cannot access the resources in the system during an ongoing transaction.

13. A system according to any of claims 10 - 12, characterized in that the factory objects are arranged to check that more than one identical resource object is not created.

14. A system according to any of claims 10 - 13, characterized by means for updating the original system using the resource objects via the non-object oriented interface of the original system, when a transaction is committed in the system.

15. A system according to any of claims 10 - 13, characterized by means for maintaining the^' original system in the same state as before the initiation of the transaction, when a transaction is rolled back in the system.

16. A system according to any of claims 10 - 15, when the original computer system is a system comprising multiple systems, characterized by a central transaction unit for coordinating all transactions in the different systems.

17. A system according to any of claims 10 - 16, characterized in that the system is a telecommunication system.

18. A system according to any of claims 10 - 17, characterized by means for rolling back all parts of a transaction, if at least one of the created resource objects votes rollback when performing the transaction.