Access-method-independent exchange with communication request6922705Abstract 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 1. In the Internet, a method for a service provider application service executing on a service provider computer to provide a directory service of application services accessible using an Internet Protocol, the method comprising: Description A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the PTO patent file or records, but otherwise reserves all copyright rights whatsoever. Communication primitives are registered with the Thread Communication Service for the specific operating system the TCS is executing on. The name, the location, and certain characteristics describing the communication primitive are retained by the TCS for subsequent use. In this context, the communication primitives become a reusable asset, needing to be developed and tested only one time. Each communication primitive has a shared object, referred to as the communication primitive object, describing the location of the various operations to be applied when using this primitive type. All primitives have the same communication primitive object structure. The TCS will load the communication primitive object at runtime only when requested for use by a communication point. In a sense, the communication primitive can be thought of as analogous to the physical connection of a telephone on a phone network. A twisted pair telephone would use one primitive while a cellular telephone would use a different primitive. The Communication Points A process can register zero or more communication points with the TCS. Each point is said to describe a service. Note, however, that a service can be a client of a different service, or a client of itself. The registration process notifies the TCS as to the name and location of the service, the default primitive to use for communicating to the service, and the default primitive to use when receiving messages from the service. The registration process also identifies certain characteristics of the communication point. These characteristics include system-dependent information, implementation- dependent information, and usage-dependent information. The characteristics include: Idle: If service is to be idle on non-connects The registered communication points are then retained by the TCS for subsequent use. When a communication point has been registered, a process can request to be connected to the service. Using the telephone model example, a communication point is the equivalent of a destination telephone. That is, you can call an individual only by knowing the attributes describing that individual, such as a telephone number. The registered characteristics would be similar to your name and address being entered into the phone book. The TCS calls the TDS, if requested, to record the registered communication point in the TDS. Connecting Communication Points When a process is executing, it may request the TCS to connect it to a communication point. For the intraprocess communication version of the TCS, the service executes as a separate thread of control. In the interprocess communication version of the TCS, the service executes as a separate process. There are several modifications permitted. First, when a communication point is registered, the registering process can identify the communication point as a public point. As such, only one instance of the service needs to be executing at any time. All processes requesting to use this point will share the same primitive. Alternatively, a service can be registered as a private service, in which case each process requesting communication to the service will be connected to their own instance of the service. Finally, when a service is initially registered, a maximum number of connection points can be preset. When this limit is reached, then all new processes requesting access to the service will be denied, until such time as the number of current instantiations of the service falls below the threshold. A single process can be connected to multiple services simultaneously. This can be accomplished through a single connection, or, though multiple connections established by the process with the various services. In the former case, each time the process sends data, the data is actually sent to all services using the communication link. In the latter instance, only a single destination is connected to the communication link. Again, using the telephone model as an example, this is equivalent to your calling a business associate on your telephone system. While connected, you can put the call on hold and dial another associate, or you can conference the associate in on the same call. Mixing the Intraprocess and Interprocess Models On systems supporting multiple threads of control within a single process address space, the TCS uses a special communication point called the intra.sub.-- p communication point to execute commands on behalf of the TCS within that address space. That is to say, when the application process makes its initial request to the TCS, the intra.sub.-- p communication point will bootstrap itself as a communication point within the application process address space. The TCS then issues specific commands to the intra.sub.-- p communication point who executes these commands on behalf of the TCS. The use of the intra.sub.-- p communication point is essential to permit intraprocess communication points while supporting interprocess communication points at the same time. When an application makes a request to connect with a registered communication point, and that point must execute as a separate thread of control within the address space of the requesting process, then the TCS must have a method to satisfy the request. Since the TCS itself is executing in a different address space, it needs a worker thread executing within the requesting process's address space to spawn the requested communication point thread on its behalf. The TCS also provides a method for a intraprocess communication point to be treated as an interprocess communication point. When an application process makes a request to use an intraprocess communication point as an interprocess communication point, the TCS will execute a generic front end loader to initialize the address space of the new process, and then invokes the specific thread requested in that address space. Communicating with a Service Once connected, a process can send messages to a service. The primitive to send this message must accept the message, the size of the message, and the destination. Similarly, a process can request to receive a message from a service. In receiving the message, the process must identify the service it is to receive the message from, the maximum length of a message it can consume, and the actual size of the message returned. Note that from the point of view of the application process, there is no need to be aware of the underlying physical primitive in use. Instead, the application sees that a Thread Communication Link is provided and need not deal with how it is provided. Disconnecting from a Service A process can request the TCS to disconnect it from a particular service. When this happens, the service can be terminate by the TCS if this was the only process connected to it. Otherwise, the service remains executing. Using TCS for Remote Communication In the TCS model, a special communication point can be created to monitor a communication device available to the computer system. This communication point acts as the conduit to send messages to, and receive messages from the communication device. The primitive used for this communication point wraps the identifier of the sending process, along with the identifier of the receiving process, around the message prior to sending the data out on the communication device. Similarly, when this communication point receives a message from the communication device, it unwraps the message to determine the process that the message is to be sent to. In this sense, the communication point is the conduit for communications with external systems. The Broker Service When a communication point is registered, the communication point may have a specific communication primitive required to either send or receive message. This poses a challenge for another communication point to connect if the requesting communication point requires a different communication primitive. When this happens, the TCS will search for a broker communication point which can convert the messages from the first primitive type to the second primitive type. The broker service, if necessary, will be inserted between the requesting communication point and the requested service communication point. The TCS Model In the TCS model, processes are nothing more than communication points. Application programs residing on a disk are also viewed as communication points (albeit the application program must be started for execution by the TCS). This powerful model enables application software development which may effectively commoditize software. The Thread Directory Service The Thread Directory Service is an extension of the Thread Communication Service offering persistence to the registered communication primitives and registered communication points. When a communication point is registered with the TDS, it is assigned a unique communication identifier. Numerous additional characteristics of the service can be registered within the TDS such as: Of the foregoing, items 2 and 4 are essential; the others are optional, though desirable. A process can request information from the Thread Directory Service specifying the desired search criteria. This is similar to dialing 411 and requesting a telephone number for an individual based on their name and street address. Each TDS has its own unique identifier. The registered communication points are assigned unique communication identifiers based on the TDS's identifier. Thus, communication points are fixed in the universe in this sense. When the Thread Communication Service works in conjunction with the Thread Directory Service, all communication points to be connected are located via their communication identifiers. When a connection is requested to a particular communication point, the requesting process specifies the unique communication identifier of the desired service. The TCS causes the identifier to be looked up in the TDS to determine how to connect to the service and then provides the actual connections. The Thread Communication Switching Service To minimize the message flow, a Thread Communication Switching Service is provided as a special instance of a communication point. It accepts multiple communication links redirecting the communications from one communication point to the appropriate destination communication point. As shown in FIGS. 1 to 4, a TCSS can communicate with communication points, or, to another TCSS. Dynamic Configuration Management Dynamic Configuration Management is a rule-based system for specifying components of software to use in constructing a Dynamically Configured Application Program. The components of software are loaded according to the specified rules and are subsequently executed. The Application Process constructs the Dynamically Configured Application Program in the Dynamic Configuration Management (DCM) by specifying zero or more 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. The Application Process can specify zero or more data files referred to as Virtual 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. The specification of a RULE includes the following information, although additional information may be incorporated by the implementation: 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. The Universal Rules are specified by the Application Process. In either case, however, the Rules contain the minimum information described above. A series of 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 include: Note, however, that additional Flow Rules may be incorporated by the implementation. A Dynamically Configured Application Program is therefore constructed by specifying Universal Rules as Prerequisites Rules of the Flow Rules. In evaluating a Flow Rule, the DCM will ensure that all Prerequisite Rules of the Flow Rule are evaluated first. 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. When the current rule has no Prerequisite Rules listed, and the current rule has never been 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. 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 associates the RULE name with an entity understood by the DCM. This is called the binding process. 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 binding of the RULE name to an entity understood by the DCM is determined by the RULE's attributes. In this sense, the Application Process can specify how the RULE is to be interpreted by the DCM. Through the use of this 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: The Configurable Application Program Service The Configurable Application Program Service provides a method to dynamically reconfigure an application process. Through the CAPS, a communication point can be dynamically replaced by another communication point. This is important for real- time systems in which you would not want to terminate the application process to replace a defective module. The Application Process uses the Configuration Administrator Minor Service to administer zero or more components of software from shared libraries. Each component is said to offer a Minor Service. The specifications for the administration of the Minor Services can be provided directly by the Application Service, or, indirectly through a data store monitored by the Configuration Administrator. These specifications can instruct the Configuration Administrator Minor Service 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 Configuration Administrator Minor Service. The Configuration Administrator Minor Service provides the following operations: Note that the Configuration Administrator Minor Service operations can be specified to occur at set time intervals; at predefined time periods; as a result of external events; or, as a result of internal events. Events, in this context are registered with the Configuration Administrator Minor Service to denote their occurrence. The advantage is that an Application Program can be constructed and executed and subsequently reconfigured to take advantage of newly installed minor software services while the Application Process is executing. The implications of such a system are that: BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1. Diagram showing Simple Thread Communication Link between TCP-1 and TCP-2. FIG. 2. Diagram showing Two Thread Communication Links. FIG. 3. Diagram showing Thread Communication Switch and Three Thread Communication Links. FIG. 4. Diagram showing Thread Trunk Line. FIG. 5. Diagram showing Example Dynamically Configured Application Program Rules. FIG. 6. Diagram showing Example Application Process. FIG. 7. Diagram showing Reconfiguring an Application Process. FIG. 8. Diagram showing Active NEE Takes Input from NEEM, Output Read by Minor Service Reader Threads. FIG. 9. Diagram showing Directed Communication Types between Communication Points FIG. 10. Diagram showing Theoretical Open Systems Interconnection (OSI) Model. FIG. 11. Pseudo Procedural Code for Example of Threaded State Machine. FIGS. 12.A and 12.B State Machine Representation of Example of Threaded State Machine. The following figures show exemplary source code in the C programming language, as implemented for Unix 4.2 MP TLP/5: FIG. 13. Examples of Source Code for Binding Services. FIG. 13.A Commands Used to Compile Binder Example. FIG. 13.B Running Binding Service Example. FIG. 13.C Sample Output from Binding Service FIG. 13.D Simple Services. FIG. 13.E Registering Binding Method and Binding Arbitrary Named Represenatives. FIG. 13.F Header File Declaring Binding Method. The following figures represent examples of data: FIG. 13.G Examples of Pattern, Transformation, Locate, Status and Query for a Shared Object in a Shared Library. FIG. 13.H Example of Shared Library Binding Method. FIG. 13.I Example of Shared Library Binding Method including Pattern, Transformation, Locate, Status & Query. FIG. 13.J Example of Data Structures Header File. FIG. 13.K Example of Registering a Binding Service Method to Make Such Method Available to Binding Services (BSV). FIG. 14. Samples of Particular Services. FIG. 14.A Sample Communication Points Module. FIG. 14.B Sample Output for Broker Data. FIG. 14.C Sample Output for Weather Data. The following figures show exemplary source code: FIG. 15. Examples of Communications Modules. FIG. 15.A Communication Data Header File. FIG. 15.B Communication Data Module. FIG. 16. Compoints. FIG. 16.A Compoints Header File. FIG. 16.B Compoints Module. FIG. 17. Communications Registration. FIG. 17.A Communications Registration Header File. FIG. 17.B Communications Registration Module. FIG. 17.C Communications Point Header File. FIG. 17.D Communications Point Module. FIG. 18. Thread Condition Variables. FIG. 18.A Thread Condition Variable Header File. FIG. 18.B Thread Condition Variable Module. FIG. 19. Generic Compoints. FIG. 19.A Generic Compoint Header File. FIG. 19.B Generic Compoint Module. FIG. 20. Thread Link Lists. FIG. 20.A Thread Link List Header File. FIG. 20.B Thread Link List Module. FIG. 21. Mutex Thread Log. FIG. 21.A Mutex Thread Log Header File. FIG. 21.B Mutex Thread Log Module. FIG. 22. Thread Mutex. FIG. 22.A Thread Mutex Header File. FIG. 22.B Thread Mutex Module. FIG. 23. Communication Primitives. FIG. 23.A Communication Primitive Header File. FIG. 23.B Communication Primitive Module. FIG. 23.C Communication Primitive Data Header File. FIG. 23.D Communication Primitive Data Module. FIG. 24. Thread Queue Conditions FIG. 24.A Thread Queue Condition Header File. FIG. 24.B Thread Queue Condition Module. FIG. 25. Registry. FIG. 25.A Registry Header File. FIG. 25.B Registry Module. FIG. 26. Minor Services Communication. FIG. 26.A Minor Services Communication Module. FIG. 27. Thread Reader-Writer. FIG. 27.A Thread Reader-Writer Lock Header File. FIG. 27.B Thread Reader-Writer Lock Module. DETAILED DESCRIPTION OF THE INVENTION The various aspects of the present invention can be implemented on a digital computer running an operating system that supports runtime-loadable software modules, such as Unix SVR4.2 MP TLP/5 (Unix System Laboratories, a subsidiary of Novell Corporation). Such a computer may, for example, be a Gateway 2000 computer having an Intel 486 microprocessor, or any other hardware compatible with that operating system. Many other operating systems may alternatively be used, including SunSoft Solaris 2.X, Microsoft Windows 95, Microsoft Windows NT, IBM's AIX, and Hewlett-Packard HP-UX, on any hardware compatible therewith. See, e.g. Solaris 2.2, SunOS 5.2 Reference Manual, Section 3, Library Routines (A-M) and (N- Z) (SunSoft Part No. 801-3954-10, Revision A, May 1993). Configurable Application Program Service The term Application Program is used to describe a software application residing on a medium accessible to the computer system. An Application Process is said to provide some well-known service, e.g. wordprocessing, spreadsheet, graphics, etc. The Application Program may be devised to provide a series of one or more Minor Services and a Primary Service, which collectively constitute the Application Service. The term Application Process, as used in this document, refers to the overall computer representation of the Application Program's execution. In this definition, the term Application Process is defined to incorporate all processes of various "weight" including, but not limited to, heavy weight, medium weight, and light weight processes relating to the Application Service. A heavy-weight process executes in its own address space, whereas medium-weight and light-weight processes may execute within the same address space. The Application Process may constitute one or more of these processes. Each of these processes is said to have a Thread of execution. A Thread, in this context, represents an execution stream of the Application Process. The notion of a Thread can be provided by the underlying operating system, referred to as kernel-supported threads, or can be provided at the application level, referred to as user-level threads, or can be a mixture of the two. For the purposes of this description, these will collectively be referred to as Threads. Note that in a distributed environment, one or more of these Threads may be executing on a remote computer system. The Application Process may be confined locally to the computer system on which the Application Process was initially started, or may have its execution threads distributed among various computer systems accessible to the computer system on which the Application Process was initially started. When a user of the computer system requests to execute an Application Program, the Application Program is loaded into the computer's memory having a single Thread of execution. This initial Thread may then create additional Threads on the local computer system, or possibly on a remote computer system. The creation of a new Thread requires the Application Process to specify the starting point of the new Thread. In procedural computer languages, for example, this would require the requesting Thread to specify the address of the procedure to begin as a new Thread. On some implementations, the new Thread must be identified by its Application Program name. The implication herein is that the Application Program is created (i.e. compiled) with this information present. The Application Program is therefore a static representation of a well-known functionality and is not easily able to dynamically load additional Threads unknown at the time the Application Program was developed. There are, however, certain Applications Programs which provide a listing of installed computer Application Programs either through a textual display or through a graphical representation referred to as an icon. Additionally, certain Application Processes search specific directories for available Application Programs to execute as Application Co-Processes, but again, the criteria for their representation is static and unalterable by the end user. In the textual representation, the name of the Application Program is provided with zero or more additional information components such as the owner, the size, and/or execution privileges. This listing is shown to the user, who may then enter the name of the application to execute. Alternatively, when using a graphical user interface with an Icon, the name of the Application Program, its specific location on the computer system, and other information is required to execute the Thread. A further limitation of the Icon is that one Application Process can be started by selecting the Icon, but that Application Process cannot select a new Icon to execute as an Application Co-Process. That is to say, the Icon is a graphical representation for the end user to select. A limitation of both the textual and graphical representation of the available Application Programs is that the information displayed to the user is dependent on the underlying operating system implementation. Certain operating systems will display the name, the size in bytes, the owner, the date created, and execution mode while others will display a subset of this information and possibly other system- dependent information. Regardless, however, the user cannot easily associate additional information with the installed application in a useful manner. Finally, many users have manually created what has become known as README files to describe this information. There are many instances in which an Application Process will select different Minor Services depending on installed features, additional software available to the computer system, or due to other factors external to the Application Process itself. Currently, the only provisions to support such run-time changes to the Application Process are to design the Application Program with the appropriate logic. This disadvantage to this approach, however, is that it limits the ability of the Application Process to dynamically configure itself based on available Minor Services, or due to other factors external to the Application Process itself. Additionally, the Application Process cannot appropriately handle cases in which an available Minor Service may conflict with another Minor Service. Once the incompatibility is detected, the Application Process will simply print an error message and terminate its processing. Finally, an Application Process which locates available Minor Services has no simple provision for executing these Minor Services, communicating with these Minor Services, nor ensuring a proper ordering of the execution of these Minor Services. The prior art therefore does not provide the necessary mechanisms for an Application Process to dynamically alter its execution based on Minor Services available either locally or remotely to the computer system. Additionally, the prior art does not provide the necessary mechanisms for the same Application Program to behave differently on two separate computer system offering two very different sets of Minor Services without this logic being introduced into the Application Program from the onset. The prior art also does not provide the mechanisms for resolving feature conflicts in which there are two or more installed Minor Services available to the Application Process, but whose use are mutually exclusive. The Application Program will typically be designed to execute the first feature ("Feature A"), and then the second ("Feature B"). If Feature B conflicts with the use of Feature A, there are no simple remedies to support a resolution. Consider, for example, that the Application Process performs various initialization sequences required for Feature A. The Application Process may then also execute various initialization sequences for Feature B. During the initialization sequences for Feature A, certain values may be set in the Application Process which are inappropriate in the case of Feature B being present. Within the prior art there are various approaches for configuration of Application Programs. Typically referred to as Software Construction Utilities, these approaches provide a rule-based system describing how an Application Program should be constructed from its corresponding application programming language source code. Examples of Software Construction Utilities include: Here, the source code provides the necessary algorithm, logic, and instructions in a human-readable form. This source code must then be compiled into an Application Program which the computer can then load and execute. The process of determining the necessary actions to create the Application Program are typically controlled by a software construction Application Program (a "make" utility) which reads specifications from a data file known as a "makefile". This process is well known and well understood in the computer programming profession. The makefile contains specification of the form: ACTION to denote that a target is dependent on prerequisites. If one or more of the prerequisites is newer than the target, then the ACTION is performed to construct the target. Each prerequisite can be listed as a target of another rule. As an example, consider: In this example, the rule to construct the target "A" shows it has a dependency on prerequisites "B" and "C". Note, however, that "B" is dependent on "b" according to the second rule, and that "C" is dependent on "c" based on rule 3. If "c" has changed since the last time "C" was constructed, then the ACTION for rule 3 would be performed to reconstruct C. Similarly, if "b" has changed since the last time "B" was constructed, then the ACTION for rule 2 would be performed to reconstruct B. Note that the ACTION for rule 2 and the ACTION for rule 3 could in fact occur simultaneously since there are no other dependencies on these rules. After rule 2 and rule 3 has completed, then rule 1 can continue. Here, if "B" or "C" has changed since the last time "A" has been constructed, then the ACTION for rule 1 will be performed to reconstruct A. The issue of software configuration has historically been addressed by one of the following mechanisms: Application Programs are typically designed and distributed following the Non- featuring Software model. Consider, for example, that when purchasing a Word Processing Application you receive all of the latest features available. This has the disadvantage that you are paying for features which you may not need. With "Run-Time Featuring", the Application Program consists of the monolithic representation of the application. Thus you receive a potentially large Application Program with certain portions of the Application Program inaccessible to you. Nonetheless, you receive the largest possible representation. The disadvantage to this approach is that you cannot ship the product until all features have been developed. Additionally, the customer must have enough memory and storage capacity for the entire Application Program even though only a one Minor Service may have been purchased. With Compile-Time Featuring, the source code representing the application has numerous sections delineated with conditional inclusions based on specified criteria. As an example, in the C language it is customary to use:
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 >>ARN086!>>ATT90!>>SUNS92!. >>ARN086! 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: 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 ail 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 Commmunication 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: 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.
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.
Each Binding Method must have associated with it the operations shown in Table 3.
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: Binding Service Interface The Binding Service itself provides the following methods for the Application Process: 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:
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.
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: 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: 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: 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: 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: 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: 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: queueConditionProcess Operations The following are queueConditionProcess operations: 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: 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: 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: 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. Communi | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||