WO2001056356A2 - Method for inter-component communication - Google Patents

Abstract

A method is provided for structuring communications between software components according to speech acts the communications represent, and a method is provided for responding to such communications. The method for structuring the communications includes providing a set of predefined communication acts, each representing one type of action and classified according to its expected effect on a recipient component. When a need exists for a first software component to communicate with another software component or components, a communication act is selected that represents the need from the set of predefined communication acts. The communication is constructed to include the selected communication act and an argument defining a subject of the communication act. The software component or components to which the communication should be addressed is determined, and the communication is directed to that software component or components. The method of responding to the communication includes interpreting the communication to determine what action a recipient software component is to perform in response to the communication. Interpreting the communication includes identifying the communication act, determining a standard set of responses associated with the communication act, and selecting a correct response from the standard set based on the context of the communication.

Description

METHOD FOR INTER-COMPONENT COMMUNICATION

Field of the Invention

This invention relates generally to computer program construction and, more particularly, to the way meanings arc communicated between independent software components when such components work together.

Background of the Invention

Individual computer programs are generally independently functioning units, but which are increasingly required to work together cooperatively. When they do, they typically become aggregate organizations of many such computer programs, which constitute the automated facilities that support businesses or business groups. These aggregate program facilities may themselves be organized into even larger aggregations that in turn must work together, but in which each such facility is now identified as an individual.

These units are all referred to herein as "components." They may vary in granularity and in their degree of operational independence from each other. In terms of granularity, they may be identified as "objects," "functions," "procedures," "components," "servers" or "applications." In terms of operational independence, they may compiled into the same program, linked into a single executable image, operate in separate virtual address spaces, or on different computers in distant locations from each other. But, in all cases each such component typically has two distinct aspects: an internal, private processing capability, expressed in individual lines of programming code, and an external, public interface, enabling other components to obtain services from the component, expressed in terms of a "signature," "message format," or in some "interface definition language."

As illustrated generally in FIGURE 1 and described below, the present invention relates to a generic process for defining the public interfaces between components, and also a standard method lor processing communications received acioss public lntcildccs. independent ol the granularity of the components

The overall syntactic structure ol the public interlaces between components is determined by the implementation technology ol the programs in question For example, within a programming language, such as in a C++ program, objects communicate with each other via messages and through the technique of throwing and catching errors Other such means exist in other programming languages Similarly, components operating at diltcrcnl locations on a network may utilize an interoperability standard such as remote procedure calls, or remote object mvocations supported by a commercial implementation ol the Common Object Request Broker Architecture (CORBA™) standard

As will be apparent lrom the detailed description below, the present mvention is not dependent on any particular syntactic structure, nor is it the definition ol a new language Instead, this mvention us directed to a method and system ol rigorously organizmg the communications between components, iegardlcss of the syntax ol the language in which the communications s carried out, or the technology in which the communications us implemented However, the mvention could also be used to construct a new programming language or interoperability standard that explicitly provides lor or enforces the programming process and method ol the invention, much as object-oriented languages explicitly provide tor and/or cnlorcc object- oriented design methods, which can also be applied when using non-objcct-orientcd programming languages

A Prior Art Processes and Algorithms tor Semantic Analysis In the prior art, the management of meaning in mtcrcomponent communications generally occurs at two points in the technology utilization hie cycle These points arc illustrated in FIGURE 2. The first point is al the very beginning of this cycle, when a new programming language or other intercomponcnt communications standard, such as CORBA™ or COM™ is designed and implemented. During the implementation of the design, the basic manner in which algorithms interpret communications at run time is also determined, by the compiler or other language interpretation capability associated with the language implementation.

The second point is at the very end of the design process, when the particular meanings to be communicated between components are determined by the designer or programmer of each individual system component, as part of the problem solution. This process also determines, completely independently for each type of communications the component is capable of receiving, precisely how the component will respond to the communication. These are the algorithms according to which the component responds to each individual communication it receives. Thus, in the prior art, no general technologies apply to semantics after the design of the programming language. This language design is the very earliest phase in the life cycle. As will be discussed below, the present invention provides generally apphcable technologies for managing meanings, which apply later in the technology apphcation life cycle.

B. Existing Science and Technology Concepts

There are generally two aspects of software design that are brought together in this invention: the first Is the concern of software design with the general means of inter-component communications, and the second is the design of programming languages around what is called a "programming paradigm." In addition, this invention draws on theories in the sciences of mathematical logic and linguistics.

1. Inter-Component Communications of Meanings

Throughout most of the history of computer programming, each program has generally functioned as a "stand-alone" island of automation or "apphcation." Communications between these applications was effected cither by people, each working with a different program, requiring that information produced by one program be re-entered into another program by another person, or by the transmission of "data" between programs, via file transfers, which might be effected over an electronic link or on some electronic media, such as an optical disk or a tape. In either case, explicit rules for translating the information between one such apphcation and another was required — sometimes these rules were followed by a human, and sometimes by a computer program, but they were expressed bilaterally, for each such communicating pair of programs. These translation rules embodied the understanding of the meanings of what was communicated, independently of the physical means.

As the need for mterapphcation communications grew, multi-lateral communications standards developed, such as the S.W.I.F.T., and more recently the FIX set of message formats for financial communications. In order to ensure that any message sent could be understood by the recipient, these standards controlled not only the format, but also very strictly limited the content of what could be communicated. They could do so because they were focusscd on a single, tightly defined domain of business activity. However, more recently, businesses have attempted to integrate applications that cross business domain boundaries - personnel management and payroll processing, sales and service, etc. In order to accomplish this effectively, more generic "interoperability" software called "middleware" has been provided by vendors, enabling real-time communications between different sorts of applications. More recently still, XML, a standard syntax for expressing information, has begun to be adopted. This has resulted in greater interoperability between different middleware products because it enables the data communicated to carry with it a description of its meaning.

Both middleware and languages such as XML, however, still depend on having the computer program designers establish standards, on a bilateral or multi-lateral basis, concerning specifically what will be communicated by the middleware. As each apphcation expects radically different information formats and contents, these standards are "brittle," in that they do not easily enable the incorporation of new σr changed apphcations, without requiring change themselves.

There is a need today for even better means of communications between independently operating components, driven largely by two industry changes: (1) component- based development and component-based deployment, and (2) Internet service integration.

Many in the computer industry believes that in the future, complex applications will be constructable from re-useable components, each such component sometimes supplied by a different vendor, as music playback systems are so constructed today, or as automobiles are built from mostly standard parts from multiple supphers. For example, a securities portfoho record keeping and valuation system might be constructed using a pre-built component that manages information about financial parties, another pre-built component that manages information about securities terms and conditions, another that manages information concerning securities prices, and a single special-purpose built component for actually creating and maintaining the securities accounts and positions. Smaller components, such as ones designed to manage business dates, may also be employed in this construction.

Today, each individual program designer or, in some more recent cases, the designer of a particular interface definition language, implicitly decides on ways in which communications will be organized for the program or language without identifying this organization as a general and separate feature of the program or interface definition language.

2. Current Methods for Constructing Interpretation Algorithms To overcome the lack of flexibility of these known communications standards, "late binding" techniques have been developed both within programming languages and for communications means. Binding between components occurs later when the communications between the components may be established at a later time in the development life cycle of the components. For example, when the compile time is the binding time, communications must be defined in the source code written by the programmer. At the other extreme, when the run-time is the binding time, communications may be established after the programs arc installed on the machines on which they are to run. Current late binding techniques, as an approach to increasing the flexibility of communications standards, include the engineering model of the International Standard's Organization Reference Model - Open Distributed Processing and U.S. Patent No. 5,842,205, which is directed primarily to message translation.

The same methods and processes have been applied to make the specification of business rules independent of the control programs that invoke them, using machine design techniques pioneered by Noam Chomsky in "Finite State languages," Information and Control. 1 (2): 91- 1 12, May 1958, and "On certain formal properties of grammars," Information and Control. 2(2): 137-167, June 1959. Such work is now a standard part of computer science curricula, included in such textbooks as Hopcroft & Ullman Introduction to Automata Theory Languages and Computation Addlson Wesley 1979 and Denning, Dennis and Qualitz Machines, Languages and Computation Prentice Hall 1978, and applied in a large body of business rules htcrature from the 1990s.

Yet in all these cases, the structure of the semantics communicated is today determined entirely by the programming language chosen (where we include other more specialized intcr- component communications languages, such as CORBA™ and COM™, and SWIFT), and the algorithms for interpreting communications are correspondingly tied to the particular language chosen. The general nature of such algorithms Is that the structure supplied by the language Is divided into two parts, as illustrated in FIGURE 5. The first part of the provided structure Is used to choose which algorithm is to be executed, and the second part, to supply information to the algorithm chosen. In this model, the part of the work done by the programming language itself is minimal, and almost all the semantics is added by the component designer and programmer. But ii each ol these components us constructed by a diilcrcnl manulactuicr, or even by the same one for initially a different purpose, they must have standardized lorms ol public interfaces, and these standards must go beyond the language in which the interlaces are expressed. These standards must mcludc standardized and universally apphcable ways of communicating particular meanings, withm and across business domains - semantic standardization. Thus, a need exists for a semantic standardization process, building on the standard syntaxes that are already under development.

Beyond the need for components that arc intentionally integrated by single companies, new Internet based products wdl automaticaUy connect users to services offered by associated parties. These interconnections cannot be merely the currently common cross references to Web pages, but also, for the products of different content providers to work together, will need to maintain and communicate current user information context between these products. For example, when a user ol a financial planning service receives a recommendation from the service to invest in a particular class ot security, the service may introduce the user to a brokerage firm. The brokerage firm soltwarc should, as a result of this introduction, already know whatever it us appropriate for that firm to know about the user. The primary means with which this is envisioned to be accomplished Is via intelligent agents. A need exists for the public interfaces of Internet services to enable such intelligent agents to communicate with such services in a more standard manner requiring less custom programmmg lor each such communications.

Simdarly, the supply-chain relationships enabled by the Internet, in which multiple suppliers and business consumers can communicate concerning all aspects of their business relationships, are intended to be supported by specific multi-lateral communications standards. But as these standards provide finite languages determined by industry consortiums, they are still examples of language design time semantics, with all its inherent lnfiexibihty. A need exists for individual members ol such relationships to be able to provide new kinds of communications, to which their business partners can quickly learn to respond.

3. Programming Paradigms A "programming paradigm" is a description of the general kinds of things that arc expressed in a computer programming language. Today, there are only three such paradigms: the (most common) procedural paradigm, exemplified by the languages used in the vast majority of commercial programs, such as Cobol, Fortran, C, and C++; the (very specialized) functional paradigm, exemplified by LISP, and the (growing in importance) declarative paradigm, exemplified by PROLOG.

In the procedural paradigm, a complete expression in a programming language is an "instruction," which tells the computer what to do. For example, in a procedural language, the expression x = 4+y tells the computer to add 4 to whatever the value of y is, and store the resulting value in the memory location named by x.

In the functional paradigm, a complete expression in a programming language defines a function, which the computer automatically attempts to evaluate. For example, in a functional language, and expression such as (fx)(+(4,x)) tells the computer the meaning of the function fx. The computer will then remember this definition and evaluate it whenever that function is used.

In the declarative paradigm, a complete expression in a programming language tells the computer what is true. The computer will automatically use a set of true statements provided to it to produce other true statements that follow from the set that was provided. For example, in a declarative language, an expression such as f(x) = z -> z = (4+x) tells the computer the condition under which the expression f(x) = z will be true, namely, whenever z happens to equal 4+x. The computer will then remember this fact and combine it with any other facts that are related, to produce new facts.

Notable about all these programming paradigms is the fact that each programming language permits the expression of only a single kind of meaning. Thus, every paradigm is semantically narrow, compared to a natural language in which any of these modes of communications are possible. And in an extension of this approach, all current inter-module communications methods permit only a single kind of meaning to be expressed. (Today, this is invariably expressed procedurally, since these methods usually permit communications between modules that are internally written in procedural languages). Thus, a need exists for extending the art of programming paradigms by permitting, as do natural languages such as English, a single language to express multiple kinds of meaning, and applies the same multiplicity to inter- component communications.

4. Linguistic and Logical Theory This invention combines two very fundamental ideas in linguistics and logic, which were developed as theories about human communications, and applies them to computer communications.

The first of these ideas is the idea of an "atomic sentence," first expressed by Ludwig Wittgenstein in Tractatus Logicus Philosophicus in 1919, and built upon ever since, e.g., expressed by Noam Chomsky as the components of "deep structure" in his Syntactic Structures of 1964. According to this idea, all complete communications are built up as combinations from fundamental, very simple, and very limited in structure elemental kinds of expressions. To simplify these theories, the very same atomic sentences, such as "Mary is tall" and "Mary is a woman" can then be expressed multiply as "Mary is a tall woman" and as "Mary is a woman who us tall " Thus invention apphes the same lundamcntal idea to soltwarc communications, requiring that each such communication be expressed m terms ol specified kinds ol atomic sentences, in order to avoid the wide variety ol ways they can be combined.

The second ol these ideas us the idea ol a Speech Act, first expressed by John Austin in How to do things with Words, 1952. The basic idea ol thus work us that, unlike the behefs of previous logicians, in which all sentences express assertions, most human communication us not concerned with expressing lacts, but rather with a broad variety ol intentions The most commonly used example us when authorities cause things to be true by proclamation. For example, when a minister says: "I now pronounce you man and wife," he is not making a statement that might be true or false, but mstead, by what he says, combined with the authority vested in him, causing a change, namely causing the couple to be married. Thus basic idea was developed into a branch of linguistic science by John Searle, Speech Acts, 1969 Today, linguists work at creating systematic catalogues lor the different types ol speech acts that can be performed by humans, while, as wc have seen, computer communications us, hke earher logics, restricted to very lew kinds ol actions. The present invention apphes such broad categories ol action types to computer communications, and makes each ol these atomic by specifying that no communication may have multiple intentions.

Brief Summary of the Invention

One object of this invention to provide a computerized method for enabling components that have not been designed together to communicate easily with each other do so.

Another object of this invention to allow integrators to construct systems from components, and programmers to create programs, that will be easier to understand, and in such a way that changes in one part of the component system or program will not require changes in other parts.

These and other objects are achieved by an inventive method for structuring communications between software components according to speech acts the communications represent and a method for responding to such communications. The method for structuring the communications includes providing a set of predefined communication acts, each representing one type of action and classified according to its expected effect on a recipient component. When a need exists for a first software component to communicate with another software component or components, a communication act is selected that represents the need from the set of predefined communication acts. The communication is constructed to include the selected communication act and an argument defining a subject of the communication act- The software component or components to which the communication should be addressed to is determined, and the communication is directed to that software component or components. The method of responding to the communication includes interpreting the communication to determine what action a recipient software component is to perform in response to the communication. Interpreting the communication includes identifying the communication act, determining a standard set of responses associated with the communication act, and selecting a correct response from the standard set based on the context of the communication.

These and other objects and advantages of the invention will become readily apparent from the following detailed description wherein embodiments of the invention are shown and described by way of illustration of the best mode of the invention. As will be realized, the invention is capable of other and different embodiments, and its several details may be capable of modifications in various respects, all without departing from the invention. Accordingly, the drawings and description are to be regarded as illustrative in nature and not in a restrictive or limiting sense with the scope of the apphcation being indicated in the claims.

Brief Description of the Drawings

For a fuller understanding of the nature and objects of the present mvention. reference should be made to the following detailed description taken in connection with the accompanying drawings wherein: FIGURE 1 is a block diagram generally illustrating communications between components in accordance with the invention;

FIGURE 2 is a flow chart illustrating the management of meaning in inter-component communications in accordance with the prior art;

FIGURE 3 is a flow chart generally illustrating the speech act analysis process and the speech act interpretation framework aspects of the invention;

FIGURE 4 is a flow chart illustrating meanings analysis in accordance with the invention;

FIGURE 5 is a block diagram illustrating interpretation of a communications act in accordance with the prior art; FIGURE 6 is a block diagram illustrating the speech act interpretation framework in accordance with the invention;

FIGURE 7 is a block diagram illustrating the context of speech act interpretation in accordance with the invention;

FIGURE 8 is a block diagram of the speech act interpreter in accordance with the invention; and

FIGURE 9 is a block diagram of an alternative speech act interpreter in accordance with the invention.

Detailed Description of the Preferred Embodiments

Briefly, the present invention us dacctcd to a computci progiamming design process and a programmmg method lor controlling communications between separate soltwarc components, enabling the components to lunction with maximum mdcpcndcncc ol each other, while simultaneously not duplicating ctlort between them

As illustrated in FIGURE 3, there are two generally distinct but related aspects ol the mvention: ( 1) the design process tor analysis ol a programmmg problem in terms ol speech acts ("the speech act analysis process" 10), and (2) the programming method, in the lorm of a framework for a set ol algorithms, to mterpret speech acts received by one component from another ("the speech act interpretation lramcwork" 20).

In the design process, communications arc classified accordmg to the type ol cllcct they arc intended to have on the state ol the environment in which they occur - a classification accordmg to "action mode" - what would be called in human hnguustics the "speech act." The design process 10 results in each separate communication between components expressing a single action mode, so that the total communications needs between components us therefore accomphshcd by a number ol separate speech acts, each isolating only a single responsibility ol the performer of the act. The programmmg method 20 us a method lor interpreting and responding to communications so designed

This speech act approach to communications design locuses on the responsibilities assigned to each component perlorming the speech act, the changes it makes in its operating domain by having performed the act Thus differs markedly lrom the standard paradigm, in which the purpose of soltwarc communications us to cause some action on the part of the receivmg component. The ventive approach enables software components to communicate more like people do, and therefore greatly decreases the knowledge that one component must have about the behavior ol others, and so increases the mdcpcndcncc with which coopciating components can work-

In accordance with the invention, the Speech Act Analysis Process 10 generally includes:

(1) a technique for classifying communications according to the effect they will have on the state of the environment of all recipients, but independent of the specific business domain of the communications, a classification according to the "action" performed by the sender;

(2) signature rules for specifying what kind of information or "propositional content" is to be included with each type of communication;

(3) a generalized method for identifying the types of actions expressed in a communication; (4) a partitioning stipulation, requiring communications that combine speech act types to be re-expressed as single speech acts, or as a bundle of separate speech acts communicated together (This ensures that every communication will represent exactly one of these types of actions.); and (5) a generahzed method for separating out the propositional content of a communications act from the type of action.

The Speech Act Interpretation Framework 20 includes a set of types of objects and a pattern for their use, with which the recipient of a speech act may handle each type.

These two parts of the inventive communications semantics cause a restructuring of the meaning analysis required for software design processes as generally depicted in FIGURE 4, and contrasts with the prior art standard methods shown in FIGURE 2.

In the inventive design process, the underlying programming language communication paradigm can be left unchanged from previous standard processes. However, this paradigm is used only in a later implementation phase, which is now separated from the design phase, and whose standard programming techniques are not the topic of this invention. The design phase in turn is divided into two parts:

( 1 ) the design of a set of speech act types and signature types for a generic business domain such as, e.g., securities trading, aircraft manufacture, or telecommunications management, and (2) the design of specific software within that domain such as, e.g., a particular equity securities trading system for use by a particular firm in a particular country during a particular decade.

The Speech Act Analysis Process 10 can be apphed cither both to work done gencricaUy for a particular business domain or to work done in the analysis of a single business problem-

However, it is generally much more effective to design types of speech acts and signatures for the business domain, rather than separately for each software design. It Is in the individual component designs, however, that these speech act types arc apphed to the communications needs of the component.

The Speech Act Interpretation Framework 20 is used in the component design process to construct the algorithms for interpreting and responding to speech acts. In prior art processes, the semantics of a response to a communication was generally determined entirely by the designer of an individual component. In the process in accordance with this invention, the Speech Act Interpretation Framework provides a generic structure that every response takes. Typically, only the details are filled in by the designer of the component- This framework (which contrasts with that of the prior art shown in FIGURE 5) is illustrated in FIGURE 6.

In this structure, there are generally three layers in the algorithm. The first layer involves the standard engineering problem of dealing with a form of expression dictated by some programming language, in which is now embedded an identification of a speech act type. The general interpretation algorithm, which in the standard model, looks first at the operator to choose an algorithm, now looks first at the speech act type, and then at the propositional content to which the act is apphed.

This central concept of prepositional content, and its differentiation from speech act type, will be discussed in greater detail below- Briefly, propositional content is what the act is about, its subject, rather than the nature of the act itself. For example, a question is a type of speech act, while a baseball team might be the subject of the question-

This semantics identifies the subject of all communications as concerning software entities, which may be software objects representing machine manifestations of behavior, such as windows, software surrogates for domain entities such as customers, airplanes, or patents, or software or hardware objects themselves, such as executing processes. As these entities may or may not be implemented in object oriented languages, they are referenced to herein with the more neutral word "entity." A communicator is itself such an entity, but some entities may not be communicators, but under the control of a communication entity. For example, a securities pricing component will contain securities price entities, but if only the whole component has a pubhc interface, then only the component, in this context, is a communicator, and the securities prices controlled by the component are not.

This invention is indifferent to any other aspects of the communication, such as whether each communication results in an acknowledgement of receipt, whether communications is accomplished by asynchronous messaging or synchronous calls, etc.

In the preferred embodiments of this invention — a multi-mode communications system — described below, the communicated items are passed between software components as these are broadly defined above. In another set of embodiments - semanticaUy rich programming languages — the communicated items are individual lines of code in a programming language, and the communications are between the source code of the program and the computer on which the code is run, with a compiler or interpreter, acting as a translator between the two. The details ol each of the five aspects of the invention aic discussed below as they apply to the preferred embodiments.

A. Action-Based Classification Scheme

The action based classification scheme defines each communication as having a specific purpose in its effect on its recipients. The classification scheme includes a set of mode classifiers. Each classifier has a definition that aUows one to determine whether a communication is properly described by that classifier. The modes identified in these schemes are not specific to a single business or other human entcrprusc, but apply to the most fundamental purposes of communications, common to aU human enterprises

A sample classification scheme us as loUows:

(1) Exustence Announcement: announcement of the existence ol an entity - when a new entity is introduced to a system or created by the system, it or its creator announces its exustence.

(2) Definition: declaration ol a definition — when a communicator with the authority to do so wishes henceforth to communicate using some term not already shared among communicators. For example, when it is declared that the lunclion f(x) means the result of adding 4 to x. (3) Rule Stipulation: stipulation of a rule to be foUowed - when an entity with the authority to control the behavior of other entities stipulates a rule they must foUow, e.g., that no communications wiU take place durmg a certain time period.

(4) Description: description ol attributes of and relationships between one or more entities

(5) Event Report: report of the occurrence of an event — where an event us the change of state of one or more entities at a particular time.

(6) Legitimization: a declaration of a state. This means that, merely by having emanated from a communicator serving an entity that has the proper authority, automatically means that some other entity has a certain attribute. For example, a security entity may declare that a ceildin user log-on has been authorized, (or is not authorized) which means that the user IS authorized (or is not) Legitimation differs lrom leporting of a description, because a description report may be false, while with legitimization, performing the legitimization communication makes the legitimization true For example, if an airplane entity reports that it contains a certain amount of luel. thus docs not automatically mean that this report is correct, whde if an air traffic control entity clears an airplane for landmg (a legitimization event) then the airplane automaticaUy has been cleared for landmg

(7) Execution Instruction instruction to cause a change ol state in one or more entities

(8) Communications Request request to a communicator that it pcriorm one ol the communications acts above

(9) Service Registration a request lrom one communicator to another that it receive a particular category of communication in the future

An action based classification scheme in accordance with the invention may have more or lewcr communications modes than the ones above, and they may be named diflerently, ol course However, such a classification scheme is prelerably always based on the very generic mode of action expected on the communication recipients, is independent ol the business domain, and these modes, which are apphed here to sottware components, apply equaUy weU to human recipients of communications Any classification scheme that exhibits these properties and further aUows standard signatures for each kmd of communications is the equivalent of such an action based scheme, no matter what the scheme us actuaUy caUed

A method for constructing such an action-based classification scheme can include the foUowing steps

1 Identify some set ol characteristic programs and their associated human activities that are to work together in a particular domam of activity such as hospital administration programs and human activities tor patient admission and release, tracking ol diagnosis and treatment, and patient billing. Each of these will correspond to a single or related set of business functions. 2- Imagine that each of these functions is performed by people, rather than programs. This amounts to treating the programs as if they were people, embodying the intentions of the programmer, or treating the program itscU^" is an extension of the will of the programmer.

3. Examine the functions, identifying each time the program's or person's responsibilities require it to communicate with other programs or people performing other functions-

4. For each such communication event, describe the general communications purpose of the communicator in terms of what he or it is trying to make happen, e.g., does he need getting a question answered, is he required to report on the work he has completed, is he asking someone else to do some work?

5. Give each of these purposes a description name, such as AskQuestion, AnswerQuestion, giveCommand, confirmCommandReceived, and provide a precise definition of what will change in the environment of aU the possible recipient components when this action has been properly performed, e.g., AskQuestion: some other components will attempt to provide an answer to the question-

B- Action Type Identification

The software communication mechanism used is enhanced by a method of identifying each communicated item according to the action type communicated. For example, a single mode communication mechanism in accordance with the prior art (such as the remote procedure caU) can be enhanced to carry mode information in a variety of ways, including simply making the first parameter of the caU always indicate the communication mode. A properly purpose-built communications mechanism in accordance with the invention, on the other hand, identifies the mode with the first element or otherwise most prominent element of the communicated item. C. Partitioning Stipulation

Preferably, no communications ,ιre permitted in which multiple action types are embedded in the same individual communication item. (Of course, multiple items may be concatenated together, and contained in a single physical message "package.") In practice in the prior art, it is possible to construct communications in which multiple actions are intended. And in fact, most programming languages and interface specifications, based on the procedural paradigm, always mix intentions- For example, an instruction to create a new customer record in a database (an execution instruction) will also contain, as part of itself, aU the attributes of the customer to be stored (a description). In communications that are conformant with this semantics in accordance with the invention, these two communicated items, (the execution instruction and the description) would be communicated in separate and independent expressions.

D. Signature Rules Each mode of communication includes a "signature," which means the entire structure of a communication in that mode. Since each communicated item represents a single mode or purpose, the permissible information passed along with each item is restricted to that required for the given purpose. So, each signature form designates exactly what pieces of information may be communicated. It may do so through a positional syntax, as the function calls in most programming languages do so, or through tagged syntax, as do S.W.I.F.T. messages, or through a combination of position and tags, as do XML and XSL syntax.

Using this invention, the structure of the signature wiU generaUy always be the same, composed of the foUowing items. The order of these items is immaterial to the invention. But some means of determining which item is which Is of course necessary, such as order or tagging.

1. Communication Act Type - an identification of the type (and possible subtype, if one exists) of the act being performed.

2. Logical Identifier of the Originator of the Act - an identification of the creator oϊ the act. This is not a communications "address," which would generaUy be handled by a lower level communications protocol, and is undoubtedly associated with each sender, but rather the unique name of the logical system component that performed the act and is responsible for issuing the communication.

3. Timestamp of the Act (optional) - this timcstamp may include both a waU-clock time (and of course date) but also a Lamport time - i.e., a partiaUy ordered identifier of the act sequence relative to some series of related acts. The Lamport time Is the time on the distributed Lamport Clock, which coordinates business transactional order independently from possibly different waU clock times for different system components, e.g., the notification of the close of day for a transaction processing component, such as an FX trade booking system, may have a Lamport time of

<sl=l>. This notification results in communications acts that are logicaUy transmitted in paraUcl to three other systems, in acts with Lamport times of <sl=2, s2=l> <sl=2, s3=l>

<sl=2, s4=l>, so that aU these other events are later than the first Lamport time, but unordered with respect to each other.

4. Action Adverb (optional) - the action adverb takes a value from a set of values that indicate the quality of service associated with the action. This set varies depending on the action. For example, an execution instruction may have an adverb of urgency (and consequently relative cost strategy for the executor to pursue) associated with it, while an asynchronous subscription dehvcry might instead have an adverb of actual cost incurred in delivering the subscribed item.

5. Argument of Act - each communications act includes of a single argument, expressing the propositional content, or attributes and relationship between entities, being caUed to attention by the act. The nature of the argument varies only with the type of the act. And the argument itseU^" may be a complex structure, rather than a flat list, which permits the arguments of some kinds of acts to be infinitely varied.

For example, the argument of an execution instruction is an ordered pair with two elements: a description of the operation to be performed; and an identifier of the object on which the operation is to be performed

(Note that in the case of an execution instruction, the state of the object on which the operation is to be performed is not part of the instruction. The state wiU be obtained by the executor in the most appropriate of a variety of manners, depending on the design of the process).

The argument of the act can be very complex, and each part may include a variety of parts. For example, an action authorization request may include: a. the business entity of whom the authorization is requested; b. the business entity requesting the authorization; c. a description of the action, which in turn comprises a quadruple: i. action type, ii. object on which the action Is to be performed, hi. action initiator description, and iv. parameters of the action; d. the state of an object on which it is to be performed; and c. the change of state that will occur if the action us taken (the effect on the object).

The foUowing is an example of this structure: a. a banking relationship manager (the business entity of whom authorization is requested) may be b. requested by either the funds transfer operations department, in one case, or the director of the operations department, in another case (the business entity requesting the authorization - note that this is different from the logical systems component where the act was initiated, which is item 2 of the signature) c. to authorize (the action description) i. a cash withdrawal (the action type) ii. to account 123 (the identifier of the object on which the action is to be taken) hi. by a particular signator of the account (the action initiator description) iv. in the amount of 2.5MM with value date of today (the parameters of the action) d. the account having a positive intraday balance state of 2MM doUars, and a set of overdraft terms and conditions (the current state of the object) e. which action would cause it to go to an overdraftcd intraday balance state of — 500M doUars (the effect on the object).

Each of the communications act types and subtypes has a shghtly different argument. The argument itself, however, once defined, is constant in structure for aU acts of that type. The invention works through the process of pre-defining, for each such act type, it's unique argument.

The method for identifying the argument for each type of communications act is as follows: 1. Consider a particular cxampl ; of an act ol^' the type, expressed not in machine language, but in a natural language, such a*- a pa' ticular command, e.g., "Drink Tea!"

2. Remove the words and word order that represent the fact that this is a command, and consider only the type of each word that rcmams and the relationship expressed among the types (drink -expresses and action) (tea - expresses a thing on which the action is performed).

3. Abstract the types of these words into a general pattern for the signature. In this case, "action expression - object on which action is to be performed".

This standardization of signatures is very different from the ad-hoc definitions of signatures common in the communications acts of single procedural programming paradigm communications designs in the prior art. In the prior art, the signatures are defined specificaUy for each different capability - for example "drink(name of liquid)." In addition, in those signatures, there are only two or three constant syntactic parts: a. the particular action to be performed by the communications recipient. In the standard prior art approach, this is always the primary controUer of the whole communications. For example, a single procedural function might be request_overdraft withdrawal_authorization.

On the other hand, in accordance with the invention, this function is preferably decomposed into three distinct parts that may be combined in different ways in each communications act:

1. the communications act type (e.g., action authorization request),

2. the action type to which the communications act Is apphed (e.g., withdrawal), and

3. the proposed state change that requires that the request be made (e.g., overdraft). By having these three items separated and standardized, they may be rccombincd to express different meanings without creating new signatures and/or "message types'^" for each different thing that automated components arc required to express. This recombination is the basis for constructing the very large and theoretically infinite number of different things that can be said out of a finite list of signatures.

b. a list of aU the other elements of the communications, in some request or perhaps in an apphcation specific order. (This would contain aU the other elements of the signature, in an unordered list.)

c. the data type of a value to be returned.

This return value is not contained the inventive model of the communications act. but rather in the model of action relationships, and in descriptions of aU the possible rational responses (subsequent communications acts). For example, an authorization request may have only four possible responses: authorization granted, not authorized, placed on hold, or a response that the entity being requested to perform the authorization docs not have the authority to make such an authorization. These four responses arc entirely independent of what Is being requested to be authorized and, like the rest of the invention's model, they are not designed by the programmer for a particular case, but rather the result of the designer of the entire aggregate system asking: "When you ask a person to authorize an action, what are the possible kinds of responses they can make?"

In contrast to these three parts of prior art signatures, the example invention signature has 5 major parts ( 1 to 5), the last of which has, for this communications act, 5 parts (1 to 5), and one of which has 4 subparts of its own or, for this particular type of communications act, 14 parts.

SimOarly, when single-industry standardization groups define complex structures for particular messages, they do not abstract to a general form for different types of speech acts, but always start with a particular complete and compound expression of the communications (e.g., equities_settlement_advice). In this way. despite the small number of signatures, this signature standard also permits much more expressive power than current c-commercc domain-specific message standard efforts, aU of which limit the content of messages to some finite list (such as SWIFT), even if they use structured arguments (such as XMLJFIX).

In both alternative cases, (single-programmer designed communications and industry standardization), starting with a hsl of the things that can be said docs not aUow for an automated network of systems to expand what can be communicated at run-time. In the prior art methods, aU new things that must be communicated must be designed in, and subject to much debate and reprogramming, for each community of communicating entities.

The standardization also, however, requires the rcification of expressions in the language itseU^". In other words, the expressions of actions themselves become arguments of the communications acts. For example, the expression

"deposit (100$ into account 123)" is a command in most automated languages- In the inventive multi-act language, it is a single argument expressing the propositional content of

a deposit relationship existing between account 123 and a particular position of $100

which can occur in at least the foUowing four communications types: action authorization request ("deposit(100$ into account 123)") - can I do it? execution instruction ("deposit (100$ into account 123)") - do it information request ("deposit (100$ into account 123)") - did you do it? event report ("deposit (100$ into account 123)") - I did it Contrast thus with the way these would look in prior art intcr-apphcation languages: dcposit_ authorization ( 100$ into account 123) deposit(100$ into account 123) deposit_query(amount, account) deposit_rcport ( 100$ into account 123)

SimUarly, and perhaps more strikingly, the signature for an execution instruction is defined so that it contains only the identity of the entity on which the execution is to be performed, and the identity of entity ultimately responsible for making the request, and of course, the name of the instruction to be executed. Thus, the signatures for individual operations do not dhfer, but differ only among the pre-defined communication act types. In other words, there are only a finite and smaU number of different possible signatures, and these are aU predetermined by the communication act type.

This contrasts sharply with the common practices of today, in which each operation or pubhcly avaUablc service is assigned a distinct and unique signature by the programmer, so that the operation cannot be accessed without knowing this signature. As a result, new services cannot be accessed untU the users of the services are able, through programming or some other means, to create messages with the given signature. With the present invention, the communicator need only know the name of the new service, and the communication mode in which it is requested.

E. Speech Act Interpretation Framework This framework provides the steps and general structure for a class of algorithms that enable a component to interpret a speech act performed by some other component. This Is a framework for a class of algorithms, any of which wiU have the structure provided here, rather than for a single algorithm. 1 - Context fo ^* Speech Act Interpreter

The outcome of the interprctatior of a speech act is the determination of what action the recipient component must perform in response. This response action may itself be another speech act, or some other kind of action. However, performance of this response action, and the algorithm by which it Is performed, are not part of this invention.

Thus, the context for the algorithms, as generaUy illustrated in FIGURE 7, is

1. the recognition of a speech act, as dehvcred through any lower level communications mechanism, by the Speech Act Interpreter 30 2- the determination by the Speech Act Interpreter 30 of what action(s) need to be performed as a result of this recognition, creating the Action Stack 50, and 3. the dehvery of this hst of actions from Action Stack 50 to the components that will perform them by the Action Executor 40.

The speech act interpreter 30 represented in FIGURE 7 is therefore the sub-component to which the algorithm framework apphes. The action executor 40 represents the ability to perform some internal action of the component, and therefore corresponds to what is pubhcly invoked in current inter-component communications. The speech act interpreter is, from this point of view, a new layer between internal actions and external invokers. Its general role is to remove the responsibUity for determining what action a component should take from any other component, and placing it within the component that wiU perform the action. In effect, it gives components the intelligence to decide for themselves what they need to do, based on what they hear going on around them, rather than being told by other components what they wiU do.

2. Responsibility and Operation of the Speech Act Interpreter

For each speech act type, there Is a standard set of appropriate responses. These responses arc determined by the purpose of the act. For example, the purpose of asking a question (a speech act) is to obtain an answer, so the nature of the response (providing an answer) is determined by the type of the act. SimUarly the purpose of providing a description is always the same: it is to cause the receiving component to "know" the description of the described entity. So the appropriate response is to create that knowledge. This knowledge may of course be implemented in any one a number of ways: e.g., by the assignment of values to the elements of a data structure, by the setting of the values of the attributes of an object, or by the storage of rows in a relational database. But the interpretation and response algorithm does not have mixed purposes, it only performs this single generaUy simple task.

The type of action that was performed results in a particular set of possible appropriate responses. This set of possible responses depends only on a completely generic model of the meanings of different kinds of communications actions. For example, an event notification may require the creation of an asynchronous subscription dehvery, the recording of the event in the information store, and the creation of an execution instruction, but it will not require a description request. Thus, the first step in the generic algorithm for interpreting speech acts Is to identify the nature of the act and determine what response or responses arc appropriate.

Among these possible appropriate responses, the correct responses - the behavior expected as a result of a communications act — depends generaUy on three things: 1) the type of act performed; 2) the context of the action, which is determined by its originator, its timestamp, the action adverb, and the subject of the action; and 3) the propositional content of the action.

These parts of the act are therefore examined by the interpreter to determine the set of correct responses. The steps for making this determination are discussed below.

3. Subcomponents and Worksteps of Speech Act Interpreter

Corresponding to the three dependencies listed above, the pattern for interpreting a communications act generaUy involves the work of three parts: an action type analyzer 60, a context analyzer 70, and an interpretation coordmator 80 (shown in FIGURE 8). These parts 60, 70, 80 optimaUy are invoked in sequence, (in order to minimize the search space) and which result in the creation of a list of consequent actions (represented in Action Stack 50 of figure 7) that must then be executed by the some other subcomponent, responsible for performing the response. As shown in FIGURE 8, the parts 60, 70, 80 each have responsibUity for a different steps in the interpretation process.

The steps in an algorithm for interpreting a communications act, assigned to the subcomponents depicted, are as foUows:

1. Determine the type of act that has been performed (in the case of a legacy system, this requires a simple classification of each legacy event signaled into an action type- Otherwise, it merely means looking at the speech act identifier in the communication) - using the Action Type Analyzer 60. 2. Determine the range of appropriate types of responses to that type of action - based on the rules described in the action model 90 - using Action Type Analyzer 60.

3. From within the is range, apply a rule 100 using any other information about the context of the action (e.g., who is the action performer, what are the elements named in the action's argument) to determine the correct types of response - using the Context Analyzer 70.

4. Describe the Details of the correct response - using the Context Analyzer 70.

The role of the Interpretation Coordinator 80 is simply to move tasks and information through the Speech Act Interpreter 30.

As an example, consider an automated component signaling that an equity trade has occurred- The type of act is an event announcement- The range of possible responses is: perform a state changing operation that affects one or more objects managed in the operational information resouicc, make an asynchronous subsciipfion delivery. send an execution request The tact that the event involves a security trade lor an account lor whom we perform settlement services means that not only is the state ol the trade changed, but also a settlement execution request is sent

In th s way, the structure to the response to any communications act us standardized, and individual algorithms lor each ol a potentially infinite number ot types communications event need not be invented by the programmer-

4 Alternative Organizations for Interpreter Subcomponents

The software provided in FIGURE 8 us, ol course, not the only structure capable ol accomphshing the four steps in the work ol the Speech Act Interpreter. For example, as depicted in FIGURE 9, thus work could also be accomphshcd by a soltwarc machine with no Interpretation Coordmator. In thus machine, an Action Type Analyzci 1 10 receives incoming speech acts directly, passes them when analyzed to a Context Analyzer 120, which in turn is directly responsible lor writing the response actions on the action stack 130.

WhUe it us the responsibility ol a communicator (i.e., the component sending the communication) to know to whom the communication us to be addressed, thus addressee us not necessarUy the ultimate executor of the response to the communication For example, m some situations, a communicator can "publish" his speech act to an environment, in which each of the listeners (i.e., the recipient components) will decide lor itseU whether it must or wishes to take any action (Examples ol this situation arc an open biddmg market and the Ethernet protocol.) In addition, there can be an intermediary that routes communications from speech act originators to those components that are intended to receive them. In this case, the act originator need only know that it must communicate the act to thus intermediary (Examples of this situation arc a traffic coordinator" in a television studio and message- routing middleware in a distributed computing system.)

Description of Exemplary Embodiments A. Primary Embodiment: Application to Controlled Component Integration

In this embodiment, separately implemented components communicate with each other either through the intermediation of some business communications integration capability, or directly, using only middleware for such services as publish and subscribe or rehable message queuing. Whatever the mechanism, the structure of aU communications between components Is specified in conformance with a communications semantics of the type described in accordance with the invention- This semantics predetermines and limits the nature of each communications item.

In this embodiment, the components themselves and the communications between them are organized and ordered in a specific manner in order to maximize their independence from each other and to ensure that there are no interdependencies between functions of components. (The dependency relationship Is acychc.) This is accomplished in several ways. The actual components provided are each partitioned into one or more logical components, each with a simply described single business purpose. This partitioning is done in conjunction with identifying the way in which the processes by which the business operates are reflected in the sequences of necessary communications between the components. This is done properly only when no components communicate in both directions with each other using the same mode of communications.

The combination of this structured matrix of communications requirements and the strictly limited nature of each communicated item, regardless of actual business content, results in an easUy understood component structure, in which modifications can be made with predictable effects. AdditionaUy, il the components thcmsch cs weic initially budt so that their pubhc mterlaces conform to the communications semantics ol the invention, they will be able to communicate with each other with no intermediation except lor perhaps syntactic translation, even if the mterlaces required aic in ddlerent languages Today, this intermediation requires an oll-the- cuff guess at the right semantic mapping, dcpcndmg entirely on the skill of the middleware programmer

Most importantly, if thus integration approach is enhanced through the use ol special software that enables domain-specific standard mappings ol entity definitions and component responsibilities, between communications that do not conform to the communications semantics described in th s mvention, then the problem of translating between the communications that can be generated by a sender and the expected resulting actions of a receiver may be systematically organized, made subject to standard, rather than ad-hoc programmmg techniques, and eventuaUy luUy automated

B Example of Primary Embodiment Overview

An mteraction is an act of communication produced by one entity, and a response from a second entity, or a related sequence ol such productions and responses between multiple entities Action-oriented communications (AOC) us a method lor designing the mteractions between automated components, and the soltwarc entities they contain, so that these mteractions foUow generaUy the same patterns lound in the mteractions among people engaged in weU-defined work

WhUe AOC could be used to design new programmmg languages, it is itself not a language, but rather a an analysis process and response algorithm, which can be apphed in many existing programmmg languages, such as C++, or using exustmg ter-component communications mechanisms, such as various implementations of CORBA™.

This example illustrates action-oriented communications by presenting a business scenario, then showing how that scenario is translated into component interactions according to traditional prior art methods, and finaUy contrasting how the scenario is to be translated using the action-oriented communications process-

The scenario describes the introduction of a new trader into a foreign exchange trading room and his subsequent making a trade. In the scenario, emphasis is on a description of the non- automated parts of the work, to give a better sense of the nature of the interactions involved, even though only some of these wiU be translated into analogous automated work. The scenario also has particular inventive features, combining characteristics of various different kinds of trading where different rules and interactions apply, to Ulustrate various different aspects of action-oriented communications in a single example. The example then describes the types of software components necessary to support this scenario, and the general nature of the interactions between these components.

These component interactions are then used to illustrate the difference between the prior art interaction design and processing methods, and the inventive action-oriented process. The prior art process requires each automated component that supports this work to communicate with each other component by means of a machine instruction, or function caU, in which Is embedded aU the information required to execute that function. Using the action-oriented process, in contrast, each component expresses its own intention to the other components, which in turn are themselves responsible for determining how they should correctly respond and for obtaining the information they require to do so. Scenario

Summary A new trader, Richard Harkness, has been hired by the head trader lor a New York FX tradmg room He shows up for work on the first day, is mtroduced to the head ol tradmg room operations, is provided with a workstation and tradmg rules, and executes a trade

Arrival and Introduction After procedures ga mg him entry to the budding, Richard Harkness us greeted at the door to the tradmg room by his new boss, head trader Harry Stillman

Harry then mtroduces Richard to the head of tradmg room operations, Anush Mathai, telling Anish that Richard is a new hire Euro Trader, asking A-nush to set Harry up so that he can begin work (Each trader in this FX tradmg room trades m only a single currency or a lew currencies aga st the US doUar: there are Euro traders, British Pound Traders, Yen Traders. Asian Exotics Traders, Lat America Currency Traders, and Canadian DoUar/Austrahan Pound traders ) Anish fiUs out some identification lorms, and escorts Richard back down to the guardroom at the entrance, presenting these forms Richard is photographed, fingerprinted, and issued a budding and tradmg room pass

Work Environment Set Up

Anish then brings Richard back upstairs, rechecks with Harry that Richard wiU be trading Euros, and asks Harry what class of tradmg Richard is authorized lor Harry Answers "Class Two" (Each trader is divided mto one of three classes, each of which has respectively more workmg capital, and is authorized to do trades of respectively larger sizes without approval) Anish selects a free workstation in the area in which the Euro traders work lor Richard

Anish assigns Richard system identification and security features (a log-in and password), and also sets up a tradmg book tor Richard, identifying Richard as a Class Two Trader, with working capital in the Class two amount. Anish explains to Richard the restrictions on class two traders, how to use the systc m. and gives him a paper list of the counterparties with whom he can trade, their phone numbers, and a list of the salespeople from whom he can take orders.

Trade Execution

SaUy McCabe, a salesperson, gives Richard an order for EU5MM. He calls a counterparty at Chase, and requests a spot quote on Euros. Chase recognizes his bonafides, and provides him a quote for both Bid and Ask. Richard makes a counteroffer on Chase's asking price for Euros, which Chase in turn accepts. Richard then enters the deal in his trading book: bot EU5MM for USD20MM spot from Chase.

The system determines that this trade is within the range Richard is aUowed, and that the counterparty Is vahd, and so tells him the deal has been accepted. The system shows him his new positions. The system also sends updated contingent liability and asset positions to the general ledger, and initiates its confirmation process.

Software Components and Interactions Involved

Software plays two roles in this scenario: Some of these human relations arc mirrored in software, such as Richard's role as a Class Two Trader, and some of the business artifacts are realized only in software, such as the trader's book, or the financial accounts. These roles are evinced by the interactions, which occur between different components of the software- Components To support both these kinds of roles the foUowing software components arc used:

User Surrogates and User Surrogate Management: A software surrogate for each person who works with the system, such as a surrogate for A-nlsh Mathai, the trading room operations head, and the management of this set of surrogates. The responsibUity of each surrogate is (1) to ensure that the person on whose behalf it operates is authenticaUy that person, identified with any required personal attributes; (2) to associate thus user with one ol the particular roles the user can play with respect to the system, and to establish and to identify any ol the attributes associated with that role; and

(3) to represent the direct requests ol thus user to other software

The responsibility of the suirogalc manager s to enable disable, and modify surrogates

Capability Control: Thus component permits users m roles to perlorm specdic lunctions. Its responsibilities thus include

(1) associating system lunctions with roles:

(2) providmg a user surrogate with the list ol lunctions the surrogate us permitted to perform; and

(3) enabling a user surrogate to perlorm one of these functions.

Trade Entry: This component us responsible for ensuring that a trade as described by a trader is a vahd trade, containing complete and acceptable intormation

Trade Bookmg: This component us responsible lor refiectmg the effects ol a trade or other transactions on the trader's book.

Financial Accounting: Thus component us responsible lor reflecting the clfects of a trade on the financial accounts.

Trade Confirmation: Thus component is responsible lor managmg the process by which trade confirmations arc exchanged with counterparties

The actual physical design of the soltware might ol course not be organized accordmg to this scheme, but even so, the responsibilities of the components wiU be represented in some form or another, and these logical components must mteract with each other, using some communications mechanism and a corresponding communications paradigm.

Interactions Below are selections from necessary interaction events for the software components to support the trade execution portion of business scenario.

Trade Execution:

1. Richard Harkness User Surrogate (RHUS) recognizes him and his role as a Trader. This step involves the interaction between a non-automated entity (Richard Harkness) and a software component (RHUS).

2. Capability Control provides RHUS with the things he is able to do.

3. RHUS indicates that he wants to enter a trade.

4. Capability Control enables this function to be performed by Trade Entry for RHUS.

5. RHUS enters the trade. 6. Trade Entry determines that the trade is vahd.

7. Trade Entry gets Trade Booking to book the trade to the RHUS book.

8. Trade Booking gets Financial Accounting to record the contingent assets and liabilities resultant from the trade.

9. Trade Booking gets Trade Confirmation to institute confirmation procedures.

Prior Art Design Process and Methods

In any traditional design process and corresponding communications execution method, a single communications interaction paradigm is used to realize aU intercomponcnt interactions. The most common of these is the function (or method) invocation, expressed in languages in which aU communications are imperatives, in which the initiator of the communication is always presenting the recipient with a "machine" instruction for the recipient to execute. Further, it is the responsibUity of the initiator to provide the recipient with the aU information required to carry out the instruction, in the form of "parameters" of the function. The design process is one in which the actual human purpose or intention behind each step in the business scenario is ignored, and the corresponding responsibilities of the sending components, and replaced with an instruction from the sender to the receiver initiating some responsibUity of the receiver, rather than the sender. This means that the sender must "know" what the receiver is responsible for doing.

More broadly, the general process for inter-component communications design for any single- paradigm prior art communications approach is to

1. Understand how to use the single speech-act paradigm by which components communicate. (This is usuaUy so ingrained in the language and thinking of the designer that it is not explicitly stated, but is still implicitly understood and an essential first step.)

2. When one component reaches a state at which some relative completion of work has occurred, and at which its work needs to be coordinated with the work of some other component, determine what needs to be done next, by some other component.

3. Determine how to communicate that need to the other component, according to the given paradigm.

4. Determine what, from among the facts, event, rules, or things known to one component, qualify as things that can be communicated to the other component, which will enable it to carry out its responsibUity.

5. Construct a communication to that effect directed at the appropriate component, using a special function "signature" designed to carry the specific information required for this individual kind of communication.

The machine instruction paradigm is illustrated here. It is illustrated by means of a set of some of the function calls or method invocations, which would correspond to the nine interactions described above, and the nature of the responses to these. These instructions are expressed in a self-explanatory pseudo-code. The description of the design process sometimes personhies the component to ha\ e the goals of its designer. OveraU, the process of designing soltware components to do this work using this paradigm is analogous to imagining that people were doing the work but could only communicate with each other by giving each other exphcit commands to do certain precise pieces of work. And the algorithm for responding to a communications is designed independently, for each individual instruction.

Trade Execution:

1. Richard Harkness User Surrogate (RHUS) recognizes him and his role as a Trader. none.

2. Capability Control provides RHUS with the things he is able to do.

A function caU from RHUS to CC: sendCapabihtyList(RHidentity, RHrole) the CC executes an algorithm to find the items in this list, based on the RHrole, and returns the hst to RHUS as a response to the function caU.

3. RHUS indicates that he wants to enter a buy trade.

A function caU from RHUS to CC: initiateBuyTradeEntry(RHidenity, RHrole) in order to execute this instruction, CC determines again, by looking at a hst, that RHrole is permitted to do this function, and, if so

4. Capability Control enables this function to be performed by Trade Entry for RHUS. a function caU from CC to Trade Entry (TE) prepareBuyTradeEntry(RHidentity, RHrole, tradingRoomldentity) causing TE to prepare according to some algorithm to receive a trade entry request from RHUS, returning the form for RHUS to fill in, and likely a set of "defaults" for the entry, based on the RHrole, already on the form- In typical designs, thus loi m will hkcly be passed through CC to RHUS, lor display to Richard Harkness by RHUS, as the return lrom mitiatcTradeEntry.

In another design. CC would return only a "done" response to that mitiatcTradeEntry invocation, and TE will now assume control of the mteraction, by a lunction caU lrom TE to RHUS bcgιnBuyTradcEntry(tradcEntryForm, deiaultValuesList).

This causes RHUS to display the tradeEntryForm with defaults to Richard Harkness. This second design choice us the path that wc wiU foUow In thus design, RHUS returns a "begun" response to TE

5. RHUS enters the trade

In the simple case be g considered, the entire lorm is fUlcd in belorc TE looks at it aga . This filled in lorm us provided to TE in a function caU from RHUS to TE: acceptBuyTradeEntry(RHιdentιty, RHrole, trade parameters(e.g., currency bot, amount, rate))

6- Trade Entry determines that the trade is vahd.

TE executes an algorithm that causes it to look at the parameter values of the trade and determme whether: each field has a value it is generaUy permitted to have, the values of the trade correspond to the values permitted to RHrole the tradmg book has sufficient aUowed positions to accommodate the trade

Assuming that this us aU the case, TE returns to RHUS that the trade has been accepted, having within the same transaction:

7. Trade Entry gets Trade Booking (TB) to book the trade to the RHUS book. a function caU from TE to TB bookBuyTrade(trade parameters) causing TB to execute an algorithm, which records the trade and updates the positions in RH's book, and cascading this update to financial accounting.

8. Trade Booking gets Financial Accounting (FA) to record the contingent assets and liabilities resultant from the trade.

TypicaUy, TB wUl be responsible for determining the contingent asset and liability postings associated with the trade execution, and make at least two function caU from TB to FA post (financialAccountID, amount, direction, transaction reference, transaction description, other parameters required by financial accounting) financial accounting then passively makes the debit and credit entries in the appropriate accounts.

9. Trade Booking gets Trade Confirmation (TC) to institute confirmation procedures, with a function caU from TB to TC- cofirmBuyTrade(trade parameters list)

Note that in each case, a. the communication from one component to another is in the form of an instruction; b- the interaction is focussed on the recipient of the communication, rather than on the originator; c- as a result, each component must know what the other component must do, instead of being concerned only with its own responsibilities; and d the logic ol the work is always "anticipatory", or oltsct by one step iiom its natural place ol determination (namely, m the component that must actually do the work)

So, in a world in which people (or software) can only give each other commands, everybody needs to know everybody else's busmess. And the algorithms executed by each component arc nothing but the procedures required to do what was requested, rather than first dctcrmmmg what us the appropriate thing to do under the circumstances (In tact, the general goal ol component-based design is thwarted by this particular common paradigm, because components that are designed m isolation from the components that must use them seldom otter the services that are required, whUe components designed for the particular use of other components are unlikely to be generahzable for use in other contexts).

Action-oriented Communications Design Process

In the inventive action-oriented design process and correspondmg communications execution method, multiple communications mteraction paradigms, one tor each kmd ol action that can be taken by a communications initiation, are used to reahze mtcrcomponent interactions

A sample (partial) list ol such different kmds of actions is as foUows.

Existence Announcement - an entity makes its avaUabihty or unavadabihty known Information Request - an entity requests a description of the state ol some other entity

Inlormation Answer - an entity returns the answer to an information request

Capability Request - an entity requests a description of what us to be pcrlormcd for some othci entity

Capability Answer - an entity returns the answer to an capability request Event Announcement - an entity announces that it has changed state.

Authorization - an entity authorizes another entity to perform certain functions.

Legitimizing Introduction - an first trusted entity mtroduces a third entity to a second, with the stipulation that the thud is to be permitted to perlorm some function. Execution Request - an entity ind cates that it wants another entity to pcilorm some operation Instruction Guide - an entity cxp.ains what it needs to know to execute an instiuction Execution Instruction - an entity instructs another entity to perlorm an operation changing its state

The distinction between a request and an mstruction, generaUy obvious m human contexts, may lnitiaUy seem meaningless to programmers schooled m imperative-only languages The importance ol distinction wiU become apparent m the course ol the scenario

In addition, for each of these kinds of actions, a smgle signature is defined, so that mstead of defining signatures lor each individual thing that must be said, a common signature is used tor aU thmgs that represent the same kmd of action

This smgle signature results lrom the tact that the "wrapper" ol the communication is no longer a particular mstruction, but is rather an expression ol the speech act type, and inside this wrapper is lound the "propositional content" ol the act, whose structuic us determined by the type of the act

A "propositional content" us an expression ol a relationship between objects and between their attributes, mdependent ol how that expression is bemg used to perlorm an act Thus, the same propositional content may be used tor different purposes diflcrcnt speech act types, where the speech act type provides the context for interpreting the intention ol the act

For example, the expression ' execute, Richard , buyTradel23" (Richard executes buyTradel23) is a smgle propositional content which might occur in the following ddlerent contexts, translated lrom a lormal language to Enghsh

authorιzatιon(execute, Richard, buyTrade) — an authorization. "Richard, you arc authorized to execute buyTradcl23"

cxccutιonInstructιon(cxccute, Richaid, buyTrade)

— a command: "Richard, execute buyTrade 123!"

ι-nformalιonRequest(exccute, Richard, buyTrade)

— a question: "Did Richard execute buyTrade 123'<^*"

In thus example, the general structure of the propositional content us "evcnt_dcscπptιon", where an event description is an action pcilormed by one entity on another. Thus, one ol the last steps in the prior art smgle paradigm design process becomes one ol the first in the meanmg-based process - determming the signatures

More broadly, the general meanmg-based process lor lntci -component communications design

1. detcrmme the range ol speech act types that arc required by the human and component interactions in the problem domain, by considering each pubhcly known action that the components perform, and associating each action with a speech act,

2. define a particular form for the perlormancc ol each mstance of these speech act types, including the signature of the act;

3. when one component reaches a state at which some relative completion ol work has occurred, and at which its work needs to be coord ated with the work ol some other component, determine what the component or some entity within the component has accomphshcd or itself needs, and determine what speech act expresses that need. Unlike the case ol smgle paradigm methods, thus determination is based on the needs of the entity performing the act, rather than the recipient;

4. construct an expression of the speech act, which volves dividing the act itseU^' from the propositional content contamed m the act; 5. determine to whom this act should be addressed. This determination Is again based on the needs or responsibilities of the component that performs the act- (For example, the addressee component could be one to which events are reported, or could be one or more trusted components to which questions are addressed); and

6. direct the appropriate communication to the appropriate component.

OveraU, the process of designing software components to communicate, using this paradigm is analogous to imagining that people were doing the work and can communicate with each other in any of the ways required by the situation, as catalogued on the list of avaUable speech acts-

The algorithm for responding to a speech act has the foUowing general structure:

1. Determine the type of act that has been performed.

2. Determine the range of appropriate types of responses to that type of action-

3. From within this range, use the context of the action to determine the correct types of response (there may be more than one).

4- Perform each of these correct responses, which may involve other speech acts.

This method of communication is more interactive than any single-paradigm method, so to save space, only part of the trade execution example is covered-

Trade Execution (first part): 1. Richard Harkness User Surrogate (RHUS) recognizes him and his role as a Trader- An action performed by Surrogate Management, directed to Capability Control (CC) existence-Announcement (RHidentity) "Here he is!"

Note that in this example, CC must trust this announcement, so that RHUS must have been introduced by a trusted source, namely the surrogate management component. This is analogous to the introduction of Richard (the trader) to Anish (the operations manager) by Harry (the head trader).

2. Capability Control provides RHUS with the things he is able to do. As a result of an existence announcement, capability control a. registers the existence of the entity RHidentity in its internaUy accessible memory, creating the capability to deal with this entity b- finds out from RHUS entity what type of entity R-H is: informationRequest (RHidentity) "Who are you?" c- receives in return, the response informationAnswer(RHtype, RHattributeStructure) "I am a trader, level 2, working in New York Trading Room, trading Euros." d. determines what RHUS can do, by executing the same algorithm as in the instruction example, and tells RHUS what it can do authorization(RHcapabilityList)

Note that in this scenario, RHUS does not need to know that it is CC's job to teU him what he is aUowed to do. He finds that out, just as Richard does, when he is told. RHUS may indeed be waiting to find this out, or doing something else in the meantime, but in any case need not know from where the information wiU come.

3. RHUS indicates that he wants to enter a buy trade an execution instruction from RHUS to CC: executionRequest( buyTrade) "I want to execute a trade" In order to execute this instruction, CC determines again, by looking at a hst, that RHrole ;s permitted to do this function, and, iϊ so (The capitahzed "buyTrade" in the request indicates that the Type of the action is specified in this request.)

Note that the function is to execute a trade, not a buy trade. The artifice of making the buy and seU different capabilities was required by the coarse design of the previous example.

4. Capabihty Control enables this function to be performed by Trade Entry for RHUS legitimizingIntroduction(RHidenity, buyTrade) ("here Is Richard Harkness, and he want to execute a trade")

The response from TE to any capabihty request is a request in turn for detaUs and defaults: capabUityRequest (buyTrade) ("what kind of a buy do you want to do, Richard?") capabUityAnswer(objectAttributeStructure) "I want to buy Euros from the New York office". (This structure has only some of the attributes filled in. In this scenario,

RHUS provides the "defaults" for his own trade, rather than vice versa.)

TE then provides the foUowing communication to RHUS instructionGuide(transactionID, tradeEntryForm) ("here is the reference number for the trade we wiU be doing, and here is what you need to teU me about the trade")

RHUS then uses this guide to prepare the information that describes the trade, and when complete, finaUy sends and instruction to TE. executιonInstιuctιon(tιansactιonID, objcctAttiibutcStructure)

("execute trade buyTiadcID with the values object AttπbuteStructure (Euro2MM, countcrpaity Chase, etc )")

In this example, as wiU aU uses ol a action-oriented communications design procedures and processing methods, there us generally much more mteraction, and so there are many more communications between components But each such communication is simpler and more standard m nature, so that the responses to it arc correspondingly simpler and more standard.

Note that m each case, a The communication from one component to another has only one of the 1 1 predefined grammatical ior s, based on the 1 1 ddlerent speech acts ldcntdicd lor thus example problem The structure ol the signature us part ol thus form, so that there arc only 1 1 predefined signatures for aU communications For example, mstead ol their bemg a special mstruction, such as "acccptBuyTradcEntry(. .)" lor each kmd ol mstruction as in the prior art, there is only single form lor aU execution mstructions "exccutιonInstructιon(transaclιonID, objectAttπbuteStructure)" b These predefined grammatical lorms arc entirely mdependent of the actual content of the act, which us contained in the signature, not in the lorm c Each component has the minimal possible knowledge of what other components will do.

So, in a world in which people (or soltwarc) can communicate with a variety ol ddlerent general intentions, which they express independently of the mformation content of the communication, they can function relatively mdependently from each other. And the algorithms executed by each component have a generic structure based on determining the speech act that has been communicated- Algorithms that operate according to this pattern can be made even more standardized through appeal to a business model. AdditionaUy, note that when performing a speech act, an automated component generaUy does not care what other component is the recipient, as long as it is dehvercd to the right place- For example, when a component asks a question, it only needs a trusted answer, it does not need to know who actuaUy produces the answer. This fact about speech act based design opens the door for a much wider role in which "middleware" can help intermediate between the work of components.

C. Application to the Context-Dependent Selection of Business Rules and Procedures

In this embodiment, the strict control of meaning for communications is used to enable more flexible use of multiple procedures or rules. This is necessary, for instance, to accomplish "mass customization," in which different customers are offered different terms and conditions involving the same product.

In many other cases as weU, the rules or procedures foUowed vary from entity to entity. In addition, in most of these cases, the information that Is required to apply the rule also varies, depending on which rule in fact apphes. This apphcation therefore involves making execution requests from a main processing component to an independent component whenever such a variable rule is executed. This request does not, conforming to the communications model, contain any descriptive information concerning the entity to which the procedure must be apphed, but only the identity of the entity. Thus, the receiving rule management component has two parts. First, a rule selection algorithm that determines which rule to apply to the given entity. In order to apply this algorithm, the component makes an information request to the communicator, which serves the entity, (which may or may not be the same as the main processing component), for the necessary information. In this way, the main processing component does not need to have pre-programmed what kind of information is necessary to determine which rule will apply. SimUarly, once a rule has been selected by the rule selection algorithm, the component again invokes the rule, passing only the identity of the entity or entities to which the rule is apphed. Then, based on the needs of this particular rule, the rule algorithm has its rule management component send a number of other requests for descriptions to the entity to which the rule apphes, or to other entities it has, by previous work, discovered arc in some relationship to that one.

For example, when determining whether a given individual is ehgiblc for a certain form of insurance, several factors must be taken into account. First of aU, the rules for determining insurability vary from state to state in the U.S. Thus, the rule selection algorithm wiU cause a query to the individual being tested to determine his state of domicUe, and select a rule based on the result. The rule so selected wills the further query the individual for the information it needs. In one state, this information may include the age of the individual, and in another, the gross income.

By dividing each communication into the simplest fundamental unit of meaning, it becomes clear which component has the responsibUity for which kind of action, and when. This also makes computer programs operate more like human experts. For example, when you ask a painting contractor to estimate the cost of painting your house, you are not responsible for simultaneously telling him aU the relevant facts about the house. You simply point him to the house, and he gathers the information he needs, even modifying those requirements, based on previous determinations. Yet computer interfaces almost always bundle the information required to make a determination in with the request to make it.

P. Apphcation to the Design ol^" Internet Services and Agents An intelligent agent in a network environment Is a smaU software component that can do work by moving across services avaUable on the network from multiple other components, requesting these services and making certain determinations about them- For example, iϊ the agent had the task of finding the cheapest lodging in San Francisco, it would go to each component that offered price quc tations, gather aU the quotations from aU such services, and find the cheapest of them. One complexity in programming such an agent is that the same type of service (such as a price quotation) wiU be requested with different signatures from different services. The required signatures will be published and avaUable to the agent, but the translations of multiple request formats must be either done by a programmer, or each particular type of request must have been subject to an ad-hoc signature standardization, for that individual domain. WhUe XML syntax will lead to greater standardization of signature specification, it will not, in itself, lead to standard contents. For example, a committee may still dchberatc about the parameters that should be passed to make by lodging price quotation requests.

Using partitioned, multi-mode communications, the agent would make a request for a price quotation with no parameters except the identity of the entity from whom the quotation is intended. The quotation service would then query the agent concerning the information about that entity which it needed.

Having described embodiments of the present invention, it should be apparent that modifications can be made without departing from the scope of the present invention.

Claims

Claims

1. A method for inter-component communications, comprising:

when a need exists for a first software component to communicate with another software component or components, selecting a communication act that represents the need from a plurahty of predefined communication acts, each ol^" said plurahty of predefined communication acts representing one type of^" action and classdied according to its expected effect on a recipient component;

constructing a communication comprising the selected communication act and an argument defining a subject of the communication act;

determining which software component or components the communication should be addressed to; and

directing the communication to that software component or components.

2. The method of Claim 1 wherein said argument describes attributes of the software components.

3. The method of Claim 1 wherein said argument describes a relationship between the components.

4. The method of Claim 1 wherein said argument includes a description of an operation to be performed.

5. The method of Claim 1 wherein said argument identifies an object on which an operation is to be performed.

6. The method of Claim 1 wherein said argument identifies a software component from whom an action Is requested-

7. The method of Claim 1 wherein said software components comprise objects, functions, procedures, servers or apphcations.

8. The method of Claim 1 wherein said communication is constructed in accordance with signature rules designating what information may be included in the communication.

9. The method of Claim 1 wherein said communication further includes an identification of the first software component-

10. The method of Claim 1 wherein said communication further includes a timestamp.

11- The method of Claim 1 wherein said communication further indicates the quahty of service associated with the communication.

12. The method of Claim 1 further comprising interpreting the communication to determine what action a recipient software component is to perform in response to the communication.

13. The method of Claim 12 wherein interpreting the communication comprises identifying the communication act, determining a standard set of responses associated with said communication act, and selecting a correct response from the standard set based on the context of the communication.

14 The method ol Claim 13 whcrcm said context comprises inlormation contained m the argument

15 The method of Claim 1 wherem directing the communication to the soltwarc component or components comprises sending the communication to an intermediary lor routing the communication to the software component or components

16 The method ol Claim 1 wherem directing the communication to the soltwarc component or components comprises publishing the communication to said components, each ol which decides whether to respond to the communication

17 A method of mterpretmg a communication received by one soltware component lrom another to determine an appropriate response, said communication comprismg a communication act and an argument delinmg a subject of the communication act, said communication act hav g been selected from a plurahty ol communication acts, each ol said plurality ol communication acts represent g one type ol action and classified accordmg to its expected cllcct on a recipient component, the method comprismg- identifying the communication act; determmmg a standard set of responses associated with said communication act, and sclcctmg a correct response from the set based on the context ol the communication

18 The method ol Claim 17 wherem said context compruses intormation contained in the argument

19 A method ol constructmg an action-based classdication scheme tor use in organizmg communications between software components, comprismg exammmg lunctions of each software component to identify instances when the component's responsibilities require it to send a communication to another soltwarc component, for each such instance, ldcntd 'mg the purpose ol the communication m terms ol^" what the soltware component sending the com nunicalion us attempting to make happen; and naming each of these purposes and providing a definition ol what wiU change in the environment of aU the possible recipient components when an action has been properly performed.

20. A method for structuring communications between soltwarc components according to speech acts they represent, comprismg:

providing a set ol predefined communication acts, each of said predefined commumcation acts representmg one type of action and classdied accordmg to its expected effect on a recipient component;

when a need exists for a first software component to communicate with another software component or components, selectmg a communication act that represents the need from the set ol predefined communication acts;

constructmg a communication comprismg the selected communication act and an argument defining a subject of the communication act;

determining which soltwarc component or components the communication should be addressed to; and

directing the communication to that soltwarc component or components-

21. The method of Claim 20 wherem said argument describes attributes of the software components-

22 The method ol Claim 20 wherem said argument describes a relationship between the components

23 The method ol Claim 20 wherem said argument mcludcs a description ol an operation to be performed-

24- The method ol Claim 20 wherem said argument identifies an object on which an operation us to be pcrlormcd

25- The method ol Claim 20 wherem said argument identifies a software component from whom an action us requested

26. The method of Claim 20 wherem said software components comprise objects, functions, procedures, servers or apphcations

27. The method ol^" Claim 20 wherem said communication is constructed in accordance with signature rules designatmg what lnlormation may be mcluded m the communication

28 The method of Claim 20 wherem said communication further mcludcs an identdication of the first soltware component

29 The method of Claim 20 wherem said communication further mcludcs a timestamp

30. The method of Claim 20 wherem said communication further mdicates the quahty ol service associated with the communication

31. The method of Claim 20 further comprismg mterpretmg the communication to detcrmme what action a recipient software component is to perlorm in response to the communication.

32. The method of Claim 31 wherein interpreting the communication comprises identifying the communication act, determining a standard set ol^" responses associated with said communication act, and selecting a correct response from the standard set based on the context of the communication.

33. The method of Claim 32 wherein said context comprises information contained in the argument.

34. The method of Claim 20 wherein directing the communication to the software component or components comprises sending the communication to an intermediary for routing the communication to the software component or components.

35. The method of Claim 20 wherein directing the communication to the software component or components comprises publishing the communication to said components, each of which decides whether to respond to the communication.