Abstract: Encoding and/or decoding of messages. On the encoding end, a composite encoder encodes message from an internal format that is used by internal system components into an external format. However, the composite encoder may encode the outgoing messages into different external formats on a per-message basis. For incoming message, a composite decoder decodes incoming messages from any one of a plurality of external formats into the internal format also on a per-message basis. A per-message report mechanism permits internal system components and the encoding/decoding components to communicate information regarding the encoding or decoding on a per message basis. XML messages can be converted automatically into Binary messages.

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

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

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

Abstract: The present invention extends to methods, systems, and computer program products for processing model based commands for distributed applications. Embodiments facilitate execution of model-based commands, including software lifecycle commands, using model-based workflow instances. Data related to command execution is stored in a shared repository such that command processors can understand their status in relationship to workflow instances. Further, since the repository is shared, command execution can be distributed and balanced across a plurality of different executive services. Embodiments also include model-based error handling and error recovery mechanisms.

Abstract: The present invention extends to methods, systems, and computer program products for managing software lifecycle. Based on declarative models and knowledge of their interpretation, embodiments of the present invention facilitate lifecycle management for model-based software applications. Lifecycle models, such as, for example, lifecycle state machine models are stored in a shared repository such that executive services can determine how software application lifecycles are to be managed and transitioned. Software lifecycle activities can verify that a transition is possible and identify any errors preventing a lifecycle transition. Model-based error handling and error recovery mechanisms can be used to correct any identified errors.

Abstract: An application program interface (API) provides a set of functions that make available support for processing XML documents for application developers who build Web applications on Microsoft Corporation's .NET™ platform.

Abstract: The described method and system synchronizes source code with byproducts or artifacts of an application creation process. In one embodiment, a generation tool may be used to produce source code header files based on a design specification, where the source code header files are compiled with a current version of source code. Compilation errors may direct a developer to modify either the specification or the source code to eliminate the errors. The described method and system may be integrated into a development platform that is adapted to direct the user to perform particular revisions or updates to bring the source code in line with the artifacts.

Abstract: Encoding and/or decoding of messages. On the encoding end, a composite encoder encodes message from an internal format that is used by internal system components into an external format. However, the composite encoder may encode the outgoing messages into different external formats on a per-message basis. For incoming message, a composite decoder decodes incoming messages from any one of a plurality of external formats into the internal format also on a per-message basis. A per-message report mechanism permits internal system components and the encoding/decoding components to communicate information regarding the encoding or decoding on a per message basis. XML messages can be converted automatically into Binary messages.

Abstract: The present invention extends to methods, systems, and computer program products for processing model based commands for distributed applications. Embodiments facilitate execution of model-based commands, including software lifecycle commands, using model-based workflow instances. Data related to command execution is stored in a shared repository such that command processors can understand their status in relationship to workflow instances. Further, since the repository is shared, command execution can be distributed and balanced across a plurality of different executive services. Embodiments also include model-based error handling and error recovery mechanisms.

Abstract: A routing protocol is provided for exchanging messages between an initial sender and an ultimate receiver, potentially via a set of intermediaries. The routing protocol provides an optional reverse message path that enables two-way message exchange patterns. The routing protocol can be expressed as a header entry within a message envelope, is independent of the underlying protocol, and can be generated at the application layer of a protocol stack. The routing protocol may allow each intermediary to process the message and dynamically alter the message path en route to the intended recipient.

Abstract: The present invention extends to methods, systems, and computer program products for processing model based commands for distributed applications. Embodiments facilitate execution of model-based commands, including software lifecycle commands, using model-based workflow instances. Data related to command execution is stored in a shared repository such that command processors can understand their status in relationship to workflow instances. Further, since the repository is shared, command execution can be distributed and balanced across a plurality of different executive services. Embodiments also include model-based error handling and error recovery mechanisms.

Abstract: Embodiments described herein provide for an overall object mode that allows for a single message object to represent multiple messaging formats. A general message object is populated with fields for multiple available messaging formats, which can be appropriately filled with information with fields for both versions 1.1 and 1.2. Depending on which version is being used or desired, the appropriate fields can be populated when creating an instance of the message object. The other fields that do not correspond to that version, however, are left blank.

Abstract: Embodiments described herein provide for a message object that simultaneously exposes an XML view and Type view for a message infoset. In this embodiment, interaction with a message can occur using either an XML or Type application program interface (API), which are synced. More specifically, embodiments herein provide or expose a common set of headers (e.g., SOAP headers) as “typed” properties (e.g., CLR properties), which allow for getting and/or setting a value thereof. In other words, the Type API reads/writes values for typed properties without regard to how the message is encoded with XML. Moreover, the two APIs are synced such that a value can be set using one API and retrieved using the other. For example, an XML API may be used as a writing mechanism for interacting with a value, while the Type API can read that same value, and vise-versa.

Abstract: The present invention extends to methods, systems, and computer program products for performing requested commands for model-based applications. Embodiments of the invention permit efficient implementation of operations for model-based applications. Since drivers that are to implement an operation request data for implementing the operation, embodiments significantly reduce the likelihood of superfluous data being exchanged between an executive service and drivers. Further, if an operation is interrupted before implementation is complete, the operation can be resumed without having to re-perform already completed portions of the operation. Additionally, a user can be regularly updated on the progress of their commands.

Abstract: The present invention provides for an automated, user friendly way of constructing and using a binding object. A developer is presented with and selects binding elements that will ultimately be used to create a runtime communication channel for transporting a message between a client and service endpoint. After receiving the user input, metadata, a channel factory and listener factory are created. The metadata describes binding elements and provides an abstract representation of a protocol stack that implements communication aspects at runtime. The channel factory is configured to use the collection of metadata at runtime to generate the runtime communication channel. Further, the listener factory is configured to accept the runtime communication channel for de-multiplexing the communication aspects in order to process the message at a service endpoint. The present invention also provides for groupings of binding elements and standardized binding objects organized based on industry need.

Abstract: Methods and systems for providing a virtual network are disclosed. At least one layer of abstraction is created between network service applications and conventional network protocols by inserting an adaptive dispatcher between applications and network transport services on each machine in a network. The message protocol in the virtual network is extensible, allowing application programs to create new headers within any message as needed. The adaptive dispatcher contains handlers that route and dispatch messages within the virtual network based on arbitrary content within each message, including any combination of headers and/or data content. Each device on the virtual network has a virtual address to which messages are directed, allowing devices to move within the network without reconfiguring routing tables.

Abstract: The present invention provides for a channel model capable of generating a runtime communication channel with pluggable modular channel components. These channel components implement one of a set of standard interfaces that allow processing details of communication semantics between components to be represented in a polymorphic way. A message and corresponding communication semantics are recursively passed through the channel components using the standard interface, thereby abstracting other modules and components from specific implementation details of how the communication semantics are performed. The message may then be sent to the next appropriate module for further processing, or the processing may be completed at that particular component or module. Note also that the message can also be de-multiplexed on the service side in a similar fashion as that described above.

Abstract: Enabling and processing events. To enable events, an application model correlated to an application is declaratively defined. The application model describes operations of the application. One or more event models correlated to the application model are declaratively defined. The event models describe application execution locations where events are desired to be emitted in the execution of the application. Based on the correlation of the event models to the application models, the applications are instrumented with instrumentation code to cause the application to emit events at the execution locations. To process events an application model is defined. The application model includes one or more observation models. The observation models include a correlation of events to the observation model by defining instrumentation models in the application model. An event is received. The event is applied to the observation model based on the correlation. The event is processed according to the observation model.

Abstract: Embodiments described herein provide a user with the ability to vary the encoding of a message object rather than being bound to a specific one, e.g., the text encoding for SOAP messaging. Accordingly, a message encoding factory is provided that is responsible for mapping a message object (e.g., SOAP Infoset) into raw octets suitable for wire transmission. By encapsulating the notion of a message encoder factory abstractly, embodiments allow users to vary the encoding of an Infoset without varying the programming model (or any other aspect of the system that uses message). In other words, embodiments herein separate the transport (e.g., TCP, HTTP, etc.) from the encoding, which allows users to use any number of encoding mechanisms—even their own proprietary ones.