Microsoft Technology Licensing, LLC

Stephen James Millet

John Peter Shewchuk

Erik B Christensen

Giovanni Moises Della-Libera

Scott David Guthrie

David S Ebbo

Mark T Anders

Nicholas Alexander Allen

Christopher G Kaler

Kenneth David Wolf

Gregory Scott Lindhorst

Bradford H Lovering

Gary Steven Burd

Kenneth Bruce Cooper

Ted Andrew Peters

Steven E Lucco

David Wortendyke

Tirunelveli R Vishwanath

Edmund Samuel Victor Pinto

Stephen Jared Maine

Stefan Harrington Pharies

Robert Meyer

Paul J Leach

Richard F Rashid

Butler W Lampson

Scott A Konersmann

Stephen T Swartz

Eric Kenneth Zinda

Nikhil Kothari

Keith W Ballinger

Anthony J Moore

Michael Marucheck

Erik B Olson

Elliot Lee Waingold

Yann Christensen

Fabio A Yeon

David Edwin Levin

Michael Steven Vernal

Susan M Warren

Manu Vasandani

Robert Michael Howard

Luis Felipe Cabrera

Justin David Brown

Lance Olson

Richard Douglas Hill

Christopher L Anderson

Robert S Wahbe

Craig Andrew Critchley

Uday Sooryakant Hegde

Tomasz Janczuk

Shy Cohen

Stephen Michael Danton

Anders Hejlsberg

Gopala Krishna R Kakivaya

John Anthony Taylor

Yan Valerie Leshinsky

Christopher Wellington Brumme

Donald F Box

Michael M Magruder

Raja Krishnaswamy

David Bau

James Ernest Johnson

Brian LaMacchia

Gregory Darrell Fee

Henry L Sanders

Julie D Bennett

Travis Muhlestein

Sean Edwin Trowbridge

James S Miller

Nathan Christopher Talbert

Jonathan C Hawkins

Brad Olenick

Umesh Madan

Krzysztof J Cwalina

Stefan R Batres

John Raymond Justice

Seth Mitchell Demsey

Brian M Grunkemeyer

Luca Bolognese

Michael James Coulson

Shawn Patrick Burke

David L Johnson

John David Doty

Loren Kohnfelder

Yung-Shin Lin

Haroon Ahmed

Brian Keith Pepin

Robert Brian Schmidt

Alfred Lee

Vijay Gajjala

Jun Fang

Krishnan Srinivasan

Jeffrey M Cooperstein

Geary L Eppley

Matthew Thomas Tavis

Pedram Faghihi Rezaei

James H Hogg

Craig T Sinclair

Max A Feingold

Nicholas M Kramer

Embodiments described herein allow a service component author to write service components without having to handle incoming messages being received at any time. This may be facilitated by a message dispatch engine that dispatches messages from the incoming message queue only when the destination service component has indicated that it is ready to receive the message having that context. If the service component is not yet ready for the message, the message dispatch component may lock the message at least until the destination service component indicates that it is now ready to receive the message. Until that time, the message dispatch engine may ignore the locked message when finding messages to dispatch.

Queued message dispatch

Technologies for conversations between various parties, the conversations including context information that can be persisted to maintain the conversation when the parties or the communications media they communicate over operate intermittently. In such a conversation, any party can embed its view of the context into a message and any party can send the next message regardless of role and regardless of the underlying network, transport, or application message exchange pattern. Such technologies provide for durable services.

Role-independent context exchange

Changes are managed in a multi-user database application environment. Proposed changes are collected, including changes to data, schema, and/or application descriptions. A user may specify foreign key relationships between items belonging to one or more of these categories. A view is produced showing the impact proposed changes would have on the environment if successfully committed. The user's proposed changes are ordered according to their dependencies, and submitted for committal together in a single transaction, subject to optimistic concurrency and consistency checks. For example, a proposed change to a data value may be inconsistent with a change which removed a data element containing the data value. The commitment operation may return identifiers and other return values, in addition to indicating whether the commitment was successful.

Unified concurrent changes to data, schema, and application

User experience in a designer tool manages cogeneration of a database application and a database accessible through the application. A user places a visual representation of an application element designed to control a relational or hierarchical dataset. Code is automatically called to add the application element to the application, and automatically invoked to create database schema elements designed to implement the dataset in the database under application element control. Users verify that an application element has been automatically added, and confirm that database schema elements implementing the dataset(s) under control of the application element have been automatically created. A tutorial illustrates a workflow utilizing a designer tool to cogenerate a database application and a database without a data design step. A wizard utilizes the designer tool to cogenerate a database application and a database that collectively implement a calendar, a diagram, a tree, a wiki, and/or a list.

Cogeneration of database applications and their databases

A distributed security system is provided. The distributed security system uses a security policy that is written in a policy language that is transport and security protocol independent as well as independent of cryptographic technologies. This security policy can be expressed using the language to create different security components allowing for greater scalability and flexibility. By abstracting underlying protocols and technologies, multiple environments and platforms can be supported.

Virtual distributed security system

A system for aggregating context information for messages includes a context container that associates names with context values and metadata for context entries. The system further includes a network protocol component configured to read messages from a network transport, an encoder component configured translate messages from a raw format into a canonical message format. The canonical message format is an enveloped message containing an application payload and message metadata. The context container is associated with a message in the canonical format. The system further includes an extraction component configured to retrieve context from a native network transport protocol and insert the context values and metadata into the context container, a plurality of additional protocol components configured to add, remove, or modify entries in the context container, and one or more higher level application components configured to operate on the canonical message using the context entries.

Envelope attachment for message context

Transforming portions of a message to a destination via a communication protocol. A message is received. It is detected whether the received message includes an encoded envelope. The encoded envelope includes a stack defining parameters including information for handling the received message in an original format. If the received message includes the encoded envelope, the defined parameters are transformed to coded parameters in a common format. The coded parameters express the same information for handling the received message in the communication protocol. The encoded envelope is encapsulated in the received message, and the received message in the common format is delivered to the destination. If the received message does not include an encoded envelope, coded parameters are generated in the common format for the received message by encoding addressing information from the received message. The received message having the coded parameters in the common format is delivered to the destination.

Transparent envelope for XML messages

A system for aggregating context information for messages. The system includes a context container. The context container associates names with context values and metadata for context entries. The system further includes a network protocol component configured to read messages from a network transport, an encoder component configured translate messages from a raw format into a canonical message format. The canonical message format is an enveloped message containing an application payload and message metadata. The context container is associated with a message in the canonical format. The system further includes an extraction component configured to retrieve context from a native network transport protocol and insert the context values and metadata into the context container, a plurality of additional protocol components configured to add, remove, or modify entries in the context container, and one or more higher level application components configured to operate on the canonical message using the context entries.

The present invention extends utilizing abstract descriptions to generate, exchange, and configure service and client runtimes. A computer system parses compiled code and potentially optional configuration information for implementing a service and converts the compiled code and any configuration information into an abstract service description. The abstract service description can then be converted into code document object model and service configuration information or exported as metadata. A corresponding service runtime can be initiated by calling a service initializer included in the abstract service description. The code document object model and configuration information and/or metadata can be transferred to another computer system. The other computer system can utilize the code document object model and configuration information and/or import the metadata to facilitate initialization of a compatible channel for communicating with the service runtime.

Utilizing abstract descriptions to generate, exchange, and configure service and client runtimes

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.

System and method for building and using communication binding objects

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. Handlers may be automatically created when an event meeting predefined criteria occurs, including the non-occurrence of a condition, making the virtual network self-healing and adaptive to reconfiguration.

Virtual network with adaptive dispatcher

Selectively modifying a message delivery requirement of a datagram message at an intermediary network node between an origin and a destination. A message delivery requirement is defined for a particular message. The message delivery guarantee defines how to transmit the particular message. A downgrading intent of the particular message is provided for the message at the origin. The downgrading intent of the particular message indicates that the message delivery requirement can be bypassed. The defined message delivery guarantee, the network delivery requirement, and the provided downgrading intent of the particular message are processed at the intermediate network node. The message delivery requirement of the particular message is ignored based on the provided downgrading intent. The message is delivered via a network protocol according to the provided downgrading intent.

Message delivery downgrading annotations

Growing community of inventors

Edmonds, WA, United States of America

Stephen James Millet