Microsoft Technology Licensing, LLC

Douglas M Purdy

Stefan Harrington Pharies

Natasha Harish Jethanandani

Erik B Christensen

Kenneth David Wolf

Donald F Box

Elliot Lee Waingold

Michael Steven Vernal

Stephen T Swartz

Sowmy Srinivasan

Sowmyanarayanan K Srinivasan

Gopala Krishna R Kakivaya

David Wortendyke

Michael James Coulson

Michael Marucheck

Yann Christensen

Ryan Thomas Sturgell

Elena A Kharitidi

Christopher G Kaler

Steven E Lucco

Stephen James Millet

Giovanni Moises Della-Libera

Bradford H Lovering

James Ernest Johnson

Tirunelveli R Vishwanath

Lance Olson

Richard Douglas Hill

Umesh Madan

Stefan R Batres

John David Doty

Craig Andrew Critchley

Vijay Gajjala

Uday Sooryakant Hegde

Krishnan Srinivasan

Matthew Thomas Tavis

Tomasz Janczuk

Geary L Eppley

David Edwin Levin

Shy Cohen

Richard Dievendorff

Max A Feingold

David Owen Driver

Stefan H Pharies

Aaron Stern

Siddhartha Puri

Saurab Nog

Anastasios Kasiolas

Jesus Ruiz-Scougall

Douglas A Walter

Kapil Gupta

Vipul A Modi

Mohammad Makarechian

Scott Christopher Seely

Jonathan T Wheeler

Alexander Martin DeJarnatt

Evgeny Osovetsky

Chaitanya Dutt Upadhyay

Yaniv Pessach

Erin Honeycutt

Michael Thomas Dice

Mauro Ottaviani

Eugene Shvets

Yasser Shohoud

Eugene Osovetsky

Alfred M Lee, Iv

Vaithiakingam B Balayoghan

Vaithialingam B Balayogan

Serge Sverdlov

Mohamed-Hany Essam Ramadan

Anand Rjagopalan

Sowmy K Srinivasan

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.

Annotating portions of a message with state properties

The present invention extends to using Simple Object Access Protocol ('SOAP') to exchange typed objects, such as, for example, parameters for invoking methods. A computer system accesses typed object parameters corresponding to a typed object. The typed object is annotated with one or more message contract attributes of a message contract model defining a mapping between typed object parameters and corresponding SOAP elements. The computer system utilizes the message contract attributes to map the typed object parameters into a SOAP element and inserts the SOAP element into a SOAP envelope. A receiving computer system accessing the SOAP element and utilizes the message contract attributes to map the SOAP element back into the typed object parameters.

Flexibly transferring typed application data

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.

Simultaneous API exposure for messages

Serialization and deserialization using data contracts. The data contract specifies data types that are serialized and deserialized for data objects that are associated with the data contract. During serialization, the data contract associated with the data object is identified. Then, the data fields that correspond to those specified data field types are extracted from the data object and serialized into a serialization format. During deserialization, the serialization mechanism receives a serialized data structure having a particular serialization format. A data contract is then identified as being associated with the serialized data structure. After deserialization of the serialized data structure into abstract data, a corresponding data object is populated with data fields that correspond only with those data field types specified in the data contract. Accordingly, data abstraction is enabled while serializing and deserializing.

Data abstraction based serialization

Methods, systems, and computer program products for converting an object of one type to an object of another type that allow for the runtime operation of the conversion process to be altered or customized. The conversion may occur within an extensible serialization engine that serializes, deserializes, and transforms objects of various types. The runtime operation of the serialization engine is altered by one or more extension routines that implement the desired customizations or extensions, without requiring replacement of other existing routines. Based on type information, identified for an initial object, the object is converted to an intermediate representation which permits runtime modification, including modification of object names, object types, and object data. The intermediate representation of the initial object is modified in accordance with extension routines that alter the runtime operation of the serialization engine, and the intermediate representation is converted to a final object and type.

Type bridges

The transfer of raw data from a source data structure to a target data structure that represent the same item. During the data transfer, if there is a given field in the target data structure that does not correspond to a field supplied by the source data structure, the transfer mechanism determines whether or not it is mandatory that the source data structure supply the field. If it is mandatory, the transfer fails. Otherwise, the transfer continues. If there is field of the source data structure that does not correspond to a field of the target data structure, the transfer mechanism determines whether or not it is mandatory that the target data structure have the field. If it is mandatory, the transfer fails. Otherwise, the corresponding data may be provided to a residual field of the target data structure dedicated for unknown data.

Mechanisms for transferring raw data from one data structure to another representing the same item

A versionable schema is both backward-compatible and forward-compatible. Such a schema is able to receive data expected by multiple versions of the schema; tolerates the absence of optional data, in accordance with other versions, and accept wildcard data in accordance with still further versions. Thus, a message or message may be validated by the versionable schema.

Type evolution

A web services namespace pertains to an infrastructure for enabling creation of a wide variety of applications. The infrastructure provides a foundation for building message-based applications of various scale and complexity. The infrastructure or framework provides APIs for basic messaging, secure messaging, reliable messaging and transacted messaging. In some embodiments, the associated APIs are factored into a hierarchy of namespaces in a manner that balances utility, usability, extensibility and versionability.

Interface infrastructure for creating and interacting with web services

Growing community of inventors

Carnation, WA, United States of America

Douglas M Purdy