Apparatus and method for providing high performance communication between software processes.

BACKGROUND OF THE INVENTION

The invention belongs to the field of decoupled information exchange between software processes which run on different computers or even on the same computer, the software processes being able to use different formats for data display and data organization or to use the same formats and the same organization, but the formats and organization can be changed later without the need for reprogramming. Also, the software processes use "semantic" information or field name information in such a way that each process can understand and use data obtained from any third-party software process, regardless of the semantic differences or the field name differences. The semantic information is decoupled from the information about the data representation and the data organization.

With the spread of different types of computers and software programs and the constant requirement for different types of computers on which different software programs run to exchange data with one another, a need has arisen for a system by means of which such data exchange can be carried out. Typically, data that needs to be exchanged between software modules that are foreign to one another includes text, data, and graphics. Occasionally, however, there is also a need to exchange digitized voice data or digitized image data or other, more exotic forms of information. These different data types are called "primitives". A software program can only process primitives that are programmed to be understood and edited. If other types of primitives than data are introduced into a software program, this causes errors.

The term "foreign" used in this context means that the software modules or host computers involved in the exchange "speak different languages". For example, the Motorola and Intel microprocessors commonly used in personal computers and workstations use different types of data in that one family of microprocessors places the most important byte in multiple-byte words, while the other family of processors does so most important byte is placed in the last position. Furthermore, text letters are encoded in IBM computers with the EBCDIC code, while text letters in almost all other computers are encoded with the ASCII code. There are also several different ways to represent numbers, including integers, floating point numbers, etc. Furthermore, third-party software modules use different types of data organization and different semantic information, ie how the individual fields in a data record are referred to and what the names mean.

The use of these different formats for the presentation and organization of data means that translations either into a general language or from the language of one computer or processes into the language of another computer or processor must be carried out before meaningful communication is possible. Furthermore, there are many software modules, between which communication is to take place, on different computers which are spatially separated from one another and are only connected to one another via local data networks, wide area networks, gateways, satellites, etc. These different networks have their own very different protocols for communication. It is also, at least in the world of financial services, that different raw data sources, such as Dow Jones News or Telerate, use different data formats and communication protocols that must be understood and followed in order to be able to receive data from these sources.

In complex data situations, such as financial data relating to stocks, bonds, money markets, etc., it is often useful to nest the data. That is, data related to a particular item is often organized as a data set with multiple "fields", each field being associated with a different aspect of the item. It is often useful if a particular field can have subfields, and a particular subfield can have its own subfields, and so on, however many levels may be required. For the purposes of the discussion contained herein, this type of data organization is referred to as "nesting". For the purposes of the discussion contained herein, the field names and their meaning with respect to the subject are referred to as "semantic information". The actual data representation for a specific field, such as floating point numbers, integers, alphanumeric characters, etc., as well as the organization of the data entry in terms of how many fields it has, which fields are primitive fields, which fields only contain data, and which ones Fields are nested fields that contain subfields are referred to as "format" or "type" information for purposes of discussion herein. A field that contains only data (and has no nested subfields) is referred to as a "primitive field", and a field that contains other fields is referred to herein as a "constructed field".

There are two basic types of operations that can occur when exchanging data between software modules. The first type of operation is called a "format operation" and involves converting the format of a record (hereinafter, records can sometimes be referred to as "a form") to another format. An example of such a format operation would be the conversion of data sets with floating point and EBCDIC fields into data sets with a packed representation, as are required for the transmission via a local ETHERNET data network. At the receiving end of the process, another format operation for converting the ETHERNET packet format into integer and ASCII fields can be performed on the receiving process or software module. Another type of operation is referred to below as a "semantic-dependent operation" because it requires access to the semantic information and to the type or format information via a form in order to be able to carry out work on the form, such as, for example, about a specific field of this form, for example deliver the current share price from IBM or yesterday's low from IBM to a software module requesting this information.

Furthermore, in today's environment there are often numerous sources of different data types and / or numerous sources of the same data type, the sources overlapping but using different formats and different communication protocols (or even overlapping with the same format and the same communication protocol). It is advantageous if a software module (software modules can sometimes be referred to below as "applications") are able to obtain information relating to a specific object without knowing the network address of the service that contains the information about it Art provides, and without knowing the details of the particular communication protocol needed to communicate with this source of information.

A need has therefore arisen for a communication system which can create an interface between different software modules, processes and computers for a reliable, meaningful exchange of data while "decoupling" the software modules and computers. "Decoupling" means that the programmer of the software module can access information from other computers or software processes without knowing where the other software modules and computers are in a network, without the format of the forms and data in to know the third-party software without knowing which communication protocols are used to transfer networks between the source process and the determination process, and without knowing which of several raw data sources can deliver the requested data. Furthermore, the term "decoupling" as used herein means that data can be requested at one point in time and delivered at another point in time, and that a process can obtain the desired data from the form instances, with foreign format data and foreign data Semantic data can be obtained by executing the corresponding semantic operations through a communication interface, to extract the requested data from the foreign forms with the extraction process that can be understood by the requesting process.

There are different systems in the prior art which make it possible to exchange information between third-party software modules with a different degree of decoupling. One such type of system is electronic mail software which implements the standards for the exchange of electronic documents (Electronic Document Exchange Standards) including the CCITT standard X.409. The software for electronic mail decouples applications in the sense that format and type data are contained in every instance of a data record or form. However, there are no arrangements for recording or processing semantic information. Semantic operations, such as extracting or translating data based on the name or meaning of the desired field in the foreign data structure, are therefore impossible. Semantically dependent operations are very important for successful communication. Furthermore, there are no provisions in the electronic mail software that can be used to implement object-based addressing, in which the requesting application simply requests information based on the object, without knowing the address of the information source of this type. Furthermore, such software cannot access a service or a network for which no communication protocol has been set up.

Relational database software and data dictionaries are other examples of software systems of the prior art that enable third-party processes to access data together. The disadvantage of this software class is that such programs can only process "flat" tables, data records and fields within data records, but not nested records within records. There are also the above-mentioned disadvantages of electronic post-software also with software for relational databases.

Lum et al., "A General Methodology for Data Conversion and Restructuring," IBM Journal of Research and Development, Issue 20, No. 5, September 1976, pages 483-497, discloses a method and model for data conversion by converting source data into an intermediate form, which is used for translation into the desired target format, the source data, the intermediate form and also a first version of the target data being represented by successive files. The model creates a variety of interfaces, including a source system interface, a target system interface, and an implementation interface, which are used sequentially. The application of the method requires that the users describe the data structures of the linearized input and output files and define the mappings between the source and target data. Two languages, DEFINE and CONVERT, have been defined for this purpose, one of which is used to describe the data and the other to determine the assignment.

In addition, Summers "Local-area distributed systems", IBM Systems Journal, Issue 28, No. 2, 1989, pages 227-240, discloses system software aspects in distributed short-range systems. In particular, this article discusses distributed operating systems in which the basic operating system objects or files are distributed. Such an operating system presents to the user the cluster of computers that make up a distributed system, like an image of a single system, and behaves like a single computer with a single architecture. This article further discusses network operating systems with heterogeneous hardware and operating systems that preserve the changing system images of the computers that act as nodes in the distributed system by maintaining their operating systems and adding a network component that works with them. The article also concerns the client-server model and the object-oriented model. The client-server model affects both distributed operating systems and network operating systems. A client makes a request to a service that is offered somewhere in the system. The system is managed by a server that may be running software on another node. In a distributed operating system, each node is able to play both the role of the client and the role of the server. In other systems, some nodes do not have the ability to act as a server. Even if all nodes have the same basic skills, certain functions can be assigned to some nodes. In the object-oriented model, each system object has a type that defines a group of operations to create and manipulate objects of that type. The implementation of an object is hidden from its users who only see the type definition.

Summers also relates to program interface and naming functions in distributed short-range systems where programs must be able to share files on a file server without changes to the programs. Three approaches for the program interface are discussed. In a first approach, an operating system call is intercepted and converted by subroutines to a request from another node. The conversion can use information that was provided in an earlier command, such as information necessary to map a drive to a remote directory. A second approach is a system interface that can be called from different programming languages. The third approach is a programming language or a programming language extension that is created specifically for distributed programming. The naming function is performed by the naming service or directory service component, which maps the names of the objects, which can be users, workstations, services, and others. The naming service can be provided by a node or by any node for its own objects, or it can be multiplied for some or all of the nodes. The naming service can also determine which objects meet the needs of the user. For example, the user may need a print service that accepts a particular format for desktop publishing. The naming service must then associate objects with their names and their attributes, such as position, accepted formats and speed.

None of these articles relates to a solution as provided by the invention.

SUMMARY OF THE INVENTION

In accordance with the teachings of the invention as set out in the claims, a method and arrangement for transferring data between applications is provided so that a requesting application can request data relating to a particular item without knowing the network address of the server or process where the dates can be found. This form of decoupling takes place through an object-oriented addressing system within the information interface.

Item-oriented addressing is implemented by the communication component of the communication interface of the invention. The communication component receives "subscription" requests from an application specifying the subject through which data is requested. An item mapper module in the communication component receives the request from the application and then searches the item in a database, table, or the like. The database stores "service records" that indicate the various server processes that provide data about various items. The corresponding service set, which identifies the particular server process, which can provide data of the requested type, and the communication protocol (hereinafter sometimes referred to as service discipline), which is used in the communication with the identified server process returned to the object image module.

The item image has access to a variety of communication programs referred to as "service disciplines". Each service discipline implements a predetermined communication protocol that is specific to a server process, network, etc. The item image then calls up the corresponding service discipline identified in the service set.

The service discipline receives the item from the item images and continues to establish communication with the appropriate server process. Subsequently, form instances containing data relating to the item are sent from the server process to the requesting process via the service discipline that established the communication.

The service protocol decoupling is implemented by the process described in the previous section.

The temporary decoupling is implemented in some service disciplines that are aimed at page-oriented server processes, such as Telerate, by accessing real-time databases that store updates in pages for which subscriptions are open.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a block diagram showing the relationships of the various software modules of the communication interface of one embodiment of the invention to client applications and the network.

Figure 2 is an example of a form class definition of the constructed manifold.

Figure 3 is an example of another constructed form class definition.

Figure 4 is an example of a constructed form class definition that contains fields that are self-constructed forms. Therefore, this is an example of nesting.

Figure 5 is an example of three primitive form classes.

Figure 6 is an example of a typical form instance as it is stored in memory.

FIG. 7 shows the division of the semantic data, the format data and the actual or value data between the form class definition and the form instance.

Figure 8 is a flow diagram of processing during a format operation.

Figure 9 is a target format specific table for use in format operations.

Figure 10 is another target format specific table for use in format operations.

Figure 11 is an example of a general format operation conversion table.

Figure 12 is a flow diagram of a typical semantic-dependent operation.

Figures 13A and 13B are a class definition and the class descriptor form in which this class definition is stored.

Figure 14 is a block diagram showing the relationships between the item mapper module and the service discipline modules of the communication component for the requesting application and the item-based addressing service.

Figure 15 shows the relationship of the various modules, libraries and interfaces of an alternative embodiment of the invention for the serving applications.

Figure 16 shows the relationships of the various modules within the communication interface of an alternative embodiment.

DETAILED DESCRIPTION OF THE PREFERRED AND ALTERNATIVE EMBODIMENTS

Referring to Figure 1, there is shown a block diagram of a typical system in which the communication interface of the invention could be incorporated, although a variety of different architectures can benefit from the teachings of the invention. The communication interface of the invention may sometimes be referred to below as the TIB or Teknekron information bus in the description of an alternative embodiment below. The reader is urged at this point to study the glossary of terms included in this description to gain a basic understanding of some of the key terms used herein to describe the invention. The teachings of the invention are contained in several computer program libraries that collectively represent a communication interface with numerous functions that facilitate modularity in client application development and changes in network communication or service communication application protocols by coupling numerous clients in a "decoupled" manner. In the following, the teachings of the invention will be referred to as the communication interface. The term "decoupling" as used herein means that the programmer of the client application need not know details about the communication protocols, the data presentation format and the data record organization of all the other applications or services with which a data exchange is desired. Furthermore, the programmer of the serving application does not need to know the location of the services or servers that provide data about certain items in order to be able to obtain data about those items. The communication interface automatically takes care of all of these details when exchanging data between client applications and between data consumer applications and data delivery services.

The system shown in Figure 1 is a typical network which couples several host computers over a network or through a shared memory. Two hasty computers, 10 and 12, are shown in Figure 1, on which two serving applications 16 and 18 run, although in other embodiments these two serving applications can run on the same computer. These host computers are coupled to one another via a network 14, which can be any known network, such as the ETHERNET communication protocol, the Token Ring protocol, etc. A network for the exchange of data is not necessary for the implementation of the invention, since any method for data exchange known in the prior art is sufficient for the purpose of implementing the invention. Accordingly, shared memory files or shared distributed memory to which hasty computers 10 and 12 have equal access are sufficient as an environment in which the teachings of the invention may be applied.

Each of the haste computers 10 and 12 has random access memory and mass storage, such as related disk or tape drives (not shown). These storage devices contain the various operating system programs, the client application programs and other programs, such as the programs in the libraries, which together form the communication interface through which the hasty computers are able to carry out useful work. The program libraries in the communication interface provide general tools that can be called by client applications to perform certain tasks, such as finding the location of the services that provide data about a particular item and communicating with the Establish service using the appropriate communication protocol.

Each of the hast computers can also be coupled to user interfaces, such as terminals, printers, etc. (not shown).

In the exemplary system shown in FIG. 1, the hasty computer has a client application program 16 stored in its memory. Assume that this client application diagram 16 requires data to be exchanged with another client application program or service 18 that controls the hasty computer 12 to perform useful work. Let us further assume that the haste computers 10 and 12 use different formats for the presentation of data, and that the application programs 18 and 18 also use different formats for the presentation and organization of the data for the data records thereby generated. These data records are mostly referred to as forms below. Let us also assume that the data path 14 between the host camputers 10 and 12 consists of a local ETHERNET data network.

Each of the haste processors 10 and 12 is also programmed with a program library, which together comprise the communication interfaces 20 and 22, respectively. The communication interface programs are either linked to the collated code of the client applications via a linker to generate the runtime cade, or the source code of the communication programs is contained in the source code of the client application diagrams before compilation. In any event, the communication library programs are connected in some way to the client application. Therefore, if two client applications were running on host computer 10, each serving application would be connected to a communication interface module, such as module 20.

The purpose of the communication interface module 20 is to inform the application 16 of the details of the data format and the organization of the data in the forms used by the application 18, the network address of the application 18 and the details of the communication protocol used by the application 18, as well as the details of the transmission to decouple the data format required via the network 14 and the data organization and the communication protocol. Communication interface module 22 serves the same purpose for application 18, relieving it of the need to know many details about application 16 and network 14. The communication interface modules allow for modularity in that changes in client applications, data formats or organizations, host computers or the networks used to connect all of the above devices can be made without these changes to ensure continuous compatibility throughout the system must be continued.

In order to implement some of these functions, the communication interfaces 20 and 22 have access to a network file system 24, which includes an item table 26 and a service table 28, via the network 14. These tables are discussed in more detail with reference to the discussion of object-based addressing below. These tables list the network addresses of the services that offer information about various items.

A typical system model in which the communication interface is used consists of users, user groups, networks, services, service instances (or servers) and objects. Users, represented by human end users, are identified by a user ID. The user ID used in the communication interface is usually the same as the user ID or login ID used by the underlying operating system (not shown). However, this is not necessarily the case. Each user is a member of exactly one group.

Groups consist of users with similar service access patterns and access rights. Access rights to a service or a system object can be assigned at the user level and at the group level. The system administrator is responsible for assigning users to the groups.

The term “network” used here denotes the underlying “transport layer” (as this term is referred to in the ISO network layer model) and all layers below the transport layer in the ISO network model. An application can send or receive data over any network to which its host computer is connected.

The communication interface in accordance with the teachings of the invention, of which blocks 20 and 22 are exemplified in Figure 1, includes for each serving application to which it is connected a communication component 30 and a data exchange component 32. Communication component 30 is a general one Group of communication devices that implement, for example, object-based addressing and / or service-discipline coupling. The communication component is linked to each client application. In addition, each communication component is linked to the standard transport layer protocols, such as TCP / IP, of the network to which it is coupled. Each communication component is linked to several transport layer protocols and can support them. The transport layer of a network does the following: it maps transport layer addresses to network addresses, often uses the transport layer connections on network connections to enable greater throughput, performs error detection and error monitoring of service quality, troubleshooting, segmentation and blocking, flow control of the individual connections of the transport layer to the network and session layers, and accelerated data transmission by. The communication component offers reliable communication protocols for serving applications as well as position transparency and network independence for the client applications.

The data exchange component of the communication interface, of which component 32 is typical, implements a powerful way of representing and transmitting data by encapsulating the data within self-describing data objects called forms. These forms are self-describing in that they contain not only the requested data, but also information about the type or format that describes the representations used for the data and the organization of the form. Because the forms contain this type or format information, format operations to convert a particular form from one format to another can be performed by using only the data in the form itself, without referring to other data used as class descriptors or class definitions that contain semantic information that must be accessed. The term semantic information in class descriptors basically means the names of the form fields.

The ability to perform format operations only on the data contained in the form itself is very important in that it prevents the delays that occur when other data objects need to be accessed and located elsewhere, such as class descriptors. Since format operations alone typically account for 25 to 50% of processing time for serving applications, the use of self-describing objects improves processing by making them faster.

The self-describing forms managed by the data exchange component also enable the implementation of general tools for data manipulation and data display. Such tools include communication tools for sending forms between processes in a machine-independent format. Furthermore, because self-describing forms can be expanded, that is, their organization can be changed or expanded without adversely affecting the client applications using these forms, making such forms extremely easy for modular application development.

Because the bottom layer of the communication interface is linked to the transport layer of the ISO model, and since the communication component 30 includes multiple service disciplines and multiple transport layer protocols to support multiple networks, it is possible to write application oriented protocols that are transparent from switch from one network to another, should a network ever fail.

A "service" represents a meaningful group of functions that are exported from an application for use by its serving applications. Examples of services are retrieval services for historical innovations, such as Dow Jones New, Quotron Datafeed and a Trade Ticket Router. Applications typically export only one service, although exporting many different services is also possible.

A "service instance" is an application or a process that is able to provide the respective service. For a given service, several "instances" can provide the service at the same time, thereby improving the throughput of the service or enabling fault tolerance.

Although networks, services and servers are traditional components that are known in the prior art, distributed systems of the prior art do not know the concept of an object space or of data independence through the self-description of nested data objects. The object space supports a form of decoupling, which is called object-based addressing. The self-description of data objects that can be nested over several levels is new. Decoupling olient applications from the various communication protocols and data formats that are prevalent in other parts of the network is also very useful.

The address space used to implement item-based addressing consists of a hierarchical group of item categories. In the preferred embodiment, a four-level object space hierarchy is used. An example of a typical item is "equity.ibm.composite.trade.". The serving applications coupled to the communication interface have the freedom and responsibility to establish conventions regarding the use and interpretation of the various object categories.

Each item is typically associated with one or more services that provide data about that item in records that are stored in the system files. Since each service is assigned a service discipline in the communication components of the communication interface, ie the communication protocol or procedure required to communicate with the service allows the client applications to request data about a particular item without knowing where to find the service instances that provide the data about that item on the network by creating subscription requests specifying only the item without the network address of the service that provides information about that item. The subscription requirements are translated by the communication interface into a current communication connection with one or more service instances, which offer information about this object.

A group of item categories is called an item domain. Multiple subject domains are allowed. Each domain can define domain-specific item coding functions for an effective display of items in message headers.

DATA INDEPENDENCE: The data exchange component

The overarching purpose of the data exchange component, such as component 32 in FIG. 1 of the communication interface, is to decouple the serving applications, such as application 16, from the details of the data display, the data structuring and the data semantics.

Referring to FIG. 2, an example of a class definition for a constructed class is shown, which defines both format and semantic information which are common to all form instances of this class. In the example selected, the form class is named Player_Name and has a class identifier of 1000. The form instances of this class 1000 contain data relating to the names, ages and world rankings of tennis players. Each class definition is assigned a class number called a class identifier, which identifies this class in a unique way.

The class definition creates a list of fields by name and the data representation of the field content. Each field contains a form, and each form can be either primitive or constructed. Primitive class forms store current data, while constructed class forms have fields that contain other forms, which can be either primitive or constructed. In the class definition of FIG. 2 there are four fields with the designation rating (order), age (age), last name (family name) and first name (first name). Each field contains a primitive class form, so that every field in the form instances of this class contains current data. For example, the Rating field will always contain a primitive form of class 11. Class 11 is a primitive class called Floating_Point (floating point), which describes a floating point data representation for the content of this field. The primitive class definition for the class Floating_Point, class 11, is contained in FIG. 5. The class definition of the primitive class 11 contains the class name, Floating_Point, which uniquely identifies the class (the class number, in this example class 11, also uniquely identifies the class) and a description of the data representation of the individual data value. The description of the individual data value uses known, predefined system data types which are understood both by the host computer and by the application which deals with this class of forms.

Typical descriptions for the data display of current data values ​​include, among others, integer, floating point, ASCI character strings or EBCDIC character strings, etc. In the case of primitive class 11, the description of the data value is Floating_Point_1 / 1, an arbitrarily chosen notation that indicates that the data that is stored in form instances of this primitive class is floating-point data with a total of two digits , one of which is to the right of the decimal point.

Let's go back to the discussion of the Player_Name class definition of Figure 2, where the second field is called Age. This field contains forms of the primitive class with the designation integer (integer), which is connected to the class number 12 and is defined in FIG. 5. According to the class definition of FIG. 5, the integer form class, class 12, has the data representation description Integer_3, which means that the field contains three-digit integer data. The last two fields of the definition of class 1000 in Figure 2 are Last_Name and First_Name (family name and first name). Both of these fields contain primitive forms of a class called String_Twenty_ASCII, class 10. The class definition of class 10 is shown in Figure 5 and specifies that form instances of this class contain ASCII character strings that are 20 characters long.

FIG. 3 shows another constructed class definition with the name Player_Address (player address), class 1001. Form instances of this class each contain three fields with the names Street, City and State (street, city and country). Each of these three fields contains primitive forms of a class called String_20_ASCII, class 10. Again, the class definition for class 10 is shown in FIG. 5 and defines a data representation using 20-character ASCII chains.

An example of the nesting of constructed class forms is shown in Figure 4. Figure 4 is a class definition for form instances in the class called Tournament_Entry (class entry) class 1002. Each farm instance in this class contains three fields with the names Tournament_Name, Player and Address (tournament name, player and address). The Taurnament_Name field contains forms of the primitive class called String_Twenty_ASCII, class 10, which is defined in FIG. 5. The field with the name Player contains instances of constructed forms of the class with the name Player_Name, class 1000, which has the format and semantic properties shown in FIG. The field named Address contains instances of the constructed form of constructed forms of the constructed class with the name Player_Address, class 1001, which has the format and semantic characteristics specified in the class definition of FIG. 3.

The class definition of Figure 4 shows how form nesting can be done by making each field of a form itself a form and each form either being primitive and having only one field or being constructed and having multiple fields. In other words, instances of a form can have as many fields as necessary, and each field can have as many subfields as necessary. Furthermore, each subfield has as many subfields as necessary. This nesting can be continued over any number of levels. This data structure makes it possible for any complexity to be displayed and edited in a simple manner.

Referring to FIG. 6, a form instance of the form class with the designation "tournament_Entry" (tournament entry), class 1002, is shown as it is stored as an object in the memory. The data block 38 contains the constructed class number 1002, which indicates that this is a form instance of the constructed class with the designation Tournament_Enty. Data block 40 indicates that this form class has three fields. These three fields have the data blocks shown at 42, 44 and 46, which contain the class numbers of the forms in these fields. The data block at 42 indicates that the first field contains a class form 10 as shown in Figure 5. A class 10 form is a primitive form that contains a 20 character string of ASCII characters as defined in the class definition for class 10 in FIG. 5. The current string of ASCII characters for this particular instance of this form is shown at 48, indicating that this is a tournament entry for the US Open tennis tournament. The data block at 44 indicates that the second field contains a form that is an instance of a constructed class 1000 form. A reference to this class definition shows that this class is called Player_Name. Data block 50 shows that this class of constructed form contains four subfields. These fields contain forms of the classes recorded in the data blocks shown at 52, 54, 56 and 58. These fields would be subfields of field 44. The first subfield has a data block at 52 which indicates that this subfield contains a form of primitive class 11. This form class is defined in Figure 5 so that it contains a two-digit floating point number with one decimal place. The current data for this instance of the form is shown at 60 and indicates that this player has an NTRP rating of 3.5. The second subfield has a data block at 54 which indicates that this subfield contains a form of primitive class 12. The class definition for this class indicates that the class is called Integer and contains integer data (Integer data). The class definition for class 1000 shown in Figure 2 indicates that this integer data, shown at block 62, indicates the age of the player. Note that the semantic data of the class definition regarding the field names is not saved in the form instance. Only format or type information is stored in the form instance in the form of the class identifier for each field.

The third subfield has a data block at 56 which indicates that this subfield contains a form of primitive class 10 called String_20_ASCII. This subfield corresponds to the field Last_Name (family name) in the form of class Player_Name, class 1000, which is shown in FIG. 2. The class definition of primitive class 10 specifies that instances of this primitive class contain a 20-character ASCII text string. This text string defines the player's family name. In the instance shown in Figure 6, the player's family name is Blackett, as shown at 64.

The last subfield has a data block at 58, which indicates that the field contains a primitive form of primitive class 10, which is a 20 character ASCII text string. This subfield is defined in the class definition of class 1000 so that it contains the first name of the player. This ASCII text string is shown at 66.

The third field in the instance of the class 1002 form has a data block at 46 which indicates that this field contains a constructed form of the constructed class 1001. The class definition for this class is shown in Figure 3 and indicates that the class has the name Player_Address. The data block at 68 indicates that this field has three subfields that contain forms of the class numbers indicated at 70, 72 and 74. These subfields each contain forms of the primitive class 10 shown in FIG. 5. Each of these three subfields therefore contains a 20 character ASCII text string. The content of these three fields is defined in the class definition for class 1001 and bears the name street, city or country for the address of the player named in field 44. These 3-character text strings are shown at 76, 78 and 80 respectively.

FIG. 7 shows a division of the semantic information, the format information and the current data between the class definition and the instances of the forms of this class. The field name and format or type information, as represented by box 82, are stored in the class definition. The format or type information (in the form of the class identifier) ​​and the current data or field values ​​are stored in the instance of the form, as represented by box 72. For example, in the instance of the form of the Tournament_Entry class, class 1002, shown in Figure 6, the format data for the first field is the data stored in block 42, while the current data for the first Field is the data shown at block 48. In essence, the class number or class identifier is equated by the communication interface to the description for the data type in the form instances of that primitive class. The communication interface can thus perform format operations on instances of a specific form by using only the format data stored in the form instance itself, without having to access the class definition. This speeds up format operations by eliminating the steps necessary to access a class definition, including network access and / or disk access, which would slow down the operation significantly. Since format-like operations comprise the set of all operations for the exchange of data between external processes, the data structure and the program library for processing the data structure defined therein enormously increase the performance of the data exchange between external processes and external computers. For example, suppose that the instance of the form shown in Figure 6 was created by a process running on a Digital Equipment Corporation (DEC) computer and the text is therefore expressed in ASCII characters. Let us further assume that this form must be sent to a process running on an IBM computer where strings are expressed in the EBCDIC code. Let us also assume that these two computers are coupled to one another via a local data network using an ETHERNET communication protocol.

In order to be able to carry out this transfer, several format operations would have to be carried out. These format operations can best be understood by referring to FIG. 1, assuming that the DEC computer is host 1 shown at 10 and the IBM computer is host 2 shown at 12.

The first format operation to transfer the instance of the form shown in FIG. 6 from application 16 to application 18 would be a conversion from the format shown in FIG. 6 to a packetized format suitable for transmission over the network 14. Networks typically work with messages that are composed of data blocks consisting of a plurality of bytes that are packetized end-to-end and preceded by multiple bytes of header information that contain various information such as message length, destination address, source address, and and so on, and which also contain error correction code bits appended to the end of the message. Sometimes delimiters are also used to mark the beginning and end of the current data block.

The second format operation that would have to be performed in this hypothetical transmission would be a conversion from the packetized format needed for transmission over network 14 to the format used by application 18 and host computer 12.

Format operations are performed by the form manager modules of the communication interface. For example, the first format operation on this hypothetical transfer would be performed by the form manager module 86 in Figure 1, while the second format operation on the hypothetical transfer would be performed by the form manager module in the data exchange component 88.

Figure 8 shows a flow diagram of the operations performed by the form manager modules when the format operations are performed. Further details regarding the various functional capabilities of the routines in the form manager modules of the communication interface are contained in the functional description of the various library routines of the communication interface contained herein. The process of Figure 8 is implemented by the software programs in the form manager modules of the data exchange components in the communication interface in accordance with the teachings of the invention. The first step is to get a format conversion call either from the application or from another module in the communication interface. This process is symbolized by block 90 and paths 92 and 94 in Figure 1. The same type call can be made from the application 18 or the communication component 96 for the host computer 12 in Figure 1 to the form manager module in the data exchange component 88 since this is a standard function or "standard tool" provided by the communication interface the invention is made available to all serving applications. Each serving application is linked to a communication interface, such as interface 20 in FIG. 1.

Typically, format conversion calls from the communication components, such as modules 30 and 96 in FIG. 1, to the form manager module are made by a service discipline module, which has the task of sending a format 1 form to a third-party application that uses format 2 , Another likely scenario for a format conversion call from another module in the communication interface would be if a service discipline received a form from another application or service that is in a foreign format and that is in the format of the serving application must be converted.

Parameters that are created by the form manager are assigned to the format conversion call. These parameters determine the "from" format and the "to" or "target" format.

Block 98 represents the process of accessing an appropriate target format specific table for the specified conversion, ie the "from" format and the "to" format specified have a dedicated table that provides details of the appropriate target format class for each primitive "from" -Format class for performing the conversion contains. There are two tables that are sequentially accessed during each format conversion operation in the preferred embodiment. In alternative embodiments, these two tables can be combined. Examples of the two tables used in the preferred embodiment are shown in Figures 9, 10 and 11. Figure 9 shows a specific format conversion table for converting from DEC machine format to X.409 format. Figure 10 shows a format-specific format conversion table for converting from the X.409 format to the IBM machine format. Figure 11 shows a general conversion procedure table which defines the name of the conversion program in the communication interface library which performs the respective conversion for each "from" - "to" format pair.

The tables of Figures 9 and 10 may not be the only tables needed to submit a form from application 16 to application 18 in Figure 1. Additional format-specific tables may be required to convert application 16 format to DEC machine format and to convert IBM machine format to application 18 format. However, the general concept of the format conversion process implemented by the form manager modules of the communication interface can be explained with reference to FIGS. 9, 10 and 11.

Assume that the first conversion required when sending a form from application 16 to application 18 is a conversion from the DEC machine format to a packetized format suitable for transmission over an ETHERNET network. In this case, the format conversion call received in step 90 would call processing by a software routine in the form manager module that would perform the process symbolized by block 98.

In this hypothetical example, the appropriate format-specific table that this routine should access would be determined by the "from" and "to" format parameters in the original format conversion call received by block 90. This would lead to access to the table shown in FIG. 9. The format conversion call would also identify the address of the form to be converted.

The next step is symbolized by block 100. This step involves accessing the form identified in the original format conversion call and searching the form to find the first field that contains a primitive form class. In other words, the record is searched until a field is found in which current data is stored and not another constructed form that has subfields.

In the case of the form shown in Figure 6, the first field in which a primitive form class is stored is field 42. The "from" column of the table of Figure 9 would be searched using class number 10 until the corresponding entry was found , In this case, the entry for a "from" class of 10 indicates that the format specified in the class definition for primitive class 25 is the "to" format. This lookup of the "to" format with the aid of the "from" format is symbolized by block 102 in FIG. The table shown in FIG. 9 can be "hard-wired" with the code of the routine which carries out the step symbolized by block 102.

Alternatively, the table of FIG. 9 may be a database or other file that is stored somewhere in the network file system 24 of FIG. 1. In such a case, the routine that performs step 102 in FIG. 8 would know the network address and file name for the file to be accessed to access the table of FIG. 9.

Next, the process symbolized by block 104 in Figure 8 is performed by accessing the general conversion procedure table shown in Figure 11. This is a table that identifies the conversion program in the Form Manager that does the actual work of converting one primitive form class to another primitive form class. This table is organized so that it has a single entry for each "from" - "to" format pair. Each entry in the table for a "from" - "to" pair includes the name of the conversion routine that does the actual conversion work. The process symbolized by block 104 includes the steps of taking the "from" - "to" pair determined by accessing the format-specific conversion table in step 102 and searching the entries of the general conversion procedure table until an entry with one "from" - "to" equivalent is found. In this case, the third entry from above in the table of FIG. 11 corresponds to the "from" - "to" format pair which is found when FIG. 9 is accessed. This entry is read and it is determined that the name of the routine which is to perform this conversion is ASCII_ETHER. (In many embodiments, the routine's memory address, rather than the name, would be stored in the table.)

Block 106 in FIG. 8 symbolizes the process of calling the conversion program identified by step 104 and executing this conversion routine to exchange the contents of the field selected in step 100 with the "to" or target format identified in step 102. In the hypothetical example, the routine ASCI-ETHER would be called and executed by step 106. The call to this routine would provide the current data stored in the field selected by the process of step 100, ie field 42 of the instance of a form shown in Figure 6, so that the text string "US Open" in a packed ETHERNET format would be converted.

Next, the test is performed at block 108 to determine if all fields containing primitive form classes have been processed. If so, the format conversion of the form is completed and the format conversion routine is terminated, as symbolized by block 110.

If further fields that contain primitive form classes need to be processed, the process symbolized by block 112 is performed. This process looks for the next field that contains a primitive form class.

The steps symbolized by blocks 102, 104, 106 and 108 are then carried out until all fields which contain primitive form classes have been converted into the corresponding “to” format.

As mentioned above, the process of searching for fields containing primitive form classes is performed sequentially through the form to be converted. If the next field found contains a form of a constructed class, this form class must be searched for itself until the first field contained in it is found with a primitive form class. This process continues through all nesting levels for all fields until all fields have been processed and all data stored in the form has been converted to the appropriate format. As an example of how this works, the process symbolized by block 112 in FIG. 6 would next find field 44 in form 6 after processing the first field 42 (fields are referenced by the data block that contains the class identifier for this in block 6) Field stored form contains, although the field contains both the class identifier and the current data or the fields and subfields of the form stored in this field). It should be noted that in the respective form class, which is represented by FIG. 6, the second field 44 contains a constructed form which is composed of several subfields. Processing would then access the constructed class 1000 form stored by the second field and continued through this constructed form in turn until it found the first field of it that contained a primitive class form. In the hypothetical example of FIG. 6, the first field would be the subfield which is designated by class number 11 at 52. The process symbolized by block 102 would then search class 11 in the "from" column in the table of Figure 9 and determine that the target format be determined by the class definition of primitive class 15. This "from" - "to" pair 11-15 would then be compared to the entries in the table of Figure 11 to find a corresponding entry. Thereafter, the process from block 106 in Figure 8 would execute the conversion program designated Float1_ETHER to convert the data block at 60 in Figure 6 to the appropriate packetized ETHERNET format. The process would then go through all levels of nesting.

Figure 12 shows a flow diagram for a typical semantically dependent operation. Semantically dependent operations enable decoupling of applications by allowing an application to receive the data of a particular field of a form instance that was created by a foreign application, as long as the field name is known and the address of the form instance is known. The communication interface according to the teachings of the invention receives requests for semantically dependent operation from the serving applications in the form of Get_Field calls (Get Field) in the preferred embodiment, where all processes use the same field names for data fields that have the same meaning ( regardless of the organization of the form or the data representation of the field in the form created by the external process). In alternative embodiments, an alias or synonym table or a database is used. In such embodiments, the Get_Field call is used to access the synonym table in the class manager and to search for all synonyms in the requested field name. All field names that are synonyms of the requested field name are returned. The class manager then searches the class definition for a match either with the requested field name or one of the synonyms and fetches the field with the matching field name.

With regard to the preferred embodiment, such Get_Field calls can be made directly from client applications to form class manager modules, such as module 122 in Figure 1, or they can be made to the communication components or form manager modules and transferred from these modules to the form class manager. The form class manager creates, destroys, manipulates, saves and reads form class definitions.

A Get_Field call provides the form class manager with the address of the form in question and the name of the field in the corresponding form. Receiving such a request is symbolized by block 120 in FIG. 12. Block 120 also symbolizes the process by which the class manager either defines the class programmatically, ie by the requesting application, or by communicating the position of a database in which the class definitions including the class definition for the corresponding form can be found. Several databases or files in which class definitions are stored can be present in the network file system 24 in FIG. 1. It is only necessary to inform the form class manager of the position of the respective file in which the class definition for the corresponding form is stored.

Next, as symbolized by block 122, the class manager module accesses the class definition for the form class identified in the original call.

The class manager then searches the class definition field names to find a match for the field name specified in the original call. This process is symbolized by block 124.

After the corresponding field has been found in the class definition, the class manager returns a relative address pointer to the corresponding field in the instances of the forms of this class. This process is symbolized by block 126 in FIG. The relative address pointer returned by the class manager is best understood by referring to Figures 2, 4 and 6. Assume that the application that made the Get_Field call would be interested in determining the age of a particular player. The Get_Field request would identify the address for the instance of the class 1002 form for the player Blackett, as shown in Figure 6. The Get_Field request would also contain the name of the corresponding field, namely "Age". The class manager would then access the instance of the corresponding form and read the class number which identifies the respective class descriptor or the class definition which is valid for this class of forms. The class manager would then access the class descriptor for class 1002 and find a class definition, as shown in Figure 4. The class manager would then access the class definitions for the individual fields of class definition 1002 and compare the field name in the original Get_Field request with the field names in the various class definitions that make up the class definition for class 1002. In other words, the class manager would compare the names of the fields in the class definitions for classes 10, 1000 and 1001 with the corresponding field name "Age". As can be seen in FIG. 2, a correspondence would be found in the class definition for class 1000. For the corresponding data record format, which is shown in FIG. 6, the "age" field would be data block 62, which is the tenth data block from the beginning of the data record. The class manager would then return a relative address pointer of 10 in black 126 of Figure 12. This relative address pointer is returned to the serving application that made the original Get_Field call. Then the serving application returns a Get_Data call to the form manager module and provides the form manager module with the relative address of the desired field in the corresponding instance of the corresponding form. The form manager module must also know the address of the instance of the desired form that it already had when the original Get_File call came through the form manager module and was transferred to the form class manager. If the form manager module does not know the address of the corresponding instance of the desired form, the form manager requests this from the serving application. After receiving the Get_Call call and receiving the relative address and the address of the instance of the desired form, the form manager accesses this instance of the form and the requested data and returns it to the serving application. This process of receiving the Get_Data call and returning the corresponding data is symbolized by block 128 in FIG.

DATA DISTRIBUTION AND SERVICE PROTOCOL ISOLATION BY OBJECT-BASED ADDRESSING AND USE OF THE SERVICE DISCIPLINE PROTOCOL LAYERS

FIG. 14 shows a block diagram of the various software modules, files, networks and computers that work together to implement two important forms of decoupling. These forms of decoupling are data distribution decoupling and service protocol decoupling. Data distribution decoupling means that the serving applications are relieved of the need to know the network addresses of servers that offer the desired services. Therefore, if a particular application needs to know information provided, for example, by the Dow Jones News Service, the serving application does not need to know which servers and which locations offer data from the original data supply of the Dow Jones News Service.

The service protocol decoupling means that the client applications do not have to know the respective communication protocols which are necessary to cross all network protocol layers and the communication protocols used by the servers, services or other applications with which data exchange is desired.

The data distribution decoupling is implemented by the communication module 30 in FIG. 14. The communication component is composed of a library of software routines that implement an item image 160 and a plurality of service disciplines to implement item-based addressing. The service disciplines 182, 184 and 186 are exemplary of the service disciplines involved in object-based addressing.

Item-based addressing allows services to be modified or replaced with alternative services that provide equivalent information without affecting information consumers. This decoupling of information consumers from information providers enables a higher degree of modularization and flexibility than conventional service-oriented models.

Item-based addressing begins with a subscription call 188 to the item image 180 by a serving application 113, which runs on a host computer 10. The subscription call is a request for information related to a particular item. Let's say the item in question was equity.IBM.news. This subscription call would pass two parameters to the object mapper 180. One of these parameters would be equity.IBM.news. The other parameter would be the name of a callback routine in the serving application 16 to which data regarding the item should be forwarded. The subscription call to item images 180 is a standard procedure call.

The purpose of the object mapper is to determine the network address for services that provide information about different objects and to call the appropriate service discipline routines to establish communication with those services. In order to find the locations of the services that offer information regarding the item contained in the subscription call, the item image 80 sends a request, symbolized by the line 190, to a directory services component 192. The directory services component is a separate process that runs on a computer that is coupled to the network 14 and can actually run on a separate computer or on the host computer 10 itself. The directory service routine maintains a database or table of records, referred to as service records, which specify which services provide information about what items, where those services are located, and which service disciplines of these services for those Communication. Directory services component 192 receives the request forwarded by item imager 180 and uses the item parameter of that request to search its tables for a match. That is, the directory services component 192 searches its service records until a service record is found that indicates a particular service or services that provide information about the desired item. This service record is then returned to the item image, as symbolized by line 194. The directory services component can find multiple matches if multiple services provide information related to the desired item.

The service record returned for the item image or the service records symbolized by line 194 contain many fields. Two fields required in the service records are the name of the service that provides information about the desired item and the name of the service discipline used by that service. Other optional fields that can be provided are the name of the server on which the said service is running and a position in the network of that server.

In general, the directory services component provides all of the service records for which an item map is available, since there may not be a complete overlap of information provided by all services about the item. Furthermore, each service runs on a separate server, which can be connected to the client application via the same network, but does not have to be connected. When there is such a variety of network paths and services, returning all service records with match in the subject area to the subject image allows the communication interface to change networks or servers or services should one or more of these components fail.

As mentioned above, the item imager 180 establishes communication with all those services that provide information about the desired item. When multiple service records are returned from directory services module 192, object mapper 160 establishes communication with all of these services.

Upon receipt of the service data records, the item image calls up each identified service discipline and forwards the item and the corresponding service data record corresponding to this service discipline. Although only three service disciplines 182, 184 and 186 are shown in Figure 14, there may be far more than three in an actual system.

If the directory services component 192 does not exist or does not find a match, no service records are returned to the object image 180. In such a case, the item image calls a standard service discipline and forwards it and the item and a null record.

Each service discipline is a software module that contains tailor-made code that is optimized for communication with the corresponding service that is related to that service discipline.

Each service discipline invoked by the object mapper 120 examines the service records that are forwarded to it and determines the location of the service with which to communicate. Assume that in the hypothetical example discussed, only one service record is returned from directory services module 192, and that this service record identifies the Dow Jones News Service running on server 196 and further service discipline A identified at 182 as the service discipline appropriate for communication with the Dow Jones News Service on server 196. Service discipline A then forwards a request message to server 196, as identified by line 198. This request message forwards the item to the service and can forward all or part of the service record.

Server 196 processes the request header and determines whether it can actually provide information about the desired item. He then sends back a reply message, which is symbolized by line 200.

After communication is established in this manner, the service continuously sends all information components belonging to the requested object to the corresponding service discipline, as symbolized by path 202. In the example selected here, the service running on server 196 filters out only those new components that belong to IBM in order to send them to the service discipline at 182.

Each service discipline can behave differently. For example, service discipline B may behave as follows at 184. The service running on the server 196 can broadcast all information components of the Dow Jones News Service on the network 14. All instances of service discipline B can monitor the network and filter out only those messages that belong to the desired object. Many different communication protocols are possible.

Service discipline A at 182 receives the data that is being transmitted by the service and forwards it to said callback routine 204 in the serving application 16. (From the image 180, the name of the callback routine was forwarded to the service discipline 182 in the original message, which is symbolized by the line 181.) The called callback routine then carries out everything for which it was programmed with the information about the desired object ,

In this way, data continues to flow to the aforementioned callback routine 204 until the serving application 16 expressly issues a release command to the object image 180. Item mapper 160 records all existing subscriptions and compares the revoke command against the various active subscriptions. If a match is found, the appropriate service discipline is notified of the cancel request, and that service discipline then sends a cancel message to the appropriate server. The service then ends the transfer of further data regarding this item to the service discipline that sent the cancel request.

It is also possible that a service discipline is free-standing and not linked to an object image. In this case, the service discipline or disciplines are linked directly to the application, and subscription calls are sent directly to the service discipline. The difference is that the application needs to know the name of the service that provides the data you want and the service discipline that is used to access the service. A database or directory services table is then accessed to find the network address of the identified service and communication is established as described above. While this software architecture does not provide data distribution decoupling, it does provide service protocol decoupling, relieving the application of the need to know details about the communication interface with the service with which data is to be exchanged.

Further details on the item-based subscription service addressing enabled by the communication interface in accordance with the teachings of the invention are provided in section 4 of the communication interface description below. The preferred embodiment of the communication interface of the invention is constructed in accordance with this description.

A current subscription function in the preferred embodiment is accomplished by executing the TIB_Consume_Create library routine described in section 4 of the description. The call to TIB_Consume_Create includes a property list of the parameters that are passed there, one of which is the identity of the callback routine described as the My_Message_Handler in Section 4 of the description.

In the description, the item-based addressing of the subscription service function is referred to as TIBINFO. The TIBINFO interface consists of two libraries. The first library is called TIBINFO-CONSUME for data consumers. The second library is called TIBINFO-PUBLISH for data providers. One application includes one library or the other, or both. It depends on whether she is a consumer or a supplier or both. An application can be a consumer and a supplier at the same time.

FIG. 15 shows a block diagram of the relationship of the communication interface in accordance with the teachings of the invention to applications and the network connecting these applications. Blocks with the same reference designation as blocks in FIG. 1 have similar functional properties to those blocks in FIG. 1.

The block diagram in Figure 15 shows the process architecture of the preferred embodiment. The software architecture, which corresponds to the architecture shown in FIG. 15, is shown in block form in FIG.

Referring to Figure 15, the communication component 30 of Figure 1 is shown as two separate function blocks 30A and 308 in Figure 15. That is, the functions of the communication component 30 in FIG. 1 are divided between two functional blocks in the process architecture of FIG. A communication library 30A is associated with each serving application 16, and a daemon process 308 for communication at the last part is associated with network 14 and communication library 30A. There is typically one communication daemon per host processor. This host processor is shown at 230 in FIG. 15, but is not present in FIG. 16. Note that, in contrast to the situation in FIG. 1, the serving applications 16 and 18 in FIG. 15 both run on the same host processor 230. Each serving application is linked to its own copies of the various library programs in communication libraries 30A and 96 and the forms library of data exchange components 32 and 88. These linked program libraries share the 30B communication daemon.

The communication daemons in the different host processors work together to ensure reliable and efficient communication between the machines. For item-addressed data, the daemons support efficient transmission by providing low-level system support for filtering messages by items.

The communication library 30A performs numerous functions that are assigned to the individual application-oriented communication sequences. For example, the communication library translates items into efficient message headers that are more compact and easier to check than ASCII item values. The communication library also maps service requests into requests that target specific service instances and monitors the status of those instances.

The data exchange component 32 of the communication interface in accordance with the teachings of the invention is implemented as a library called a "form library". This library is linked to the client application and offers all core functions of the data exchange component. The form library can be linked independently of the communication library and does not require the communication daemon 308 for its operation.

The communication daemon performs two tasks. In the object-based addressing mode described above, in which the service instance has been informed of the object and the network address to which data relating to this object is to be sent, the communication daemon 308 has the network address to which the data is to be sent. This data is then forwarded from the daemon to the communication library, which is linked to the client application, which in turn forwards the data to the corresponding callback routine in the client application. In another mode, the communication daemon filters the data arriving from the network 14 for the item when the service entities that provide data are in a broadcast mode (general delivery) and data about many different items to all daemons broadcast in the network.

Blocks 231, 233 and 235 in Figure 15 represent the interface functions implemented by the programs in the communication library 30A and the form library 32. The TIBINFO interface 233 offers item-based addressing services via the communication paradigm, which is known as a subscription call. In this paradigm, a data consumer subscribes to a service or item and then receives a continuous stream of data about the service or item until the consumer explicitly ends the subscription (or an error occurs). A subscription paradigm is very well suited for real-time applications that monitor dynamically changing values, such as stock prices. In contrast, the more traditional request / response communication is poorly suited for such real-time applications, since these require data consumers to "query" data providers in order to be informed of changes.

The interface 235 defines a programmatic interface to the protocol group and to the service from which the market data subscription service (MDSS) subcomponent 234 in FIG. 16 is composed. This service discipline will be described in detail later. The RMDP interface 235 is a service address protocol in that it requires the client application to know the name of the service with which data is to be exchanged.

The software architecture of the system is shown in FIG. A distributed communication component 232 comprises various protocol engines 237, 239 and 241. A protocol engine encapsulates a communication protocol that represents an interface between service discipline protocols and the respective network protocols. Distributed component 232 is coupled to a variety of service disciplines 234, 236 and 238. The service discipline 234 exhibits the behavior which is referred to as market data subscription service in the following. This protocol enables data consumers to receive a continuous data stream with tolerance to individual data sources. This protocol group provides mechanisms for the management of the load balancing and authorization policy.

The service discipline, called MSA, 236, has a different behavior. The service discipline, designated SASSII, 238, supports item-based address subscription services as described above.

The software architecture illustrated in Figures 15 and 16 represents an alternative embodiment to the embodiment described above with reference to Figures 1-14.

Class manager modules normally store the class definitions required for the semantically dependent operations in the RAM of the host machine as class descriptors. Class definitions are the description of the semantic information and the format information that define a class. Class descriptors are storage objects that embody the class definition. Class descriptors are stored in at least two ways. In the random access memory (PAM), class descriptors are stored as forms in a native format of the machine and the serving application that generated the class definition. Descriptors stored on disk or tape are stored as text in ASCII strings.

When asked to perform a semantically dependent operation, the class manager module searches its class descriptors stored in the PAM and determines whether the appropriate class descriptor is present. If so, the class descriptor is used to perform the operation described above with reference to Figure 12. If the appropriate class descriptor is not available, the class manager must obtain it. This is done by searching known files of the class descriptors that are stored in the system files 24 in FIG. 1, or by making a request to the third-party application that created the class definition to send the class definition to the requesting module. The locations of the files that store class descriptors are known to the client applications, and the class manager modules also store these addresses. The request for a semantically dependent operation often contains the address of the file in which the corresponding class descriptor can be found. If the request does not contain such an address, the class manager searches its own stored class descriptors and the files identified in records stored by the class manager that indicate the locations of system class descriptor files.

When the class manager requests the class descriptor from the foreign application that created it, the foreign application sends a request to its class manager to send the appropriate class descriptor over the network to the requesting class manager or module. The class descriptor is then sent like any other form and used by the requesting class manager to perform the requested semantically dependent operation.

If the class manager needs to access a file to obtain a class descriptor, it must also convert the packed ASCII representation in which the class descriptors are stored on disk or tape to the format of a native form for storage in RAM. This is done by breaking down the ASCII text in order to separate the different field names and descriptions of the field contents and the class numbers.

Figures 13A and 13B show a class definition and the structure and organization of a class descriptor for the class definition of Figure 13A and storage in RAM as a form. The class definition given in FIG. 13A is called Person_Class and has only two fields, namely Last and First. Each of these fields is set to store a 20-character ASCII text string.

Figure 13B has a data block 140 containing 1021, which indicates that the form is a constructed form with class number 1021. The data block at 142 indicates that the form has 3 fields. The first field contains a primitive class that is specified to contain an ASCII text string that stores the class name, Person_Class, in data block 146. The second field is a primitive class to which number 2, data block 148, is assigned, which is determined to contain a Boolean, data block 150. Semantically, the second field in the class definition for class 1021 is defined to determine whether the form class is primitive (true) or constructed (false). In this case, data block 150 is incorrect, indicating that class 1021 is a constructed class. The third field is a constructed class to which class number 112 is assigned, as represented by data block 152. The class definition for class 1021 defines the third field as a constructed class form that provides the names and descriptions for the fields in the class definition. Data block 154 indicates that there are two fields in a class 112 form. The first field of class 112 is itself a constructed class, which is assigned class number 150, data block 156, and which has two subfields, data block 158. The first subfield is a primitive class 15, data block 160, which is described in the class definition for class 150 so that it contains the name of the first field in class 1021. Data block 162 communicates the name of the first field in class 1021. The second subfield is a primitive class 15, data block 164, and is described in the class definition of class 150 (not shown) as a field that contains an ASCI string that contains the representation, data block 166, in the first field of class 1021 stored current data describes. The second field of class 112 is described in the class definition of class 112 as a field containing a constructed form of class 150, data block 168, which has two fields, data block 170, which is the name of the next field in class 1021 and describe the type of representation of the current data stored in this second field.

DESCRIPTION

There now follows a more detailed description of the various library programs and the overall structure and operation of an embodiment of the communication interface in accordance with the teachings of the invention.

Information Driven Architecture, Teknekron Information BUS, TIB, TIBINFO, TIBFORMS, SubjectBased Addressing and RMDP are trademarks of Teknekron Software Systems, Inc.

CONTENT

1. introduction

Second Architecture of the Teknekron Information Bus

Third Reliable Market Data Protocol: RMDP

4th Item-addressed subscription service: TIBINFO

5th Data exchange component: TIBFORM

6th Appendix: 'man' pages

1. introduction

Teknekron Information Bus Software is a distributed software component that is designed to facilitate the exchange of data between applications that run in a distributed real-time environment. It is based on communication protocols of the industry standard (TCP / IP) and data exchange standards (eg X.400).

This document describes a "preliminary version" of the TIB application programming interface (API) and contains interface descriptions of all TIB core components. It has been published for informational purposes only. The reader should note that changes to the interfaces described herein are reserved. Although Teknekron does not anticipate major changes to the interface description contained herein, minor changes are expected to be proposed and implemented as a result of the distribution process.

The document is structured as follows. Section 2 contains an architectural overview of TIB. Section 3 describes the Reliable Market Data Protocol. This all-purpose protocol is particularly well suited to the requirements of page-based market data services. It is also often used for the distribution of bulletins and reports. Section 4 describes TIBINFO, an interface that supports subject-based addressing. Section 5 describes a component and its interface that supports a very flexible and comprehensive data exchange standard. This component is called TIBFORMS. The appendix contains (UNIX-like) manual pages for the core interfaces.

Second Architecture Overview

2.1 Introduction

The Teknekron Information Bus (TIB) consists of two main components: the (application-oriented) data communication component and the data exchange component. These are shown in Figure 2.1. In addition, a set of presentation tools and a set of support service tools have been created around these components to help the application developer write TIB-based applications.

The (application-oriented) data communication component implements an extensive framework for implementing high-level communication protocol groups. Two protocol groups have been implemented that are tailored to the needs of fault-tolerant real-time applications that communicate via messages. In particular, the groups implement subscription services that provide communication support for monitoring dynamically changing values ​​over a network. Subscription services implement a communication paradigm that is well suited for the distribution of market data from, for example, Quotron or Telerate.

One of the protocol groups supports a conventional, service-oriented, cooperative processing model. The other protocol group directly supports a new, information-oriented, cooperative processing model by implementing object-based addressing. Using this addressing scheme, applications can request information for items through a general purpose interface. Object-based addressing enables the decoupling of information consumers from information producers, which increases the modularity and expandability of the system.

The application-oriented protocol groups are set up on a general group of communication devices, which are referred to as distributed communication components, which are shown as a lower layer in FIG. 2.1. This layer not only offers its clients reliable communication protocols, but also position transparency and network independence.

The layer is based on standard transport layer protocols (eg TCP / IP) and is able to support several transport protocols. The data exchange component implements a powerful way of displaying and transmitting data. All data is encapsulated in self-describing data objects, so-called TIB forms or simply forms. Since TIB forms are self-describing, they allow the implementation of general tools for manipulating and displaying data. Such tools include communication tools for sending forms between processes in a machine-independent format. Since a self-describing form can be expanded without having an adverse effect on the applications that use it, forms make the development of modular applications much easier.

The two main components of TIB are designed so that application programmers can use them independently or together. For example, forms are useful not only for communication applications that share data, but also for non-communicating applications that want to use the general tools and modular programming techniques supported by forms. Of course, such applications do not require TIB's communication services. Similarly, applications that use object-based addressing, for example, do not have to submit forms, but can instead transfer any data structure. Note that the implementation of the communication component does use forms, but does not require applications to use them.

2.2 System model

The system model supported by TIB consists of users, user groups, networks, services, service instances (or servers) and objects.

The term user representing a human "end user" can be found in most systems. A user is identified by a user ID. The TIB user ID is usually the same as the user ID (or login ID) that is supported by the underlying operating system, but this does not always have to be the case.

Each user is a member of exactly one group. The underlying idea is that a group is made up of users with similar service access patterns and access rights. Access rights to a service or a system object can be assigned at the user level and at the group level. The system administrator is responsible for assigning users to the groups.

A network is a logical concept, which is defined by the underlying transport layer and is supported by TIB. An application can send or receive data over any network to which its host computer is connected. It also supports all gateway functions and inter-network forwarding supported by the underlying transport layer protocols.

Since the bottom layer of the TIB communication component supports multiple networks, application-oriented protocols can be written that switch invisibly from one network to another in the event of a network failure.

A "service" represents a meaningful group of functions that are exported from an application for use by its serving applications. Examples of services are retrieval services for historical innovations, a Quotron Datafeed and a Trade Ticket Router. An application typically exports only one service, although it can export many different services.

A service instance is an application process that is able to provide the respective service. (Sometimes these are also referred to as "server processes".) For a given service, multiple instances can provide the service at the same time, thereby improving performance or enabling fault tolerance. Application-oriented communication protocols in TIB can implement the concept of a "fault-tolerant" service by creating an automatic switch from a failed service instance to a functional one that offers the same service.

Networks, services and servers are traditional components of a system model and are implemented in one way or another in most distributed systems. On the other hand, the concept of an object is new for the information model implemented by TIB.

The object space consists of a hierarchical group of object categories. The current version of TIB supports a hierarchy with 4 levels, as represented by the following, well-trained subject: "equity.ibm.composite.trade." TIB does not prescribe a policy regarding the interpretation of the different subject categories. Instead, the applications have the freedom and responsibility to establish conventions themselves regarding the use and interpretation of the various categories of objects.

Each item is typically assigned to one or more services that generate data about that item. TIB's item-based protocol groups are responsible for translating an application's request for data about an item into communication links to one or more service entities that provide information about that item.

A group of item categories is called an item domain. TIB supports multiple subject domains. This fact is useful, for example, when switching from one domain to another. Each domain can define domain-specific item coding functions for an effective display of items in message headers.

2.3 Process architecture

The TIB communication component is a true distributed system, the functions of which are split between a front TIB / communication library associated with each application and a back TIB / communication daemon process, typically one per host processor. This process architecture is shown in Figure 2.2. Note that this functional division between the TIB library and the TIB daemon is completely invisible to the application. In fact, with the exception of certain error return codes, the application is unaware of the existence of the TIB daemon.

The TIB daemons cooperate with each other to ensure reliable and efficient communication between the machines. For item-addressed data, they support efficient transmission by providing low-level system support for message filtering.

The TIB / Communication Library performs numerous functions that are assigned to the individual application-oriented communication groups. For example, the library translates items into efficient message headers that are more compact and easier to check than ASCII item values. It also maps service requests into requests that target specific service instances and monitors the status of those instances.

The TIB data exchange component is implemented as a library called the TIB / Forms Library, which is linked to the application. This library offers all core functions of the data exchange components and can be linked independently of the TIB / communication library. The TIB / forms library does not need the TIB / communication daemon.

2.4 Communication component

The TIB communication component consists of 3 subcomponents: the distributed communication component (DCC) of low level, and the two application-oriented communication protocol groups of high level - the Market Data Subscription Service (MDSS) and the Subject-Addressed Subscription Service (SASS).

The high level protocol groups are tailored around a communication paradigm called a subscription. In this paradigm, a data consumer "subscribes" to a service or item and then receives a continuous stream of data about the service or item until the consumer explicitly ends the subscription (or an error occurs). A subscription paradigm is very well suited for real-time applications that monitor dynamically changing values, such as stock prices. In contrast, the more traditional query-response communication paradigm is poorly suited for such real-time applications, since these require data consumers to "query" data providers to be informed of changes.

The main difference between the two high level protocols is that the MDSS is service-oriented and the SASS is object-oriented. Therefore, for example, MDSS supports sending operations and messages to services in addition to subscriptions, whereas SASS does not support similar functions.

2.4.1 Market Data Subscription Service

2.4.1.1 Overview

MDSS enables data consumers to receive a continuous data stream with a fault tolerance for errors in individual data sources. This protocol group provides mechanisms for managing the load balancing and authorization policy.

Two properties distinguish the MDSS protocols from the typical client / server protocols (eg RPC). First, subscriptions are explicitly supported, which means that changes to requested values ​​are automatically distributed to clients. Second, clients request (or subscribe to) a service, which is contrary to a server, and it is the responsibility of the MDSS component to forward the client's request to an available server. The MDSS is then responsible for monitoring the server connection and restoring it if it fails, using a different server if necessary.

The MDSS has been designed to perform the following important tasks:

(1) Fault tolerance. By supporting automatic switching between redundant services, by explicitly supporting double (or triple) networks, and by using the fault-tolerant transmission protocols implemented in the DCC (such as the "reliable broadcasting protocols"), the MDSS ensures the integrity of a Subscription in the event of all possible failures at individual points. An unfavorable error can temporarily disrupt a subscription, but the MDSS detects errors in good time and quickly looks for an alternative communication path and / or an alternative server. Troubleshooting is also done automatically.

(2) load balancing. The MDSS tries to balance the load across the entire server in operation for a service. When a server fails or starts up again, it automatically balances the load again. In addition, MDSS supports a server allocation policy that tries to optimize the use of scarce resources, such as the "slots" in a page buffer or the bandwidth of the external communication line.

(3) network efficiency. The MDSS supports the intelligent multiple send protocol implemented in the DCC. This protocol tries to optimize the limited resources of the network bandwidth and the processor 1/0 bandwidth by creating an automatic, dynamic switchover from point-to-point communication protocols to broadcasting protocols. For example, the protocol can deliver data from Telerate page 8 to the first five subscribers by point-to-point distribution and later switch all subscribers to broadcast distribution when the sixth subscriber joins.

(4) High level communication interface. The MDSS implements a simple, easy-to-use application development interface that covers most of the complexity of programming a distributed system, including finding servers, establishing communication links, responding to failures, and recovering and balancing.

2.4.1.2 Functionality

The NDSS supports the following core functions:

get: MDSS establishes a fault-tolerant connection to a server for the specified services and "fetches" (ie loads) the current value for the specified page or the specified data element. The connection is subscription-based, so updates to the specified page are automatically forwarded.

halt: "stops" the subscription for the specified service.

"derive" (derive): sends a modifier to the server that could potentially change the subscription.

The MDSS protocol has been especially optimized for the support of page-oriented market data supply, and this focus is also reflected in the choice of function names. However, the protocol group itself is quite general and supports the distribution of any type of data. Therefore, the protocol group is also suitable for other contexts and is used by them (eg - data distribution in an electronic scoreboard).

2.4.2 Subject-Addressed Subscription Service (SASS)

2.4.2.1 Overview

The SASS is a sophisticated protocol group that offers application developers a very high-level communication interface that fully supports the information-oriented, cooperative processing model. This is achieved through the use of object-based addressing.

The general idea behind object-based addressing and its implementation by SASS is very simple. Whenever an application needs data, and in particular data that represents a dynamically changing value (eg a share price), the application simply subscribes to this data by specifying the relevant object. For example, to get all trade tickets through IBM, the application can create the following subscription: "trade_ticket.IBM". After an application has subscribed to a certain object, it is the task of the SASS to select one or more service instances that offer information about this object. The SASS then establishes the corresponding communication connections and notifies (if desired) the service instances that the Offer information.

The SASS has been designed to perform several important tasks:

(1) Decoupling information consumers from information providers. By using object-based addressing, information consumers can request information in a manner that is independent of the application that produces the information. Therefore, the manufacturing application can be modified or replaced by a new application that provides the same information without affecting the consumers of the information.

(2) efficiency. Support for message filtering is built into the low levels of the TIB daemon, where this task can be performed very efficiently. The SASS also supports filtering data on the producer side: data that is of no interest to any application at the moment can simply be omitted before it is put on the network, thereby saving network bandwidth and processor 1/0 bandwidth.

(3) High level communication interface. The SASS interface reduces the complexity of programming a distributed application in three ways. First, the consumer application does not request information by server or service, but by subject. Setting information at this level is easier and more natural than at the service level. It also isolates the program from changes in service providers (e.g. a switch from IDN to ticker 3 for stock prices). Second, the SASS presents all data through a simple, uniform interface - a programmer who needs information offered by three services does not have to learn three service-specific protocols, as would be the case with a conventional processing model. Third, the SASS automates many of the difficult and error-prone tasks, such as searching for a suitable service instance or establishing the right communication link.

2.4.2.2 Functionality

The SASS offers three basic functions to a data consumer:

"Subscribe": when the consumer requests real-time information about one or more items. The SASS component establishes all the necessary communication links to ensure that all data that corresponds to the specified object or objects are delivered to the consumer. The consumer can indicate that the data is delivered either asynchronously (interrupt-driven) or synchronously. A subscription can result in the service instance of the producer being informed about the subscription. This always happens when the producer has set up a registration procedure for his service. This notification of the producer via any specified registration procedure is invisible to the consumer.

e "cancel": is the opposite of "subscribe". The SASS component tactfully closes each dedicated communication channel and notifies the creator if a suitable registration procedure for the service is available.

"receive": "receive" and "callbacks" are two different ways for applications to receive messages that match their subscriptions. Callbacks are asynchronous and support the event-driven programming style - a style that is particularly well suited for applications that require real-time data exchange. "Receive" supports a conventional synchronous interface for receiving messages. The SASS provides a complementary group of functions for a data generator.

It should be noted that an application to the SASS can be both a producer and a consumer, and this can often be the case.

2.4.3 Distributed Communication Component

2.4.3.1 Overview

The Distributed Communication Component (DCC) provides higher-level TIB protocols for communication services. In particular, it offers several types of error-transparent protocols.

The DCC has several important tasks:

(1) The creation of a simple, stable and uniform communication model. This task has several advantages.

First, it offers increased programmer productivity by shielding developers from the complexities of a distributed environment: finding a target process, establishing communication with it, and determining when something went wrong are tasks that are best performed by a capable one Communication infrastructure are carried out and not by the programmer. Second, the DCC shortens development time not only by increasing programmer productivity, but also by simplifying the integration of new features. Finally, it extends configurability by ensuring that applications do not need to know anything about the physical distribution of other components. This prevents developers from adding dependencies due to a specific physical configuration. (Such dependencies would make subsequent reconfigurations difficult.)

(2) Portability through encapsulation of important system structures. This task becomes important when migration to a new hardware or software environment becomes necessary. The effort to shield the applications from the specific, underlying communication protocols and access procedures pays off particularly well in these cases. By isolating the changes needed into a small section of the system (in this case, the DCC), the applications can be ported almost unchanged and the company's investment in the applications is protected.

(3) efficiency. This is particularly important in this component. To achieve this, the DCC is set up on less complex, "connectionless" transport protocols in standard protocol groups (eg TCP / IP and OSI). The DCC was also carefully designed to avoid the most complex protocol problem, namely the proliferation of data "copy" operations.

The DCC fulfills these tasks by implementing a service layer above the general services provided by the purchased software. Rather than reinventing basic functions such as reliable data transfer or flow control mechanisms, the DCC focuses on shielding applications from the idiosyncrasies of any operating system. Examples of this include the hardware-oriented interfaces of the MS-DOS environment or the per-process file descriptor limitation of Unix. By creating a single, unified communication tool that can be easily replicated across many hardware and software environments, the DCC does the above.

2.4.3.2 Functionality

The DCC implements several different transmission protocols to meet the various interaction paradigms, fault tolerance requirements, and performance requirements imposed by the high level protocols. Two of the more interesting protocols are the reliable broadcast protocol and the intelligent multi-send protocol.

Standard broadcast protocols are not reliable and are unable to detect lost messages. The reliable DCC broadcasting protocols ensure that all operational hosts either receive every message that is sent or notice that the message has been lost. In contrast to the so-called reliable broadcasting protocols, lost messages are retransmitted on a limited, periodic basis.

The intelligent multi-send protocol enables a reliable data stream to several destinations. The novel aspect of this protocol is that it can dynamically switch from point-to-point to broadcast to optimize network and processor load. Switching from point-to-point to broadcast (and vice versa) is invisible to protocols at higher levels. This protocol enables the support of a much larger number of consumers than would be possible with point-to-point or broadcasting alone. The protocol is set up on other protocols within the DCC.

All DCC protocols currently only exchange data in discrete units, ie messages (in contrast to many transport protocols). The DCC guarantees that the messages coming from a single process are received in the order in which they are sent.

The DCC contains fault-tolerant message transmission protocols that support retransmission in the event of a lost message. The package guarantees "at most once" semantics in terms of message delivery and makes every effort to ensure "exactly once" semantics.

The DCC has no exposed interfaces that application developers could use.

Third RELIABLE MARKET DATA PROTOCOL

3.1 Introduction

The Reliable Market Data Protocol (RMDP) defines a programmatic interface to the protocol group and the services that comprise the Market Data Subscription Service (MDSS) TIB subcomponent. With RMDP, ​​market data consumers can receive a continuous stream of data based on a subscription request for a given service. RMDP tolerates failures of individual servers by offering features for the automatic connection to alternative servers that offer the same service. All mechanisms for detecting a server failure and for troubleshooting as well as for tracking available servers are implemented in the RMDP library. As a result, application programs can be written in a very simple and naive way.

The protocol provides mechanisms for the management of the load balancing and authorization policy. Let us consider an exchange room with three Telerate lines as an example. To maximize the use of the available bandwidth of these telerate lines, the system administrator can "assign" certain commonly used pages to certain servers, ie page 5 is assigned to server A, page 405 to server B, etc. Each user (or user group) would be assigned a "standard" server for pages that are not explicitly assigned beforehand. (These assignments are recorded in the TIB Services directory.)

To take errors into account, pages or users are assigned priority lists by servers. If a server fails in hardware or software, the RMDF looks for the next server on the list and connects to it. When a server resumes operations, it communicates its presence to all RMDP clients, and the RMDP reconnects the original clients to the server. (Automatic reconnection prevents some servers from becoming overloaded while others are idle.) Except for status messages, the failover and recovery connections are invisible to the application.

The MDSS protocol group including RMDP is set up on the DCC and uses the reliable communication protocols implemented in this component. In particular, the MDSS group uses the reliable broadcasting protocols and the intelligent multiple transmission protocols contained therein. RMDP supports both LANS and wide area networks (WANS). RMDP also supports dual (or multiple) networks in a transparent manner.

RMDP is a "service-addressed" protocol: a complementary protocol, TIBINFO, supports "object-based addressing".

3.2 Programmatic interface

RNDP programs are event-driven. All RMDP function calls are not blocking: even if the call leads to communication with a server, the call returns immediately. Server responses and error messages will be returned later through a callback procedure provided by the application.

The most important task abstraction implemented in RMDP is that of an rstream, a "reliable stream" of data associated with a particular subscription to a specified service. Although different servers can deliver subscription data at different times due to failures and restores, the rstream implements the abstraction of a single, unified data stream. Except for short periods of time during the failure and reconnection, an Rstream is connected to exactly one server for the specified service. An application can open as many rstreams as necessary, the number being limited only by the available memory.

An Rstream is bidirectional - in particular, the RMDP client can send control commands and messages to the connected server via the Rstream. These commands and messages can trigger responses or error messages from the server, and in one case a command will result in a "derived" subscription being generated. Regardless of the cause, all data and error messages (whether generated locally or on another server) are delivered to the client via the corresponding rstream.

The RMDP interface is a narrow interface that consists of only six functions, which are described below:

void

rmdp_Setprop (property, value)

rmdp_prop_t property:

caddr_t value:

Are used to set the values ​​of the RMDP properties. These calls must be made before calling rmdp_Init (). Required properties are in the list below with? characterized. Other properties are optional. The properties currently used are:

* RMDP_CALLBACK

Callback function pointer. See the description of the recall below.

RMDP_SERVICE_MAP

The name of the services directory to be used instead of the default directory.

RMDP_GROUP

The user group used to determine the correct server list. Should have the prefix '+'. The default is the group '+' (ie the null group).

RMDP_RETRY_TIME

The number of seconds that the client waits between successive attempts to the same server, for example in the case of "buffer full". The default is 30.

RNDP_QUIET_TIME

Time in seconds that a stream can be "quiet" before the protocol assumes that the server has died and is "chasing" another server. The default is 75.

RMDP_VERITY_TIME

Time in seconds between successive calls to the server by the client. The default is 60.

RMDP_APP_NAME

Name of the application, eg "telerate", "reuters", etc. If this property is set, the relevant entries from the service directory are saved in the buffer.

void

rmdp_Init ():

This initializes the internal data structures and must be called before all rmdp_Get () calls.

rstream

rmdp_Get (service, request, host)

char * service. * request, * host:

Used to receive a data stream for a specific "service" and a subscription request. For standard market data services, the request is for a page name (for example, "5", "AANN"). If 'host' is non-NULL, the RMDP only uses the server on the specified host. In this case, no new connection to alternative servers will be attempted if one server fails. If 'host' is NULL, the RMDP queries the TIB Services directory to find a list of alternate servers for the request. 'rstream' is a translucent value used to refer to the stream. All data that is routed to the application's callback function is identified by this value.

An error is indicated by rstream rstream ==

ZERO.

rstream

rmdp_Derive (rstream, op)

RStreamold:

char * op:

This creates a new subscription and therefore a new 'rstream' from an existing subscription. 'command' is a character string that is sent to the server, where it is interpreted accordingly to determine the specific derivation.

The standard market data servers understand the following commands: "n" for next-page, "p" for previous-page, and "t XXXX" for time-page.

Derived currents cannot be restored in the event of a server failure. If they are successful, an rstream is returned, otherwise NULL is returned.

void

rmdp message (rstream, msg)

Rstreamrstream:

char * msg:

Sends the string 'msg' to the server used by the 'rstream'. The messages are forwarded directly to the server and are in no way influenced by the state of the stream. Messages understood by standard market data servers include "rr <PAGE NAME>" to request a page again, and "q a" to request the server's network address. Some messages trigger a response from the server (such as requests). In this case, the response is delivered to all streams connected to the server.

void

rmdp_Halt (rstream)

Rstreamrstream:

Stops the 'rstream' tactfully.

void

callback (rstream, msgtype, msg, act, err)

Rstreamrstream;

mdp_msg_t msgtype;

char * msg

mdp_act_t act;

mdp_err_t err;

This is the callback function that was registered with rmdp_Setprop (RMDP_CALLBACK, callback). 'rstream' is the stream to which the message belongs. 'msgtype' can take any of the values ​​below (see "RMDP message type"). 'msg' is a string that can contain v1100 compatible escape sequences, as in MDSS. (However, this is NOT started with an A [[... E. This role is assumed by the 'msgtype' parameter.)

The last two parameters are only important if 'msgtype' is MDP_MSG_STATUS. 'act' can take any value that occurs in "RMDP Action Type" (see below), but a special action is only necessary if act == 'MDP_ACT_CANCEL'. The latter indicates that the power is being cut off and is no longer valid. It is now up to the application to take the right action. In both cases, 'err' can take one of the values ​​contained in "RMDP Errortype" (see below) and provides a description of the status.

RMDP message types (mdp_msg_t)

The message types are listed below. These types are defined in the underlying (unreliable) market data protocol (MDP) and are exported to the RMDP.

RMDP measure type (mdp_act_t)

The types of measures are listed below. These types of measures inform the RMDP clients of activities that occur in the lower-level logs. Generally speaking, these are messages "for information" that do not require any additional measures from the RMDP client. The exception to this is the "MDP_ACT_CANCEL" measure, for which there is no recovery. These types are defined in the underlying (unreliable) market data protocol (MDP) and are exported to the RMDP.

RMDP error types (mdp_err_t)

Error description for logging or reporting to end users. These types are defined in the underlying (unreliable) Market Data Protocol (MDP) and are exported to the RMDP.

MDP_ERR_OK = 0

MDP_ERR_LOW = 1

NDP_ERR_QUIET = 2

MDP_ERR_INVAL = 3

MDP_ERR_RESRC = 4

NDP_ERR_INTERNAL = 5

MDP_ERR_DELAY = 6

NDP_ERR_SYS = 7

MDP_ERR COMM = 8

4th Item-addressed subscription service: TIBINFO

4.1 Introduction

TIBINFO defines a programmatic interface to the protocols and services, which comprise the TIB subcomponent, which provide the subject-addressed subscription services (SASS). The TIBINFO interface consists of the following libraries: TIBINFO-CONSUME for data consumer applications, and TIBINFO-PUBLISH for data publication applications. One application includes one library or the other, or both. It depends on whether she is a consumer or a supplier or both. An application can be a consumer and a producer at the same time.

By supporting object-based addressing, TIBINFO supports an information-oriented model of collaborative processing by creating a process for consumer applications to request information in a manner that is independent of the service (or services) that generate the information. As a result, services can be modified or replaced with alternative services that provide equivalent information without affecting information consumers. This decoupling of information consumers from information providers enables a higher degree of modularization and flexibility than conventional service-oriented processing models.

In order for object-based addressing to be useful in a real-time environment, it must be implemented effectively. Taking this task into account, support for object-based addressing was built into the lower levels of the distributed communication component. In particular, the filtering of the messages by object is carried out within the TIB daemon itself.

4.2 Terms

object

The object space is hierarchical. A hierarchy with 4 levels of the following format is currently supported:

major [.minor [.qualifierl [.qualifier2]]]

where '[' and ']' are metacharacters that delimit an optional component. major, minor, qualifier1 and gualifier2 are referred to as item identifiers. An item identifier is a character string that consists of the printable ASCII characters except '.', '?' and '*' exists. An item label can also be an empty string. In this case, it corresponds to each item identification in this position. The complete item, including the '.' Separators, must not exceed 32 characters. The writing of the objects is case sensitive.

Some examples of valid items are listed below. The comments relate to the interpretation of items on the consumer side. (The semantics on the publication application side are slightly different.)

equity. ibm. composite. quota

equity..composite.quote Target with a smaller item

equity. ibm comparison with qualifien and qualifier2

equity.ibm. same as above

Objects are not interpreted within TIBINFO and the SASS. Therefore, applications have the freedom to create conventions about the object space. It should be noted that the SASS components first try to match the larger and smaller item identifiers. Although applications can create the convention that "equity.ibm" and "..equity.ibm" are equivalent items, "equity.ibm" subscriptions are processed more effectively.

Stream

A stream is an abstraction for grouping subscriptions. A stream's subscriptions share a common set of properties, remarkably the same message routine (ie, "callback" routine) and the same error routine. All subscriptions to a stream can be "canceled" simply by destroying the stream.

A current loads the system with little overhead. Currents can therefore be generated and destroyed freely.

Protocol engines, service disciplines and object images

The SASS and DCC components implement many support services to provide the functionality in TIBINFO. These include item images for more efficient item handling, service disciplines to control interaction with servers, and protocol engines to implement reliable communication protocols. TIBINFO provides an interface for setting up properties of these components. Therefore, the behavior of the object imager can be determined by the TIBINFO interface, for example by setting the appropriate settings. Since these properties are located in configuration files, configuration and location-dependent parameters for the above-mentioned components can be supported by TIBINFO.

In the future, the property definitions for TIBINFO and for the underlying components can be increased to support extensions. The use of properties leads to flexibility and expandability within the limits of a stable, functional interface.

4.3 Description

The TIBINFO interface is an easy-to-use, high-level interface. The published data can be a form or an uninterpreted byte chain. Messages can be received either in a synchronous manner or in an asynchronous manner suitable for event-driven programming. The following functions are sufficient to write sophisticated consumer applications using event-driven programming.

Tib_stream * tib_consume_create (property-list, TIB_EOP)

Generates a TIBINFO stream that supports multiple subscriptions via the "subscribe" function. The property list is a (possibly empty) list of property-value pairs, as represented by tib_consume_create (TIB_PROP_MSGHANDLER, my-handler, TIB_PROP_ERRHANDLER, my-err-handler. TIB_EOP);

Valid properties are defined below. TIB_EQP is a literal that signals the end of the property list.

void tib destroy (stream)

Tib_stream * stream:

Requests resources used by the specific stream.

Tib_errorcode tib_subscribe (stream, subject, clientdata)

Tib_stream * stream:

Tib-subject * subject:

caddr_t clientdata.

Informs the TIB that the client application is interested in messages containing the displayed item. If a "messagehandler" (a message routine) is assigned to the stream, it is called whenever a message corresponding to the subscription arrives. Corresponding messages are sent on a FIFO basis (first in / first-aut). The value of the client data is returned in every message that corresponds to the subject of the subscription. Note that multiple subscriptions to the same item on the same stream are undefined.

void tib cancel (stream)

Tib_stream * stream;

Cancels the subscription to the specified subject of the serving application.

void my_message_handler (stream.msg)

Tib_stream * stream;

Tib_message * message;

This is the call back function that was registered with the power. Forms will be returned unpackaged. The function can refer to the entire message structure using the macros described below.

The following functions are sufficient to write producer applications. Two publication functions are provided to support the different data types that can be transmitted through the TIB-INFO interface.

tib_publish_create (property-list, TIB_EOP)

Used to generate a TIBINFO stream for the publication of records. The property list is a (possibly empty) list of property value pairs, as represented by

tib_ublish_create (TIB_PROP_ERRHANDLER, my_handler, TIB_EOP).

Valid properties are defined below. TIB_EOP is a constant that signals the end of the property list.

tib destroy (stream)

Tib_stream stream;

Requests resources used by the specific stream.

Tib_errorcode tib_publish_form (stream, subject, form)

Tib_stream * stream;

Tib_subject * subject;

Form form;

Accepts a single, unpackaged form, packages it, and publishes it.

Tib_errorcode tib_publish_buffer (stream, subject, length, form)

Tib_stream * stream;

Tib_subject * subject;

short length;

Form form;

Accepts a byte cache of fixed length and publishes it.

The remaining functions are control functions that apply to both the consumer and the publication side.

void Tib_batch ()

Can be used before initiating multiple subscriptions. Informs the TIB library that it can delay processing the subscriptions until a tib_unbatch. This allows the TIB library to try to optimize the execution of the requests. It should be noted that no guarantees can be given about the order or the chronological order of a "batched" request. In particular, (i) requests can be executed before receiving the tib_unbatch function, and (ii) the effects of changing the properties in the middle of a stacked request sequence are undefined. Stacking and unstacking requests (batch and unbatch) can be nested. (Note that the use of tib_batch is completely optional and does not change the semantics of a correct program in any way.)

Tib_errorcode tib_stream_set (stream, property, value)

Tib_stream * stream;

Tib _property * property;

caddr_t value;

Is used to dynamically change the adjustable properties of a current. These properties are described below. Note that some properties can only be set before power generation (via tib_default_set) or during power generation.

caddr_t tib_stream_get (stream, property)

Tib_stream * stream;

Tib_property * property;

Used to receive the current value of the specified property.

Tib_errorcode tib-default-set (property, value)

Tib_stream * stream:

Tib_property * property:

caddr_t value:

Used to change the initial properties of a stream. During power generation, the default values ​​are used as the initial value in the new stream whenever a property value is not explicitly specified in the generation argument list.

Tib_errorcode tib_default_get (property)

Tib_stream * stream:

Tib_property * property:

Used to receive the default value of the specified property.

tib_unbatch ()

Informs TIBINFO about ending "batching" functions (stacking functions) and possibly executing outstanding ones.

TIBINIFO attributes

The properties defined by TIBINFO and the permitted values ​​are listed below and are described in detail on the corresponding "man" pages. The last grouping of properties enables the programmer to send standard property values ​​and information to the underlying system components - in particular to the network protocol engines, the TIB object images, and various service disciplines.

TIBINFO_CONSUME message structure

The component information of a TIBINFO message can be accessed using the following macros:

tib_msg_clientdata (msg)

tib_msg_subject (msg)

tib_msg_size (msg)

tib_msg_value (msg)

The following macros return TRUE (1) (TRUE) or FALSE (0) (FALSE):

tib_msg_is_buffer (msg)

tib_msg_is_form (msg)

5th TIB forms

5.1 Introduction

The form package provides the tools for creating and manipulating self-describing data objects, such as forms. Forms have sufficient expressiveness, flexibility and efficiency to describe all data that are exchanged between the different TIB applications and between the most important software modules of each application.

The forms package provides its clients with data abstraction. Therefore, unlike a case where a data abstraction is used for each different type of data being exchanged, the software using a forms package only has to deal with a single data abstraction. Using forms as the only way to exchange user data facilitates (i) the integration of new software modules that communicate with other software modules, and (ii) the modular expansion of existing data formats without modifying the underlying code. This results in software that is easier to understand, expand, and maintain.

Forms are the most important shared objects in the infrastructure of TIB communication and TIB applications; therefore they belong to the most important abstractions of TIB.

The most important tasks when creating the form packages were:

o Extensibility - It is desirable to be able to change the definition of a form class without recompiling the application and to be able to introduce new form classes into the system.

maintainability - changes to the form class definition can affect many workstations; Such changes must therefore be disseminated systematically.

o Expressiveness - forms must be able to describe complex objects; therefore, form packages should support many general types such as integer, real, string, etc., and sequences of these types.

o Efficiency - Forms should be the most commonly used object for sending information between processes - for processes on the same workstation as well as for processes on different workstations. Therefore, forms should be designed to enable the communications infrastructure to send information in an efficient manner.

Note that our use of the term "form" differs from the normal use of the term in database systems and so-called "form management systems". In these systems, a "form" is a format for representing a database or file set. (Typically, a user creates a form in such systems and imports a database record into the form.)

Our form term is more fundamental, similar to such basic terms as data set or data group. Our term derives its meaning from the original meaning of the Latin root 'forma'. Webster defines this as: "The form and structure of a thing as opposed to its material". Forms can be instantiated, edited, forwarded as arguments, sent over a network, or stored in files and databases. Their content can also be presented in many different formats. Templates can be used to determine how a form is to be presented. A single form (more precisely, a form class) can have many "templates" because it may have to be presented in many different ways. For example, different users may want to use different formats to display a form.

5.2 Description

Forms are self-describing data objects. Each form contains a reference to its form class, which fully describes the form. Forms also contain metadata that enables the form package to perform most operations without accessing the associated form class definition.

Each form is an element of a specific farm class. All forms within a class have the same fields and field names (in fact all defining attributes of the forms of a specific class are identical). Each form class has a label, and two classes are considered different if they have different labels (even if the classes have identical definitions). Even if the form software assigns special meaning or processing support to individual form names, applications that use them can very well do so. (Indeed, certain form naming conventions are expected to be established.)

There are two main classifications of forms: primitive versus constructed, and fixed-length versus variable-length.

Primitive forms are used to represent primitive data types, such as integers, floating point numbers, character strings, etc. Primitive forms contain metadata in the form header and information header as well as the data of the corresponding type, such as integers, strings, etc.

Constructed forms contain subforms. A constructed form contains other forms, which in turn can contain subforms.

Fixed length forms are simply fixed length forms; for example, all forms of a class with a fixed length take up the same number of bytes. An example of a primitive form of fixed length is the integer form class: Integer forms always require 6 bytes. (2 bytes for the form header and 4 bytes for the integer data).

Variable size forms contain variable size data; variable size primitive forms contain variable size data such as variable length strings; constructed forms of variable sizes contain a variable number of subforms of a single class. Such forms resemble a data group of elements of the same type.

5.3 Class identifiers

When a class is defined, it is assigned an identifier. This identifier is part of every form instance of the class and is used to identify the form class. This identifier is available in addition to the designation. Class identifiers must be unique within their scope. Class identifiers are 2 bytes long: bit 15 is set if the class is a class of fixed length; otherwise this bit is cleared; Bit 14 is set if the class is a primitive class; otherwise this bit is cleared.

5.4 Semantics of assignment

The "copy" semantics are used to assign and load values ​​of a form (or a form sequence). When assigning a value to a form (form field or sequence element), the value of the

Form is copied to the assigned location - no pointer to the given value is set up.

Clients who are interested in pointer semantics should use the form of the general type Form Pointer and the function Form_set_data_pointer. Form Pointer forms only contain a pointer to a form; therefore, pointer semantics are used for the assignment. Note that the C programming language supports pointer semantics for data group assignment.

5.5 Referencing a form field

A subform or a field of a constructed form can be accessed by its field name or by its field identifier (the latter is generated by the form package). The description of a subform that is not a direct descendant of a given form is made up of the path name of all fields, separated by a period, that contain the requested subform. Note that this is similar to the naming convention of the C language records.

A field identifier can be obtained if the name of the field is given and the function Form_class_get_field_id is used. The direct fields of a form can be traversed by using Form_field_id_first to get the identifier of the first field and by subsequently calling Form_field_id_next to get the identifiers of the individual subsequent fields.

Access to a field by its name is convenient, access by its identifier is quick. Most functions of the form package reference a form field by its identifier and not by its name.

5.6 Form class definition language

Form classes can be described using the "form class definition language" shown below. Even complex forms can be described within the simple language features shown below. The great advantage of a formal language, however, is that it offers a comprehensive framework: by adding new language constructs, the descriptive power of the language can be increased enormously without making older descriptions incompatible.

A description of a form class includes the description of some class attributes, such as the class label, and a list of specifications for each field in the class. Three examples are shown below:

To describe a class, the class name, a statement about fixed or variable size and a list of the fields must be available. For primitive classes, the data type and size must also be described. No information is required for all other attributes; default values ​​are set for these. To define a class field, either the name or the identifier of the field class must be specified. The following form class attributes can be described:

The class name.

CLASS_ID - Unique, short integer identifier of the class. By default it is set to a value specified by the package.

IS_FIXED - Describes whether the class has a fixed or variable size. Expects a boolean. This attribute is required.

IS_PRIMITIVE - Describes whether it is a primitive or constructed class. Expects a boolean. Set to FALSE by default.

FIELDS_NUM - An integer that describes the starting number of fields in the form. By default it is set to the number of fields described.

DATA_TYPE - An integer specified by the clients that indicates what type of data it is. Mainly used to define primitive classes. Has no default value.

DATA_SIZE - The size of the form data section. Mainly used to define primitive classes. Has no default value.

FIELDS - Shows the beginning of the field definition of the class.

The following field attributes can be described:

The field name of the class.

FIELD_CLASS_ID - The class identifier for the forms to be included in the field. Note that the class name can be used for the same purpose.

FIELD_OLASS_NAME - The class label for the forms that should be included in the field.

Here is an example of the definition of three classes:

Note that variable length forms contain fields of a single class. "integer" and "string_30" used in the above examples are two primitive classes that are defined within the form class package itself.

5.7 Form classes are forms

Form classes are implemented as forms. This means that functions that accept forms as arguments also accept form classes. Some of the more useful functions in form classes are:

Form_ack, Form_unpack - Can be used to pack and unpack form classes.

Form_copy - Can be used to copy form classes.

Form_show - Can be used to print form classes.

5.8 types

typedef form class

A form class handle

typedef Formclass_id

A form class identifier.

typedef Formclass_attr

A form class attribute type. The following attributes are supported:

FORMCLASS_SIZE - The size of the form instances of the class.

FORMCLASS_NAME - The class label.

FORMCLASS_ID - A two-byte unique identifier.

FORMCLASS_FIELDS_NUM - The number of (direct) fields in the class. This only applies to classes of fixed length. The number of fields in a variable length class is different for each instance; therefore it is included in every form instance.

FORMCLASS_INSTANCES_NUM - The number of form instances of the respective class.

FORMCLASS_15_FIXED - True if the form is a fixed length. False if it is a variable length form.

FORMCLASS_15_PRIMITIVE - True if it is a form of primitive type. False if the form is a constructed type, that is, if the form has subforms.

FORMCLASS_DATA_TYPE - This field value is assigned by the user of the forms to indicate the data type of the primitive forms. In the current application we use the type constants as defined by the specified type Farm_data_type in the file forms.

FORMCLASS_DATA_SIZE - This field contains the data size of the primitive forms in bytes. For example, the primitive class Short has the data size two.

Since it contains the C type short, which is contained in two bytes.

typedef Formclass_field_attr

A form class field attribute type. The following form class field attributes are supported:

FORMCLASS_FIELD_NAME - The name of the class field.

FORMCLASS_FIELD CLASS ID - The class identifier of the form of the field.

typedef shape

A form handle.

typedef Form_field_id

An identifier for a field on a form. Can identify fields at every level of a form. A field identifier can be fetched from a field name using the Form_dass_get_field_name function. A form_field_id is manipulated by the functions: Form_field_id_first and Form_field_id_next.

typedef Form_attr

A form attribute type. The following form attributes are supported:

FORM_CLASS_ID - The class identifier of the form.

FORM_DATA_SIZE - The size of the form's data. Available only for constructed, non-primitive forms, or for variable size primitive forms. For primitive forms of fixed length, this attribute is available via the form class.

FORM_FIELDS_NUM - The number of fields in the respective form. Available only for constructed, non-primitive forms. For primitive forms, this attribute is available through the form class.

typedef Form_data

The data type that is contained in primitive forms.

typedef Form_pack_format

Describes the possible form packaging types. The following packaging formats are supported:

FORM_PACK_LIGHT - Easy packaging; is mainly used for inter-process communication between processes on the same machine. Is more efficient than other types of packaging. The easy packaging consists of arranging the respective form in rows, but it does not translate the form data into a machine-independent format.

FORM-PACK-XDR - Arranges the form in rows as it translates the data into a machine-independent format. The machine-independent format used is Sun's XDR format.

5.9 Procedural interface to the form class package

The form class package is responsible for creating and editing form classes. The form package uses these descriptions to create and edit instances of given form classes. Unsurprisingly, an instance of a form class is called a form.

Formclass_create

Creates a class handle according to the given argument list. If the attribute CLASS_CFILE is described, this should be followed by a cfile handle and a path name. In this case formclass_create looks for the description for the form class in the described configuration file. The description is compiled into an internal data structure that is used by the form package.

Formclass_create returns a pointer to the class data structure. If there are syntax errors in the class description file, the function sets the error message flag and returns NULL.

Formclass_destroy

The class description specified by the given class handle is broken down and the memory is used again.

If there are live instances of the class, the class is not destroyed and the error value is updated to "FORMCLASS_ERR_NON_ZERO_INSTANCES_NUM".

Form class-get

When handling a form class and an attribute of a class (eg one of the attributes of the type Formclass_attr), Formalass_get returns the value to the attribute. If the attribute is unknown, the error value is updated to "FORMCLASS_ERR_UNKNOWN_ATTRIBUTE".

Formclass_get_handle_by_id

With a form class identifier, Formclass_get_handle_by_id returns the handle to the appropriate class descriptor. If the requested class identifier is unknown, Formalass_get_handle_by_id returns NULL, but does not set an error flag.

Formclass_get_handle_by_name

With a form class name, Formclass_get_handle_by_name returns the handle to the appropriate class descriptor. If the requested class name is unknown, Formclass_get_handle_by_name returns NULL, but does not set an error flag.

Formclass_get_field_id

When handling a form class and field name, this function returns the form identifier that is used for quick access to the form. If the specified field name does not exist, it updates the error variable to FORMCLASS_ERR_UNKNOWN_FIELD_NAME.

Formclass_field_get

Returns the value of the attribute of the requested field. If an invalid identifier is specified in this procedure, it updates the error variable to FORMCLASS_ERR_UNKNOWN_FIELD_ID.

Formclass_iserr

Returns TRUE if the error flag of the form class is switched on, otherwise FALSE.

Formclass_errno

Returns the error number of the form class. If there is no error, it returns FORMCLASS_OK. For a list of supported error values, see the Form Classes file.

5.10 The form package

Form_create

Create a form (ie an instance) of the form class defined by the parameter and return a handle to the generated form.

Form_destroy

The specified form is "destroyed" when its memory is used.

Form_get

When handling a form and a valid attribute (eg one of the values ​​of the type Form_attr mentioned), Form_get returns the value of the requested attribute.

The FORM_DATA_SIZE attribute is only supported for forms of variable size. For forms of a fixed size, this information is kept in the class description and not for every form instance.

If FORM_DATA_SIZE is requested from a form of fixed length, the error flag is set to FORM_ERR_NO_SIZE_ASTTR_FOR_FIXED_LENGTH_FORM.

The FORM_FIELDS_NUM attribute is only supported for constructed forms. If FORM_FIELDS_NUM is requested from a primitive form, the error flag is set to FORM_ERR_ILLEGAL_ATTR_FOR_PRIMITIVE_FORM.

If the respective attribute is not known, the error flag is set to FORM_ERR_UNKNOWN_ATTR. If the error flag is set differently than FORM_OK, Form_get returns NULL.

Form_set_data

Sets the data value of the form to the specified value. The given data argument is assumed to be a pointer to the data, that is, a pointer to an integer, or a pointer to a data structure. For strings, however, we expect a pointer to a character.

Note that we use copy semantics for assignments.

Form_get_data

Return a pointer to data clipping on a form. In the case of a form of a primitive class, the data is the current value of the form type. If the form is not a primitive class, that is, if the number of fields is not zero, the value of the form is a guide to the field order of the form.

Attention: the returned handle points to the data structure of the form and should not be changed. If the returned value is to be modified, it should be copied to private storage.

Form_set_data_pointer

With a form of variable size, Form_set_data_pointer assigns the given pointer to the points of the form data section. Form_set_data_pointer provides a copy process with pointer semantics as opposed to copy semantics.

If the given form is a fixed-length form, the error flag is set to FORM_ERR_CANT_ASSIGN_POINTER_TO_FIXED_FORM.

Form_field_Set_data

This is a convenient routine that corresponds to calling Form_field_get and then using the fetched form to call Form_set_data. More precise: form_field_Set_data (form, field_id, form_data, size) == form_Set_data (form_field_get (form, field_id), form_data, size), plus error checking.

Form_field_get_data

Note that we use copy semantics for assignments.

This is a convenient routine that corresponds to calling Form_field_get and then using the fetched form to call Form_get_data. More precise: form_field_get_data (form, field_id, form_data, size) form_get_data (form_field_get (form, field_id), form_data, size) plus error checking.

Attention: the returned handle points to the data structure of the form and should not be changed. If the returned value is to be modified, it should be copied to private storage.

Form_field_id_first

Form_field_id_first sets the given field-id to identify the first direct field of the given form handle.

Note that the memory for the given field_id should be allocated (and released) by the form package clients and not by the form package.

Form_field_id_next

Form_field_id_next sets the given field-id to identify the next direct field of the given form handle. Calls to Form_field_id_next must precede calls to Form_field_id first.

Note that the memory for the given field_id should be allocated (and released) by the form package clients and not by the form package.

Form_field_set

Sets the given form or form sequence as the given form field value. Note that we use copy semantics for assignments.

If a non-existent field identifier (field_id) is specified, the error flag is set to FORM_ERR_ILLEGAL_ID.

Form_field_get

Returns a handle to the value of the requested field. The returned value is either a handle to a form or to a form sequence.

Attention: the returned handle points to the data structure of the form and should not be changed. If the returned value is to be modified, it should be copied to a private memory using the Form_copy function.

If a non-existent field identifier (field_id) is specified, the error flag is set to FORM_ERR_ILLEGAL_ID and Form_field_get returns NULL.

Form_field_append

Form_field_append appends the given append-form argument to the end of the base-form form sequence. Form_field_append returns the identifier (id) of the attached new field.

Form_field_delete

Form_field_delete deletes the given field from the given base_form.

If a non-existent field identifier (field_id) is specified, the error flag is set to FORM_ERR_ILLEGAL_ID and Form_field_delete returns NULL.

Form_pack

Form_pack returns a pointer to a byte stream that contains the packaged form that was packaged according to the requested format and type.

If the requested package type is FORM_PACK_LIGHT, Form_pack arranges the form in order, but the form data is not translated into a machine-independent representation. A lightly packaged form is therefore suitable for transfer between processes on the same machine.

If the requested package type is FORM_PACK_XDR, Form_pack arranges the form in order and also translates the form display into a machine-independent display form, which is XDR from Sun. Forms that have been packaged with an XDR format are therefore suitable for transmission across a network across machine boundaries.

Form classes are implemented as forms, so Form_pack can be used to package both form classes and forms.

Form_unpack

If the form is displayed externally, create a form instance according to the given class and extract the external representation into the instance.

Form classes are implemented as forms, so Form_unpack can be used to unpack both form classes and forms.

Form_copy

Copy the values ​​of the source form into the identification form. If the forms belong to different classes, no copying is carried out and the error value is updated to FORM_ERR_ILLEGAL_CLASS.

Form classes are implemented as forms, so Form_copy can be used to copy both form classes and forms.

Form_show

Return an ASCII string that contains the list of field labels and associated values ​​for the specified fields. The character string is suitable for display on a terminal or for printing (e.g. it contains new line characters). The returned string is allocated by the function and must be released by the user. (This function is very helpful for troubleshooting.)

Form classes are implemented as forms, so Form_show can be used to print both form classes and forms.

Form_iserr

Returns TRUE if the error flag is set, otherwise FALSE

Form_errno

Returns the error number of the form class. If there is no error, it returns FORMCLASS_OK. The possible error values ​​are defined in the file forms.

GLOSSARY

The following is a list of definitions of some of the words and phrases used in this description of the invention.

Format or type: The data representation and data organization of a structural data record, ie a form.

Foreign: A computer or software process that uses a different format or record than the format record of another computer or software process.

Form: A data record or data object whose structure is self-describing by including fields that contain class descriptor numbers that correspond to class descriptors or class definitions. These class descriptors describe a form class whose instances all have the same internal representation, the same organization, and the same semantic information. This means that all instances, ie Occurrences of forms of this class that have the same number of fields with the same name, and that the data in the corresponding fields have the same display and each corresponding field means the same. Forms can be either primitive or constructed. A form is primitive if it only stores a single data unit. A form is constructed when it has multiple internal components called fields. Each field is itself a form that is either primitive or constructed. Each field can store data or the class ID, ie the class number, of another form.

Class / Class Descriptor / Class Definition: A definition of the structure and organization of a particular set of records or "forms", all of which have the same internal representation, organization, and semantic information. A class descriptor is a record or "object" in memory that stores the data that defines all of these parameters of the class definition. The class is the name of the group of forms, and the class definition is the information about the general characteristics of the group. Classes can be either primitive or constructed. A primitive class contains a class label that uniquely identifies the class (this label is assigned a class number or class identifier) ​​and a description of the representation of a single data value. The description of the representation uses well-known primitives that the host computer and the serving applications understand, such as string_20 ASCII, floating point, integers, string_20 EBCDIC etc. A constructed class definition includes a unique name and defines several fields by name and content, that appear in this type of form. The class definition describes the organization and semantics or the form by describing the field names. The field names give the fields meaning. Each field is described by specifying a field name and the form class of its data, since each field is itself a form. A field can be a list of forms of the same class instead of a single form. A constructed class definition does not contain current data, although a class descriptor does so in the form of data that defines the organization and semantics of this type of form. All current data that defines instances of forms is stored in forms of primitive classes, and the data type stored in primitive classes is described in the class definition of the primitive class. For example, the primitive class called "Age" has a field of type integer_3, which is defined in the class definition for the age class of the forms. Form instances of this class contain three-digit integer values.

Field: A component (?) In an instance of a form that can have one or more components (?), Each of which is labeled differently and each means something different. Fields are "primitive" if they contain current data and they are "constructed" if they contain other forms, such as groupings of other fields. A record or form that contains at least one field that contains another form is called nested. The second form of a first form recorded in the constructed field has its own fields, which can also be primitive or constructed. This makes infinitely complex nesting layers possible.

Process: An instance of a software program or software module that runs on a computer.

Semantic information: The names and meanings of the various fields in a form with respect to forms.

Nested: A data structure consisting of records with multiple fields, each of which can contain other records with multiple fields.

Primitive field: A field or a form or a record in which current data is stored.

Constructed field: A field that contains another form or record.

Format operation: An operation to convert a form from one format to another format.

Semantically dependent operation: An operation that requires at least access to the semantic information of the class definition for a particular form in order to provide data from that form to a requesting process.

Application: A software program that runs on a computer but is not an operating system program.

Decoupling: Freeing a process, a software module or an application from the need to know the communication protocols, data formats and positions of all other processes, computers and networks with which data is to be exchanged.

Class: A definition of a group of forms, where all forms in the class have the same format and semantics.

Interface: A library of software programs or software modules that can be called by an application or another module of the interface that provide support functions for performing tasks. In the case of the present invention, the communication interface offers a program library which implements the desired decoupling between external processes and computers in order to enable simplified programming of applications for exchanging data with external processes and computers.

Subscription request: A request for data related to a particular item that does not describe the source server or servers, the process or processes or the location thereof from which the data related to that item can be obtained.

Service record: A record that contains fields that describe the important characteristics of an application that provides the specified service.

Server process: An application process that provides the functions of the data described by a particular service, such as Telerate, Dow Jones News Service, etc.

Service discipline or service protocol: The protocol for communicating with a specific server process, application or local data network.

Client application: An application associated with the communication interface libraries in accordance with the teachings of the invention or otherwise associated with a service.

Transport Layer: A layer of the standard ISO model for networks between computers to which the communication interface of the invention is associated.

Transport layer protocol: The communication protocol or communication discipline implemented in a particular network.

Service: A meaningful group of functions or data that an application can export so that it is used by serving applications. In other words, a service is a general class of applications that perform a specific activity, such as applications that provide information to Dow Jones News.

Service instance: A process that runs on a specific computer and is able to provide the specified service (sometimes referred to as a server process)

Server: A computer running a specific process to perform something, such as files stored in mass storage, or raw data from a source of information, such as Telerate, to a network or other computer or another Feed workstation so that they can be distributed to other processes that are connected to the server.

Item Space: A hierarchical group of item categories.

Item Domain: A group of item categories (see also Item Space).

Class definition: The description of a form class.

Class descriptor: A storage object that stores the form class definition. It is saved as a form in the class manager. It is saved on disk as an ASCI character string. Basically, it is a certain representation or a format of a class definition. It can be an ASCII file or a form of representation. If the class manager does not have a class descriptor that it needs, it asks the third-party application that created the class definition for the class descriptor. It then receives a class descriptor in the form of a form as it is generated by the external application. Alternatively, the class manager looks for a file or files that are identified for it by the application that is requesting the semantically dependent operation or that are identified in records that are maintained by the class manager. The class definitions stored in these files are in ASCII text format. The class manager then converts the ASCII text found in this way into a class descriptor in the format of a native form by dividing the ASCII text into the various field names and descriptions for the content of the individual fields.

Native format / form: The original format of a form or the form structure of an application and its host computer.

Identifier: A unique identifier for a form, record, class, storage object, etc. The class numbers assigned to classes in this patent specification are examples of identifiers.

Handle: A pointer to an object, record, file, class descriptor, form, etc. This pointer essentially defines an access path to the object. Absolute, relative and offset addresses are examples of handling.

Class data structure: All data stored in a class manager regarding a specific class. The class descriptor is the most important part of this data structure, but other information may also be available.

Configuration file: A file that stores data that describes the properties and attributes or parameters of the various software components, sets and forms.

Form class attribute: A property of the form class that indicates whether the class is primitive or constructed, for example. Size is another attribute.