Proxy assembly for simulating real assembly features on a remote device

A proxy service for simulating real assembly features on a remote device is described. A data stream including reflection data of a real assembly is generated. The reflection data stream may include data associated with proxy types without including the code from the real assembly. A client obtains the reflection data stream. The reflection data stream facilitates the generation of a proxy assembly on the client and allows the client to instantiate features of the real assembly on the client without the code for the real assembly.

BACKGROUND

Many software applications include units of code packaged into files. These units of code may be referred to as assemblies. In some situations, codes for actual assemblies are installed on a server. Access to the real assemblies is typically restricted for security reasons, and therefore, direct access to the real assemblies does not exist. In such situations, remote programs and applications cannot make use of the real assemblies.

In other situations, real assemblies cannot be copied over from the server because they are only licensed for server installation. Also, the server may provide a unique context that cannot be replicated on the remote device. Therefore, the remote device does not have access to and cannot use real assemblies. Furthermore, in some situations the server may be running different or incompatible versions of the operating system and real assemblies may be incompatible with the remote device environment.

SUMMARY

Generally, aspects of the disclosure relate to a proxy assembly for simulating real assembly features on a remote device. As a succinct summation of a few functional aspects of some embodiments of the present disclosure, a data stream including reflection data of a real assembly is generated. In one aspect, reflection data may include a description of the controls of an assembly. The reflection data stream may include data associated with proxy types without including the code for the real assembly. The proxy types may include type data, property data, sub-property data and/or attribute data that is associated with the reflection data stream. In one aspect, a client obtains the reflection data stream from a server. The reflection data stream may facilitate the generation of a proxy assembly on the client and allow the client to simulate features of the real assembly on the client without the code for the real assembly.

Such a proxy assembly provides dynamic functionality for a client computer without requiring the real assembly to be installed on the client. In this manner, aspects of the proxy assembly may circumvent licensing issues where the real assemblies are licensed to be installed on the server.

DETAILED DESCRIPTION

Embodiments are described more fully below with reference to the accompanying drawings, which form a part hereof, and which show specific exemplary embodiments. However, embodiments may be implemented in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope. Embodiments may be practiced as methods, systems or devices. Accordingly, embodiments may take the form of an entirely hardware implementation, an entirely software implementation or an implementation combining software and hardware aspects. The following detailed description is, therefore, not to be taken in a limiting sense.

The logical operations of the various embodiments are implemented (1) as a sequence of computer implemented steps running on a computing system and/or (2) as interconnected machine modules within the computing system. The implementation is a matter of choice dependent on the performance requirements of the computing system implementing the invention. Accordingly, the logical operations making up the embodiments of the present invention described herein are referred to alternatively as operations, steps or modules.

Illustrative Embodiments of a Proxy Assembly for Simulating Real Assembly Features on a Remote Device

Embodiments of the disclosure relate to a proxy assembly for simulating real assembly features on a remote device. As a succinct summation of a few aspects of the disclosure, a data stream including reflection data of a real assembly is generated. The reflection data stream may include data associated with proxy types without including the code from the real assembly. The proxy types may include type data, property data, sub-property data and/or attribute data that is associated with the reflection data stream. In one aspect, a client obtains the reflection data stream from a server. The reflection data stream may facilitate the generation of a proxy assembly on the client and allow the client to simulate features of the real assembly on the client without the code for the real assembly.

FIG. 3represents one exemplary system overview300for generating a proxy assembly. Client302and server304represent a general modular overview of some aspects of the disclosure. Client302and server304may include the same modular elements being represented during different processes. Client302and server304may be integrated as a combination of software and hardware elements, an operating system or any combination thereof. Hardware, databases, software or applications referenced herein may be integrated as a single element or include various elements in communication with one another.

Software and/or hardware elements are depicted herein for explanatory purposes only and not for limiting the configuration to multiple elements or a single element performing several functions. Elements of client302may “live on” a single computing device or a plurality of computing devices in communication with one another. Likewise, elements of server304may “live on” a single server or a plurality of servers in communication with one another. Aspects of client302and server304may include computing device100as exemplified inFIG. 1and/or mobile computing device200as exemplified inFIG. 2. In one aspect, server304may be represented by aspects of MICROSOFT SHAREPOINT from MICROSOFT CORPORATION, headquartered in Redmond, Wash.

InFIG. 3, client302may include proxy assembly306, proxy builder308, proxy initializer310, and framework312. Reference numbers306-312may include separate programs, separate databases, separate computing devices and separate hardware. Reference numbers306-312may also include multiple programs, databases, computing devices, hardware or any combination thereof. Server304may include real assembly314, reflection service316, pre-scan service318, data stream builder320and framework322. Reference numbers314-322may include separate programs, separate databases, separate computing devices and separate hardware. Reference numbers314-322may also include multiple programs, databases, computing devices, hardware or any combination thereof. Moreover, even though eXtensible Markup Language (“XML”) is referenced herein, any type of data stream conducive to network communication may be implemented. XML is referenced herein as one example of the plurality of various network communication languages that may be implemented. In one aspect, the XML data stream is encrypted for security. Any type of data stream may be implemented as is more fully set forth herein.

InFIG. 3, client302may be associated with framework312and server304may be associated with framework322. Framework312and322may include a set of applications, a set of development tools for building applications, web applications and/or XML programming services. Aspects may include a platform that provides development tools to allow programmers to write code using a plurality of different program languages. In one embodiment, framework312and322may be represented by aspects of MICROSOFT .NET platform from MICROSOFT CORPORATION, headquartered in Redmond, Wash. Framework312and322may include any type of framework for performing operations on an operating system. In one aspect, framework312and322include some of the same applicants, programs and methods so that operations performed on framework322may be replicated on framework312or vice versa.

Server304may also include real assembly314. Real assembly314may include the code of a program, application or routine that is installed on server304. Real assembly314may include one or more types. The types may include one or more usable portions of real assembly314that performs a function. The types of real assembly314may also include properties, methods, fields, events, and other metadata. The types of real assembly314may include attributes associated with the types, attributes associated with the properties, sub-properties of properties, and/or values. In one aspect, real assembly314includes aspects of object-oriented programming.

Server304may include reflection service316. Reflection service316may include code associated with real assembly314, or reflection service316may include a separate program for performing reflection operations. Succinctly stated, reflection service316includes determining “data about data.” For example, inFIG. 3, reflection service316may determine that real assembly314includes several types. With regard to type one, reflection service316may determine that type one includes certain properties, fields, events, methods, metadata, values, attributes, sub-properties or any other data associated with the code for real assembly314. In one aspect, reflection service316does not copy any of the code associated with real assembly314. The “data about data” associated with real assembly314may be utilized, as more fully set forth below, to facilitate a proxy assembly.

Pre-scan service318may include a service for scanning data associated with reflection service316to optimize the data. Pre-scan service318may identify some repeated property data so that the repeated property data is written once. Pre-scan service318may also identify framework properties. In this manner, properties that are available to the client may not need to be written in that the property data can be obtained from the client. Pre-scan service318may also identify recursive properties. Recursive properties may include properties that reference one another and cause a recursion in a data stream. In such a situation, pre-scan service318may identify the recursion so that operations may be performed for resolution. Pre-scan service318may include any type of scanning service for optimizing data for a data stream.

Server304may further include data stream builder320. Even though data stream builder320is depicted inFIG. 3as a separate module, data stream builder320may be associated with various operations of server304. For example, data stream builder320may include operations for building a data stream during a reflection operation, a pre-scan operation and/or any other operation performed in association with an assembly request. Succinctly stated, aspects of data stream builder320include building a data stream from data associated with reflection service316and pre-scan service318. The data stream may include an XML data stream, an XML data stream with a reference list, and/or any other type of data stream sufficient for communication between two devices.

Client302may include proxy assembly306. As a general analogy, proxy assembly306may be analogized to a “shell” of real assembly314. Proxy assembly306may include proxy types, properties, fields, values and attributes associated with real assembly314without requiring the code of real assembly314. In one aspect, the proxy types, properties, attributes, fields and values associated with the fields are instantiated from the received reflection data stream and framework312. The proxy types may also be associated client methods that provide some functionality to proxy assembly306. Proxy assembly306may be associated with a program, application and/or routine to provide real assembly features without requiring the code of the real assembly.

Client302may include proxy builder308. Proxy builder308may include an assembly context module, a referenced context module, a class context module, a property context module, and/or an attributes context module. Succinctly stated, depending on the received reflection data stream, proxy builder308may pass the data stream to the appropriate module for building the proxy assembly from the received reflection data stream. In one aspect, proxy builder308may include a program for generating a proxy assembly from an XML data stream that includes reflection data. For example, an assembly context module may receive a reflection data stream. The reflection data stream may be passed to a reference context module to determine data associated with a reference table. Types may be passed to a class context module and properties may be passed to a property context module for determining data associated with the same. The property context module may also determine sub-properties associated with the reflection data stream. When attributes are associated with the reflection data stream, the data stream may be passed to an attributes context module for determining the same. In one aspect, proxy builder308is associated with framework312. In another aspect, proxy builder308is a module of framework312. In still another aspect, proxy builder308includes any type of builder for facilitating the generation of a proxy assembly from a received reflection data stream.

Client302may further include proxy initializer310. Even though proxy initializer31is depicted as a separate module, proxy initializer310may include an initialize method associated with proxy assembly306. In one aspect, proxy initializer310interprets the reflection data stream and extracts associated values therefrom. Proxy assembly instantiates an initialize method to associate the values with variables of the proxy types. Proxy initializer310may include storing data associated with the types that are created by proxy builder308. The stored data may be utilized to build or retrieve methods for initialization of the types. In one aspect, proxy initializer310assigns values to the fields of proxy assembly306. For properties that are associated with framework312and that can be serialized and transferred between client302and server304, the properties may be assigned their respective values. For complex properties based on supporting types, methods associated with the supporting types may be stored until called. Nested properties may involve initializing data associated with one property and storing data associated with a mid-level property. Regarding property references, some references may be stored as local variables and reloaded to initialize other fields or fill in arguments to methods. A database may be maintained to record which local variables contain such references for reloading. In other aspects, proxy initializer310may include any type of initializer for initializing a proxy assembly.

In general and as is more fully set forth below, client302sends an assembly request to server304. In response, server304performs reflection on real assembly314to determine relevant proxy data associated with the real assembly. The relevant proxy data is pre-scanned to optimize a generated data stream. A data stream is built to include the aspects of the reflection data. A reflection data stream is sent to client302. Client302builds and initializes a proxy assembly from the received reflection data stream. In some aspects, some elements of a reflection data stream may include aspects of the structure as follows:

FIG. 4is an operational flow diagram representing an exemplary embodiment for determining types associated with a real assembly for reference in a reflection data stream. Operational flow400starts at start operation402and flows to operation404, where the real assembly is obtained. At operation406, the real assembly is parsed to determine one or more types. A type may include one or more usable portions of the real assembly that perform a function. Operational flow400continues to decision operation408where it is determined whether the parsed types are proxy types. A proxy type may be identified by a list of proxy types that is associated with the server. Stated another way, proxy type definitions may be hard coded on the server. In another embodiment, proxy type definitions may be sent with an assembly request from the client. In this manner, the client has freedom to determine which types are reflected. When a type is identified as a proxy type, the proxy type is listed as indicated by operation410.

When a type is not identified as a proxy type, operational flow400may flow to operation412where the type is ignored. Stated another way, the type is not a type that includes data to facilitate a proxy assembly on a client. Operational flow400flows to decision operation414where it is determined if another type exists. Where another type exists, operational flow400loops back to decision operation408. Where another type does not exist, operational flow400continues to end operation416. In one aspect, where operational flow400does not identify a proxy type or a reference type, end operation416may signify that the real assembly does not include elements for proxy.

In another aspect of operational flow400, when the proxy types are identified, operation410may include a list of the same. In one aspect of operation410, after the types have been considered for proxy status, the types of the properties are recursively checked to assure that they are included on the list of types to proxy. If the type of a property is not included in the list, child properties are considered. Where the property type is on the list, then child properties do not require consideration. The list may be reflected as indicated by operation418. Succinctly stated, reflection may include determining “data about data.” For example, reflection may determine properties, methods, metadata, values, attributes, sub-properties or any other data associated with the list of types. Operational flow400continues to operation420, where proxy data associated with operation418is obtained. In one aspect, proxy data includes properties, sub-properties, attributes and/or values associated with the types identified in operation410. In one aspect, operation420does not include method data associated with the types. In another aspect, operation420does not include the code associated with the real assembly.

Operational flow400continues to operation422, where the proxy data is pre-scanned. Operation422is more fully set forth below in association withFIG. 5. Operational flow400continues to operation424, where a data stream is generated. Operation424is more fully described below in association withFIG. 6. Operational flow400may also continue to operation426, where a proxy assembly is generated. Operation426is more fully described below in association withFIG. 7. Operational flow400continues to end operation416.

FIG. 5is an operational flow diagram representing an exemplary embodiment for pre-scanning reflection data. Operational flow500starts at start operation502and flows to operation504, where the pre-scan operation is initialized. In one aspect, the pre-scan operation is initialized after reflection data is generated. A pre-scan operation may be initialized to optimize the writing of data during data stream generation. At decision operation506, it is determined whether repeated property data exists among the proxy types. Repeated data may include repeated object references. To determine repeated object references, the object references are compared and properties that refer to the same object are recorded as indicated by operation508. In such a situation, a data stream may be optimized because repeated objects are not written more than once. The repeated objects may be referenced in the data stream. From operation508, operational flow500continues to operation510as indicated below.

Decision operation510includes determining whether framework data exists among the types. For example, types may include data that is referenced in the framework. In one aspect, the framework may also exist on a client device that is requesting the assembly. In such a situation, framework data may be excluded as indicated in operation512. In one aspect, initial value data is not omitted during operation512. In this situation, unnecessary data is not written where it can be obtained on the client device. From operation512, operational flow500continues to operation514as indicated below.

Decision operation514includes determining whether recursive data exists in the real assembly. Recursive data may include data that references itself and may cause a recursion in a data stream. For example, operational flow500may identify instances of recursive data by determining whether a sequence is listed more than twice. In one aspect, the sequence is a sequence of property types maintained in a stack associated with operation410. The sequence of data between the first and second instance is compared to the sequence of data between the second and third instance. When the sequences match, the data sequences are considered recursive. During the generation of a data stream, the value of such a property may be recorded as null as indicated by operation516. From operation516, operational flow500continues to operation520as indicated below.

Operational flow500continues to operation520, where a data stream is generated. Operation522is more fully described below in association withFIG. 6. Operational flow500may also continue to operation522, where a proxy assembly is generated. Operation522is more fully described below in association withFIG. 7. Operational flow500may then continue to end operation524.

FIG. 6is an operational flow diagram representing an exemplary embodiment for generating a data stream. In one aspect, the data stream includes an XML data stream. In another aspect, the XML data stream is encrypted for security before the XML data stream is transmitted. However, aspects may include generation of any type of data stream sufficient to convey data between devices. Even though operational flow600depicts a separate operational flow apart from operational flow400and500. Operational flow600may include operations occurring during any aspect of operational flow400and/or operational flow500. Stated another way, data stream generation may occur piecemeal during operational flow400and/or operational flow500.

Operational flow600starts at start operation602and flows to operation604, where the data stream builder is initialized. At operation606, a data stream table is generated. In one aspect the data stream table is the first set of data in the data stream. The data stream table may include identifiers associated with externally referenced types. Operational flow600continues to operation608where a type is written to the data stream. At operation610, it is determined whether the type includes repeated data. Where the type includes repeated data, an identifier may be set as indicated by operation612. In one aspect, the identifier is set locally. Operational flow600continues to operation614as indicated below.

At operation614, it is determined whether the type includes framework data. Where the type includes framework data, the data may be omitted as indicated by operation616. Operational flow600continues to operation618as indicated below.

At operation618, it is determined whether the type includes recursive data. Where the type includes recursive data, a null value may be set to the data stream table as indicated by operation620. Operational flow600continues to operation622as indicated below.

At operation622, data is written to the data stream. Stated another way, data that is not referenced in the data stream table may be written to the data stream. In one aspect, the data is written as an XML data stream. Operational flow600continues to decision operation624where it is determined whether to write another type. Where it is decided to write another type, operational flow600loops back. Where another type does not require writing, operational flow600continues to operation626, where a proxy assembly is generated. Operation626is set forth below with respect toFIG. 7. Operational flow600continues to end operation628.

FIG. 7is an operational flow diagram representing an exemplary embodiment for generating a proxy assembly. In one aspect, operations associated with operational flow700are representative of reflection emit functionality associated with the framework of the client. Operational flow700begins at start operation702and continues to operation704where the reflection data stream is obtained. The reflection data stream may be obtained in any manner. For example, the reflection data stream may be obtained from the server, a database and/or an intermediary device. Operational flow700continues to operation706where the types referenced in the data stream table are obtained. In general, identifications associated with the data stream reference table are matched to a type. Operational flow700continues to decision operation708where it is determined whether the data stream reference table includes unknown types. For example, a type may be set to null indicating that a type that exists on the server does not exist on the client.

In one aspect, operational flow700continues to operation710where the unknown type is reconciled. The unknown type may be reconciled at operation710or the unknown type may be reconciled at some other point in operational flow700such as operation732. If one of the types does not exist on the client, options may exist. For example, the unknown type may be treated as a string or the unknown type may be ignored. In some cases, a value may be converted to a string to be utilized by a data stream.

Operational flow700continues to operation710where the type is built. In one aspect, elements of the reflection data stream are sent to a class context module where the type is built. At decision operation712, it is determined whether property data (and/or sub-property data) exists that is associated with the type. Where property data does not exist, operational flow700continues to decision operation718as set forth below. Where property data does exist, properties and fields are built as indicated by operation714. In one aspect, elements of the reflection data stream are sent to a property context module where the properties are built. At operation716, an identifier is added to a table for reference during an initialization operation.

Operational flow700continues to decision operation718where it is determined whether attribute data exists that is associated with the type, properties and/or sub-properties. Where attribute data does not exist, operational flow700continues to decision operation724as more fully set forth below. Where attribute data does exist, attributes are built as indicated by operation720. In one aspect, elements of the reflection data stream are sent to an attribute context module where the attributes are built.

Operational flow700continues to decision operation722where it is determined whether to add methods. Where methods are not to be added, operational flow700continues to decision operation726as more fully set forth below. Where methods are to be added, operational flow700continues to operation724where the methods are generated. The methods may include get and set methods, initialization methods, and/or any other methods for providing real assembly features.

At decision operation726, it is determined whether another type exists. When another type exists, operational flow700loops back to decision operation708. Where another type does not exist, operational flow700continues to end operation728. For example, the proxy assembly may be used in conjunction with a web page designer. The web page designer may require type information in the control assembly so it can be displayed in a property grid to allow a user to edit the known properties of the controls. The proxy assembly allows the property grid to support any kind of control, rather than having to build information into the web page designer about a known set of controls. As another example, proxy assemblies may provide features to autocomplete engines such as MICROSOFT INTELLISENSE from MICROSOFT CORPORATION, headquartered in Redmond, Wash. In such an example, proxy assemblies may facilitate the generation of files that drive an autocomplete engine. In another aspect, the proxy assembly may be analogized to a “shell” of a real assembly. The proxy assembly may include proxy types, properties, fields, values and attributes associated with the real assembly without requiring the code of the real assembly. The proxy assembly may be associated with any program, application and/or routine to provide real assembly features without requiring the code of the real assembly.

As is set forth herein a proxy assembly provides dynamic functionality for a client computer without requiring the real assembly to be installed on the client. In this manner, aspects of the proxy assembly may circumvent licensing issues where the real assemblies are licensed to be installed on the server.

Illustrative Operating Environment

Referring toFIG. 1, an exemplary system for implementing the invention includes a computing device, such as computing device100. In a basic configuration, computing device100typically includes at least one processing unit102and system memory104. Depending on the exact configuration and type of computing device, system memory104may be volatile (such as RAM), non-volatile (such as ROM, flash memory, and the like) or some combination of the two. System memory104typically includes operating system105, one or more applications106, and may include program data107. In one embodiment, applications106further include application120for proxy service. This basic configuration is illustrated inFIG. 1by those components within dashed line108.

FIG. 2illustrates a mobile computing device200that may be used in one exemplary embodiment of the present invention. With reference toFIG. 2, one exemplary system for implementing the invention includes a mobile computing device, such as mobile computing device200. The mobile computing device200has processor260, memory262, display228, and keypad232. Memory262generally includes both volatile memory (e.g., RAM) and non-volatile memory (e.g., ROM, Flash Memory, or the like). Mobile computing device200includes operating system264, which is resident in memory262and executes on processor260. Keypad232may be a push button numeric dialing pad (such as on a typical telephone), or a multi-key keyboard (such as a conventional keyboard). Display228may be a liquid crystal display, or any other type of display commonly used in mobile computing devices. Display228may be touch-sensitive, and would then also act as an input device.

One or more application programs266are loaded into memory262and run on operating system264. Examples of application programs include phone dialer programs, e-mail programs, scheduling programs, PIM (personal information management) programs, word processing programs, spreadsheet programs, Internet browser programs, and so forth. Mobile computing device200also includes non-volatile storage268within memory262. Non-volatile storage268may be used to store persistent information which should not be lost if mobile computing device200is powered down. Applications266may use and store information in storage268, such as e-mail or other messages used by an e-mail application, contact information used by a PIM, appointment information used by a scheduling program, documents used by a word processing application, and the like. In one embodiment, applications266further include application280for proxy service.

Mobile computing device200has power supply270, which may be implemented as one or more batteries. Power supply270might further include an external power source, such as an AC adapter or a powered docking cradle that supplements or recharges the batteries.

Mobile computing device200is shown with two types of external notification mechanisms: LED240and audio interface274. These devices may be directly coupled to power supply270so that when activated, they remain on for a duration dictated by the notification mechanism even though processor260and other components might shut down to conserve battery power. LED240may be programmed to remain on indefinitely until the user takes action to indicate the powered-on status of the device. Audio interface274is used to provide audible signals to and receive audible signals from the user. For example, audio interface274may be coupled to a speaker for providing audible output and to a microphone for receiving audible input, such as to facilitate a telephone conversation.

Mobile computing device200also includes radio interface layer272that performs the function of transmitting and receiving communications, such as radio frequency communications. Radio interface layer272facilitates wireless connectivity between mobile computing device200and the outside world, via a communications carrier or service provider. Transmissions to and from radio interface layer272are conducted under control of operating system264. In other words, communications received by radio interface layer272may be disseminated to application programs266via operating system264, and vice versa.

Although the invention has been described in language that is specific to structural features and/or methodological steps, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or steps described. Rather, the specific features and steps are disclosed as forms of implementing the claimed invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.