System and method for integrated management of components of a resource

Abstract

Exemplary techniques are provided for defining a binding or relationship between the content of a document managed by an application and a service entity managed by an application service. The binding may enable the user to retrieve the service entity by selecting the document content within the application. The binding may comprise application metadata associated with the document content which provides a reference to the service entity, and context metadata which specifies a transformation performed on the application metadata to retrieve the service entity.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part claiming benefit under 35 U.S.C. §120 of commonly assigned U.S. patent application Ser. No. 10/648,506, filed Aug. 25, 2003.

FIELD OF THE INVENTION

The present invention relates to the field of resource management and, more specifically, to integrating resource management between application services and applications.

BACKGROUND OF THE INVENTION

In conventional resource management systems, application services typically function in connection with applications. Such application services may each manage different components of a resource. For example, two application services may manage different components of a loan approval process. Specifically, a first application service may manage a credit history component of the loan approval process, while a second application service may manage a down payment component of the loan approval process. Each of the application services may manage related service entities associated with the loan approval process. For example, the first application service may mange “applicant” service entities, while the second application service may manage related “loan” service entities.

Applications functioning in connection with the application services may be, for example, electronic mail applications, word processing applications, or spreadsheet applications that enable the production of documents. Such documents may often refer to service entities and influence the management of the service entities at the application services. For example, a document may include the text, “John Smith has missed a credit card payment.” “John Smith” may be an instance of both the applicant entity managed by the first application service and the loan entity managed by the second application service. Thus, the document may influence the management of the applicant entity “John Smith” and the loan entity “John Smith”. Specifically, the document may influence a user to change the state of the applicant entity “John Smith” at the first application service to a “deny loan” state. The document may also cause the state of the loan entity “John Smith” at the second application service to be changed to a “refund down payment” state.

Although documents may often influence the management of service entities at the application services, there is generally limited ability to access, query, and manage service entities from within an application. For example, if the document influences a user to change the state of applicant entity “John Smith” at the first application service, then, to change the state, the user must access the first application service and identify the applicant service entity at the first application service. It may often be difficult, however, to identify a service entity at a application service because a document often does not provide sufficient semantics about attributes by which the service entity is defined. For example, while the document refers to the loan applicant “John Smith” by his full name, the first application service may define the applicant service entity by separate “first name” and “last name” attributes.

The limited ability to access, query, and manage service entities from within an application is particularly cumbersome when a document influences the management of related entities from different application services. For example, if the document causes a user to change the state of applicant entity “John Smith” at the first application service and to change the state of loan entity “John Smith” at the second application service, then the user must separately access each application service and separately identify each service entity at each application service. Separately identifying of service entities at different application services is cumbersome because, even if the different service entities are related, the service entities may be defined at each application service by different sets of attributes. For example, while the first application service may define the applicant service entity by separate “first name” and “last name” attributes, the second application service may define the loan entity by an “applicant” attribute rather than by a name attribute.

Another difficulty relating to the management of service entities in conventional resource management systems is that an application typically provides limited information about the availability of actions which can be performed on service entities at the application services. Specifically, each application service may have specific rules and conditions related to the performance of actions on service entities. For example, such rules and conditions may include a maximum number of times which an action may be performed, a period in which an action must be performed, a limited user or class of users which may perform an action, or a condition which must occur before or after the performance of an action. An application generally cannot determine what such rules and conditions are and whether they are satisfied. Thus, a user must access each component process to determine if an action is available within the process.

Additionally, an application typically has limited abilities to coordinate the management of resources among multiple users according to such rules and conditions. Specifically, an application has limited ability to track the performance of actions and to prevent or advise against the performance of actions that are invalid or likely to generate conflicts. Furthermore, applications typically have limited ability to provide users with information about relationships between entities and processes managed by different application services and the performance of actions on such related entities by other users. Such information may be used to determine the availability of an action and to protect against conflicts related to the performance of the action.

Thus, there is a need in the art for systems and methods for integrating resource management between application services and applications. It is desired that such systems and methods enable, for example, matching of related service entities from different application services, association of service entities with documents, and management of service entities from within an application.

SUMMARY OF THE INVENTION

In accordance with one embodiment of the present invention, a method is provided for use in a system which includes an application executing on a first computer and an application service executing on a second computer, the first and second computers being coupled via a network, the application being operable to manage a document and receive input from a user comprising document content, the document content corresponding to a service entity managed by the application service. The method is for defining a binding between the document content and the service entity. The binding enables the user to retrieve the service entity by selecting the document content within the application. The method comprises: (A) defining application metadata for the document content, the application metadata being associated with the document content, the application metadata including information which provides a reference to the service entity; and (B) defining context metadata which specifies a transformation performed on at least a portion of the information included in the application metadata to retrieve the service entity.

Another embodiment of the present invention provides at least one computer-readable medium for use in a system which includes an application executing on a first computer and an application service executing on a second computer, the first and second computers being coupled via a network, the application being operable to manage a document and receive input from a user comprising document content, the document content corresponding to a service entity managed by the application service. The at least one computer-readable medium includes information which defines a binding between the document content and the service entity. The binding enables the user to retrieve the service entity by selecting the document content within the application. The at least one computer-readable medium comprises: application metadata for the document content, the application metadata being associated with the document content, the application metadata including information which provides a reference to the service entity; and context metadata which specifies a transformation performed on at least a portion of the information included in the application metadata to retrieve the service entity.

BRIEF DESCRIPTION OF THE DRAWINGS

The illustrative embodiments will be better understood after reading the following detailed description with reference to the appended drawings, in which:

FIG. 1 is a block diagram representing a general purpose computer system in which aspects of the present invention and/or portions thereof may be incorporated;

FIG. 2 is a block diagram of an exemplary prior art resource management system;

FIGS. 3a and 3b are flow diagrams of exemplary business processes;

FIG. 4 shows an exemplary document;

FIG. 5 is a block diagram of an exemplary resource management system in accordance with the present invention;

FIG. 6 is a flow chart showing an exemplary technique for establishing a binding between an application entity and a service entity in accordance with one embodiment of the present invention;

FIG. 7 shows an exemplary application user interface in accordance with the present invention;

FIGS. 8a and 8b are flow diagrams of an exemplary method for managing service entities from within an application in accordance with the present invention;

FIG. 9 shows an exemplary application user interface including available actions in accordance with the present invention; and

FIG. 10 is a flow chart showing an exemplary technique automatically recognizing user input as an application entity, according to one embodiment of the invention.

DETAILED DESCRIPTION

I. Illustrative Computer Environment

FIG. 1 and the following discussion are intended to provide a brief general description of a suitable computing environment in which the present invention and/or portions thereof may be implemented. Although not required, the invention is described in the general context of computer-executable instructions, such as program modules, being executed by a computer, such as a client workstation or a application service. Generally, program modules include routines, programs, objects, components, data structures and the like that perform particular tasks or implement particular abstract data types. Moreover, it should be appreciated that the invention and/or portions thereof may be practiced with other computer system configurations, including hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

As shown in FIG. 1, an exemplary general purpose computing system includes a conventional personal computer 120 or the like, including a processing unit 121, a system memory 122, and a system bus 123 that couples various system components including the system memory to the processing unit 121. The system bus 123 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read-only memory (ROM) 124 and random access memory (RAM) 125. A basic input/output system 126 (BIOS), containing the basic routines that help to transfer information between elements within the personal computer 120, such as during start-up, is stored in ROM 124.

The personal computer 120 may further include a hard disk drive 127 for reading from and writing to a hard disk (not shown), a magnetic disk drive 128 for reading from or writing to a removable magnetic disk 129, and an optical disk drive 130 for reading from or writing to a removable optical disk 131 such as a CD-ROM or other optical media. The hard disk drive 127, magnetic disk drive 128, and optical disk drive 130 are connected to the system bus 123 by a hard disk drive interface 132, a magnetic disk drive interface 133, and an optical drive interface 134, respectively. The drives and their associated computer-readable media provide non-volatile storage of computer readable instructions, data structures, program modules and other data for the personal computer 120.

Although the exemplary environment described herein employs a hard disk, a removable magnetic disk 129, and a removable optical disk 131, it should be appreciated that other types of computer readable media which can store data that is accessible by a computer may also be used in the exemplary operating environment. Such other types of media include a magnetic cassette, a flash memory card, a digital video disk, a Bernoulli cartridge, a random access memory (RAM), a read-only memory (ROM), and the like.

A number of program modules may be stored on the hard disk, magnetic disk 129, optical disk 131, ROM 124 or RAM 125, including an operating system 135, one or more application 212 programs 136, other program modules 137 and program data 138. A user may enter commands and information into the personal computer 120 through input devices such as a keyboard 140 and pointing device 142 such as a mouse. Other input devices (not shown) may include a microphone, joystick, game pad, satellite disk, scanner, or the like. These and other input devices are often connected to the processing unit 121 through a serial port interface 146 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port, or universal serial bus (USB). A monitor 147 or other type of display device is also connected to the system bus 123 via an interface, such as a video adapter 148. In addition to the monitor 147, a personal computer typically includes other peripheral output devices (not shown), such as speakers and printers. The exemplary system of FIG. 1 also includes a host adapter 155, a Small Computer System Interface (SCSI) bus 156, and an external storage device 162 connected to the SCSI bus 156.

The personal computer 120 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 149. The remote computer 149 may be another personal computer, a application service, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the personal computer 120, although only a memory storage device 150 has been illustrated in FIG. 1. The logical connections depicted in FIG. 1 include a local area network (LAN) 151 and a wide area network (WAN) 152. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet.

When used in a LAN networking environment, the personal computer 120 is connected to the LAN 151 through a network interface or adapter 153. When used in a WAN networking environment, the personal computer 120 typically includes a modem 154 or other means for establishing communications over the wide area network 152, such as the Internet. The modem 154, which may be internal or external, is connected to the system bus 123 via the serial port interface 146. In a networked environment, program modules depicted relative to the personal computer 120, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

II Illustrative Resource Management Environment

An exemplary conventional resource management system 200 is shown in FIG. 2. System 200 includes application services 210a and 210b functioning in connection with an application 232 on a client 230. Generally, application services 210 manage resources, while application 232 presents and exchanges information about such resources.

Application services 210 may be application services such as, for example, line of business (LOB) application services, database application services, network application services, print application services, and file application services. Specifically, application service 210a may be an LOB application service that manages a credit history component of a loan approval process, while application service 210b may be an LOB application service that manages a down payment component of a loan approval process.

An exemplary credit history component process 300a managed by application service 210a is shown in FIG. 3a. At state 302a, a loan application is received. At state 304a, a credit history is received. At state 306a, it is determined if the credit history is satisfactory. If the credit history is satisfactory, then, at state 308a, the loan is approved. If the credit history is not satisfactory, then, at state 310a, the loan is denied.

An exemplary down payment component process 300b managed by application service 210b is shown in FIG. 3b. At state 302b, a loan application is received. At state 304b, a down payment is requested. At state 308a, it is determined if the loan is approved. If the loan is approved, then, at state 308b, the first monthly payment is requested. If the loan is not approved, then, at state 310b, the down payment is refunded.

Application services 210 manage service entities 215 associated with component processes 300. Application service 210a manages service entities 215a and 215a′, while application service 210b manages service entities 215b and 215b′. Specifically, service entity 215a may be an “applicant” entity associated with credit history component process 300a, while service entity 215b may be a related “loan” entity 215b associated with loan approval process 300b. Service entities 215a′ and 215b′ may be non-related service entities that are specific to each component process 300a and 300b, respectively.

Application services 210 may maintain service metadata 205 corresponding to such service entities 215. Service metadata 205 may be defined in a language such as, for example, extensible markup language (XML). Service metadata 205 may include attributes of the service entities 215 and may also include unique keys of the service entities 215. Exemplary attributes of the applicant entity 215a and the loan entity 215b are shown below:

Exemplary Applicant Entity 215a
<applicant>
<ID> 1 </ID>
<first name> John </first name>
<last name> Smith </last name>
</applicant>
Exemplary Loan Entity 215b
<loan>
<ID> 10 </ID>
<applicant>
<name> John Smith </name>
</applicant>
</loan>

Service metadata 205 may also include actions available on service entities 215. Such actions may be static actions, which are available irrespective of the process state of service entities 215, or dynamic actions, which are dependent on the process state of service entities 215.

Static actions may be actions such as, for example, actions for viewing and changing the attributes of service entities 215, actions for following or drilling down a relationship to see related instances, and always available actions for changing the process state. Metadata for viewing and changing attributes may include, for example, mechanisms rendering a view such as launching a dialog.

Metadata for dynamic actions may include methods for changing the process state, functions of the process state in which such methods are available, and restrictions on protecting the process from multiple or conflicting use of such methods by the same or different users.

Service metadata 205 may also include information about access to service entities 215. Such metadata may include, for example, access limitations or restrictions for a particular user or group of users to an instance or class of service entities 215, static action, or relationship. Authorization such as, for example, a valid password or identifier may be required to gain access to each such instance or class of an entity, static action, or relationship.

Service metadata 205 may also include descriptions of methods to obtain information about entity instances. Such metadata may also include descriptions of methods to derive actual or possible relationships between entity instances, views, and static actions.

Application services 210 communicate with client 230 via network 220. Network 220 may be a local area network (LAN) or a wide area network (WAN) such as, for example, the Internet. Client 230 may be a computing device such as computing device 120 of FIG. 1. Client 230 may be equipped with a web browser or another front end application to gain access to application services 210. Application 232 runs at client 230 and may be an application such as, for example, a word processor, a spreadsheet, or an email system. Application 232 may enable a document 234 to be created, presented, and/or exchanged among users.

Document 234 may refer to and influence the management of service entities. Referring now to FIG. 4, document 234 includes the text, “John Smith has missed a credit card payment.” Document 234 thus refers to both the applicant service entity 215a and the loan service entity 215b. Document 234 may influence the management of such referred service entities 215a and 215b. For example, document 234 may influence a user to change the state of applicant service entity “John Smith” 215a from state 306a to state 310a. Document 234 may also influence a user to change the state of loan service entity “John Smith” 215b from state 306b to state 310b.

Importantly, in a conventional system 200 as shown in FIG. 2, a user cannot manage service entities 215 from within application 232. Thus, to change the state of applicant service entity 215a, the user must separately access application service 210a and identify applicant service entity 215a within application service 210a. Furthermore, to change the state of loan service entity 215b, the user must separately access application service 210b and identify the loan service entity 215b within application service 210b.

III Exemplary Systems and Methods of the Present Invention

Unlike conventional system 200 of FIG. 2, the present invention enables application entities to be created and defined by a user. The present invention also enables related service entities to be matched and consolidated. Each application entity may be associated with one or more related service entities. Metadata corresponding to the associated service entities may be provided to the application. Such metadata may enable the associated service entities to be managed from within the application.

An exemplary resource management system 500 in accordance with the present invention is shown in FIG. 5. Generally, application services 210 expose service metadata 505 corresponding to service entities 215 to context service 510 and action service 520. Context service 510 consolidates service entities 215 into context entities 515 based on service metadata 505. Context service 510 also consolidates service metadata 505 into context metadata 525. Action service 520 determines dynamic actions available on service entities 215. Application 532 maintains application metadata 545 corresponding to application entities 535.

Application services 210 expose service metadata 505 to context service 510 via network 220. Unlike conventional service metadata 205 of FIG. 2, service metadata 505 in accordance with the present invention may include a classification of the availability of actions to be performed in connection with service entities 215. Specifically, application services 210 may classify an action as being universally available, optimistically available, or available according to a rule.

An action that is universally available is an action that may be always be performed. Such actions are not subject to any rules or conditions.

An action that is optimistically available is available subject to specified rules and conditions. For example, such rules may include a maximum number of times which an action may be performed, a time period in which an action must be performed, a user or class of users which must perform an action, a condition which must occur before performance of an action, a condition which must occur after performance of an action. Classifying an action as optimistically available enables application services 210 to make an action available without specifying all possible rules and conditions which must be satisfied for the rule to be available.

An action that is available according to a rule is available only in compliance with specified rules and conditions. Classifying an action as available according to a rule enables application services 210 to deny the availability of action unless specified rules and conditions are satisfied.

Context service 510 may be an application running on a computing device such as, for example, computing device 120 of FIG. 1. Context service 510 may parse service metadata 505 to identify service entities 215 and corresponding static actions available on the service entities. Context service 510 may validate service metadata 505 by, for example, making a dummy call for identified service entities to application services 210.

Context service 510 consolidates service entities 215 into context entities 515. To consolidate service entities 215, context service matches related service entities 215 and consolidates such related service entities 215 into a single context entity 515. For example, context service 510 may match related service entities 215a and 215b and consolidate them into context entity 515a. Context service 510 may also determine that service entities 210a′ and 210b′ are not related and may thus consolidate each of service entities 210a′ and 210b′ into a separate context entity 515b and 515c, respectively.

Context service 510 matches related service entities 215 based on service metadata 505. Specifically, context service 510 cross references attributes of service entities 215 to identify actual and potential relationships. Context service 510 may identify such relationships based on a nomenclature of the attributes. For example, context service 510 may match the applicant service entity 215a to the loan service entity 215b because the loan service entity 215b includes an “applicant” attribute. Context service 510 may fragment and compose attributes. Furthermore, context service 510 may perform transformations on attributes. For example, context service 510 may perform a transformation to match the “first name” and “last name” attributes of the applicant service entity 215a to the “name” attribute of the loan service entity 215b.

In addition to consolidating the service entities 215 into context entities 515, context service 510 consolidates service metadata 505 into context metadata 525. Specifically, in addition to consolidating the attributes of service entities 215, context service 510 consolidates dynamic actions available on service entities 215. For example, context service 510 may fragment and compose static actions available on service entities 215. Furthermore, context service 510 may perform transformations on static actions of service entities 215.

Context service 510 may also consolidate service metadata 505 about access to service entities 215. For example, context service 510 may persist context metadata 525 specifying that a particular class of users has access to the context entity 215a but does not have access to the context entity 215b.

Context service 510 may also consolidate metadata about entity instances and the derivation of actual or possible relationships between such instances, views, and static actions. Context service 510 may also maintain rendering information for service metadata 505. Context service 510 may also pre-fetch service metadata 505 from application services 210 to increase the availability of service metadata 505. Context service 510 may also store procedures for restoring service metadata 505 when application services 210 go offline such as, for example, in the event of a power failure.

Action service 520 may be an application running on a computing device such as, for example, computing device 120 of FIG. 1. Generally, action service 520 determines dynamic actions available on service entities 215. Action service 520 may query context service 510 to identify which of application services 210 have dynamic actions available on a service entity 215. Action service 520 may then query the identified application services 210 to obtain the available dynamic actions for the service entity 215.

Alternatively, action service 520 may query the identified application services 210 to obtain status information for an entity. Action service 520 may then retrieve service metadata 505 corresponding to the entity to determine the available actions for the service entity 215.

Action service 520 includes tracking mechanism 522, which tracks the performance of actions on service entities 215 at application services 210. Tracking mechanism 522 determines when a user invokes a state change method on a process and tracks the success, failure, or pending completion of the method.

Action service 520 also includes conflict protection mechanism 524, which prevents and advises against the performance of dynamic actions at application services 210 that are invalid or likely to generate conflicts. Conflict protection mechanism 524 evaluates the classification of the availability of actions to be performed on service entities 215. Specifically, as described above, such actions may be classified as universally available, optimistically available, or available according to a rule. Conflict protection mechanism 524 uses and interprets such classifications along with the actions tracked by tracking mechanism 522 to determine whether actions are available and to detect dynamic actions that may cause actual and potential conflicts.

Application 532 may be an application such as, for example, a word processor, a spreadsheet, or an email system that enables the creation, production, and exchange of a document 534. However, unlike conventional application 232 of FIG. 2, application 532 includes application entities 535, which may allow one or more service entities 215 to be accessed and/or managed.

In one embodiment, an application entity 535 in the system of FIG. 5 is characterized by application metadata 545 corresponding to the application entity 535 and context metadata 525 which enables one or more service entities 215 to be accessed. Specifically, in one embodiment, application metadata 545 corresponding to an application entity 535 defines a reference to specific information maintained by context service 410 and/or application service 110. In one embodiment, user access to a service entity 215 from within application 532 via application entity 535 is facilitated by execution service 536, which provides application metadata 545 as input to context service 510. Context service 510 processes the input according to one or more transformations defined by context metadata 525 to access one or more service entities 215.

In one embodiment, by defining a binding between document content and a service entity via an abstract reference like metadata, rather than via a physical pointer (e.g., a URL), actions which a user may take with regard to the service entity may be defined at run time (e.g., by the metadata). For example, actions which a user may take with regard to a service entity may be defined by characteristics of the service entity, the user, the application, the application service, or any other suitable information. Further, these actions may be modified without modifying the application, application service or the service entity.

One embodiment of the invention provides a method for defining a binding, or relationship, between an application entity 535 and one or more service entities 215. An exemplary process for defining such a binding is depicted in FIG. 6.

Upon the start of process 600, application metadata 545 is defined in act 610. Application metadata may be defined in any suitable manner, as the invention is not limited in this respect. Although three exemplary techniques for defining application metadata are described below, it should be appreciated that any suitable mechanism may be employed, as the invention is not limited in this respect.

A first exemplary technique for defining application metadata 545 employs a mechanism referred to herein as a “smart tag.” Conventionally, a smart tag comprises a data structure which is embedded in a document (e.g., document 534) and which is associated with certain content (e.g., one or more words) of the document. Smart tag mechanisms are well-known to those skilled in the art. As an example, several of the Microsoft Office suite of applications, offered by Microsoft Corporation of Redmond, Wash., employ smart tags to create an association between document content and a data structure. A smart tag may be automatically associated with document content. Conventionally, the data structure of a smart tag may include various data provided in XML schema format.

In one embodiment of the invention, the data structure is modified to include information, also provided in XML schema format, which execution service 536 is configured to recognize as a reference to context metadata 525 maintained by context service 510. For example, in one embodiment, the XML schema includes a tag which signifies a reference to context information. In one embodiment, the tag may include one or more attributes which indicate specific context information which is referenced. A sample XML schema indicating a reference to context information is shown below.

<ContextInformation xmlns:xsd=“http://www.w3.org/2001/XMLSchema”
xmlns:xsi=“http://www.w3.org/2001/XMLSchemainstance”
MetadataScopeName=“http://InformationBridge/Sample” EntityName=
“Account” viewName=“AccountDefault”
xmlns=“http://schemas.microsoft.com/InformationBridge/2004/
ContextInformation”>
<Reference>
<AccountName xmlns=“urn-SampleSolution-Data” ID=“Litware”
iwb:MetadataScopeName=“http://InformationBridge/Sample”
xmlns:iwb=“http://schemas.microsoft.com/InformationBridge/2004”
iwb:EntityName=“Account” iwb:ViewName=“AccountDefault” />
</Reference>
</ContextInformation>

As can be seen in the sample above, the XML schema includes a <ContextInformation> tag. In one embodiment, execution service 536 is configured to recognize this tag as a reference to context data. The <ContextInformation> tag includes attributes such as “MetadataScopeName,” “EntityName,” “ViewName,” and “ReferenceSchemaName,” as well as a “Reference” attribute block which identifies specific information to display. Each of these items is discussed below.

The exemplary XML schema above includes an attribute which specifies a “MetadataScopeName” of “http://InformationBridge/Sample.” In one embodiment, a metadata scope name may specify a namespace for context metadata 525. This reference to the metadata scope name identifies the context metadata which provides the transformation information that allows the desired one or more service entities to be accessed. In general, a metadata scope name defines content and operation information which can be logically grouped. As can be seen by this exemplary attribute, a metadata scope name may be defined using a Uniform Resource Locator (URL). Of course, a metadata scope name may be identified in any suitable manner.

The exemplary schema above also includes an attribute which defines an “EntityName” of “Account.” An entity name attribute may specify a conceptual data object, such as a service entity. A service entity may represent, for example, an item such as a customer, order, or invoice. Of course, the exemplary attribute provided represents an account.

The exemplary schema above also includes an attribute which defines a ViewName of “AccountDefault.” In one embodiment, a view name specifies a specific manner of visually representing data comprising an entity to a user. For example, for the “Account” entity, there may be there may be an “AccountDefault” view, a “AccountFinancial” view, and/or an “AccountSales” view. Each view may include different service entity information which may be presented to the user in a particular manner.

Thus, as can be seen from the foregoing description, an XML schema provided in the data structure of a smart tag may contain application metadata 545 which may be employed by execution service 536 as input to context service 510 to access one or more service entities 215 according to transformations defined by context metadata 525.

A second exemplary technique for defining application metadata 545 employs a URL. In one embodiment, the URL includes attributes encoded according to a specific syntax which execution service 536 is configured to recognize as constituting application metadata 545.

In one embodiment, rather than employing a conventional protocol handler (e.g., “http” or “ftp”), a URL may specify a particular protocol handler (e.g., “ibf”) which execution service 536 is configured to recognize as signifying a reference to context metadata. As a result, when the URL is invoked (e.g., clicked on), execution service 536 will receive the resulting instruction and process attributes encoded within the URL as input.

In one embodiment, attributes are encoded according to a syntax (e.g., provided in a particular order within the URL) so that execution service 536 may process each attribute accordingly. In one embodiment, these attributes are similar to the attributes described above with reference to the XML schema provided in the data structure of a smart tag. For example, the URL may include attributes provided according to the exemplary syntax that follows:

• • ibf:v1/YourMetadataScopeName/YourEntityName/YourViewName/YourReferenceSch emaName/SyntaxType?YourQueryString

In this exemplary URL, “ibf” is a URL moniker which specifies a particular protocol that execution service 536 is configured to recognize as a reference to context metadata, “v1” specifies a version of URL syntax (thereby defining the syntax for the remainder of the URL), “YourMetadataScopeName” specifies a metadata scope, “YourEntityName” specifies an entity within the metadata scope, “YourViewName” specifies a view of the entity, “YourReferenceSchemaName” specifies a schema element which may be accessed, “SyntaxType” specifies a format of a subsequent query string in the URL, and “YourQueryString” specifies a query string, having a syntax defined according to the preceding syntax type, for retrieving context data. In one embodiment, a query string may be provided in encoded format, XML format or simple syntax format. For example, an exemplary URL having a query string in simple syntax format is as follows:

• • ibf:v1/Microsoft. Solutions.SampleSolution.SR/ServiceRequest/ServiceRequestDetails/Xsd.TicketNumber(urn-SampleSolution-Data)/ref?root=TicketNumber&xmlns=μurn-SampleSolution-Data&Id=SR245797

The URL above includes a first attribute which defines “YourMetadataScopeName” as “Microsoft.Solutions.SampleSolution.SR”, a second attribute which defines “YourEntityName” as “ServiceRequest”, a third attribute which defines “YourViewName” as “ServiceRequestDetails”, a fourth attribute which defines “YourReferenceSchemaName” as “Xsd.TicketNumber (urn-SampleSolution-Data)”, a fifth attribute which defines “SyntaxType” as “ref”, and an attribute defining “YourQueryString” as “root=TicketNumber&xmlns=urn-SampleSolution-Data&Id=SR245797”.

Of course, a URL which provides a reference to context information need not be encoded according to the syntax described above, as the invention is not limited in this respect. For example, a URL need not specify a protocol handler of “ibf,” and may provide any suitable attributes, in any suitable manner.

A third exemplary technique for specifying application metadata 545 employs an attached schema. Conventionally, applications (e.g., application 532) may allow a user to create and attach a schema (e.g., an XML schema) to a document (e.g., document 534) to define content which is added to specific areas within the document. For example, a purchase order document template may have a number of fields which a user may fill in to complete a purchase order, and the purchase order template may have an attached schema which defines information which the user may provide for each field. For example, a particular field may be defined by the document's attached schema as containing the name of an approving entity for the purchase order.

In one embodiment, an attached schema may be used to define application metadata for specific content in the document. This may be accomplished in numerous ways, as the invention is not limited to a particular implementation. In one example, the schema may simply be modified to include one or more attributes which define a reference to context information, such as any of the attributes described above with reference to the smart tag and URL techniques. However, because it may not always be practical to modify a schema attached to a document (e.g., because the user does not have authority to do so), in another exemplary embodiment, execution service 536 may be configured to recognize content in a particular document portion as a reference to specific context data. As an example, execution service 536 may be configured to recognize a particular document element, as defined by an element in its attached schema, as referencing particular context data. For example, the attached schema element may indicate that an approver name is contained in the field, and execution service 536 may be configured to associate the approver name with, for example, context metadata 525 having a particular metadata scope name, entity name, view name, reference schema name, and/or other of the attributes described above. In this respect, execution service 536 may maintain multiple levels of application metadata for the application entity, including a first level which includes an element in an attached schema and a second level which associates the schema element with attributes that may be provided as input to context service 510.

In one embodiment, application metadata 545 may be defined manually by a user. For example, the user may provide input via a keyboard which defines application metadata 545. FIG. 7 shows an exemplary user interface 705 by means of which a user may provide input which defines application metadata 545 for an application entity 535. User interface 705 may execute on client 230, or any other suitable device. User interface 705 includes document window 710, which displays document 534, including the text “John Smith has missed a credit card payment.” The text “John Smith” has been defined as an application entity 535. In the embodiment depicted, the fact that the text “John Smith” is an application entity is indicated by underline 712, although any suitable visual indication (or no indication at all) may be employed.

User interface 705 also includes application metadata window 720, which may be opened by the user by selecting (e.g., clicking on) application entity 535. Application metadata window 720 displays application metadata 545, including attributes of application entity 535. In one embodiment, a user may edit application metadata 545 for application entity 535 by providing input by means of a keyboard and/or mouse within application metadata window 720. Of course, any suitable interface for defining application metadata 545 may be employed, as the invention is not limited in this respect.

Upon the completion of act 610 (FIG. 6), the process proceeds to act 620, wherein context metadata 525 is defined. In one embodiment, context metadata 525 defines a transformation between application metadata 545 and one or more service entities 215. A transformation may comprise, for example, a mapping between application metadata 545 and service metadata 505 and/or service entities 515.

A transformation may be defined in any of numerous ways, as the invention is not limited to a particular implementation. In one embodiment, context metadata 525 defines a transformation via an XSL transformation (XSLT), which is an XML-based tool for mapping a source XML schema (e.g., application metadata 545) to a result XML schema (service metadata 505), as is well-known to those skilled in the art. However, any suitable technique may employed, as the invention is not limited in this respect.

Upon the completion of act 620, process 620 completes. Once an application entity is defined, it may be employed to retrieve and manage one or more service entities. An exemplary process for employing an application entity to access one or more service entities is described below with reference to FIGS. 8A and 8B.

Referring first to FIG. 8A, at step 810, an application entity 535 is selected by a user at application 532. For example, the applicant application entity 535a may be selected at application 532 by clicking on link 612 using an attached mouse.

At step 812, execution service 536 on client 230 retrieves application metadata 545 corresponding to the selected application entity 535 from application 532. For example, if the applicant application entity 535a is selected, then execution service 536 may retrieve corresponding application metadata 545a. At step 814, execution service 536 passes the retrieved application metadata 545a to context service 510.

At step 816, context service 510 matches the selected application entity 535 to associated context entities 515. The matching of entities is discussed in detail above with reference to FIG. 5, and may be performed by, for example, cross referencing the attributes of entities included in application metadata 545 and context metadata 525. For example, context service 510 may match the applicant application entity 535a to context entity 515a based on common attributes.

At step 818, context service 510 identifies associated service entities 215 from which the associated context entities 515 are derived. For example, context service 510 may identify that context entity 515a is derived from the applicant service entity 215a and the loan service entity 215b.

At step 820, context service 510 examines context metadata 525 to determine static actions available on the associated service entities 215. Context service 510 may generate a graph of the associated service entities 215, the relationships to those entities, and the static actions available on those entities and relationships.

At step 822, context service 510 queries action service 520 to determine dynamic actions available on the associated service entities 215. Action service 520 provides the available actions on service entities 215 as well as any actions which may result in a conflict. Action service 520 may also provide limitations on multiple use of the same or multiple dynamic actions from the same process.

At step 824, context service 510 provides the available actions to execution service 536. Context service 510 may also provide other service metadata 505 for the associated service entities 215. If access to one of the associated service entities 215 is restricted, then the user may be required to provide authorization to receive metadata for that entity. For example, the user may be required to log in with an identifier or password.

At step 826, execution service 536 generates a display of the actions available on the associated service entities 215. Execution service 536 includes state and relationship view mechanism 538 to provide views of relationships between related service entities 215. Such relationships may be filtered to provide only those that are relevant to determine functions of state involved in conflict protection. State and relationship view mechanism 512 may provide information about the state of taking, success, failure, and current status of state change methods for related service entities 215.

Referring now to FIG. 9, display 915 shows the actions available on the associated service entities 215. Display 915 is shown in application service actions window 630. The display 915 includes a first display portion 915b showing the available static and dynamic actions for associated service entities 215a and 215b. Display 915 also includes a second display portion 915b showing information about the availability of actions at application services 210. Second display portion 915b shows relationships between component processes 300a and 300b, the state of each component process 300a and 300b, and the availability of actions on applicant service entity 215a and loan service entity 215b within each process 300a and 300b, respectively. Information about the success, failure, and status of pending actions within processes 300a and 300b may be displayed by, for example, clicking on the process in display 915 with an attached mouse.

Alternatively, the available actions may be displayed as a cascading menu set or as sets of categorized actions and options. Furthermore, the available actions may be displayed in a dialog box within document window 610. Execution service 536 may also invoke dialogs and rendering mechanisms specified by context service 510.

At step 828, a user may request an action from the display 815. The user may request the action by, for example, clicking on the action with the attached mouse. If, for example, the user selects “View Attributes” or “Change Attributes”, then the attributes of the associated service entities 215a and 215b may appear in a new window or dialog box within user interface 805. The user may then view and change the attributes.

In an alternative embodiment, execution service 536 may perform available actions automatically without displaying such actions to the user.

At step 830, the requested action is forwarded to the appropriate application service 210. If a requested action is a static action, then it may be forwarded to the appropriate application services 210 via context service 510. If the requested action is a dynamic action, then it may be forwarded to the appropriate application services 210 via action service 520.

At step 832, the action may be performed at the appropriate application service 210. The performance of the action may be logged by tracking mechanism 522.

Upon the completion of step 832, process 800 completes.

In accordance with one embodiment of the invention, information which is used to retrieve a service entity may also be used to define an application entity automatically. An exemplary technique for defining application entities automatically which employs aspects of the smart tag technique described above, is described below with reference to FIG. 10.

The following is provided to assist the reader in understanding both smart tag technology and aspects of the invention. Generally, the relationship between an item of content in document 534 and the data structure of a smart tag is established using recognizer 540, which is a module that typically runs in the background on client 230 as the user works with document 534. Typically, as a user enters text into document 534, the text is passed to recognizer 540 at the same time that it appears on the screen of client 230. If recognizer 540 identifies the input as related to the recognizer's purpose, it may create a smart tag for the text and associates a data structure thereto.

In accordance with one embodiment of the invention, context metadata 525 and/or service metadata 505 may be exposed to recognizer 540 by context service 510 and/or application service 210 via network 220, such that as the user enters input to document 534, the input may be compared with attributes of context metadata 525 and/or service metadata 505, or derivations thereof, to determine whether the input should define an application entity. Thus, upon the start of the process of FIG. 10, user input (e.g., to document 534) is monitored, and in act 1020 a determination is made as to whether the input is recognized as defining an application entity.

The determination of whether user input is recognized as defining an application entity may be accomplished in any of numerous ways. In one embodiment, text which comprises user input may be compared to elements of context metadata 525 and/or service metadata 505, or derivations thereof. For example, user input of the text “Contoso, Ltd.” to a spreadsheet may be compared with context metadata 525 and/or service metadata 505, or a derivation thereof, to determine whether the input is recognized as an application entity.

If the input is not recognized as an application entity in act 1020, the process returns to act 1010, and user input continues to be monitored.

If the input is recognized as an application entity in act 1020, in one embodiment an application entity 535 is created which corresponds to the input in a manner which is transparent to the user. Alternatively, the user may be prompted upon the recognition to confirm that application entity 535 should be created. In one example, an indication that the user's input has been recognized as a potential application entity may be presented via a GUI to the user, along with a prompt to confirm that an application entity should be created. Upon the user's providing a confirmation, an application entity may be created. Any suitable technique for creating an application entity may be employed, as the invention is not limited in this respect.

Upon the completion of act 1020, application metadata 545 is implemented for the application entity 535 in act 1030. The application metadata may, for example, define a reference to the context metadata 525 and/or service metadata 505 which caused the application entity 535 to be defined in act 1020. As discussed above with reference to the smart tag technique of FIG. 6, in one embodiment, application metadata 545 may comprise an XML schema which is added to the data structure that constitutes a smart tag.

Upon the completion of act 1030, process 1000 completes.

It should be appreciated that although the process of FIG. 10 is described with reference to smart tag technology, any suitable technique may be employed for automatically (or semi-automatically) recognizing and/or defining an application entity. For example, on a system which does not employ smart tags, a component akin to a recognizer could be configured to monitor user input as it is provided, and compare the input to metadata or a derivation thereof to determine whether the input should define an application entity. Such a “recognition engine” component may execute on the client or on any other suitable device, as the invention is not limited in this respect.

A recognition engine may also be configured to automatically, or semi-automatically, define application metadata 545 for an application entity 535 which enables the application entity to be employed to access and/or manage service entities. Application metadata 545 may take any suitable form, such as an XML schema, a URL which provides attributes as described above, or any other desired format. The invention is not limited in this respect.

While the present invention has been described in connection with the preferred embodiments, it is to be understood that other similar embodiments may be used or modifications and additions may be made to the described embodiment for performing the same function of the present invention without deviating therefrom. Therefore, the present invention should not be limited to any single embodiment, but rather should be construed in breadth and scope in accordance with the appended claims.

Claims

1. In a system which includes an application executing on a first computer and an application service executing on a second computer, the first and second computers being coupled via a network, the application being operable to manage a document and receive input from a user comprising document content, the document content corresponding to a service entity managed by the application service, a method for defining a binding between the document content and the service entity, the binding enabling the user to access the service entity by selecting the document content within the application, the method comprising:

(A) defining application metadata for the document content, the application metadata being associated with the document content, the application metadata including information which provides a reference to the service entity; and

(B) defining context metadata which specifies a transformation performed on at least a portion of the information included in the application metadata to access the service entity.

2. The method of claim 1, wherein the application metadata is provided via an XML schema which is associated with the document content.

3. The method of claim 2, wherein the XML schema is provided in a data structure employed by a smart tag.

4. The method of claim 2, wherein the XML schema is attached to the document.

5. The method of claim 1, wherein the application metadata is provided via a URL.

6. The method of claim 1, wherein the application metadata includes references to the context metadata, the service entity, and a view of the service entity.

7. The method of claim 1, further including an act, performed before the act (A), comprising automatically recognizing that the document content provided by the user corresponds to the service entity.

8. The method of claim 7, wherein the acts (A) and (B) are performed transparently to the user.

9. The method of claim 7, wherein the act of automatically recognizing further comprises comparing the document content to at least one of the context metadata and a derivation of the context metadata.

10. The method of claim 1, wherein the document comprises one of a word processing document, a spreadsheet, a presentation, a drawing and a web page.

11. At least one computer-readable medium for use in a system which includes an application executing on a first computer and an application service executing on a second computer, the first and second computers being coupled via a network, the application being operable to manage a document and receive input from a user comprising document content, the document content corresponding to a service entity managed by the application service, the at least one computer-readable medium including information which defines a binding between the document content and the service entity, the binding enabling the user to access the service entity by selecting the document content within the application, the binding comprising:

application metadata for the document content, the application metadata being associated with the document content, the application metadata including information which provides a reference to the service entity; and

context metadata which specifies a transformation performed on at least a portion of the information included in the application metadata to access the service entity.

12. The at least one computer-readable medium of claim 11, wherein the application metadata is provided via an XML schema which is associated with the document content.

13. The at least one computer-readable medium of claim 12, wherein the XML schema is provided in a data structure employed by a smart tag.

14. The at least one computer-readable medium of claim 12, wherein the XML schema is attached to the document.

15. The at least one computer-readable medium of claim 11, wherein the application metadata is provided via a URL.

16. The at least one computer-readable medium of claim 11, wherein the application metadata includes references to the context metadata, the service entity, and a view of the service entity.

17. The at least one computer-readable medium of claim 11, further including an act, performed before the act (A), comprising automatically recognizing that the document content provided by the user corresponds to the service entity.

18. The at least one computer-readable medium of claim 17, wherein the acts (A) and (B) are performed transparently to the user.

19. The at least one computer-readable medium of claim 17, wherein the act of automatically recognizing further comprises comparing the document content to at least one of the context metadata and a derivation of the context metadata.

20. The at least one computer-readable medium of claim 11, wherein the document comprises one of a word processing document, a spreadsheet, a presentation, a drawing and a web page.