System for implementation-independent interface specification.

IS 2 154 647 T3

DESCRIPTION

Implementation-independent interface specification method and system.

Background of the invention

A portion of the description in this patent document contains material that is subject to copyright protection. The copyright owner does not object to the facsimile reproduction by anyone of the patent document or patent description as it appears in the patent and trademark office, patent file or records, but is otherwise reserves any other rights.

Field of the invention

The invention refers to the specification of protocols and interfaces in distributed and modular data processing or computing systems such as telecommunications exchanges and, more specifically, to the specification of application-level protocols, that is, level number 7 in the Open Systems Interconnection (OSI) protocol stack.

Description of Related Art

One aspect of computer systems, particularly networked or distributed systems, is that many communication protocols must be used to communicate between and with the various components that make up the system. The monitoring of communications between components of a computer system requires the creation of well-defined communication protocols. Interprocess communications within an information system typically communicate in terms of requests and responses. Such systems have limited communication facilities and are only capable of processing all requests in the order in which they are received. Typical process-to-process protocols only realize this fairly simple data transmission capability.

The protocols are implemented in computing systems to effect the orderly exchange of information between computing components. For calculation components to communicate, conventions are required. Protocols can be used to create a standard communications path between two computing devices. The agreed protocol conventions typically determine the nature of the data representation, the format and speed of that data representation over a communications path, and the sequence of any control messages to be sent. Although a protocol is the logical or conceptual set of rules for communication between similar processes, interfaces include the set of rules between different processes and are often physical rather than logical connections. The procedure of a protocol constitutes a predetermined dialogue that both ends of a communication link must scrupulously maintain. At the link level, a protocol consists of an exchange of octets or sequences of octets that guarantee the control and integrity of a message transfer.

In the case of process-to-process communications within a data processing system, the protocols typically provide only a very simple data transfer capability. Data is received only in the order in which it is sent and the information that passes between processes consists only of the request, the response and possibly some data. All data or requests must be processed by the receiving process in series; multiple streams cannot be handled simultaneously. This type of communication system makes the task of creating a server or some other device difficult to allow the simultaneous handling of multiple requests. An example of this type of system is described in US Patent No. 4,396,983 to Segarra et al. Which describes an inter-process communication system within a distributed processor system.

Some servers capable of handling multiple requests have been developed, but they have typically been developed using a method that restricts the usefulness of a message-based protocol. Such servers operate by only sending data addresses between processes and not the data itself. The IBM Technical Disclosure Bulletin vol. 23 n ° 5, oct. 1980, "Distributed Data Processing Systems" describes a modified version of such a system. Similarly, IBM Technical Disclosure Bulletin vol. 22 n^° 7, Dec. 1979, "Message-Based Protocol For Interprocessor Communication" describes a message-based protocol for communicating between processes running on different processors that are loosely coupled via a common bus.

United States Patent No. 4,649,473 issued to Hammer et al. Describes a system

ES 2 154 647 T3 that uses an information transfer facility between processes to carry out the transfer of information between processes that cannot share common storage and that can be located in more than one processor. This system uses "notes" which are packets of information. Each packet performs a job request in such a way that the server process can control the reception and processing of the requests and their corresponding data at its own convenience.

The advent of low-cost data processing devices has led to the development of local area communications networks that can handle a large number of devices used within a single business environment. The capabilities of the prior art systems were limited to the use of a single communications protocol for each different treatment system. This meant that the addition of new devices once the system was operational was difficult, if not impossible, because the new device would have to operate with a communications protocol identical to that of the other devices already within the system.

However, more sophisticated local air network systems have now been developed that allow a plurality of remote treatment devices to be connected to a central processor over a communications channel. Topically associated with each data terminal device was a communications controller having a rotary switch that can be selectively regulated to send the controller address. Each controller then sends its address to the central computer. The central processor will retrieve from a look-up table, stored in the processor, the program instructions including the communications protocol to be used by the controller in controlling the transfer of data between the central computer and the specified remote devices. Such a system is described in US Patent No. 4,787,028 issued to Finfrock et al.

Another drawback of currently available systems derives from the fact that technological advances have produced a variety of computer and data processing systems that operate at variable data rates and with variable formats. The information technology industry has not developed or followed a series of standardized protocols. Therefore, it is often impossible for various computer systems to communicate and exchange information with each other. At present, if individuals using diverse hardware wish to communicate with a central computer or with other separate computers, the data that is transmitted at a speed and in a different format from the receiving system will be unintelligible to the second or receiving computer. More often than not, the second computer did not use the same speed and the same format as the first system or emitting system.

Systems have been developed to solve this problem, at least partially. For example, devices have been developed in which a software program or computer hardware is used to analyze incoming data to determine the exact data rate and precise format of the data being transmitted. However, such systems are topically quite expensive and complex, because they require developing an algorithm in which multiple data rates and formats are specified. The algorithm, after determining the speed and format of the transmitted data, must make the necessary changes to the receiving computer so that it can easily interpret the data it receives.

A "communications network for communicating with computers provided with disparate protocols", as described in US Patent No. 4,688,170, overcomes some of the deficiencies specified above. Describes a global communications network between various sizes and types of computers using different data rates and different data formats. The described system achieves this by putting into the memory of one of the computers on the network a program that contains a list of the data rates and formats used by all the computers on the global network with which any of the computers within it could communicate. of the network. The system is started by the individual user who must select a specific channel number associated with the computer with which the user wishes to communicate. The user's computer then entered into communication with the target computer and learned the data rate and format of the target computer. However, the sending computer is the one that contains the program listing, the sending computer, after consulting the list, later transmitted information at the speed and format applicable to the receiving computer.

Other solutions to communication problems have addressed a different aspect of the evolution in computer architectures towards distributed systems, that is, the trend towards the use of separate subsystems for users, resource management and communications management within a network. general communications. The system described in US Patent No. 4,396,983 issued to Segarra et al. Makes it possible for any local system to communicate with any other local system within the network without the use of a primary or central system. The described system achieves this through a variety of communications limitations, as well as by managing the protocols

ES 2 154 647 T3 communications through the use of specialized communications modules located within the functional layer of communications of the distributed system. This system is limited, however, to some specific types of distributed systems.

European Patent Application No. 0 387 172 A3 dated September 12, 1990, issued to Brandle et al. For a "Procedure Call Interface" (the Brandle reference) describes a computer language interface that is used by application programs to call system library routines (procedures). The computer language interface allows application programs, which can be written in any computer programming language, to call up the system library routines without taking into account the calling conventions used by the computer programming language in which they are used. the library routines were implemented.

The computer language interface is implemented by a service manager, a segment procedure, and a service table. Every application program that uses the library routines must have a segment procedure. An application program invokes a library routine using the segment procedure to communicate parameters and other information to the service manager. The service manager receives and examines the parameters and other information in order to determine the library routine to invoke. Once the service manager has identified the library routine, a service table is used to identify the parameters and the call settings required by the library routine.

In contrast to the present invention, the Brandle reference does not describe a technique to automaotically facilitate operational data communication between a first software unit and a second software unit running on different processors and where operational communication is defined by a protocol. bidirectional within an interface specification. In fact, Brandle's reference does not describe an interface specification. The Brandle reference also does not contemplate a bidirectional protocol that is implemented by specific first and second part interfaces that are generated from the interface specification using an off-line segment generation tool.

The Brandle reference does not describe or suggest the improved method claimed herein. Brandle's reference does not describe a language-independent interface specification, and therefore does not describe or suggest creating a language-independent interface specification that defines the contract between pairs of parties. Furthermore, the Brandle reference does not describe or suggest the generation of specific interface implementations of part of the interface specification for use in first and second components to allow operational communications between such first and second components.

Andrew D. Birrell and Bruce J. Nelson, Implementing Remote Procedure Calls, ACM Transactions on Computer Systems, vol. 2, n^° 1 (February 1984) (the “Birrell reference”) describes a technique for extending the procedure call mechanism (for the transfer of control and data within a program running on a single computer) to a distributed processing environment. where multiple computer devices are connected by a communication network. The Birrell reference calls this conceptual extension a "remote procedure call" (RPC). The Birrell reference proposes a program structure for RPC using a concept there called "segments".

When a remote procedure call is found, five pieces of program code participate in the transaction: the user code, the user segment code, the RPC communications package, the server segment code, and the server code. The user code, the user segment code, and one instance of the RPC communications packet run on the calling machine, while the server code, the server segment code, and another instance of the RPC communications packet run on the calling machine. called machine.

When a user code wants to make a remote call, it makes a local call that invokes a corresponding procedure in the user segment code. The user segment code is responsible for specifying the destination procedure and its arguments to one or more packets and for asking the RPC communications packet to transmit the packet to the called machine. Upon receipt of these packets, the RPC communications packet in the called machine passes them to the server segment code. The server segment code unpacks these packets and makes a local call that invokes an appropriate procedure on the server.

Meanwhile, the calling process at the calling machine is suspended until the appropriate result packets are received. When the call on the server finishes the execution, the server code returns the results to the server segment code which in turn passes the results again

ES 2 154 647 T3 two to the suspended process in the calling machine. The user segment code unpacks the returned results and passes them to the user code.

The user segment code and the server segment are generated automatically by a program that uses an interface module which is primarily a list of procedure names along with the types of their arguments and results. The information contained in the interface module is typically suitable for compile-time type verification and for generating call sequences. The RPC paradigm described in the Birrell reference requires a programmer to design the interface for communication between the user and the server code.

Other methods for solving communication problems between and within computer and data processing systems include the CCITT recommendation for the use of X, 210, Remote Operations and ISO 9072-1, Model information processing systems-text communications. - remote open systems interconnection operations for CCITT applications that were developed in close collaboration and are technically aligned. The CCITT recommendation X.219 defines remote operation services and open systems interconnection notation for CCITT applications, to support interactive applications in a distributed open systems environment. However, they follow the X.219 recommendation, only the operations are formally specified. There is no formal specification of the actual protocols or of any interaction limitations. The CCITT standards are the recommendations of the International Telegraph and Telephone Advisory Committee. Numerous CCITT communications standards have been published and have gained acceptance in the computer industry. For example, "CCITT V.24" has been widely accepted for use in the lower layers of network architectures. Such standards are useful and necessary to define conventional connections between data equipment and modems. Such phasic standards provide an efficient compatible interface between two different hardware devices.

The system of the present invention is applicable at the application level, that is, level n ° 7 of the OSI protocol stack, and thus most of the techniques of the prior art explained above that refer to lower layers in the stack of protocols are not directly relevant. On the other hand, the CCITT X.219 Remote Operations and Advanced Network Systems Architecture (ANSA) standards refer to application-level protocols and therefore to the present invention. The architecture of advanced network systems, ANSA (the ISA project, provides interfaces where groups of operations are specified.

However, peer protocols, in which two communicating parties are considered equal and each party can initiate communications, must be created from two different client-server specifications that have no formal connection to each other. In addition, the interface specifications are at least partially integrated with the implementation that makes the system less flexible, less modular, and less system independent. The ANSA system provides interaction limitations to be specified, but only for some limited purposes not related to the specification itself. The ANSA computational model includes the structuring concepts provided by ANSA for application programmers to use when designing distributed programs. It includes important concepts such as services, operations, objects, interfaces, invocations, interface types, activities, and conformity data.

Another architecture and related specification is the Common Object Request Broker developed by a group of companies, including Sun Microsystems, Inc., Hewlett Packard, Inc., and Digital Equipment Corporation, among others. This specification provides the means by which objects in a system can transparently generate and transmit requests and receive responses. The Object Request Broker is a classic model of concrete objects that also provides interoperability between applications on different machines in heterogeneous distributed environments, providing uninterrupted interconnection between multiple object systems. This specification does not, however, provide for the implementation of specific peer-to-peer protocols with the parties treated as equals.

Therefore, it will be highly useful within the telecommunications industry to be able to specify some communication protocols and other interfaces in a single separate specification that exists apart from the implementation of any communicating part or component. That is, it will be beneficial to have a method whereby multiple pairs of two parties within a computer system can describe two-way communications in the same description or common specification. It is also desirable that all these protocols can be described in this way, whether they are client-server protocols or peer protocols. The system of the present invention provides such a system, using in part

ES 2 154 647 T3 specified language called ELIN. The ELIN language, its concepts and its constructions are described in detail in the “ELIN Language Reference”, published by Telefonaktiebolaget LM Ericsson (ed).

Summary of the invention

According to the invention a method as claimed in claim 1 and a system as claimed in claim 13 are provided. Preferred forms of the invention are set forth in the dependent claims.

The system of the present invention provides the complete specification of application-level communication protocols used within a computer system, both simplex and duplex in nature, and each protocol is stored in an offline software development system. Protocol specifications are separate design objects that can be used as "contracts" between pairs of software modules that implement communicating parties. In the system of the present invention, the contract for complete communications between pairs of communicating parties is collectively specified. That is, the contract may include various aspects of the interaction of the pairs of parties, including their respective responsibilities, their respective permitted operations with their data and addresses, and the permitted order on how operations can be sent between respective parties of the pair. This method of specifying protocols using an interface specification in a well-defined, specialized, but common language also allows the specification to be reused for "contracts" between other pairs of communicating parties.

Furthermore, this aspect of the system of the present invention increases the level of modularity achievable within a computer system and increases standardization across a system as well as the ease with which a system can be expanded. In addition, it allows a truly independent development and verification of software programs that must interact with each other. This aspect of the present invention provides the ability to easily perform independent software development and verification even in very remote geographic locations.

In another aspect, the system of the present invention includes a mechanism for specifying all internal interfaces in the application layer within a data processing or calculation system using some special and well-defined constructs. These definitional elements allow to develop, for example, a peer protocol specification that contains the following components: (1) a formal grouping of the operations to be used within the two parts of the protocols; and (2) the specification of interaction limitations for use within the protocol. In another aspect, the system of the present invention also provides the ability to specify client-server or unidirectional type protocols.

In another aspect, the system of the present invention includes the use of a protocol specification for the generation of a segment code that later guarantees that perfect coordination is achieved between two communicating parties. In the system of the present invention, operations are specified by the following information: class of operation; arguments; results; and errors. Furthermore, this aspect of the system of the present invention still provides interaction limitations to be specified as part of the interface or protocol specification. This aspect of the system of the present invention helps the implementer of a communicating party using the protocol to understand what operations can be invoked in a given time.

In another aspect, the system of the present invention includes a mechanism for generating a "protocol monitor" to monitor the system and detect when a particular implementation is misbehaving and violating specified interaction rules. When a rule is violated, this aspect of the system of the present invention makes both parties aware of the violation and provides the corrective action to be taken. Such a feature should only be triggered, however, in the event of a design failure in the implementation of one of the communicating parties. Therefore, the protocol monitor aspect of the system of the present invention has its primary utility in the system verification and software development phases.

In another aspect, the system of the present invention includes a means for specifying interaction limitations including a set of symbolic states, each with a list of allowed operating components. The result of the specification of the interaction constraints is a finite state machine, that is, the protocol monitor. Each operation is specified separately and in an operational specification in which the arguments, results and errors are specified with name and data type, which in turn can be of primitive or constructed type.

IS 2 154 647 T3

In another aspect, the system of the present invention employs an object-oriented interface design language, called ELIN, which can be exercised to create uniform independent interface specifications. The ELIN language, consisting of a number of unique and specialized terms and constructs, provides a mechanism for creating specifications for use with two-way communications. Therefore, the resulting specifications can be used by multiple pairs of communicating parties for the specific implementation of their communications interface protocol. Furthermore, the ELIN language provides a mechanism to describe not only communications of the type in which one party controls data exchanges, but also communications in which both parties act as equals and can initiate and / or control data exchanges.

In another aspect, the system of the present invention includes a mechanism for interface specification that achieves independence from any programming language and any specific computer architecture. From the specifications created using the ELIN language of the system of the present invention, tools can then be applied to generate a segment code for various individual programming languages. This generation aspect of the segment code of the system of the present invention is vital for the whole system and mechanism. The whole concept is based on these segment code generators to provide an efficient and intuitive interface to the specified protocol for the system or application programmer.

In one aspect, the present invention is a system and method for automaotically facilitating the operational communication of data between associated pairs of a group of software units. The technique begins with the creation of a set of high-level interface specifications independent of the computer programming language using an object-oriented paradigm. Each of the high-level interface specifications defines a bidirectional protocol for operational communication between a pair of software units.

An off-line segment generation tool then generates a first part-specific interface and a second part-specific interface using a particular high-level interface specification. The first part-specific interface is entered into the software unit of a pair while the second part-specific interface is entered into the second software unit of the pair.

The software unit pair runs on different processors. The pair of part-specific interfaces runs simultaneously on the respective processors, resulting in the implementation of the desired bidirectional protocol for operational communication between the pair of software units.

In one aspect, the present invention is a system and method for generating and verifying the interaction of a set of software modules. Each of these software modules was designed in such a way that it is capable of interactively creating and manipulating objects belonging to one or more object classes that are automatically generated from an interface specification.

The technique begins with the definition of an interface specification independent of the computer language to control the interaction of the set of software modules. The process of defining the interface specification includes providing a unique name for the specification, listing one or more case variables that define the characteristics of a class of objects, and specifying limitations, if any, on the interaction of the software modules. . The definition of the interface specification may optionally include the provision of interaction variables that specify the public and / or private interaction of a group of objects.

The interface specification later becomes an interface implementation for a specific computer system by identifying the software modules that have to exchange data to create and manipulate objects inactively. Then a set of operating orders is defined for each software module and the limitations to be placed, if any, on the interaction of the software modules are also specified. These pieces of information are also associated with a specific identity (called the "name") of the communications protocol.

Then a set of functional software modules is created that are capable of interacting or communicating with each other using the interface implementation defined above. The interaction of the software modules can be regulated so that the software modules can communicate with peers or limit the interaction of the software modules that is necessary in a client server environment. Finally, the set of software modules is executed in the computer system using the interface implementation to allow operational communication between the various software modules.

IS 2 154 647 T3

As those skilled in this particular art will readily appreciate, the principles and aspects of this invention could also be used to advantage in a variety of computer applications other than telecommunications switching systems.

Brief description of the drawings

For an understanding of the present invention and for its other objects and advantages, reference can now be made to the following description, taken in conjunction with the attached drawings, in which:

Figure 1 is a functional block diagram illustrating a prior art communication network for communicating with computers having disparate protocols.

Figure 2 is a block diagram illustrating a prior art data processing system that accommodates a plurality of remote devices, each operating under a different communication protocol using communication controllers that send signals that include the address of the controller. .

FIG. 3 is a general diagrammatic view of a prior art multiprocess system having an inter-process communications facility for controlling inter-process communications within a processor system.

Figure 4 is a block diagram illustrating how the common interface specification of the system of the present invention is used for an interface specification of the server-client type for runtime dynamic link performed independently of the programming language.

Figure 5 is a block diagram illustrating how software units can be addressed via the dispatcher in the system of the present invention. The input to the distributor is generated from the interface specifications and unit specifications.

Figure 6 is an illustrative diagram of how the interface specification can be used to generate a segment code for streamlining and coordination of communications in the system of the present invention.

Figure 7 is a diagram illustrating how interface specifications are used within the system of the present invention.

And FIG. 8 is an illustrative diagram of how an object-oriented interface description language is used to implement common interface specifications or protocols that facilitate communications within the system of the present invention.

Detailed description

The system of the present invention uses, in some respects, object-oriented programming principles. Object-oriented programming essentially involves four elements: classes, objects, case variables (or data elements implemented in C ++), and methods (or element functions in C ++). A class is simply a template used to define objects, which are instances of the class from which they are created. Classes have two types of components: case variables and methods. Case variables serve as data elements and methods serve as functions, that is, they define the behavior of an object. You can combine case variables and methods into a single common object at runtime. That is, an object encapsulates a case of the variables that can be manipulated using the methods. Therefore, programming is carried out with a focus on objects, rather than on the functions or tasks to be performed.

Some object-oriented programming techniques known in the art are incorporated into the system of the present invention in the preferred implementation of the system of the present invention in the C ++ programming language. Such techniques include inheritance, polymorphism, and encapsulation. Inheritance allows a new class to be derived from an existing class so that the code can be used easily, so that data and code can be added to a class or the behavior of a class can be altered, without having to change the code. existing class. Polymorphism is the property that provides the ability to use different types of objects in the same way because different

ES 2 154 647 T3 types of objects share a common interface. Interface inheritance is the property that makes it possible to derive other types of objects from a common denominator. Finally, encapsulation is a technique for combining the data and operations necessary to process all the data under one “roof”. It also allows the ability to protect data against excessive or unnecessary access and hide the details of the data organization.

In the system of the present invention, all public interfaces connecting software units to the external environment (except for cross compilers and related libraries) are specified using ELIN. This allows specifying all software units in terms of the interfaces to which they are connected, activating such specification in a segment code generator. The following is a step-by-step description of developing a software unit using ELIN, illustrated according to the preferred method of developing object-logic implemented in C ++. Other parallel processes are used to develop database specifications, unit functions, and other elements of a system. The following steps illustrate block-object development (steps 1 and 2), unit-object development (steps 3 through 6), and packaging (step 7).

Step 1: Interface specifications are available or new ones are specified in ELIN.

Step 2: A software unit with interfaces is identified.

Step 3: C ++ header files are generated from the unit specification and the specifications for the interfaces to which the unit is connected (ADT, PROTOCOL, PERSISTENT ADT).

Step 4: The hand-made code is written to .h and .cc files which, if necessary, include the generated .h files.

Step 5: All .cc files are compiled with a cross compiler and a file-object (.o) is produced for each of the .cc files.

Step 6: All object-files are linked with standard libraries and the complete software unit is created.

Step 7: The software units are packaged together within a system entity that must be assigned to the same processor. The packages are called cargo packages and can contain a group of units of variable rate.

Step 8: Transfer the packages to the target system.

Step 9: On the target system: Save the package temporarily.

Step 10: Link / reassign and copy the packet load modules in suitable places in memory depending on the type of information.

Referring first to Figure 1, a communication network is illustrated in the prior art that allows communications between computers having disparate protocols. Although computers can employ various data rates and data formats to receive and transmit data, they are still capable of intelligently communicating with each other on the illustrated network. This communication network may include, for example, several various host computers 10, 12, several personal computers 14, 16, a laptop computer 18, and a local area network transit center 20. The host computers 10 and 12 as well as the Personal computers 14 and 16 could include peripherals such as a printer 22 and a disk file 24. All computers communicate with each other using separate modems 26 and a world telephone system 27 or a local telephone exchange 28.

However, since the various computers using this communications network are programmed to transmit or receive data based on specific bit rates and data formats, communication between these various computers would be impossible unless each individual computer is aware of of these various bit rates and data formats. For example, each of the data formats would include a data packet with a parity bit, would be of various word lengths, would include a collic redundancy check, and would be synchronous or asynchronous. The system illustrated in Figure 1 allows communication between these systems by providing a program that is stored in the random access memory ("RAM") of at least one of the computers on the network. This program contained the various bit rates and data formats that are used by the various types of computers that the computer wishes to communicate with. Often times, the program being stored did not contain these specific data bit rates and data formats, but did contain the information necessary to implement

ES 2 154 647 T3 a system for simulating the various data rates and data formats. In this situation, the individual user will determine the various data bit rates and data formats that are used to communicate with the computers of interest and will input this information into the computer itself.

Referring now to Figure 2, a prior art data processing system is illustrated that accommodates multiple remote devices using different communication protocols through the use of communication controllers that send signals alerting the central processor to their addresses. The described system includes a local area network treatment system in which a plurality of remote treatment devices such as point of sale data terminals are connected to a central processor by a communication channel. Associated with each of the data terminal devices is a communication controller in which is mounted a rotary switching element that is selectively regulated to send binary signals including the address of the controller. When a power supply condition occurs for the system, each controller will send a message including its address to the central processor identifying the controller. The central processor, using the controller's address as a further address, will retrieve from a look-up table stored in the processor the program instructions including the communication protocol that the controller will use when controlling the transfer of data between the central processor and remote devices. treatment. The instructions are loaded into a RAM memory located inside the controller. The address switch is still manually adjusted so that each controller will have a different address.

Referring again to Figure 2, a block diagram of a data processing system is shown in which a central processor 30 is coupled by a communication channel or link 32 to a plurality of remote processing devices that may include a data terminal device 34 and a communication controller 36 that controls the transfer of data between the terminal device 34 and the central processor 30. Controller 36, processor 30, and terminal device 34 are connected to channel 32 via junction box 38 and bus 40. As will be fully described below, each of the controllers 36 is capable of being coupled over communication lines 42 via modems 44 or directly to a remote controller 46 which in turn controls the transfer of data between the central processor 32 and communication devices. processing such as data terminal devices 48 connected to remote controller 46. A disk file memory 50 connected to central processor 30 on line 54 includes a look-up table 52 that contains a plurality of programs associated with different types of communication protocols such as asynchronous, bisynchronous, and bit synchronous used by remote devices of the system. treatment when transferring data on channel 32. For a complete description of the different types of communication protocols, refer to US Patent No. 4,346,440 issued August 25, 1982.

Referring now to FIG. 3, an overview of a prior art multi-threaded system utilizing an inter-process communications facility for inter-process communications within a processor system is illustrated. In Figure 3, a high-level view of a distributed processing environment is generally indicated at 60. A processor A indicated at 62 is coupled by a physical path indicated by a line 64 to a processor B indicated at 66. Processor A is indicated to have a process A indicated at 68 and a process B indicated at 70 residents in uel. A storage area 72 is associated with process A and process B as represented by lines 74 and 76 respectively to provide process control and access to data storage.

Processor B is indicated to have a process C indicated at 78 and a process D indicated at 80 residents in uel. A storage area 82 is associated with process C and process D as represented by lines 84 and 86 respectively to provide process control and access to data storage.

The processes, or programs running within the processors, have to communicate with each other. On processors of different configurations, or on the same processor as it changes over time, two communicating processes may be in different relative positions and may have different physical paths between them.

In the system illustrated in Figure 3, an inter-process communication facility (IPCF) is provided within processor A and processor B at 88 and 90, respectively, to accommodate inter-process communication that is position transparent to processes. in communication. IPCF 88 is coupled to process A in processor A as represented by line 92 and to process B as represented by line 94. Lines 92 and 94 represent interfaces between process A and process B to IPCF 88. These interfaces allow communication between process A and process B provided that

ES 2 154 647 T3 appropriate data paths are established. The IPCF 88 is also coupled by a transport mechanism 96 on line 64 via a transport mechanism 98 in processor B to the IPCF 88. The IPCF 88 is in turn coupled as represented by interface lines 100 and 102 to the process C and process D. These interfaces with the IPCFs and the transport mechanisms allow the establishment of communication between all the indicated processes, without the process knowing the position of the process with which it is communicating.

In the system illustrated in Figure 3, the transport mechanisms 96 and 98 preferably include a plurality of transport mechanisms such as local transport mechanisms for use when process A and process B or process C and process D communicate within of a unique processor. If processor A and processor B reside on the same machine, a bus transport mechanism is used to facilitate inter-process communication on processor A and processor B. For communication between machines, the use of a communication protocol such as SNA is suitable.

Transport mechanisms 96, 98 are data shifters. They are responsible for transferring bytes of data from one place to another and do not understand the meaning of the information moved. Thus, the storage 72 in processor A is coupled to the transport mechanism 96 as represented by a line 104 and the storage 82 in the processor B is coupled to the transport mechanism 98 as represented by a line 106 to allow information transfers directly by the mechanisms. transport 96, 98.

The IPCF of the process trying to communicate chooses the transport mechanism for the communication. The communicating processes do not have to be aware of the mechanism used. The process that is trying to communicate supplies the name of the target process, as known to the process that is trying to communicate, to the IPCF using an appropriate directory service to locate it. The IPCF then selects the appropriate transport mechanism and uses services provided by the system to establish the connection between the processes in a standard manner. The IPCF can be used by all levels of processes, from applications to basic system services such as a search manager.

To allow the use of many different transport mechanisms, each with different capabilities and characteristics, the IPCF includes a generic transport mechanism interface for each process. The interface defines a group of functions for the establishment of connections and for the passing of information between processes. The defined functions apply to the transport mechanisms used by the IPCF. Programs written in the interface are independent of the transport mechanism and therefore independent of their relative positions when communicating.

Communication between processes is carried out in terms of sending and receiving messages through a connection between them established by the IPCF. The messages contain work requests and / or data. With regard to a particular job request, a process assumes the role of an applicant or a server. The applicant initiates a job request by sending a request to a server that performs it. The requests contain a job request (an order and its parameters) and optionally some data. Both the request and the data are of variable length.

With reference next to Figure 4, it illustrates the fact that the mechanism creates and relates classes and examples of classes using the concept of a dispatcher 120 contained within a core 122 in the operating system, which allows a relationship of interface between a pair of software units 124 and 126, containing, respectively, a client class of objects 128 and a server class of objects 130. Figure 4 illustrates in detail the steps necessary to create objects within the system, as well as the way in which the created objects can be claimed or manipulated by means of the resident code in the server software located in the "server" software unit 130.

Objects are examples of classes that are language interpretations that contain both data and code or functions within a single package or unit. Since they are capable of containing definitions of both data and functions within a single package or unit, they act as independent miniature programs. They can therefore be used as functional blocks when creating more complex programs without having to redevelop the necessary code for the functions. Since they can be maintained and modified independently, program maintenance and revision is simplified.

A class is a template that is used to define an object, and therefore an object is an instance of a class. A class contains two types of components, case variables or data elements and methods or element functions. To support programmers who develop programs that play the role of client within the computer system, a client class is automatically generated using the

ES 2 154 647 T3 use of an interface specification. The generated client class acts as a kind of agent for the server class. The client program units of the system demand operations from the client class objects to ensure that the calls are transferred to the software implementation resident in the server class. Therefore, all code related to the dynamic join function is in the client class but hidden from the user of the client class. The user of the client class has the impression of manipulating the server.

Class declarations control how the compiler will store addresses in data-objects and in what order addresses will be displayed in operations tables. Some class declarations are automatically generated by the system. When an object is created within the system, its "creation method" can be placed by a request to the distributor portion 120 of the operating system located within the core 122. Distributor 120 contains information, that is, memory addresses, of the locations of all implementations of the interfaces. As software units are loaded into the computer system, it publishes certain information about their accessibility to other units, at distributor 120. Addresses to functions that create objects of their type are also published at distributor 120 at an address 134 pointing to to the creation method 135 in the server class 130.

In order for a software unit 124 to create a new object of a certain type, it must first ask vendor 120, offering information about the class for which a new object is desired. Using an off-line generated uan number "X" corresponding to interface specification 132, you can receive the address of the appropriate creation method 136 that is used to claim that function. What is returned is the address of the newly created object or case of the desired class. The mechanism illustrated in figure 4 is used as part of a linked procedure call mechanism as described in the co-pending United States patent application entitled "System for Dynamic Runtime Joining of Software Modules in a Computer System ”, Filed on July 1, 1992, in the name of K. Lundin et al., And issued on August 16, 1994 and assigned to Telefonaktiebolaget LM Ericsson (publ.). The linked procedure call mechanism implements a system for dynamic runtime linking of separately loaded software units. In particular, this is useful within the context of a system for changing software during computer operations where both old and new versions of software will coexist for some period within the system. Such a system for updating or changing software during operation is described in co-pending United States Patent Applications Serial Numbers 5,410,703 and 5,555,418, entitled "System for Changing Software During Computer Operations," filed July 1, 1992, by Nilsson et al., And granted on April 25, 1995 and September 10, 1996, respectively, and assigned to Telefonaktiebolaget LM Ericsson (publ.). In such a system, distribution is used to access an interface using the bound procedure call. The necessary data will be available at distributor 120 because, at load time, all interfaces accessible via the linked procedure call mechanism are published to the core distributor 120 of operating system 122.

The diagram in FIG. 5 illustrates how the old software 150 and the new software 152 in the program unit are intertwined and linked during run time by such a linked procedure call mechanism. Distributor 120 within core 122 may direct execution of software unit 154 to old software unit 150 or new software unit 152. At the same time as the replacement, the server classes of both the old and new versions publish their interfaces to the dispatcher 120. The dispatcher 120 contains two address entries at a time, an entry 156 for the old software unit 150 and an entry 158 for the new 152 software unit. Processes created before the replacement will receive an address pointing to the old software unit 150 and its server classes while other processes may receive addresses to newer versions of the server class.

After the replacement has been completed and activities within the old software unit 150 have been completed, the old software unit 150 can be removed from memory and the interfaces published by the server classes on the old software unit 150 can be removed. If an attempt is made to remove these server classes from memory before all processes within the old software unit have finished executing, the system generates an exception call from kernel 122. An exception handling process within the system then gives to the uncompleted process the opportunity to re-create and use the new software unit 152 or otherwise terminate.

As part of the use of the procedure-bound call mechanism, the interface specification of the system of the present invention is written in an interface-oriented description language.

ES 2 154 647 T3 to object called ELIN, whose language reference manual is the property of Ellemtel Utvecklings Aktiebolag dated November 6, 1991. In this language, there are special constructions, called summary data types (ADTs), that are they specifically address the specification of bound procedure call interfaces. An ADT in the ELIN language is a specification of the interface provided by objects of some types. These objects are suitable to be implemented as instances of a class if an object-oriented programming language is used. A specification for a linked procedure call interface in ELIN language will include the following information:

(a) A name for the specification;

(b) Other interfaces used as a basis for said interface;

(c) One or more constructors (used to create cases); and (d) Zeroomaos method specifications, each of which consists of a method name, arguments, return type, and exceptions.

The following is coded, an example of an interface specification that could be used as part of a bound procedure call mechanism and that describes an interface to stack-type objects:

ADT Stack IS

BASE TelecomObject;

METHODS

CONSTRUCTOR (IN size: Integer); push (IN data: Integer); pop () RETURNS Integer;

END ADT Stack;

© 1992 Telefonaktiebolaget LM Ericsson

This interface specification defines an ADT called a stack, the base being named "TelecomObject". The objects in this database can accept process calls from the listed function elements. Having identified a base indicates that there is another specification of this type called TelecomObject. Said base also has some specified methods that it inherited to the stream, such as an ADT derived from the ADT base. The function elements or methods specified in the ADT definition above are added to those specified in the ADT base. In sum, the above code includes an ADT specification which is a type of interface specification that can be created within the system.

An interface can be derived from another interface which is then called the base interface of the derived interface. Master interfaces can be derived from another interface, inheriting the interface derived from the operations of each of its base interfaces. Also, the derived interface can declare its own additional operations, although it cannot define operations that have the same name as those inherited from the base interfaces. It should be clear that inheritance only affects the interface level of the class, not the implementation level.

As shown in Figure 6, the system of the present invention includes a segment cocode generation tool 170 that is used to certify the coordination between the client and the server that are not necessarily linked. Instead, the join can occur dynamically at runtime by using the segment code that has been generated for each side of the 172 interface specification. The interface specification 172 is specified language-independent, albeit using the object-oriented paradigm. The segment code generation process guarantees that an application to one of several programming languages ​​is achieved, and in the following sections there is a brief description of how such an application could be made using the C ++ language.

Referring again to FIG. 6, there is illustrated one way in which an interface specification 172 employs the segment generation tool 170 in connection with a group of generated files 174 in the system of the present invention. Figure 6 illustrates, in particular, the general structure of the C ++ application implemented in that language. An interface specification, written in the object-oriented interface description language, ELIN, used in the system of the present invention, is

ES 2 154 647 T3 similar to a class definition used in the C ++ programming language. Likewise, the mechanism for accessing operations through objects is similar to the way in which the programming language

C ++ deals with element virtual functions. Therefore, the C ++ application illustrated in the figure is instructive as to the operation of this aspect of the system of the present invention.

The segment generation tool 170 generates two files for the client side and the server side, one with the suffix “.h” (header) and the other with the suffix “.cc” (code). For the client, the ".h" or header file contains two class definitions. A class is a compatible copy of the corresponding class in the ".h" file or header as far as virtual element functions and case variables are concerned. This ensures compatibility between the client and server and makes it possible for the client to claim objects created by the server. However, this class constructor is private, so the class cannot be used to create automated objects on the stack. The second class is the one to be used on the client, which acts as an intelligent indicator through which the objects created by the server can be accessed.

For the server side, the segment generation tool 170 generates the same two files “.h” (header) and “.cc” (code). The content of the ".h" file consists of a class definition that guarantees compatibility with the client. AND^orThis is the class that is used as a basis for implementation. The implementations can be based directly on the generated class or the generated class can be used as a base from which to derive other classes. The “.cc” file contains a structure, the “creation method” and code that makes the publication of the creation method address. The body of the create method is responsible for creating an object that is compatible with the generated class and returning a pointer to the newly created object.

There are several reasons for generating different but compatible class definitions for the client and server sides instead of a shared class definition. First, it provides different levels of visibility for items on the client and the server. For example, a constructor must be public on the server but should not necessarily be public if it resides on the client. Second, client and server programs can be linked for testing purposes without encountering the name collision problem if different classes are used.

With reference to Figure 7 below, a certain arrangement of graphics is shown illustrating examples of some specifications and class definitions and their relationship to each other used in the system of the present invention. Figure 7 illustrates the logical structure of some generated files and written specifications as it could be implemented in the system of the present invention. At the highest level, the common interface specification 180 defines an “X” ADT and the methods for which the class will accept calls. Logically subordinate to this ADT, at the next level of definition, there is a specification for a user unit 182 of the common interface specification 180 and a specification for a provider unit 184 of the common interface specification 180. The user unit is specified to be an ADT X client while the provider unit is specified to be an ADT X server.

At the next logical level below unit specifications 182 and 184 are the generated class definitions for users and providers respectively. The class definition generated for User X 186 illustrates some user classes defined for both public and private use. The class definition generated for Provider X 188 illustrates some public and private definitions for provider data and functions.

With finally reference to figure 8, an illustrative diagram of how a protocol specification is used for the generation of segment code is shown, which guarantees perfect coordination between two communicating parties. The segment code structure is illustrated in Figure 8 and includes user-written code 200, generated code 202, and core code 204. In modular computerized and distributed systems, one example of which is a telecommunications system, many application-level protocols are used to facilitate communications in and between various portions of the system.

Protocols can be thought of as a collection of contracts between pairs of parties within the system who agree to communicate in a particular way and format. Some protocols can be described as client-server protocols where only one party is an initiator. Other protocols, called peer protocols, allow both parties to initiate communications. In the system of the present invention, unlike other existing systems, the complete agreement or protocol between pairs of parties is specified in a single interface specification that is separate from the specific implementation of the parties. That is, the "contract" between pairs of parties could include

ES 2 154 647 T3 various aspects of the interaction of the pairs of parties, including their respective responsibilities, their respective allowed operations with their data and addresses and the allowed order on how operations can be sent between respective parties of the pair. This implies, therefore, that this single specification can serve as a generic agreement that can be reused for agreements between any pair of parties within the system.

The system of the present invention implements the unique interface / protocol specification for pairs of parts of a communications contract in the proprietary, object-oriented interface description language called ELIN. The specification in such a language of peer-type protocols, for example, includes the following components: (1) a formal grouping of operations in protocols, each protocol having two parts; and (2) a specification of interaction limitations. The peer protocol specification exists separately from implementations that use the protocol to perform their communications. The peer protocol specification is organized according to the following format: (1) protocol name; (2) name of the first party and its list of accepted operations; (3) name of the second party and its list of accepted operations; (4) interaction limitations (optional).

An example of a protocol specification for a pair of parties with interaction limitations is set out below, in co-code. The information included in such a protocol specification can be used for segment code generation:

PROTOCOL CommunicationService;

PARTY DataProducer;

ACCEPTS

StartTransmission,

Terminate Transmission, ReSendData;

END PARTY DataProducer;

PARTY DataConsumer;

ACCEPTS

StringData, IntegerData,

NoMoreDataToSend;

END PARTY DataConsumer;

INTERACTION

STATE START

WHEN StartTransmission THEN Started;

STATE Started

WHEN TerminateTransmission THEN START;

WHEN IntegerData THEN Dataphase;

WHEN StringData THEN Dataphase;

STATE Dataphase

WHEN IntegerData THEN Dataphase;

WHEN StringData THEN Dataphase;

WHEN ResendData THEN Dataphase;

WHEN NoMoreDataToSend THEN DataphaseEnded;

STATE DataphaseEnded

WHEN ResendData THEN ResendOrdered; ;

WHEN TerminateTransmission THEN START;

STATE ResendOrdered

IS 2 154 647 T3

WHEN StringData THEN DataphaseEnded;

WHEN IntegerData THEN DataphaseEnded;

END PROTOCOL CommunicationService;

(ξ) 1992 Telefonaktiebolaget LM Ericsson

The logical structure of a part that communicates within the system is also illustrated in the figure

8. As illustrated in Figure 8, specialized terminology and constructs including ELIN are used to describe communications between processes and processors throughout the system, as well as data types used within the system. Unlike other systems known in the art, this aspect of the system of the present invention provides the ability to locate all interface information for use throughout the system in a single offline location. Furthermore, the protocols used and defined in this aspect of the present invention allow the devices to act as equals, initiating any part of the communications. The parties are not predefined as primary or secondary for communication purposes. This aspect of the system of the present invention allows systems that are developed and operated in different and remote locations to interoperate easily, provided that each is developed using the only specified interfaces. The protocol specifications for this aspect of the system of the present invention are separate and distinct from any application implementations within the system.

As also illustrated in FIG. 8, the user-written code 200 plays a part in the communications protocol that can both send and receive signals, if the signals meet the protocol specification. The data reception tools 206, 208 and 210 handle incoming signals that arrive in the protocol. The data sending procedures 212, 214, 216 include code automatically generated by the segment generation tool to create and send signals to the system following the protocol specification. The actions of receiving the signals 218 and of sending the signals 220 are directed by an interface agent 222, which is part of the generated code 202. This interface specification 222 is the mandatory portion of the generated code 202 and must be present for the interface and protocols to function properly.

The dispatcher 224 is a procedure that is generated by the segment generation tool and that is claimed for each incoming signal to said particular implementation of the specification. The dispatcher 224 receives the signal, decodes the signal, separates the signal identifier from the signal body, and then distributes it as illustrated in 226 to the procedure to be written in this implementation.

Protocol supervisor 228, an optional part of generated code 202, serves to monitor traffic and determine whether the two communicating parties in any given case comply with interface rules when sending or receiving signals. Protocol Police 228 operates as a state machine by overseeing obedience to protocol rules. The logic of the state machine is expressed in the example code indicated above.

In the core code 204, as illustrated in FIG. 8, resides a communications port 230. This communications port 230 is considered by the addressing mechanisms of the system of the present invention as a passive support means. Communications port 230 is not aware of the protocol it is passing through, but serves to facilitate communications. The communications support 232 is the general communications support that exists within the operating system. It can operate between processes within the same processor or between processes on different processors. If I am operating between processors, the communications carrier 232 will constitute a hardware communications link. The mirror image of the entire illustration contained in figure 8 will represent the corresponding activities that take place in the support and operation of a second communicating party within the system.

As illustrated above, the system of the present invention allows the specification of common protocols or interfaces, for use in an entire calculation or data processing system to be generated and stored in a single offline location. In addition, it allows you to create such common specifications using specialized terminology and constructions that allow you to easily and generically formulate and create the specifications in a language-independent way. Such a method increases not only the ease of use, but also the modularity and expandability of the system including these aspects of the present invention. Furthermore, the system of the present invention allows to clone specifications for specific implementations and to be used by some segment generation tools to create specific language implementations. The common interface specifications of this

In addition, they can be used to carry out dynamic linking of software units and change of software execution time by providing flag information regarding published or accessible interfaces and software units.

It is thus considered that the operation and construction of the present invention will be apparent from the above description. Although the depicted and described method, apparatus and system have been characterized as preferred, it will be readily apparent that various changes and modifications can be made therein without departing from the scope of the invention defined in the following claims.