Access method with process interactive service6779000Abstract The present invention provides a virtual network, sitting "above" the physical connectivity and thereby providing the administrative controls necessary to link various communication devices via an Access-Method-Independent Exchange. In this sense, the Access-Method-Independent Exchange can be viewed as providing the logical connectivity required. In accordance with the present invention, connectivity is provided by a series of communication primitives designed to work with each of the specific communication devices in use. As new communication devices are developed, primitives can be added to the Access-Method-Independent Exchange to support these new devices without changing the application source code. A Thread Communication Service is provided, along with a Binding Service to link Communication Points. A Thread Directory Service is available, as well as a Broker Service and a Thread Communication Switching Service. Intraprocess, as well as Interprocess, services are available. Dynamic Configuration Management and a Configurable Application Program Service provide software which can be commoditized, as well as upgraded while in operation. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
#if defined(FEATURE.sub.-- A)
. . .
#elif defined(FEATURE.sub.-- B)
. . .
#endif
The disadvantage to Compile-Time Featuring is that it makes the source code difficult to understand. Additionally, as more Minor Services are added, the complexity of maintaining the source code increases thus introducing the prospects for inadvertent software errors, known as bugs. Load-Time Featuring is not very common in the industry as there is little perceived benefit. Considering that the Application must know the features to test for, there is little advantage in this approach versus the previously mentioned approaches. An alternative method for dynamically configuring an application process during execution is to use a shared library >>ARNO86! >>ATT90! >>SUNS92!. >>ARNO86! Arnold, J, "Shared Libraries On UNIX System V," 1986 Summer USENIX Conference Atlanta, Ga. pp: 395-404, 1986. >>ATT90! AT&T, "UNIX System V Release 4 Programmer's Reference Manual", 1990. >>SUNS92! Sun Microsystems, Inc., "SunOS 5.2 Linker and Libraries Manual", pp: 19-41, 1992. With shared libraries, an application program references services available in the library without copying all of the text portion into the Application Program. When the Application Program is executed, the resulting Application Process opens the shared library, loads the service from the library, and then executes the service. The service is retained until the Application Process explicitly request that the service is to be removed from the Application Process. The advantage of using shared libraries is that the underlying library can be upgraded, altered, or otherwise changed independently of the Application Program. The disadvantage in using shared libraries in this manner is that the shared library can only be altered when there are no Application Processes referencing the shared library. Another disadvantage in using shared libraries is that Application Programs are not normally designed to explicitly search and load services from the shared libraries on demand. Thus the prior art provides a mechanism to administer the Application Program software construction process based on available Minor Services. It does not, however, address the needs or requirements for dynamic reconfiguration of the Application Process. The distinction here is that the former approach constructs a static representation of the Application Program while the later is a dynamic representation of the Application Process. Thread Directory Service The invention provides a Thread Directory Service to administer one or more Thread Service Directories. Through the Thread Directory Service a thread can: 1. register new services, 2. remove existing services, and/or 3. query the directory to search for services. In registering a new service, a series of attributes are provided by the registering thread describing the type of service to be provided. These attributes are classified as Public or Private attributes. Public attributes are considered public information and are accessible through the Thread Directory Service by any thread executing locally, or remotely. Private attributes are only accessible by the Thread Directory Service. The administrator of the Thread Directory Service has access to all attributes. A complete description of the attributes is provided in the Embodiment section below. In registering a new service, the Thread Directory Service assigns a unique Thread Communication Identifier to the new service and retains this Identifier in the Thread Service Directory. Once registered, any thread can call the Thread Directory Service to query for a Thread Service by providing one or more Public Attributes. The Thread Directory Service will then search the Thread Service Directory reporting the Thread Communication Identifier(s) of those services matching the specified attributes. In querying the Thread Service Directory, a requesting thread can specify the search criteria attributes using Boolean expressions. Only the Service Thread owner, or the administrator of the Thread Directory Service can delete entries from the Thread Service Directory. Thread Communication Service The Thread Communication Service (TCS) is a computer software method for dynamically administering the communications between two or more Minor Services of an Application Process. The TCS provides the capability to: 1. register low level communication primitives for connectivity and synchronization 2. register Minor Services as communication points 3. begin the execution of a communication point as a Minor Service of the Application Process 4. remove communication points 5. connect communication points using a communication link 6. disconnect communication points 7. suspend communication links 8. resume communication links 9. terminate the execution of a communication point 10. allow a communication point to broadcast to multiple communication points 11. allow a communication point to receive messages from multiple communication points Thread Communication Switching Services The Thread Communication Switching Services system has several features. It routes communications between two or more threads interconnected through a Thread Communication Link. It minimizes the number of Thread Communication Links required to be maintained by the Thread Connect Service. It also packages multiple Thread Communication Packets into a single packet for long distance communications. It also provides redundancy of communications in the event that a Thread Communication Point in the Thread Communication Link terminates unexpectedly. Binding Service The Binding Service is a computer software method to dynamically administer the association of one or more arbitrary named representations with entities understood by the Application Process. Each arbitrary named representation is a sequence of one or more bytes applied at the Application Process level. Definitions An arbitrary named representation is initially considered as Unbound. When an association between the arbitrary named representation is made with an entity understood by the Binding Service, then the arbitrary named representation is considered Bound. The process of determining the association is called the Binding Process. The Binding Process applies an ordered series of Binding Methods to determine if an association between an arbitrary named representation and the entities understood by the Binding Service can be made. To determine the significance of an arbitrary named representation within the scope of the Application Process, the Application Process can request the Binding Service to apply the Binding Methods to the arbitrary named representation to determine what entity the name represents. Binding Methods The Binding Service provides a series of Default Binding Methods including the ordering of Binding Methods as should be applied by the Binding Service. These Binding Methods and their ordering are specified in a Binding Configuration File which is read by the Binding Service during its initialization. Additional Binding Methods can be added to the Binding Configuration File by the end user. Other Binding Methods can be registered with the Binding Service during the Application Process' run time execution. The registration of a Binding Method must include the information shown in Table 1.
TABLE 1
Binding Method Registration Information.
Order of Evaluation
Location of Binding Method
Name of Binding Method
Example descriptive Binding Methods and their definitions are shown in Table 2. An Example of implementing a Shared Library Binding Method and a Shared Object Binding Method are shown in shown in FIG. 13.E through FIG. 13.K and are compiled using the second command line of FIG. 13.A. FIG. 13.D provides a listing of a simple minor service that is compiled using the first command line shown in FIG. 13.1. An example execution of the said compiled program is shown in FIG. 13.B. The sampled output from the execution of said compiled program is shown in FIG. 13.C.
TABLE 2
Default Binding Methods.
File Binding Method
a method to bind the arbitrary named
representation to a file accessible by the
computer system
Shell Binding Method
a method to bind the arbitrary named
representation to a user level shell
Data Binding Method
a method to bind the arbitrary named
representation to a datum available to the
Application Process
Function Binding Method
a method to bind the arbitrary named
representation to a function (procedure)
accessible to the Application Process
Thread Binding Method
a method to bind the arbitrary named
representation to a thread of the Application
Process
Process Binding Method
a method to bind the arbitrary named
representation to an existing Application
Process
Each Binding Method must have associated with it the operations shown in Table 3.
TABLE 3
Binding Method Operations
Pattern Matching Method
Name Transformation Method
Locate Method
Status Method
Query Method
The Binding Method Operations Pattern Matching: if the arbitrary named representation matches the specified regular expression pattern, then apply the Locate Operation to determine if the named representation can be found. If the Pattern Matching Method is specified as NULL, then proceed as if the name was matched. If the arbitrary named representation does not match the specified regular expression pattern, then go to the next Binding Method. Transformation: if the arbitrary named representation successfully completes the Pattern Matching operation, then apply the Transformation operation to the arbitrary named representation and use this transformed name for subsequent operations. If the Transformation operation is not specified for this Binding Method, then use the specified arbitrary named representation for subsequent operations. Locate Operation: use the registered Locate operation to see if the arbitrary named representation can be found. If the Locate Method returns success, then the arbitrary named representation is considered BOUND using this Binding Method. If the Locate operation fails, then the arbitrary named representation remains unbound. Status Operation: given a BOUND arbitrary named representation, use this operation to retrieve the status information describing this entity. This includes the following information: arbitrary name: the specified arbitrary named representation expanded name: the expanded description to be associated with this arbitrary named representation owner information: description of the owner of this bound entity status timers: includes the creation time, the last modification time, the last access time size: the size of the entity in bytes value: the last recorded value associated with the entity entity specific data: entity specific data values including the size of this data Query Operation: given a BOUND arbitrary named representation, report the status information as described by in the Status Operation. Binding Service Interface The Binding Service itself provides the following methods for the Application Process: Register register a new Binding Method Set Order set the ordering of the Binding Methods Unregister remove a Binding Method Bind apply the Binding Methods on a specified arbitrary named representation Unbind unbind the arbitrary named representation Establish request the Binding Service to read a specified Binding Service Configuration File Report report the requested information to the Application Process. This may include the list of Binding Methods, the order of evaluation of Binding Methods, and/or the characteristics of the Binding Methods Query report the requested information on the arbitrary named representation to the Application Process Purge delete all references to arbitrary named references that are currently UNBOUND. Dynamic Configuration Management The Dynamic Configuration Management, hereinafter sometimes referred to as the DCM, provides a method for an Application Process to dynamically construct and subsequently execute a Dynamically Configured Application Program offering an Application Service with zero or more Minor Services. The Application Process constructs a Dynamically Configured Application Program in the DCM by specifying a series of RULES identifying the components of the Dynamically Configured Application Program, the interactions between these components, the policy for evaluating these components, the order of evaluation of these components, and a method for satisfying the RULE. Additionally, the Application Process can specify zero or more data files referred to as Program Rules Files containing RULES for the Dynamically Configured Application Program. In this sense, the Application Process provides the blueprint for constructing the Dynamically Configured Application Program either through an Application Programming Interface and through zero or mode Application Program Rules Files. Once constructed, the Application Process can then request the DCM to execute the Dynamically Configured Application Program. The specification of a RULE includes the information shown in Table 4, although additional information may be provided by the actual implementation:
TABLE 4
Rule Specification Components
A unique alphanumeric name to identify the RULE
A DCM operator denoting the policy for evaluating the RULE
Zero or more Prerequisite Universal RULES
Zero or more Attributes describing characteristics of the RULE
A method (possibly given as NULL) for satisfying the RULE
There are two classifications of RULES supported by the DCM given as Reserved Rules and Universal Rules. The Reserved Rules have special meaning to the DCM and cannot be redefined. The Universal Rules are specified by the Application Process. In either case, however, the Rules contain the minimum information described in Table 4. A series of one or more Reserved Rules, referred to as the Flow Rules, provide the framework for executing the Dynamically Configured Application Program. Whenever a Dynamically Configured Application Program is to be executed, the DCM begins by evaluating the Flow Rules. All other actions are derived as a result thereof. The Flow Rules are shown in Table 5.
TABLE 5
The Flow Rules.
DCMINIT RULE
APINIT RULE
MAIN RULE
DONE RULE
APDONE RULE
DCMDONE RULE
The MAIN RULE must be specified for the Dynamically Configured Application Program to execute. The other Flow Rules (DCMINIT, APINIT, DONE, APDONE, and DCMDONE are optional). The DCM groups all Rules with the same name together as if they were specified as a single entity. This permits, for example, the Application Process to specify potions of a Rule during initialization sequences and the remainder of the Rule when initialization has completed. When the Dynamically Configured Application Program is to be executed, the DCM will evaluate each of the specified Flow Rules. In evaluating a RULE, the DCM views the RULE name as the current rule. The evaluation process is such that the DCM will first evaluate all Prerequisite Rules of the current rule. Thus, a Prerequisite Rule becomes the current rule and the evaluation continues with its Prerequisite Rules. This is implemented using well known directed graph techniques. When the current rule has no Prerequisite Rules listed, and the DCM determines the current rule must be evaluated, then the DCM will execute the method for this rule. After executing the method for the current rule, the DCM attaches a time stamp value denoting when the current rule was evaluated. When the current rule has one or more Prerequisite Rules, then the DCM compares the time stamp value of the current rule with that of its Prerequisite Rules. If the time stamp value of the current rule is older than the time stamp value of its Prerequisite Rules, then the current rule's method is executed to satisfy the rule and the time stamp value of the current rule is updated to denote when the current rule was evaluated. Otherwise, the current rule's time stamp value remains unchanged and the method is not executed. After evaluating the last Flow Rule of the Dynamically Configured Application Program, the DCM considers the application as having completed and returns control back to the initial Application Process. The policy for evaluating a RULE is determined by the DCM operator component of the RULE. By default, a TIME.sub.--VALUE operator (:) will be applied which provides the behavior as described above. Additional DCM operators can be derived and implemented into the DCM to describe the relationship between the RULE and its Prerequisite Rules. Initially when a RULE is specified, the DCM makes no assumptions as to what the RULE name represents. During the evaluation of the RULE, the DCM uses the Binding Service to associate the RULE name with an entity understood by the DCM. The list of entities understood by the DCM and their corresponding interpretation by the DCM are provided during the initialization of the DCM. In this sense, the list of entities can be modified and updated over time based on market demand for new entities and their interpretations. The DCM provides the following default Binding Methods: SHARED LIBRARY BINDING METHOD: The rule represents a shared library available to the Application Process. SHARED OBJECT BINDING METHOD: The RULE name represents a shared object from a shared library. If the RULE has a prerequisite RULE BOUND to a SHARED LIBRARY, then the shared object is presumed to exist in that library. If the method for the rule is to be executed, then the DCM opens the shared library, extracts the shared object, and executes the shared object. To specify a SHARED OBJECT BINDING METHOD, the rule must have the Reserved Rule SHARED OBJECT as a prerequisite rule. THREAD BINDING METHOD: The RULE name represents a procedure to invoke as a separate thread of execution within the Application Process. To specify a THREAD BINDING METHOD, the rule must have the Reserved Rule THREAD as a prerequisite rule. SHELL BINDING METHOD: The RULE name does not represent a physical entity, but rather, its method is specified as statements to be executed by the underlying SHELL provided by the operating system. To specify a SHELL BINDING METHOD, the rule must have the Reserved Rule SHELL as a prerequisite rule. FUNCTION BINDING METHOD: The FUNCTION BINDING METHOD associates the rule name with a function (procedure) available in the application program. The DCM will search the symbol name list for the Application Process to locate the address of the function. If the DCM must trigger the method for the rule, then the function is invoked. FILE BINDING METHOD: The rule name represents the name of a file accessible by the computer system. DEFAULT BINDING METHOD: If no binding method has not been specified for the rule, then the DCM will bind the rule name using the DEFAULT BINDING METHOD. The DEFAULT BINDING METHOD is to associate the rule name with a function (procedure) available in the application program. The DCM will search the symbol name list for the Application Process to locate the address of the function. If the DCM must trigger the method for the rule, then the function is invoked. If the DCM cannot locate the function in the Application Process's symbol table, then the RULE is considered to have failed. The DCM can exist as a co-process of the Application Process, or as a sibling process of the Application Process. In the former sense, the DCM can be accessed by multiple Application Programs thus providing a sharing of information. In the later case, the DCM resides within the Application Process. There are no constraints inherent in the model to preclude the use of the DCM across multiple computer systems. Through the use of the Dynamic Configuration Management method, Minor Services for an Application Service can be designed, implemented, tested, and distributed independently of the corresponding Application Program. The end-user can therefore purchase and install only those Minor Services of interest. When the Application Program is to be executed, the resulting Application Process will dynamically configure itself to provide the available Minor Services. The advantage to the computer industry is that the Minor Services, for example, can be designed after the Application Program and sold individually to the end user. The implications are that: 1) the base Application Program need not be altered to support these additional Minor Services; 2) since the end-user is purchasing only those Minor Services of interest, the end user does not have to provide additional media storage capacity to support unwanted Minor Services; 3) additional Minor Services can be designed, implemented, tested, and installed after the base Application Program thus providing: a) the designer of the Application Program the ability to design, implement, and test additional Minor Services based on new market demands without changing the existing base Application Program b) the ability to design, implement, and test additional Minor Services specific to an individual customer without effecting other customers. In this sense, all customers would have the exact same base Application Program, but potentially different installed Minor Services 4) the development of additional Minor Services can be thoroughly tested as smaller units when compared to the approach used today in which a new, monolithic representation of the Application Program must be tested. The advantage herein is that the computational resources required to develop the software are decreased, the cost of testing is decreased, and the Minor Services can be delivered to the market in a shorter time interval. Configurable Application Program Service The Configurable Application Process Service is a computer software method for dynamically administering the component Minor Services of an Application Process. The Configurable Application Process Service consists of a Configuration Administrator Minor Service thread using the Communication Manager Program Service described elsewhere in this patent application. Various other Minor Service threads may be created by the Configuration Administrator as described herein. The Application Process uses the Configuration Administrator Minor Service, hereinafter referred to as the CAMS, to administer zero or more components of software. Each component is said to offer a well defined application Minor Service hereinafter singularly and collectively referred to as the AMS. The specifications for the administration of the AMS can be provided directly by an Application Process, or, indirectly through a data store monitored by the CAMS. These specifications can instruct the CAMS to perform the desired operation immediately, at a predefined time (which may be an interval), or, as a result of some event which is later communicated to the CAMS. There are fifteen general operations available through the Configurable Application Process Service given as: 1. LOCATE: locate and report the location of a specified AMS 2. LOAD: configure the specified AMS into the Configurable Application Program Service 3. EXECUTE: execute the specified AMS 4. REPLACE: replace the specified AMS with a new AMS 5. UNLOAD: unload the specified AMS from main memory 6. DUMP.sub.--MAP: dump a map of the current values of a specified AMS 7. LOAD.sub.--MAP: load a map of current values for a specified AMS 8. NOTIFICATION: notify the CAMS that the specified event has occurred 9. INSERT: insert the specified AMS in between two existing AMS 10. EXTRACT: removes specified AMS previously inserted with INSERT operation 11. SUSPEND: suspend the communications to a specified AMS 12. RESUME: resume the communications to a specified AMS 13. COMPRIMS: set the default communication primitives for an AMS 14. TERMINATE: terminate the execution of the specified AMS. 15. QUERY: report useful information on the current AMS being administered through the configurable Application Process Service. Other technology which may be configured with the Configurable Application Program Service includes the Binding Service as described in this application. The advantage to the computer industry is that an Application Program can be constructed and executed and subsequently re configured to take advantage of newly installed minor software services while the Application Process is executing. The implications of such a system are that: 1. Mission critical Application Programs which require 24 hour, 365 days a year execution can be re configured without terminating the existing Dynamically Configured Application Process's execution. 2. An Application Process can be re configured without terminating that Application Process which would otherwise cause the Application Process to lose all data currently held in Random Access Memory. 3. An Application Process which requires a significant initialization sequence does not need to be terminated to install new minor software services. Instead, the Application Process can be re configured on demand. 4. New software services can be designed, implemented, and tested using an existing Application Process such that the new services can be deinstalled if found in fault without disrupting the existing Application Process. 5. Application Processes which monitor real time events can be dynamically reconfigured to adjust to those real time events without terminating the existing Application Process. 6. Diagnostic Minor Services can be configured into an existing Application Process for administrative, diagnostic, or statistical analysis and subsequently removed without affecting the existing Application Process. Named Execution Environment This portion of the invention is a computer application service called the Named Execution Environment Manager. A series of one or more machines interconnected through some form of a networking scheme can register one or more arbitrary attributes describing the characteristics of the machine. These attributes are known as the Registered Environment Attributes within the Named Execution Environment. This registration process can be completed by the system administrator (the owner of the machine), or can be completed by an automated Application Process which probes the machine to determine the default attributes of the machine. When an Application Process requires the use of an execution environment, the Application Process calls the Named Execution Environment Manager and specifies one or more attributes describing the requirements of the desired execution environment. These attributes are referred to as the Required Environment Attributes. Further, the Application Process provides the Named Execution Environment Manager specific information to be associated with the new environment if it can be created. This information is called the Named Execution Environment Attributes. The Named Execution Environment Manager then selects an appropriate machine based on a boolean evaluation of the Required Environment Attributes provided by the Application Process, and the Registered Environment Attributes describing the physical machines. When the Named Execution Environment Manager finds a machine whose Registered Environment Attributes satisfy the specified Required Environment Attributes, the Named Execution Environment Manager then establishes an execution environment on the associated physical machine for use by the Application Process. The Named Execution Environment Manager then applies the various Named Execution Environment Attributes to this newly created execution environment, and retains this information either in memory, or on a storage device accessible to the Named Execution Environment Manager. One of the Named Execution Environment Attributes specified by the Application Process is a logical name to be associated with the execution environment. The Application Process then provides the Named Execution Environment Manager the logical name of an environment and a request to execute in that environment. The Named Execution Environment Manager locates the associated environment and sends the Application Process's request to that environment. The request can be any command understood by the environment. The returned values from executing the Application Process's request in the named environment is then sent to the Application Process. This is accomplished using the Thread Communication Service as described in this patent application. Threaded State Machine This part of the invention is a state machine manager thread providing the administration of a state machine, and the administration and execution of various components of a state machine. EXEMPLARY EMBODIMENTS OF THE INVENTION Without limiting the generality of the invention as summarized above, the following descriptions, taken with the accompanying Figures, further provide specific examples of how the various aspects of the invention may be embodied in particular software. Those skilled in the art will recognize that changes in form and details may be made therein without departing from the scope and spirit of the invention. Thread Directory Service A Thread Service Directory contains zero or more entries describing Service Threads. A Service Thread is defined as an entity providing some form of a service which may or may not require direct interaction with an application program. Each Thread Service Directory entry contains items 2 and 4 below, and desirably one or more of the other entries described below: 1. textual description of the type of service; 2. sending communication primitive and receiving communication primitive; 3. communication mechanism used in establishing this service; 4. Location of the service; 5. input types understood by the service; 6. output types generated by the service; 7. keyword search list used to locate this service entry; 8. token describing if the execution of the service can be started; 9. token describing the data representation in communication with the service, i.e., binary, ASCII, etc., 10. token describing if the execution of the service must have previously been started; 11. token describing if Thread Communication Identifier is listed or is unlisted; 12. token describing if a public connection to the service can be used; 13. token describing if a private connection to the service can be used; 14. token describing if a public connection is mandatory; 15. token describing if a private connection is mandatory; 16. token describing if the service is a component of a larger service; 17. shell actions to execute in initializing this service; 18. the maximum number of concurrent communications; 19. licensing information; 20. other general user information; 21. link to additional Services required in using this service; 22. series of status information components including but not limited to security privileges and owner information; 23. series of additional information components used for future enhancements; 24. Thread Communication Identifier; 25. Secondary Thread Service Directory; 26. Usage Fee; 27. Directory Service Fees. Access to the Thread Service Directory is provided by the Thread Directory Service which executes as a separate thread but which may be called from an application program. The Thread Directory Service offers a series of operations such as REGISTER, DELETE, QUERY, and others. When a new Service Thread is made available to the computer system, it can register its service by calling the Thread Directory Service specifying a REGISTER operation and providing the required information along with any optional information or attributes. Alternatively, a separate application can register other Service Threads available to the computer system by calling the Thread Directory Service and specifying a REGISTER operation along with the appropriate information. This permits a separate application program to provide this information without requiring the Service Thread to register itself. Duplicate entries in a given Thread Service Directory are not permitted. In this instance, the Thread Directory Service will return an error indication to the registering thread. In registering the Service Thread, the Thread Directory Service will assign a unique Thread Communication Identifier to be associated with the Service Thread. The Thread Directory Service will then return this identifier to the thread registering the service. A Service Thread can subsequently request that its entry is to be deleted from the Thread Service Directory by calling the Thread Directory Service and requesting a DELETE operation. Alternatively, a separate application thread, with appropriate permissions can perform the same operation. A thread can query the information in the Thread Service Directory by calling the Thread Directory Service specifying a QUERY operation and providing zero or more components of an entry on which the Thread Service Directory is to search for. This information is then made available to the requesting thread. A special Thread Directory Administrator Service is also provided to the owner of the Thread Directory Service to perform various administrative functions such as report generation, directory reordering, billing, and trouble reporting. The Thread Directory Service and its components provides for software what the telephone companies provide for their end users. The entire Thread Directory Service and its components are implemented through software and require no physical wire connection as does the telephone to use its service with the exception of any internal computer hardware. Note that the Thread Directory Service and its representation of the Thread Service Directory can be maintained on separate computer facilities connected through some form of a communication channel such as, but not limited to, a network, a telephone modem, a direct link, fiber connection, or wireless connection. The only caveat is that there must be some form of communication available between these computer systems. Additionally, it is possible for the Thread Directory Service to establish communications through several computer systems to ultimately reach one or more additional Thread Service Directories. Thread Communication Service The Architecture The Thread Communication Service (TCS) is a computer software method to dynamically administer the communications of two or more Minor Services of an Application Process. In this context, the Minor Services are referred to as communication points. A communication point can request the TCS to connect it to another communication point and in doing so, the TCS is said to have established a Thread Communication Link (TCL) between the communication points. Through the TCL, a communication point can send data to the connected communication point, and, can receive data from the connected communication point. When a communication point no longer needs the TCL, it notifies the TCS to disconnect the TCL. Communication Primitives Communication primitives are the low level mechanism used to transmit and receive data between two or more communication points. The communication primitives are constructed using low level operating system interfaces which provide the underlying connectivity and synchronization requirements. To use a communication primitive with the Communication Manager, the communication primitive must provide the following operations: CREATE: allocates and initializes a new copy of the communication primitive DESTROY: de-allocates a copy of the communication primitive SEND: sends data out to the communication primitive and notifies receiver of pending message RECEIVE: receives data from the communication primitive RECONNECT: provides a method to cycle a communication primitive with a NULL message CONNECT: a special method for perform a connection DISCONNECT: a special method to perform a disconnect SUSPEND: a special method to suspend the execution of this type of communication primitive RESUME: a special method to resume the execution of this communication primitive Two examples of communication primitives are the: queueConditionThread and queueConditionProcess. The queueConditionThread provides a communication primitive between Application Services executing in the same address space, whereas a queueConditionProcess provides a communication primitive for use between Application Processes executing in disjoint address spaces. queueCondition Thread Operations The following are queueConditionThread operations: CREATE: allocate the storage space for a QueueCondition primitive and initialize the message queue, the condition variable and the mutex DESTROY: de-allocates the storage space of a queueConditionThread SEND: locks the message queue, posts the message to the queue, broadcasts the condition of the queue has changed and unlocks the queue RECEIVE: locks the message queue, reads the message from the queue, and unlocks the queue RECONNECT: locks the message queue, posts a NULL message to the queue, broadcasts the condition of the queue has changed and unlocks the queue queueConditionProcess Operations The following are queueConditionProcess operations: CREATE: allocates the storage space for a queueConditionProcess primitive in a shared memory segment, or a mapped memory region and initialize the message queue, the condition variable and the mutex DESTROY: de-allocates the storage space of the queueConditionProcess primitive from the shared memory segment, or the mapped memory region SEND: locks the message queue, posts the message to the queue, broadcasts the condition of the queue has changed and unlocks the queue RECEIVE: locks the message queue, reads the message from the queue, and unlocks the queue RECONNECT: locks the message queue, reads a NULL message from the queue, and unlocks the queue The TCS maintains a list of available communication primitives for use by the communication points. This list is referred to as the Communication Primitives List. The queueConditionThread and queueConditionProcess primitives are added to this list. Each member of this list is a communication primitive and contains references to the available operations for this primitive. The Application Process can add a member, delete a member, or query member information from the Communication Primitive List. Communication Primitives can be added for all low level physical networks, and for higher level OSI protocols. These include NetWare, TCP/IP, X.25 communications and the likes. The only requirement is that the communication primitive provide the operations described above. The Application Process can request the TCS to REGISTER a communication primitive for use in subsequent communications. The communication primitive is identified by: 1) its address within the operating system, or 2) by its reference name supported by the underlying operating system, such as a shared object from a shared library, or, 3) the Application Process can request the communication primitive to be registered in the Thread Directory Service (see the description of TDS), or 4) the Application Process can request the BINDER SERVICE to bind the identifiable name to an entity understood by the BINDER SERVICE. The Communication Primitive should, however, be a loadable module that the underlying operating system can load as part of the Application Process requesting a connection to a communication point, as described below. The list of Communication Primitives available to the Application Process can be retained in memory, or, retained in a file on a storage medium (disk), or, retained in the TDS, or, retained in an Application Process accessible to the requesting Application Process. Registering Communication Points The Application Process can requests the TCS to REGISTER a Minor Service as a communication point. The Minor Service is identified by: 1) its address within the operating system, or, 2) by its reference name supported by the underlying operating system, such as a shared object from a shared library, or, 3) the Application Process can request a Minor Service to be registered in the Thread Directory Service (see the description of TDS), or 4) the Application Process can request the BINDER SERVICE to bind the identifiable name of the service to an entity understood by the BINDER SERVICE, or, 5) by other means supported by the underlying operating system to ensure that the operating system can resolve the reference (i.e., the binding of the name is done by the operating system when the name is referenced in a connection). In the registration process, the communication point can be identified as either a Sender communication point, a Receiver communication point, or as both a Sender and a Receiver communication point. The registration process can also permit the Application Process to specify the desired low level communication primitive to use when the communication points is to Receive communications, and the communication primitive to use when the communication point is to Send communications. The specifications for the low level communication primitive can include: 1) its address within the operating system, or, 2) by its reference name supported by the underlying operating system, such as a shared object from a shared library, or, 3) the Application Process can query the list of available communication primitives from the TDS, or from the Application Process itself, or, 4) the Application Process can request the BINDER SERVICE to bind the identifiable name of the communication primitive to an entity understood by the TCS, or, 5) by other means supported by the underlying operating system to ensure that the operating system can resolve the reference (i.e., the binding of the name is done by the operating system when the name is referenced). The list of registered communication points can be retained in memory, or, retained in a file on a storage medium accessible to the computer system, or, retained in the TDS, or, retained in an Application Process accessible to the requesting Application Process. Connecting Communication Points The Application Process can request the TCS to CONNECT two communication points with a TCL. In specifying the communication points, the TCS ensures that one communication point is a Sender communication point and the other communication point is a Receiver communication point. Further, the Communication Manager ensures that the Sender communication point and the Receiver communication point both use the same underlying synchronization primitive for connectivity and synchronization. If either condition is not satisfied, the Communication Manager will abort the request and notifies the Application Process of the error condition. Communication Point Selection The selection of the communication points is determined by the implementation which could include: 1) the Application Process provides the name (and possibly the location) of the Minor Service, or, 2) the Application Process calls the TDS to search for a communication point based on specific criteria, or, 3) the Application Process uses the BINDER SERVICE to bind an arbitrary named representation to an entity understood by the TCS, or, 4) the Application Process uses the underlying operating system implementation to resolve the name of the entity. Regardless of the method used, the TCS must be able to resolve the name and location of the communication point. If the TCS cannot determine the name and location of the first communication point, it will call the TDS to determine if the name represents a Thread Communication Identifier as described in the Thread Directory Service (TDS) section of this application. Creating Communication Points If necessary (based on registration data; see the section on TDS), the TCS will start an invocation of a communication point as a separate thread of control. The invocation of a communication point can be as a separate process, or, as a separate thread. In either case, the TCS will begin the invocation of the Minor Service if the Minor Service must be executed, and if there are no administrative constraints, such as the number of instances of runnable Minor Services of the specified type has been exhausted (See the section on TDS). Alternatively, the Application Process can request that the TCS CREATE an instance of a particular Minor Service without specifying a communication point that should be attached to it. This permits the TCS to begin the execution of the communication point, subject to the constraints in the preceding paragraph), and permit the communication point to perform some processing prior to having a connected communication point. This is particularly useful for daemon Minor Services performing housekeeping (memory management, etc). At a later time, the Application Process can request the TCS to connect a communication point to this CREATED communication point. In creating the Minor Service, the requesting Application Process can specify if the Minor Service is to be executed as a Sender, Receiver, or both. This information can be compared against the registered information to ensure the Minor Service has desired communication capability. The TCS performs the following actions: 1) locate the requested service and complain if it cannot be found; otherwise establish a thread communication link for this communication point (allocates memory and initializes) and record the location of the Minor Service communication point. 2) if the Minor Service communication point has the capability to send: a) locate the communication primitive used by the Minor Service to send. b) create an instance of the communication primitive (allocate memory and initialize). This is accomplished by executing the communication primitive's CREATE operation. c) set the minimum threshold value (when there are this many messages waiting to be retrieved from the connected communication point, then resume the execution of this communication point). Note that a default value of zero discontinues this feature. d) set the maximum threshold value (when there are this many messages having been sent, but still not received by the connected communication point, then suspend the execution of this communication point). Note that a default value of zero discontinues this feature. e) load the communication primitive into memory if not already available. f) this information (related to step 2) is stored in the Minor Service communication point's thread communication link area for the sender. 3) if the Minor Service communication point has the capability to receive: a) locate the communication primitive used by the Minor Service to receive. b) create an instance of the communication primitive (allocate memory and initialize). This is accomplished by executing the communication primitive's CREATE operation. c) set the minimum threshold value (when there are this many message waiting to be received, then resume the execution of the sender). Note that a default value of zero discontinues this feature. d) set the maximum threshold value (when there are this many messages waiting to be received, then suspend the sender). Note that a default value of zero discontinues this feature. e) load the communication primitive into memory if not already available. f) this information (related to step 3) is stored in the Minor Service communication point's thread communication link area for the receiver. 4) using the located communication point information, start an instance of the communication point and notify it of the communication control structure as defined above. Connecting Communication Points The Application Process can request the TCS to connect two communication points such that the communication points can communicate with each other. If either communication point is not currently active, the TCS will CREATE the missing communication point (see Creating Communication Points). When both communication points are created, the TCS will link the two communication points based on the specified communication direction which is given as one of: Direction 1) the request is to connect two communication points with each communication point being able to send and receive, or Direction 2) the request is to connect one communication point to send and the other communication point to receive, or Direction 3) the request is to connect one communication point to receive and the other communication point to send, or Direction 4) the request is to connect one communication point to neither receive nor send, and the other communication point to neither receive nor send; thus ensuring the specified communication points are simply CREATED. For the purposes of describing the connection process, with reference for example to FIG. 9, we describe the case of CP-A being connected to CP-B using communication direction 1 as described above: step 1) add CP-B's receiver to CP-A's senderList. step 2) add CP-A's sender to CP-B's receiverList. step 3) add CP-A's receiver to CP-B's senderList. step 4) add CP-B's sender to CP-A's receiverList. step 5) if the CP-A service is idle, then reactivate it. step 6) if the CP-B service is idle, then reactivate it. For the case of CP-C being connected to CP-D using communication direction 2, as described above, then step 1) and step 2) are not completed. For the case of CP-E being connected to CP-F using communication direction 3, as described above, then step 3 and step 4 are not completed. For the case of CP-G being connected to CP-H using communication direction 4, as described above, then step 1), step 2), step 3) and step 4) are not completed. In this manner, the TCS establishes a communication link between the two communication points. In specifying a CONNECT request, the Application Process may specify only one of the two communication points. If a Sender communication point is not specified, then the requesting Application is Process is assumed to be the Sender communication point. If the specified Receiver communication point is not currently executing, then the TCS will issue a CREATE operation for the Receiver communication point. Alternatively, if the Application Process does not specify a Receiver communication point, then the Application Process is assumed to be the Receiver communication point. If the specified Sender communication point is not currently executing, then the TCS will issue a CREATE operation for the Sender communication point. Once connected, the Receiver communication point uses the RECEIVE operation of its Receiver to Receive message. The Sender communication point uses the SEND operation of its Sender to send message. Note that certain communication primitives require specialized initializations for establishing connections and hence, if the communication primitive contains a CONNECT function pointer, then the communication primitive's CONNECT function will be executed before any other steps in this section. Suspending Communication Points The Application Process can request the TCS to SUSPEND a TCL currently in use by two communication points. In suspending the TCL, the TCS will temporarily suspend the execution of the Sender communication points. Alternatively, if the Sender communication primitive has a special SUSPEND operation defined, then the TCS will invoke that SUSPEND operation. Resuming Communication Points The Application Process can request the TCS to RESUME a TCL currently in the suspended state. In resuming the TCL, the TCS will resume the execution of the Sender communication points. Alternatively, if the communication primitive of the SENDER has a special RESUME operation defined, then the TCS will invoke that RESUME operation. Disconnecting Communication Points The Application Process can request the TCL to DISCONNECT one or more communication points using a TCL. In performing the disconnect, the TCS temporarily suspends the communication points, removes the current TCL, and restores the prior TCL associated with the communication points. The execution of the communication points are then resumed. The requesting Application Process can specify if the TCS is to terminate either or both of the communication points participating in the thread communication link being disconnected. For each point being disconnected, the TCS will perform the following actions: 1) if the receiver component of the communication point is defined and the receiver communication primitive has a DISCONNECT operation defined, then the TCS will invoke that operation. 2) if the sender component of the communication point is defined and the sender communication primitive has a DISCONNECT operation defined, then the TCS will invoke that operation. Destroying a Communication Point The Application Process can request the TCS to DESTROY a communication point. In doing so, the TCS will eliminate the registered information regarding this communication points from its storage. If the communication point is currently executing, then the TCS sends a signal to the communication point to terminate. On some implementations, a special message may be sent by the TCS to the communication point notifying it that it is to terminate. Reconnecting a Communication Point An Application Process can request the TCS to RECONNECT a specified communication point. In doing so, the TCS will send a NULL message to the communication point. This is useful to determine the state of the communication point and to cycle the communication primitive. Executing a Communication Point The Application Process can request the TCS to EXECUTE a specified communication point. In doing so, the TCS will examine its TCL for a communication point having the specified name. If the communication point is not currently executing, then TCL will issue a CREATE request for the specified communication point. The communication point's thread is then specified to resume execution. In this manner, a daemon Minor Service can be created. Note that if the communication point is a Receiver communication point, then the communication point will presumably block on its first call to its communication primitive's RECEIVE operation. Alternatively, if the communication point is a Sender Minor Service, then the communication point will presumably continue to send messages using its communication primitive's SEND operation, and these message will remain until a Receiver communication point is connected. EXAMPLE TCS Application Program FIG. 14.A provides an example of registering communication points (Minor Services) and connecting the Application Process to these communication points to take advantage of the Minor Service. FIG. 14.B contains sample input for a Minor Service called the broker service. FIG. 15.A contains the communication data header file used by the communication data module with the example TCS Application Program. FIG. 15.B contains an example communication data module to be used with the example TCS Application Program. FIG. 16.A contains the communication point header file used by the communication point module with the example TCS Application Progra. FIG. 16.B contains the communication point module providing the ability to create a communication point in the example TCS Application Program. A communication point can also be destroyed using the Destroy function of this module. FIG. 17.A contains an example communication registration header file used by the communication registration module with the example TCS Application Program. FIG. 17.B contains an example communication registration module to register a Minor Service available to the example Application Process. FIG. 17.C contains the example compoint header file used by the example compoint module with the example TCS Application Program. FIG. 17.D contains the example compoint module describing memory management functions representing the communication point with the example TCS Application Example. FIG. 18.A contains an example thread condition variable header file used by the example thread condition variable module with the example TCS Application Program. FIG. 18.B contains an example thread condition variable module for use with the example TCS Application Program. FIG. 19.A contains an example generic communication point header file for use with the example TCS Application Program. FIG. 19.B contains an example generic communication module for use with the example TCS Application Program. FIG. 20.A contains an example thread link list header file for use with the example TCS Application Program. FIG. 20.B contains an example thread link list module for use with the example TCS Application Program. FIG. 21.A contains an example of a mutex thread log header file for use with the example TCS Application Program. FIG. 21.B contains an example of a mutex module for use with the example TCS Application Program. FIG. 22.A contains an example of a thread mutex module header file for use with the thread mutex module with the example TCS Application Program. FIG. 22.B contains an example of a thread mutex module for use with the example TCS Application Program. FIG. 23.A contains an example of a communication primitive header file for use with the communication primitive module listed in FIG. 23.B. FIG. 23.B contains an example of a communication primitive module providing a Create, Destroy, Load, and Unload function for use with the example TCS Application Program. FIG. 23.C contains an example of a communication primitive's data header file for use with the communication primitive's data module described in FIG. 23.D for use with the example TCS Application Program. FIG. 23.D contains an example of a communication primitive's data module for use with said example TCS Application Program. FIG. 24.A contains an example of a thread queue condition header file for use with the thread queue condition module described in FIG. 24.B for use with said example TCS Application Program. FIG. 24.B contains an example of a thread queue condition module for use with said example TCS Application Program. FIG. 25.A contains an example of a registry header file for use with the registry module described in FIG. 25.B for use with the said example TCS Application Program. FIG. 25.B contains an example of a registry module for use with the said example TCS Application Program. FIG. 26.A provides an example of a minor service communication module providing a weather service as an available Minor Service for the Application Process to register, create, and subsequently connect to, and a broker service as an available Minor Service for the Application Process to register, create, and subsequently connect to. These are to be used with the said example TCS Application Program. FIG. 27.A provides an example of a thread reader-writer lock header file for use with the thread reader-writer module described in FIG. 27.B for use with the said example TCS Application Program. FIG. 27.B provide an exam | ||||||