Patent application number | Description | Published |
20080320503 | URL Namespace to Support Multiple-Protocol Processing within Worker Processes - A server system in typical operation has a process manager, multiple listeners (each to receive requests for its protocols) and multiple worker processes that are each able to handle requests in multiple protocols. At server start-up, each listener connects with the process manager via a pipe published by the process manager. The listener then receives information via the process manager that includes information defining the application(s) for which that listener is to “listen” and associating application(s) to application pool(s). When the listener receives a request for such an application, the listener starts a queue for the associated application pool. The listener may use a hierarchical matching scheme to determine the associated application or application pool from the requested application. The process manager launches an appropriate worker process to handle requests in the listener's protocol. The worker process then makes a connection with the listener. | 12-25-2008 |
20090158283 | DECOUPLING STATIC PROGRAM DATA AND EXECUTION DATA - Persisting execution state of a continuation based runtime program. The continuation based runtime program includes static program data defining activities executed by the program. One or more of the activities are parent activities including sequences of child activities. The continuation based runtime program is loaded. A child activity to be executed is identified based on scheduling defined in a parent of the child activity in the continuation based runtime program. The child activity is sent to a continuation based runtime separate from one or more other activities in the continuation based runtime program. The child activity is executed at the continuation based runtime, creating an activity instance. Continuation state information is stored separate from the static program data by storing information about the activity instance separate from one or more other activities defined in the continuation based runtime program. | 06-18-2009 |
20100036859 | Message Exchange Pattern Rendezvous Abstraction - A rendezvous abstraction that is used to correlate messages within message exchange. The rendezvous abstraction may be instantiated to correlate messages regardless of the type of message exchange pattern, and regardless of the underlying protocols used to communication message. Messages exchanges of primitive protocols are modeled as unilateral message exchanges. The rendezvous abstraction is used to correlate messages of the unilateral message exchange, and serves as an abstraction that is used to represented the rendezvous point where the message of the message exchange pattern are handled. Accordingly, instead of focusing on the protocol-specific mechanisms for correlation, if even available, the application author may simply work with a standard rendezvous abstraction. | 02-11-2010 |
20100057707 | QUERY-ORIENTED MESSAGE CHARACTERIZATION - Processing messages. Messages are processed based on a characteristic derived from information in messages, metadata about messages, or other information external to messages. Values for one or more pieces of information are received. At least one of the values for one or more pieces of information is associated with a first message. Queries are received. The queries specify one or more of the pieces of information. At least a portion of the plurality of values for the one or more pieces of information is processed in conjunction with the one or more queries to create one or more normalized characteristics for the first message. The one or more normalized characteristics for the first message are in a same format irrespective of the format of the pieces of information. The first message, and/or other messages, is processed based on at least one of the one or more normalized characteristics. | 03-04-2010 |
20100057933 | PROBABILISTIC MESH ROUTING - Routing messages using unreliable routing data. A method includes receiving a message from a computer readable communication medium. Characteristic properties of the message are calculated so as to determine state requirements for a service instance at a service for processing of the message. An attempt is made to acquire an appropriate service instance that satisfies the state requirements for processing the message. A determination is made that attempting to acquire an appropriate service instance that satisfies the state requirements for processing the message is not successful at acquiring an appropriate service instance. As a result, the message is redirected using an unreliable local cache of routing information and without coordination between processing nodes. | 03-04-2010 |
20100107177 | DISPATCH MECHANISM FOR COORDINATING APPLICATION AND COMMUNICATION MEDIUM STATE - The present invention extends to methods, systems, and computer program products for coordinating application state and communication medium state. Embodiments of the invention provide mechanisms by which a dispatcher can enable application code to coordinate changes in application state with the consumption of messages from a communication medium. The coordination can be automatic where the dispatcher performs the coordination, or manual, where the coordination is performed more expressly by application code. Embodiments also include mechanisms by which applications targeting an execution (e.g., continuation based) runtime may compose alternative state transitions in the application with a peek lock protocol. | 04-29-2010 |
20100153930 | CUSTOMIZABLE DYNAMIC LANGUAGE EXPRESSION INTERPRETER - Embodiments described herein are directed to allowing a user to extend the functionality of a software code interpretation system. In one embodiment, a computer system receives user-defined conversion rules from a user for converting dynamic language code to continuation-based abstract memory representations. The computer system identifies portions of software code that are to be converted from dynamic language abstract memory representations into continuation-based abstract memory representations, where the identified code portions include undefined, extensible input primitives. The computer system also generates a dynamic, extensible set of output primitives interpretable by a continuation-based code interpretation system using the received conversion rules and converts the identified code portions including the undefined, extensible input primitives from dynamic language abstract memory representations into continuation-based abstract memory representations using the generated set of output primitives. | 06-17-2010 |
20100169862 | INTERFACE INFRASTRUCTURE FOR A CONTINUATION BASED RUNTIME - Namespace for continuation-based runtime. Some embodiments described herein are directed to a framework using continuation based runtime namespaces that pertain to an infrastructure for enabling the creation of a wide variety of continuation-based programs that perform a wide-array of tasks. The infrastructure provides a foundation for building continuation-based, declarative applications of various scale and complexity. In some embodiments, the associated application programming interfaces (APIs) are factored into a hierarchy of namespaces in a manner that balances utility, usability, extensibility, and versionability. | 07-01-2010 |
20100242030 | PROVIDING EXECUTION CONTEXT IN CONTINUATION BASED RUNTIMES - In an embodiment, a computer system instantiates a parent activity configured for execution in a continuation based runtime. The parent activity includes various child activities configured to perform pulses of work. The parent activity is also configured to add execution properties to an execution context. The computer system adds execution properties to the parent activity's execution context to generate a modified execution context which includes execution properties that extend the functionality of the parent and child activities. The added execution properties include corresponding identifiers that identify the added execution properties. The computer system also executes the parent activity including the various child activities within the modified execution context in the continuation based runtime. The modified execution context includes the added execution properties that are available to the parent and any child activities during execution, where at least one child activity implements functionality provided by the added execution properties. | 09-23-2010 |
20100293538 | DYNAMIC PROGRAM UPDATING IN A CONTINUATION BASED RUNTIME - A computer system assigns a workflow version number to a first version of a continuation-based program. The program includes a workflow indicating when each of the program's activities is to be executed in a continuation-based runtime. The computer system stores the workflow version number in corresponding workflow instance state. The state indicates which workflow version number the workflow should be associated with. The computer system receives updates that are to be applied to the continuation-based program. The updates include an indication of which portions of the program are to be updated and an updated workflow version number. The system determines that the stored workflow version number is different than the received updated workflow version number and, based on the determination, maps the received updates from the workflow associated with the stored workflow version number to the updated workflow associated with the updated workflow version number in a revision map. | 11-18-2010 |
20100299300 | RUNTIME INTERPRETATION OF DECLARATIVE PROGRAMS - Embodiments are directed to interpreting declarative program types at runtime without compiling and mapping between a declarative type and a dynamic runtime type. A computer system accesses a portion of a declarative program, where the declarative program includes fully modeled activity types. The computer system dynamically constructs a dynamic activity type based on one of the fully modeled activity types of the declarative program, where the dynamic activity type is configured for interpretive execution without compilation. The computer system also interpretively executes the dynamically constructed dynamic activity type such that the dynamic activity is executed without compilation. | 11-25-2010 |
20100299678 | DYNAMIC EVENT COLLECTION AND STRUCTURED STORAGE - In one embodiment, a computer system accesses an event associated with an activity, where the activity has been executed by a runtime as part of a software application. The runtime includes a software hook configured to listen for event stream operation indications from the user. The computer system tags the accessed event with an additional portion of identification information that uniquely identifies the executed activity. The computer system receives an event stream operation indication from the user indicating that event transmission for an identified event stream is to be dynamically enabled or disabled and identifies the user-indicated event stream using the tagged identification information. The computer system also dynamically performs the indicated event stream operation on the identified event stream according to the user's indication. | 11-25-2010 |
20100306777 | WORKFLOW MESSAGE AND ACTIVITY CORRELATION - Embodiments are directed to generating trace events that are configured to report an association between a workflow activity and a message. A computer system receives a message over a communication medium, where the workflow activity includes a unique workflow activity identifier (ID) that uniquely identifies the workflow activity. The message also includes a unique message ID that uniquely identifies the message. The computer system generates a trace event that includes a combination of the unique workflow activity ID and the unique message ID. The trace event is configured to report the association between the workflow activity and the message. The computer system also stores the generated trace event in a data store. | 12-02-2010 |
20100306778 | LOCALITY-BASED SCHEDULING IN CONTINUATION-BASED RUNTIMES - A computer system establishes an execution environment for executing activities in a continuation based runtime including instantiating an activity scheduler configured to perform the following: scheduling activities for execution in the CBR. The activity scheduler resolves the scheduled activity's arguments and variables prior to invoking the scheduled activity using the activity's unique context. The activity scheduler also determines, based on the activity's unique context, whether the scheduled activity comprises a work item that is to be queued at the top of the execution stack and, based on the determination, queues the work item to the execution stack. The computer system executes the work items of the scheduled activity as queued in the execution stack of the established execution environment in the CBR. | 12-02-2010 |
20110078509 | INFERENCE OF CONTRACT USING DECLARATIVE PROGRAM DEFINITION - A declarative program definition. The definition is analyzed to produce an application contract that describes semantics for sending and receiving application messages during the successful execution of operations by the program. In addition, this analysis may also generate local behaviors associated with the local execution of the program. Alternatively or in addition, the analysis may infer secondary contracts regarding the sending and receiving of application messages, even though the full details of the secondary contracts are not present in the declarative program definition. For instance, the secondary contracts might include error contracts or consistency contracts. | 03-31-2011 |
20110145826 | MECHANISM FOR PARTITIONING PROGRAM TREES INTO ENVIRONMENTS - Partitioning continuation based runtime programs. Embodiments may include differentiating activities of a continuation based runtime program between public children activities and implementation children activities. The continuation based runtime program is partitioned into visibility spaces. The visibility spaces have boundaries based on implementation children activities. The continuation based runtime program is partially processes at a visibility space granularity. | 06-16-2011 |
20110153713 | OUT OF ORDER DURABLE MESSAGE PROCESSING - The dispatching of messages from an incoming message pool to service instance(s). Message are received non-destructively and exclusively from the incoming message pool. If a particular service instance receives a message out of order, the processing of the message is deferred without releasing the exclusivity in the incoming message queue. Thus, the target service instance may continue to process one or more other messages until the target service instance is ready to process one or more deferred messages. In this way, messages may be pulled from the incoming message queue for dispatch to service instance(s), while maintaining correct order of processing, even if messages do not arrive into the incoming message queue in the correct order. | 06-23-2011 |
20110238921 | ANTICIPATORY RESPONSE PRE-CACHING - Interaction between a client and a service in which the service responds to requests from the client. In addition to responding to specific client requests, the service also anticipates or speculates about what the client may request in the future. Rather than await the client request (that may or may not ultimately be made), the service provides the unrequested anticipatory data to the client in the same data stream as the response data that actual responds to the specific client requests. The client may then use the anticipatory data to fully or partially respond to future requests from the client, if the client does make the request anticipated by the service. Thus, in some cases, latency may be reduced when responding to requests in which anticipatory data has already been provided. The service may give priority to the actual requested data, and gives secondary priority to the anticipatory data. | 09-29-2011 |
20130185694 | DECLARATIVE DYNAMIC CONTROL FLOW IN CONTINUATION-BASED RUNTIME - Techniques are described herein that are capable of executing a computer program in accordance with a declarative dynamic control flow in a continuation-based runtime. A declarative dynamic control flow identifies a set of continuations. A representation of logic that corresponds to the declarative dynamic control flow is provided in accordance with execution of the computer program in the continuation-based runtime. The declarative dynamic control flow identifies a set of continuations. Each continuation identifies a respective rule, which defines a respective event, and a respective action, which is to be performed upon occurrence of the respective event. A determination is made that a specified event occurs. The set of continuations is dynamically modified based on occurrence of the specified event. | 07-18-2013 |
20130232226 | ANNOTATING PORTIONS OF A MESSAGE WITH STATE PROPERTIES - Embodiments described herein provide for allowing processing code of a message to attach state thereto. More specifically, as a SOAP message is processed, various states known as properties (e.g., message security, message identifier, etc.) can be attached to the message for various purposes. In other words, embodiments provide for a properties object that represents a set of processing-level annotations to a message. These properties (representing the processing state of the headers or other portions of the message) can then be used by other component or modules for further processing purposes. Typically, these properties can then be removed (or sustained if desired) prior to transporting the SOAP message on the wire. | 09-05-2013 |
20130282655 | QUERY-ORIENTED MESSAGE CHARACTERIZATION - Processing messages. Messages are processed based on a characteristic derived from information in messages, metadata about messages, or other information external to messages. Values for one or more pieces of information are received. At least one of the values for one or more pieces of information is associated with a first message. Queries are received. The queries specify one or more of the pieces of information. At least a portion of the plurality of values for the one or more pieces of information is processed in conjunction with the one or more queries to create one or more normalized characteristics for the first message. The one or more normalized characteristics for the first message are in a same format irrespective of the format of the pieces of information. The first message, and/or other messages, is processed based on at least one of the one or more normalized characteristics. | 10-24-2013 |
20130282986 | ANTICIPATORY RESPONSE PRE-CACHING - Interaction between a client and a service in which the service responds to requests from the client. In addition to responding to specific client requests, the service also anticipates or speculates about what the client may request in the future. Rather than await the client request (that may or may not ultimately be made), the service provides the unrequested anticipatory data to the client in the same data stream as the response data that actual responds to the specific client requests. The client may then use the anticipatory data to fully or partially respond to future requests from the client, if the client does make the request anticipated by the service. Thus, in some cases, latency may be reduced when responding to requests in which anticipatory data has already been provided. The service may give priority to the actual requested data, and gives secondary priority to the anticipatory data. | 10-24-2013 |
20130290469 | ANTICIPATORY RESPONSE PRE-CACHING - Interaction between a client and a service in which the service responds to requests from the client. In addition to responding to specific client requests, the service also anticipates or speculates about what the client may request in the future. Rather than await the client request (that may or may not ultimately be made), the service provides the unrequested anticipatory data to the client in the same data stream as the response data that actual responds to the specific client requests. The client may then use the anticipatory data to fully or partially respond to future requests from the client, if the client does make the request anticipated by the service. Thus, in some cases, latency may be reduced when responding to requests in which anticipatory data has already been provided. The service may give priority to the actual requested data, and gives secondary priority to the anticipatory data. | 10-31-2013 |