Execution of application process using registry having binding methods

Abstract

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

Having thus described the invention, what it is desired to claim and thereby protect by Letters Patent is:

1. A memory for storing data for access by an application process executing on a computer in order to bind a sequence of one or more bytes to an entity understood by the application process,

the memory comprising a data structure for a registry,

the registry comprising an ordered list of binding methods, wherein at least one of the binding methods in the ordered list is a member of the group consisting of pattern matching method, name transformation method, locate method, status method and query method; and

each binding method having associated therewith an identifier describing the name of the binding method, an identifier describing the location of the binding method, and an identifier describing the order of evaluation of the binding method, thereby storing data for access by an application process executing on a computer in order to bind a sequence of one or more bytes to an entity understood by the application process.

2. The memory of claim 1, wherein said ordered list is a linked list, for determining order of precedence.

3. A method to administer information in a registry of binding methods comprising the following steps:

providing a registry data structure in a memory for storing data for access by an application process executing on a computer in order to bind a sequence of one or more bytes to an entity understood by the application process, the memory comprising a data structure for a registry, the registry comprising g an ordered list of binding methods, wherein at least one of the binding methods in the ordered list is a member of the group consisting of pattern matching method, name transformation method, locate method, status method and query method, and each binding method having associated therewith an identifier describing the name of the binding method, an identifier describing the location of the binding method, and an identifier describing the order of evaluation of the binding method; and

providing a minor service as a binding service of a computer system, said binding service including means for responding to receipt of a registration request as to a previously unregistered binding method by establishing an entry in said registry data structure, said entry including the Name, Location, and desired ordering for the previously unregistered binding method.

4. The method of claim 3, wherein said minor service is a module of a computer system, said minor service including means for responding to receipt of a Set Order request by establishing said registered binding methods in an ordered list according to said Set Order request.

5. The method of claim 4, said minor service including means for responding to receipt of an Establish Order request by establishing said binding methods in an ordered list by reading said ordered list from a Binding Service Configuration File.

6. The method of claim 4, said minor service including means for responding to receipt of a Purge Order request by eliminating references to binding methods in said ordered list.

7. The method of claim 3, said minor service further including means for responding to a bind request from an application process, wherein said bind request includes an arbitrary name representation specified by said application process, said minor service performing the following steps in response thereto:

selecting a registered binding method

connecting to said registered binding method's registered pattern matching minor service;

communicating to said pattern matching minor service said arbitrary name representation; and

receiving from said pattern matching minor service a response indicating whether or not said arbitrary name representation equates to a regular expression associated with said registered binding method.

8. The method of claim 3, said minor service including means for responding to a bind request from an application process, said bind request including an arbitrary name representation specified by said application process, said minor service performing the following steps in response thereto:

selecting a registered binding method;

connecting to said registered binding method's transformation method minor service;

communicating to said transformation method said arbitrary name representation; and

receiving from said connected transformation method a response indicating the value of the transformed name.

9. The method of claim 3, said minor service including means for responding to a bind request from an application process, said bind request including an arbitrary name representation specified by said application process, said minor service performing the following steps in response thereto:

selecting a registered binding method;

connecting to said registered binding method's Locate method minor service;

communicating to said Locate method said arbitrary name representation; and

receiving from said connected Locate method a response indicating the value of the location of said name.

10. The method of claim 3, wherein a requesting process causes an arbitrary named representation consisting of one or more bytes of memory, to become associated with an entity, wherein the method comprises the use of a multiplicity of computers, each said computer having an operating system, the operating system including interfaces providing communication connectivity wherein at least one of said interfaces is used for communicating information between the first process being the requesting process executing on a first computer and a second process being a binding service process executing on a second computer, wherein:

the requesting process causes a communication to be sent to the binding process, the communication including the arbitrary named representation and a bid request, and the binding process binds the arbitrary named representation to an entity understood by the binding process, and communicates the results thereof to the requesting process.

11. The method of claim 3 wherein at least one component of software is executed and wherein:

a) said component of software was provided by a service provider; and

b) said component of software was designed and implemented by a service provider.

12. The method of claim 3 wherein said requesting process executes at least one component of software provided by a service provider and wherein said second process executes at least one component of software provided by said service provider.

13. A method to selectively use an Application Process to provide a Binding Service comprising the steps:

causing said Application Process to provide an Ordered List comprised of binding methods;

invoking said binding methods serially until said binding method returns SUCCESS or until no more binding methods are left in said Ordered List; and

said Application Process dynamically altering said Ordered List; wherein said binding methods comprise at least one of the following: a pattern matching method, a name transformation method, a locate method, a status method, and a query method.

14. A method for using a memory for storing data for access by an application process executing on a computer in order to bind a sequence of one or more bytes to an entity understood by the application process, the memory comprising a data structure for a registry, the registry comprising an ordered list of binding methods, wherein at least one of the binding methods in the ordered list is a member of the group consisting of pattern matching method, name transformation method, locate method, status method and query method, and each binding method having associated therewith an identifier describing the name of the binding method, an identifier describing the location of the binding method, and an identifier describing the order of evaluation of the binding method wherein the binding method comprises one or more of:

a) a pattern matching method providing means to determine if the arbitrary named representation matches a specified pattern;

b) a name transformation method providing means for transforming the arbitrary named representation into a second representation;

c) a locate method providing means for locating the arbitrary named representation;

d) a status method providing means for retrieving information related to the arbitrary named representation;

e) a query method providing means for reporting the retrieved information related to the entity.

15. The method of claim 14, wherein the entity is one of:

v a) an application program;

b) an application service;

c) an application process;

d) an application process including a multiplicity of threads;

e) an application process including at least one process executing on a local computer, and one process executing on a remote computer, each process having at least one thread of execution;

f) an application process including references to application program names to be executed by said application process;

g) a client process;

h) a communication point;

i) an entity providing a service to an application process, and the entity is a component of the operating system;

j) an entity providing a service to an application process, and the entity is accessible by the operating system;

k) an entity providing a service to an application process, and the reference to the entity is resolved by the operating system.

16. The method of claim 14, herein the entity is one of:

a) a file;

b) a data file;

c) a file containing programming instructions;

d) a text file including structure definitions, each structure having a name associated therewith and one or more members, each said member having a name associated therewith an a data type.

17. The method of claim 14, wherein the entity is one of:

a) a shared library;

b) an object;

c) a function;

d) a procedure;

e) a thread;

f) a datum;

g) a user level shell.

18. The method of claim 14, wherein the entity is a service for monitoring a communication device, said entity providing access and interactions with a communication device, said interactions providing means to send messages, and to receive messages.

19. The method of claim 14, wherein the entity is one of:

a) a communication protocol provided by an operating system

b) a communication protocol supported by the underlying operating system.

20. The method of claim 14, wherein the entity is a protocol providing a set of services that permit users to communicate with each other across the entire internet.

21. The method of claim 14, wherein said entity is a communications protocol for use with communications wherein the physical connectivity is provided by at least one of:

a) a regional bell operating company;

b) a long distance carrier;

c) a cellular network provider;

d) a provider of signal-based or wireless communications;

e) a cable television provider;

f) a service provider providing physical connectivity.

22. The method of claim 14, wherein the entity is a protocol being one of:

a) a computer mail protocol;

b) an application protocol for sending and receiving computer mail;

c) a protocol for communicating with a communication device, said device being one of:

A. a cellular device

B. a radio station device

C. a television device

D. a voice device

E. a wireless device

F. a network device

G. a telephone device

H. a telephone modem device

I. a fax device

J. a pager device

d) : a protocol for communicating over a physical device provided by one of:

A. a regional bell operating company

B. a long distance carrier

C. a cellular network provider

D. a cable television industry provider

E. a wireless device provider;

e) a protocol for structuring data into packets or frames, and attaching control information to the packets or frames, such as checksums for error detection, and packet numbers;

f) a network protocol for routing datagrams to an intended destination, wherein the protocol uses a router to forward messages;

g) a communication protocol that will split a message into multiple datagrams and make sure that they all arrive correctly and reassembled for the application program at the receiving end

h) a TCP protocol;

i) an internet protocol;

j) a TCP/IP protocol;

k) a communication protocol defining the rules for communication;

l) a NetWare protocol;

m) a protocol for communicating over of physical network;

n) an X.25 protocol.

23. The method of claim 14, wherein the entity is one of

a) component of software;

b) a loadable software module;

c) a software application residing on a medium accessible to the computer system.

24. The method of claim 14, wherein the entity provides one or more

a) a minor service to an application service;

b) a service;

c) an application service said application service being one of:

A, wordprocessing

B. spreadsheet

C. graphics

D. a directory service

E. a communication service

F. a binding service

G. a dynamic configuration management service

H. a named execution environment service.

25. The method of claim 14, wherein a first process reports requested information about an arbitrary named representation to a requesting process, wherein the method comprises the use of a multiplicity of computers, each said computer having an operating system, the operating system including interfaces providing communication connectivity wherein at least one of said interfaces is used for communicating information between the processes, wherein:

the first process accesses a communication from the requesting process, the communication being a request for information on an arbitrary named representation, and then,

the first process reports the requested information to the requesting process.

26. The method of claim 25 wherein the arbitrary named representation is representative of an entity and wherein the reported information includes information describing the type of entity.

27. The method of claim 25 wherein the arbitrary named representation is representative of an entity and wherein the entity information includes information identifying characteristics of the entity.

28. The method of claim 25 wherein the arbitrary named representation is representative of an entity and wherein the reported information includes information describing the default primitive to use for communicating with the entity.

29. The method of claim 25 wherein the arbitrary named representation is representative of an entity and wherein the reported information describes one or more of:

a) system dependent information;

b) implementation dependent information;

c) usage dependent information.

30. The method of claim 25 wherein the arbitrary named representation is representative of an entity providing a service, and wherein the reported information includes information identifying if the service executes as a sibling thread, or in a disjoint address space.

31. The method of claim 25 wherein the arbitrary named representation is representative of an entity providing a service, and wherein the reported information includes information describing if the service execution is to be idled when not connected.

32. The method of claim 25 wherein the arbitrary named representation is representative of an entity, and wherein the reported information includes the name and location of the entity.

33. The method of claim 25 wherein the arbitrary named representation is representative of an entity providing a service, and wherein the reported information includes information describing when the service is to be resumed.

34. The method of claim 25 wherein the arbitrary named representation is representative of an entity providing a service, and wherein the reported information includes information describing when the service is to be suspended.

35. The method of claim 25 wherein the arbitrary named representation is representative of an entity providing a service, and wherein the reported information includes information describing how to terminate the service.

36. The method of claim 25 wherein the reported information includes a name and a location.

37. The method of claim 25 wherein the reported information includes a text description.

38. The method of claim 25 wherein the reported information includes information for using a communication primitive.

39. The method of claim 25 wherein the reported information includes information for at least one operating system interface providing communication connectivity and synchronization.

40. The method of claim 25 wherein the reported information includes a protocol for communicating with an entity, said protocol being one of:

a) a mail protocol;

b) a TCP protocol;

c) an internet protocol;

d) a TCP/IP protocol;

e) a protocol implemented in at least one layer of the OSI reference model;

f) an application protocol providing communication service;

g) a local area network protocol;

h) a protocol for network communications;

i) a protocol providing a set of services that permit users to communicate with each other across the entire Internet.

41. The method of claim 25 wherein the reported information includes a protocol for communicating with an entity wherein said protocol is for use with communications wherein the physical connectivity is provided by at least one of:

a) a Regional Bell Operating Company;

b) a long distance carrier;

c) a cellular network provider;

d) a provider of signal-based or wireless communications;

e) a cable television industry provider;

f) a service provider providing physical connectivity.

42. The method of claim 25 wherein the reported information includes a protocol for communicating with an entity wherein said protocol is for use with a communication device, said device being at least one of:

a) telephone device;

b) a pager device;

c) a fax device;

d) an email device;

e) a cellular phone device;

f) a broadcast audio and video device;

g) a voice device.

43. The method of claim 25 wherein the reported information includes a communication mechanism used in communicating with an entity.

44. The method of claim 25 wherein the reported entity information includes information identifying a remote computer system.

45. The method of claim 25 wherein the reported information includes a description of the input types to be communicated to an entity.

46. The method of claim 25 wherein the reported information includes a description of the output types communicated by an entity.

47. The method of claim 25 wherein the reported information includes one or more keywords used to locate an entry.

48. The method of claim 25 wherein the reported information includes information identifying if an entity can be started.

49. The method of claim 25 wherein the reported information includes a description of a data representation used in communicating with an entity.

50. The method of claim 25 wherein the reported information includes a description as to whether an entity is listed or unlisted.

51. The method of claim 25 wherein the reported information includes information describing one or more of:

a) if a public communication connection to an entity can be used;

b) if a private communication connection to an entity can be used.

52. The method of claim 25 wherein the reported information includes information describing one or more of:

a) if a public communication connection to an entity is mandatory;

b) if a private communication connection to an entity is mandatory.

53. The method of claim 25 wherein the reported information includes information describing if an entity is part of a larger service.

54. The method of claim 25 wherein the reported information includes information describing shell actions to execute to initialize an entity.

55. The method of claim 25 wherein the reported information includes the maximum number of concurrent communications.

56. The method of claim 25 wherein the reported information includes licensing information.

57. The method of claim 25 wherein the reported information includes general user information.

58. The method of claim 57 wherein the general user information includes one or more of a telephone number, beeper number, pager number, fax number, cellular number, and each of many email IDs, radio stations and television channels.

59. The method of claim 57 wherein the general user information includes purchase information.

60. The method of claim 57 wherein the general user information includes media storage capacity.

61. The method of claim 25 wherein the reported information includes a link to additional services required.

62. The method of claim 25 wherein the reported information includes a series of status information components including but not limited to security privileges and owner information.

63. The method of claim 25 wherein the reported information includes a unique communication identifier.

64. The method of claim 25 wherein the reported information includes a reference to a secondary service directory containing recorded entity entries.

65. The method of claim 25 wherein the reported information includes at least one of:

a) usage fees

b) a fee.

66. The method of claim 25 wherein the reported information includes a communication identifier.

67. The method of claim 25 wherein the reported information includes one or more of:

a) information describing an operating system

b) information describing underlying hardware

c) information describing installed software

d) information describing access methods

e) information describing the physical execution environment

f) information describing security requirements

g) information describing the default shell

h) information with special meaning to the said application process

i) information with special meaning to the user

j) information describing the physical computer system

k) information describing an access method to the computer

l) information describing functionality

m) information describing a communication identifier

n) information describing the entity

o) information describing a telephone number.

68. The method of claim 25 wherein the reported information includes a computer system name.

69. The method of claim 25 wherein the reported information includes one or more of:

a) a telephone number

b) a beeper number

c) a pager number

d) a fax number

e) a cellular number

f) one or more email Ids

g) unique user identifiers

h) a communication identifier

i) a radio station

j) a television channel.

70. The method of claim 25 wherein the reported information includes one or more of:

a) an address

b) a reference named supported by the underlying operating system.

71. The method of claim 25 wherein the reported information includes information describing the owner, the size, and, or execution privileges.

72. The method of claim 25 wherein the reported information includes one or more attributes and information describing if each said attribute is public or private, wherein public attributes are considered public information and are accessible through said directory service by any thread executing locally or remotely; and wherein private attributes are only accessible by said directory service.

73. The method of claim 25 wherein the reported information includes one or more user unique identifier.

74. The method of claim 25 wherein the reported information includes one or more service provider's unique identifier.

75. The method of claim 25 wherein the reported information includes one or more service unique identifiers.

76. The method of claim 25 wherein the reported information includes information describing the required physical connectivity to reach a service.

77. The method of claim 25 wherein the reported information includes one or more unique identifiers wherein each said identifier is associated with an entity.

78. The method of claim 25 wherein the reported information includes one or more of:

a) an arbitrary named representation associated with an entity

b) an expanded name associated with an entity

c) owner information

d) status times including the creation time, the last modification time, and the last access time

e) the size of the entity in bytes

f) the last recorded value associated with the entity.

79. The method of claim 25 wherein said reported information includes information describing a map area for communicating values from a first process to a second process.

80. The method of claim 25 wherein the arbitrary named representation is representative of a file containing specifications for communicating data to a process.

81. The method of claim 25 wherein the arbitrary named representation is representative of a file containing specifications for loading communicated data.

82. The method of claim 25 wherein the arbitrary named representative is representative of a service providing one or more of:

a) a textual representation of an available application program

b) a graphical representation of an available application program.

83. The method of claim 25 wherein the arbitrary named representative is representative of a service for providing one or more of:

a) a name

b) size information

c) owner information

d) date created

e) execution mode.

84. The method of claim 25 wherein the reported information includes statements to be executed.

85. The method of claim 25 wherein the reported information includes a protocol for communicating on a network linking hundreds of thousands of computer systems together.

86. The method of claim 25 wherein the arbitrary named representation is representative of a service providing the capability to monitor a communication device.

87. The method of claim 25 wherein the arbitrary named representation is representative of a service providing the capability to access a medium accessible to the computer system.

88. The method of claim 25 wherein the arbitrary named representation is representative of a service providing access to a file, and communication of the content of the file.

89. The method of claim 25 wherein the arbitrary named representation is representative of a service providing access to a storage medium.

90. The method of claim 25 wherein the arbitrary named representation is representative of a service providing communications between a first process executing on a first computer and a second process executing on a second computer, said computers connected over one of:

a) a network

b) a direct connection

c) a telephone modem

d) a wireless connection.

91. The method of claim 25 wherein the reported information includes a specification identifying one or more remote computer systems accessible to the current computer system.

92. The method of claim 25 wherein the arbitrary named representation is representative of a protocol being one of:

a) a protocol for channel access

b) a protocol for an ARPANET Network

c) a protocol for an NSFnet Network

d) a protocol for a regional Network

e) a protocol for a local Network

f) a protocol for a military Network

g) an Internet Protocol

h) a protocol in the OSI reference model

i) a TCP/IP Protocol

j) a protocol for communicating with a pager device

k) a protocol for communicating with a fax device

l) a computer mail protocol

m) a protocol for communicating with a communication device, said device being one of:

A. a cellular device

B. a radio station device

C. a television device

D. a voice device

E. a wireless device

F. a network device

G. a telephone device

H. a telephone modem device

n) a protocol for communicating over a physical device provided by one of:

A. a dialtone provider

B. a long distance carrier

C. a cellular network provider

D. a Cable Television Industry provider

E. a wireless device provider.

93. The method of claim 25 wherein the arbitrary named representation is representative of a service providing the capability to execute requests communicated by a first process.

94. The method of claim 25 wherein the arbitrary named representation is representative of a service including the capability to redirect standard input and standard output.

95. The method of claim 25 wherein the arbitrary named representation is representative of a service for making a target, said service including means to ensure prerequisites are up-to-date, and triggering a predefined action to make the target if the target is older than at least one prerequisite.

96. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means to defer execution of said service until all prerequisite services have completed.

97. The method of claim 25 wherein the arbitrary named representation is representative of a service for displaying an arbitrary named representation.

98. The method of claim 25 wherein the arbitrary named representation is representative of a service for binding an arbitrary named representation to an entity understood by said application service.

99. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for indicating if an arbitrary named representation includes a predefined suffix portion.

100. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for comparing an object name to a predefined pattern.

101. The method of claim 25 wherein the arbitrary named representation is representative of a service for transforming a first object name into a second object name distinct from said first name.

102. The method of claim 25 wherein the arbitrary named representation is representative of a service for locating an object and returning a handle to said object, said object being a component of software, and said handle being a reference to said component of software.

103. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for searching an arbitrary named representation for a matching pattern.

104. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means to determine if a user has access to a service, and if so, gaining access to said service and reporting that the service is now accessed.

105. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for determining the operating system's status of an entity, given said entity's location.

106. The method of claim 25 wherein the arbitrary named representation is representative of a service for registering an entity.

107. The method of claim 25 wherein the arbitrary named representation is representative of a service for binding an arbitrary named representation to an entity understood by said application service.

108. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for a user to register a communication primitive, said means including requesting registration information from a user, and receiving requested information from the user.

109. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for user to register a communication point, said means including requesting registration information from a user, and receiving requested information from the user.

110. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for connecting to a service, said means including requesting a user to identify the service, and creating a communication link to said service.

111. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for visually displaying information.

112. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for listing registered entity information.

113. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for displaying service registration information.

114. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for displaying information describing a communication point.

115. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for listing available communication points.

116. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for displaying the name and location of a specified communication primitive.

117. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for displaying information on a specified communication point.

118. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for generating a list of executing communication points.

119. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for locating a particular communication point.

120. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for connecting a first application process to a registered service, said connecting providing a means for sending and receiving communications between said first application process and said service.

121. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for disconnecting a first application process from a service said application process is currently connected to.

122. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for receiving a message from a connected process and displaying said message.

123. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for sending a message from a first process to a connected process.

124. The method of claim 25 wherein the arbitrary named representation is representative of a communication service providing means for connecting a first service to a second service comprising the steps of:

a) locating said first service and establishing a reference thereto, and

b) locating said second service and establishing a reference thereto, and

c) creating a communication link for said first service and said second service to communicate, and

d) causing said first service to begin executing as a first service thread, and

e) causing said second service to begin executing as a second service thread, and

f) providing said first service thread with access to said communication link

g) providing said second service thread with access to said communication link.

125. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for comparing a first service to a second service and indicating if said services are equivalent.

126. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for connecting a service process to a client process, comprising the steps of:

a) adding the client process receiver to the service process sender list

b) adding the service process sender to the client process receiver list.

127. The method of claim 25 wherein the arbitrary named representation is representative of a communication service providing means for connecting a client process to a service process, wherein the client process has access to a memory location for maintaining one or more references to connected processes, and said service process has access to a memory location for maintaining one or more references to connected processes, comprising the steps of:

a) the communication service process access the client process memory location and adds a reference to the service receiver communication primitive

b) the communication service process access the service process memory and adds a reference of the client sender communication primitive.

128. The method of claim 14 wherein the entity is a communication service providing means for receiving a pending communication, comprising the steps of:

a) accessing a receiver including a communication primitive for receiving communications, and a memory location for storing received communications, and

b) using said primitive to receive said communication in said memory location.

129. The method of claim 25 wherein the arbitrary named representation is representative of a communication service providing means for a first process to receive communication from one or more connected processes wherein sand application service causes said connected process to continue execution when there the number of pending communications is below a predefined threshhold.

130. The method of claim 25 wherein the arbitrary named representation is representative of a communication service for sending data to a multiplicity of connected processes.

131. The method of claim 25 wherein the arbitrary named representation is representative of a communication service for sending data to a multiplicity of connected processes.

132. The method of claim 25 wherein the arbitrary named representation is representative of a communication service providing means for sending communications from a first process to one or more connected processes wherein said communication service causes said first process to suspend execution when the number of pending communications is above a predefined thresh-hold.

133. The method of claim 25 wherein the arbitrary named representation is representative of a generic front end loader services said service providing means to initialize an address space of a new process and invoke a specific thread within that address space.

134. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for monitoring a communication device wherein n the service wraps the identifier of the sending process along with the identifier of the receiving process around the message prior to sending data out on the communication device.

135. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for monitoring a communication device wherein when the service receives a message from the communication device, it unwraps the message to determine the process that the message is to be sent to, and sends the message to the specified process.

136. The method of claim 25 wherein the arbitrary named representation is representative of a broker service, said broker service providing means for converting a message from a first primitive type to a second primitive type.

137. The method of claim 25 wherein the arbitrary named representation is representative of a connection service for connecting a requesting process to a service, wherein

a) the first process communicates a unique identifier to the connection service, and

b) the connection service causes the identifier to be looked up in a directory service to determine how to connect to the service associated with the unique identifier, and

c) the connection service causes said requesting process to be connected to the service using the determined means of connecting.

138. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for specifying components of software to use in constructing a dynamically configured application program, said components of software being loaded according the specified rules, and subsequently loaded.

139. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means to provide specifications identifying components of software to be used for dynamically configuring an application program, the interactions between these components, the policy for evaluating these components, and the order of evaluation of the components.

140. The method of claim 25 wherein the arbitrary named representation is representative of a service offering the means to reconfigure an application process wherein a communication point of an application process is dynamically replaced by another communication point.

141. The method of claim 25 wherein the arbitrary named representation is representative of a service providing means for replacing a minor service with a new minor service and rerouting communication channels as appropriate.

142. The method of claim 25 wherein the arbitrary named representation is representative of a software construction service providing means for constructing an application program from source code.

143. The method of claim 25 wherein the arbitrary named representation is representative of a Me containing specifications for a software construction service, the specification describing the necessary actions to create an Application Program.

144. The method of claim 25 wherein the arbitrary named representation is representative of a binding service providing means to dynamically administer the association of one or more arbitrary named representations with entities understood by the binding service.

145. The method of claim 25 wherein the arbitrary named representation is representative of a configuration file including specifications identifying binding methods, ordering of binding methods, and the location of the binding method.

146. The method of claim 25 wherein the arbitrary named representation is representative of a service providing the means for converting data from a first primitive type to a second primitive type.

147. The method of claim 25 wherein the arbitrary named representation is representative of a service providing the means for converting data from a first communication primitive type to a second communication primitive type.

148. The method of claim 25 wherein the arbitrary named representation is representative of a service providing the means for converting data from a first protocol to a second protocol.

149. The method of claim 25 wherein the arbitrary named representation is representative of a service providing one or more of:

a) a billing service

b) a report generation service

c) a trouble reporting service.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to computer networks and communication management, and to the establishment of communication between various users and/or software applications.

2. Background of the Invention

The term "The Information Superhighway" is commonly thought of as an extension of the Internet, a network linking hundreds of thousands of computer systems together and communicating via a standard protocol.

A computer network is simply a collection of autonomous computers connected together to permit sharing of hardware and software resources, and to increase overall reliability. The qualifying term "local area" is usually applied to computer networks in which the computers are located in a single building or in nearby buildings, such as on a college campus or at a single corporate site. When the computers are further apart the term "wide area network" may be used.

As computer networks have developed, various approaches have been used in the choice of communication medium, network topology, message format, protocols for channel access, and so forth. Some of these approaches have emerged as de facto standards, but there is still no single standard for network communication. The Internet is a continually evolving collection of networks, including Arpanet, NSFnet, regional networks such as NYsernet, local networks at a number of university and research institutions, a number of military networks, and increasing, various commercial networks. The protocols generally referred to as TCP/IP were originally developed for use through Arpanet and have subsequently become widely used in the industry. The protocols provide a set of services that permit users to communicate with each other across the entire Internet.

A model for network architectures has been proposed and widely accepted. It is known as the International Standards Organization (ISO) Open Systems Interconnection (OSI) reference model. (See FIG. 10.) The OSI reference model is not itself a network architecture. Rather it specifies a hierarchy of protocol layers and defines the function of each layer in the network. Each layer in one computer of the network carries on a conversation with the corresponding layer in another computer with which communication is taking place, in accordance with a protocol defining the rules of this communication. In reality, information is transferred down from layer to layer in one computer, then through the channel medium and back up the successive layers of the other computer. However, for purposes of design of the various layers and understanding their functions, it is easier to consider each of the layers as communicating with its counterpart at the same level, in a "horizontal" direction. (See, e.g. The TCP/IP Companion, by Martin R. Arick, Boston: QED Publishing Group 1993, and U.S. Pat. No. 5,159,592. These, and all patents and publications referenced herein, are hereby incorporated by reference.)

As shown in FIG. 10, the lowest layer defined by the OSI model is called the "physical layer," and is concerned with transmitting raw data bits over the communication channel. Design of the physical layer involves issues of electrical, mechanical or optical engineering, depending on the medium used for the communication channel. The second layer, next above the physical layer, is called the "data link" layer. The main task of the data link layer is to transform the physical layer, which interfaces directly with the channel medium, into a communication link that appears error-free to the next layer above, known as the network layer. The data link layer performs such functions as structuring data into packets or frames, and attaching control information to the packets or frames, such as checksums for error detection, and packet numbers.

The Internet Protocol (IP) is implemented in the third layer of the OSI reference model, the "network layer," and provides a basic service to TCP: delivering datagrams to their destinations. TCP simply hands IP a datagram with an intended destination; IP is unaware of any relationship between successive datagrams, and merely handles routing of each datagram to its destination. If the destination is a station connected to a different LAN, the IP makes use of routers to forward the message.

The basic function of the Transmission Control Protocol (TCP) is to make sure that commands and messages from an application protocol, such as computer mail, are sent to their desired destinations. TCP keeps track of what is sent, and retransmits anything that does not get to its destination correctly. If any message is too long to be sent as one "datagram," TCP will split it into multiple datagrams and makes sure that they all arrive correctly and are reassembled for the application program at the receiving end. Since these functions are needed for many applications, they are collected into a separate protocol (TCP) rather than being part of each application. TCP is implemented in the "transport layer," namely the fourth layer of the OSI reference model.

Except as otherwise is evident from the context, the various functions of the present invention reside above the transport layer of the OSI model. The present invention may be used in conjunction with TCP/IP at the transport and network layers, as well as with any other protocol that may be selected.

As shown in FIG. 10, the OSI model provides for three layers above the transport layer, namely a "session layer," a "presentation layer," and an "application layer," but in the Internet these theoretical "layers" are undifferentiated and generally are all handled by application software. The present invention provides for session control and for communicating with applications programs. Thus the present invention may be described in accordance with the OSI theoretical model as operating at the session layer and application layers.

"Connectivity" and "convergence" have been used to describe two aspects of the communications and computing revolution taking place. In 1994, technology provides to communicate by telephone, pager, fax, email, cellular phone, and broadcast audio and video. However, to use these communication services, you have to employ a telephone number, beeper number, pager number, fax number, cellular number, and each of many email IDs, radio stations and television channels. The user is confronted with an overabundance of methods providing such physical connectivity, one which will only grow in the future.

The types of physical connections are provided by various systems including the Regional Bell Operating Companies, the Long Distance Carriers, the Cellular Networks, and others providing signal-based or wireless communications. The Cable Television Industry provides connectivity for video signals and increasingly other services.

SUMMARY OF THE INVENTION

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. When viewed in accordance with the OSI model, the communication primitives operate at the level of the transport layer, and, to the extent appropriate, at the network layer, and in some instances down to the data link layer, and occasionally as needed, the physical layer.

Using the Access-Method-Independent Exchange of the present invention, anybody can provide a service. Similarly, anybody can be a client of a service. A service can even be a client of another service. This is because every user and every service is identified by a unique communication identifier. In accordance with the present invention, various communication points are connected together to form a communication link.

The aforesaid identifiers are assigned to the user, or service provider, during their subscription process. For service providers, additional information must be provided and added to the Thread Directory Service. This information includes the required physical connectivity to reach the service.

When users want to access the Access-Method-Independent Exchange, they simply supply Exchange with their unique identifiers. The Binding Service validates each user and permits access to the Exchange. The user may then connect to any registered service by simply calling the service's communication identifier. Of course, if they are unfamiliar with the service providers communication identifier, they can request assistance through the Thread Directory Service. The Thread Directory Service provides a listing of available services grouped by relationship. The user can search for keywords, titles, or other information such as service fees. Ultimately, the user can request to gain access to the service.

The Access-Method-Independent Exchange is not limited to servicing a particular geographic area and hence can easily work with foreign countries. The Access-Method-Independent Exchange includes the ability to provide voice or data message processing.

Access-Method-Independent Exchange Components: A Technical Overview The Thread Communication Service

At the core of the technology is the Thread Communication Service (TCS), a software utility used to administer the dynamic communications between computer processes executing on a local computer, or, on a remote system. Two versions of the TCS have been implemented: one for intraprocess communications and a second for interprocess communications. The intraprocess version of the TCS is used for a single application process with multiple threads of control. The interprocess version of the TCS provides the administration of communications between processes executing in disjoint address spaces on a local, or remote computer system.

In the TCS everything is viewed as either being a communication primitive, or, a communication point. The communication primitives are the low-level mechanisms used to provide the physical communication between various processes. The processes participating in the communication are referred to as communication points. Two or more communication points are connected by a communication link using the communication primitives.

The Communication Primitives

The communication primitives are built using the underlying computer operating system intraprocess and interprocess communication facilities and thus are operating-system-specific. On one operating system there may be, for example, five communication primitives supported, while another operating system may support twenty. A communication primitive generally must provide for several operations to be applied such as:

Create: The ability to create an instance of the primitive

Destroy: The ability to destroy an instance of the primitive

Send: The ability to send data to the primitive

Receive: The ability to receive data from the primitive

Cycle: Send a default and receive default messages to/from the primitive

Connect: Primitive specific connection function

Disconnect: Primitive specific disconnection function

Suspend: Primitive specific suspension function

Resume: Primitive specific resumption function

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:

Scope: Determines if service executes as a sibling thread, or in separate address space.

Stack: Required stack size

Idle: If service is to be idle on non-connects

Maxmsg: Maximum number of pending messages prior to suspension

Minmsg: Minimum number of pending messages at which service is resumed

Restart: Service is restartable

Termination: Method for terminating the service

Discarded: Method for discarding unwanted messages

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:

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 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

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:

1. A unique alphanumeric name to identify the RULE

2. A DCM operator denoting the policy for evaluating the RULE

3. Zero or more Prerequisite RULES

4. Zero or more Attributes describing characteristics of the RULE

5. 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. 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:

1. DCMINIT RULE

2. APINIT RULE

3. MAIN RULE

4. APDONE RULE

5. DCMDONE RULE

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:

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.

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:

1. Locates specified Minor Services

2. Loads specified Minor Services

3. Executes specified Minor Services

4. Establishes communication channel with the specified Minor Service.

5. Suspends execution of specified Minor Services

6. Resumes execution of specified Minor Services

7. Replaces specified Minor Service with a new Minor Service rerouting communication channels as appropriate

8. Unloads specified Minor Service

9. Provides for manual state retention between replaceable Minor Services

10. Notification

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:

1. Mission-critical Application Programs which require 24 hour, 365 days a year execution can be reconfigured without terminating execution of the existing Application Process.

2. An Application Process can be reconfigured 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 reconfigured on demand.

4. New software services can be designed, implemented, and tested using an existing Application Process such that the new services can be de installed 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.

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 12B. 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:

1. augmented make--"Augmented Version of Make," UNIX System V, Release 2.0 Support Tools Guide, pp: 3.1-19, April 1984.

2. build--Erickson, B., Pellegron, J. F., "Build--A Software Construction Tool," AT&T Bell Laboratories Technical Journal, vol. 63, No. 6, Part 2, pp: 1049-1059, July 1984.

3. make--Feldman, S., "Make--A Program for Maintaining Computer Programs," Software--Practice and Experience, vol. 9, No. 4, pp: 256-265, April 1979.

4. mk--Hume, A., "Mk: A Successor To Make," USENIX Phoenix 1987 Summer Conference Proceedings, pp: 445-457, 1987.

5. nmake--Fowler, G. S., "The Fourth Generation Make," USENIX Portland 1985 Summer Conference Proceedings, pp: 159-174, 1985.

6. Microsoft NMAAE--"Microsoft C: Advances Programming Techniques," Microsoft Corporation, pp: 103-132, 1990.

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: target.sub.--name:prerequisite.sub.--list

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:

rule 1 A:B C

concatenate B and C to construct A rule 2 B:b

copy "b" to "B"

rule 3 C:c

copy "c" to "C"

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:

1. All of the Application Program's Minor Services are developed and compiled into the Application Program which is then sold to the customer. I shall refer to this "Non-featuring Software."

2. All of the Application Program's Minor Services are developed and compiled into the Application Program which is then sold to the customer. Certain Minor Services, however, will be inaccessible to the customer unless the customer pays additional fees. At that time, a key file is provided to the customer with the appropriate purchased Minor Services turned on. I shall refer to this as "Run-Time Featuring."

3. All of the Application Program's Minor Services are developed, but during the software construction process certain features will be selected to include in the Application Program. I shall refer to this as "Compile-Time Featuring."

4. All of the Application Program's Minor Services are developed, but sold as separate Application Programs. In this instance, all of the components representing the Application are well known. During the execution of the Application Program, the features are tested to see if they are present. If a feature is not present, then it is simply ignored. I shall refer to this as "Load-Time Featuring."

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:

                  #if defined(FEATURE.sub.-- A)
                         . . .
                      #elif defined(FEATURE.sub.-- B)
                         . . .
                      #endif

                TABLE 1
                Binding Method Registration Information.
                      Order of Evaluation
                      Location of Binding Method
                      Name of Binding Method

                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

                TABLE 3
                Binding Method Operations
                       Pattern Matching Method
                       Name Transformation Method
                       Locate Method
                       Status Method
                       Query Method

        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

                         TABLE 5
                         The Flow Rules.
                                 DCMINIT RULE
                                 APINIT RULE
                                 MAIN RULE
                                 DONE RULE
                                 APDONE RULE
                                 DCMDONE RULE