Microsoft Technology Licensing, LLC

Geary L Eppley

Umesh Madan

David Wortendyke

Aaron Stern

Craig Andrew Critchley

Luis Felipe Cabrera

Christopher G Kaler

Bradford H Lovering

Jeffrey C Schlimmer

Erik B Christensen

Kenneth David Wolf

Steven E Lucco

John Peter Shewchuk

Donald F Box

Stephen James Millet

Giovanni Moises Della-Libera

Henrik Frystyk Nielsen

James Ernest Johnson

Tirunelveli R Vishwanath

David E Langworthy

Lance Olson

Richard Douglas Hill

Stefan R Batres

Michael James Coulson

John David Doty

Stefan Harrington Pharies

Uday Sooryakant Hegde

Vijay Gajjala

Michael Marucheck

Krishnan Srinivasan

Elliot Lee Waingold

Tomasz Janczuk

Matthew Thomas Tavis

Stephen T Swartz

David Edwin Levin

Michael Steven Vernal

Shy Cohen

Max A Feingold

Richard Dievendorff

Douglas M Purdy

Natasha Harish Jethanandani

David Owen Driver

Siddhartha Puri

Saurab Nog

Douglas A Walter

Jesus Ruiz-Scougall

Anastasios Kasiolas

Kapil Gupta

Vipul A Modi

Ryan Thomas Sturgell

Sowmyanarayanan K Srinivasan

Scott Christopher Seely

Jonathan T Wheeler

Evgeny Osovetsky

Mohammad Makarechian

Alexander Martin DeJarnatt

Chaitanya Dutt Upadhyay

Michael Thomas Dice

Yaniv Pessach

Mauro Ottaviani

Erin Honeycutt

Eugene Shvets

Alfred M Lee, Iv

Yasser Shohoud

Pompiliu Diplan

Anand Rjagopalan

Mohamed-Hany Essam Ramadan

Serge Sverdlov

Vaithialingam B Balayogan

Systems and methods for open content model Web service messaging in a networked computing environment are described. In one aspect, a transport neutral message is generated that includes message recipient, endpoint addressing information, and one or more reference properties. The reference properties include selectively opaque message context. The transport neutral message is bound to a transport protocol for communication to the message recipient. At least a portion of the selectively opaque message context is not directed to the message recipient.

Open content model Web service messaging

At least one implementation described herein relates to evaluating queries structured according to a first format against one or more objects structured according to a second, different format without serializing the object. Typically, evaluating an XML (eXtensible Markup Language) query against a CLR (Common Language Runtime) object required serializing the CLR object and deriving an XML construct from the serialized data. The query is then be evaluated against the XML construct. In the described implementations, significant system resources are realized by creating an infoset model that maps properties of an object to an object infoset. The query is then evaluated using the infoset to locate object values and, thus, no serialization is required. Dynamically generated IL is used and re-used to efficiently perform subsequent evaluation steps on similar queries.

Evaluating queries against in-memory objects without serialization

Embodiments herein prevent or mitigate attacks on inverse query engines by providing safe mode routines that allow for the acceptance of third party messages and/or query expressions, as well as prevent trusted sources from accidental attacks. The mitigations fall into two categories: compile-time and runtime. Compile-time mitigations prevent query expressions from being accepted and compiled that are susceptible to known attacks. For example, the complexity of query expressions may be limited to functions with linear runtimes; constant memory usage; or ones that do not create large strings. Further, language constructs for the criteria in the query expression may not allow for nested predicates complexities. Runtime mitigations, on the other hand, monitor the data size and processing lengths of messages against the various query expressions. If these runtime quotas are exceeded, an exception or other violation indication may be thrown (e.g., abort), deeming the evaluation as under attack.

Safe mode for inverse query evaluations

Implementations described herein relate to evaluating multiple queries represented in an opcode tree having opcode nodes and branch nodes. Each opcode node comprises an opcode that is a part of an opcode block derived from compilation of a query, the opcode block consisting of a linear sequence of opcodes. Opcode nodes are arranged in the tree according to location of its corresponding opcode in the opcode block with opcodes that occur earlier in the opcode block being represented at a higher tree level than subsequent opcodes. Only one opcode node corresponds to a common opcode block segment that is included in multiple queries. Executing the opcode tree against an input evaluates each of the multiple queries represented in the opcode tree.

Systems and methods for parallel evaluation of multiple queries

At least one implementation described herein relates to using multiple filter engines to optimize query processing. A filter engine comprises a general matcher and at least one optimized matcher, a matcher being a filter engine in its own right. When the filter engine receives an input, the input is analyzed to determine if it can be handled by the optimized matcher. While the general matcher is fully compliant with a query language, the optimized matcher only handles a subset of the query language. Therefore, inputs that can be processed in the optimized matcher are compared against fewer filters, making the filtering process more efficient. The filter engine may also process only a portion of an input in the optimized matcher and another portion of the input in the general matcher, which reduces processing overhead.

Systems and methods for filter table optimization

An inverse query engine system having a cache integrated therein and methods for maintaining the cache are described herein. Entities storing filters in the inverse query engine cache thus do not have to maintain an individual cache to maintain the filters. The inverse query engine system cache is maintained within a bounded size by removing expired filters from the cache and trimming the cache to an optimal size when the cache reaches a maximum size. In the event that filter size cannot be determined efficiently, weights may be associated with filters stored in the cache, each weight identifying an estimate of a filter size. The weights are used to determine cache size and to maintain the cache size within particular bounds.

Inverse query engine systems with cache and methods for cache maintenance

Example embodiments provide a high performance navigator configured to lightly touch on the elements or input of a message, without necessarily having to build an entire tree structure for each input within the message. In addition, as portions of the inputs are identified as requiring further details, only those stub nodes representing that particular input will be created; thus avoiding the setup cost associated with loading an entire tree. Other example embodiments also provide for other optimizations such as reducing the class types of node allocations needed for navigating a particular message. For instance, a single class is defined that holds enough fields to store all of the information needed for numerous input nodes. Further, these common node structures can simultaneously generate as an array that further allows for more efficient navigation of the inputs.

High performance navigator for parsing inputs of a message

Implementations described herein relate to using a filter engine opcode tree for evaluating multiple queries. The opcode tree includes opcode nodes and branch nodes. Each opcode node includes one or more computer instructions resulting from compiling a query. Executing the opcode tree a single time evaluates each of multiple queries represented in the opcode tree. When a new opcode node is added to the tree, the context of the opcode tree and the structure of the new opcode are taken into account when modifying a branch node or an opcode node. In certain situation, a branch node is optimized to include an indexed lookup function such as a hash function, to optimize processing of opcode nodes that depend from the branch node. Adding and removing nodes to/from the opcode tree can be handled by a filter engine component or by an opcode object being added to/removed from the tree.

Systems and methods for updating a query engine opcode tree

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

Embodiments provide for select indexing, which uses an array to simultaneously construct output sets for instructions that operate on input nodesets with common axes. During evaluation of a message against an instruction tree, when a branching node with a large 'splay' is iterated over, rather than iterating over an input nodeset with a common axis once per branch, the select indexing described herein iterates over the nodeset once in total. More specifically, the select index data structure includes an array of empty node sets for instructions that both, branch from a branching node, and evaluate input nodes that share a common axis. Identifiers for the input nodeset are compared to indices within the select index, and matches for the input nodes are added to the corresponding nodeset for the appropriate instruction. The results of the evaluation may then be passed to the branches of the select instructions for further processing.

Select indexing in merged inverse query evaluations

Systems and methods for using endpoint references in a publish-subscribe system are described. In one aspect, an endpoint reference is created by a component of the pub-sub system. The endpoint reference includes an endpoint address and one or more contexts. Each context is directed to a respective component of the pub-sub system. Each context is transparent to the respective component, and selectively opaque to all other pub-sub system components.

Using endpoint references in a pub-sub system

An inverse query engine that uses an instruction tree to represents the queries to be applied against input, instead of applying each query individually. Each node in the instruction tree represents executable code. Each branch of the instruction tree when executed from the root node to a terminating branch node represents the instructions to be executed to process that query against the input. The instruction tree is forward-only in that once a node in a tree is processed against an input, that executable code associated with that node is not ever processed again for that node. Accordingly, processing resources and time is conserved.

Forward-only evaluation for XPATH inverse query processing

Growing community of inventors

Carnation, WA, United States of America

Geary L Eppley