Agents of types interfacing

FIELD: physics; computer facilities.

SUBSTANCE: offered invention concerns ways and systems for transformation of object of one type in object of other type. Transformation can be carried out in an augmented agent of serialisation which carries out serialisation, deserialisation and transformation of objects of various types. Changes during performance are imported to operation of an agent of serialisation by means of one or more procedures of expansion which realise required configuring for specific needs or expansion, thus not demanding replacements of other available procedures. On the basis of the information on the type, identified for initial object, object will converse to the intermediate representation which supposes change during performance, including change of names of object, types of object and object data. The intermediate representation of initial object change according to procedures of expansion which make changes to operation of a resort of serialisation during performance, and the intermediate representation will converse to target object or type.

EFFECT: possibility of change or configuring for specific needs of operation of transformation process to performance time.

35 cl, 7 dwg

 

I. the technical Field to which the invention relates

The present invention relates to serialize objects. More specifically, the present invention relates to methods, systems and computer program products for converting an object of one type to objects of another type by extension procedures that modify the tool serialization at runtime without the need to replace other existing procedures, tools serialization.

II. Prior art

Generally speaking, serialization is the conversion of individual objects “in memory” (the type of the object, the bytes of which are contained in the memory and which is used when sending sequences of bytes between independent processes) or count (nested) objects in memory in a linear sequence of bytes suitable for transmission to a remote location, save to disk, etc. on the Contrary, the deserialization takes a sequence of bytes and creates corresponding individual objects “in memory” or a graph of objects in memory. The result of the joint action serialization and deserialization is the making of an exact copy of the original object.

Usually serialization code is a complete implementation (software representation of the object and methods of interaction with him) without configuration options for specific needs, except that by replacing the entire implementation. Due to the lack of expansion options and configuration for specific needs for the market, including developers and other stakeholders, offers inflexible means of serialization. During the whole implementation direct implementation of incremental improvements and configuration for specific needs, designed to solve a specific problem, often impossible, and this may require an uncomfortable synthetic methods, or certain desired operations simply cannot be performed. If the configuration for specific needs should be carried out in any case, the standard procedures that implement the requested operation is typically inaccessible to the developer, and therefore, they have to re-implement that significantly (and often excessive) increases the volume of works on development of the required configuration for your specific needs. As a result, new functionality can be added to the serialization code only developers serialization code that gives end users the possibility of developing their own enhancements and improvements to existing functionality.

Although the purpose of serialization and deserialization is often creating technoscope object, in some circumstances, may require conversion types, names, and data objects at run time. In accordance with the foregoing, serialization and deserialization, for example, can be used when an object is passed to a remote location. In this remote location can be expected for certain types of object, the object data and object names that differ from the types of data and names of the original object. Traditional serialization code can be written to perform transformations of objects, however, such transformation cannot be added at runtime, and they are the same for all users, thereby ignored the likelihood that different users may have different needs. Although a given conversion can be critical to a particular user at a particular time, the aggregate significance of this transformation may be irrelevant to users in General, and hence it will never be developed.

For traditional serialization code is also characterized by a weak flexibility in terms of identification of objects to be converted, or perform transformations on the data contained in the object. Accordingly requires the methods, systems and computer program products for converting the of bjectiv one type to objects of another type on the basis of specialized (specific needs) procedures for making changes to serialization and deserialization at run time without having to re-implement standard procedures.

The invention

The present invention relates to methods, systems and computer program products for converting object of the source type to the target type and allows you to change or be configured to the specific needs of the work process transformation at run time. In accordance with an illustrative variants of implementation of the present invention, which are described in more detail below, extensible tool serialization performs serialization, deserialization and transformation of objects of different types. In the tool serialization changes during execution by one or more extension procedures that implement the required extension or configuration for specific needs. These procedures are extensions make changes to the tool serialization at runtime so that you are not replacing other existing procedures.

In one illustrative embodiment, the type information to identify the original object is passed by means of serialization for processing. Based on this information about the type of the source object is converted into an intermediate representation, which cannot be changed at run time, including changes to object names, object types, and object data. Prom is mediate the representation of the source object is changed in accordance with one or more extension procedures, that make changes to the tool serialization at runtime, and the intermediate representation is converted into the target target object type.

The intermediate representation of the source object may include an object name, object type, object data, each of these properties can be modified through the extension procedures. The intermediate representation can also be modified by one or more standard procedures, tools serialization. Modifying the intermediate representation can be performed based on a specific template type information, data objects in the source object, metadata, or a combination of the above.

When the source object is the object in memory, the tool performs serialization serialization of the source object with the purpose of formation of the target object. The target object may be formatted according to the extensible markup language (XML) or other format suitable for submission to a serialized object. Similarly, when the target object is “in memory”means serialization deserializes the source object for the formation of the target object. Create an instance of the target object and the filling can be performed as part of the deserialization process. When some who were circumstances as the original object, and the target object can be the object of “in memory” or both can be serialized objects, for example, when the tool serialization converts the object. To reduce the requirement to buffer the changes in the intermediate representation may be delayed until a conversion of this intermediate representation of the target object.

Additional characteristics and advantages of the invention are given below in the description and will partly be obvious from the description or may be learned in the practical application of the invention. The characteristics and advantages of the invention can be realized and obtained by means of the combinations specified in the accompanying claims. These and other features of the present invention will become more fully understood from the following description and appended claims, or may be learned through practical application of the present invention in accordance with the following.

List of figures

For a description of the method, which can be obtained from the above-mentioned and other advantages and features of the present invention, a more detailed description of the invention set forth above in brief, made with reference to specific variations in its implementation, which is illustrated in the accompanying drawings. Meaning umava, these drawings illustrate only typical embodiments of the invention and therefore should not be construed as limiting its scope, the invention will be described and explained with additional specific details and detail using the accompanying drawings, in which:

Fig. 1 is an illustrative module serialization and infrastructure (basic set of components that are incorporated in the system) serialization according to the present invention;

Fig. 2-4 - transformations of objects in the context of illustrative serialization, deserialization, and conveyors type conversion;

Fig. 5A-5B is illustrative of the steps and stages of the ways to implement serialization, deserialization, and transform objects according to the present invention;

Fig. 6 is an illustrative system that provides a suitable operating environment for the present invention.

A detailed description of the preferred embodiments

The present invention comprises methods, systems and computer program products for converting objects from the source type to the target type and allows you to change or be configured for the specific needs of the work process transformation at run time. Embodiments of the present invention can contain one or Bo is its special purpose computers and/or one or more General purpose computers, includes various hardware, which is described in more detail below with reference to Fig. 6.

In Fig. 1 depicts an illustrative module serialization and infrastructure 100 serialization (also known as a means of serialization) in accordance with the present invention. For instance 110 of the object module 100 serialization creates the appropriate serialized object 150 extensible markup language (XML). Similarly for object 160 XML module 100 serialization creates the appropriate deserialized instance 170 object. It should be noted that in the application materials, the term “serialization” is used as a generic term for serialization (for example, conversion of individual objects “in memory” or a graph of objects in memory in a linear sequence of bytes suitable for transmission to a remote location, save to disk, and the like), deserialize (creation of a linear sequence of bytes corresponding to the individual objects “in memory” or an object graph in memory”), conversion (converting from one object to another), etc., for example, This applies to the case under review, where the module 100 serialization performs serialization, deserialization and convert various types of objects.

The module 100 serialization includes one or more modules 120 reflection, and one the or more modules 130 conversion and one or more modules 140 formation. In this illustrative embodiment, the module 100 serialization converts the received instance of the object 110 in-memory object 150 XML, suitable for transmission to a remote location, and converts the received instance 160 XML object instance 170 object “in memory”. Of course, in-memory and XML are just examples of the types of objects that can be created or received by the module 100 serialization. Each of the modules from the module serialization modules 120 reflection, modules 130 conversion and modules 140 formation) can be replaced during run-configured for specific needs serialization, deserialization, or conversion.

The modules 120 reflections are responsible for identifying type information for a received instance of the object 110 and the enacted object 160 XML. The type information may include stored or received metadata associated with the managed types in the managed code environment. Alternatively, the type information may come in modules 120 reflections from various sources, including the automatic generation at compile time, the manual generation information on the standard types, etc.

The modules 130 conversion perform conversion between objects of different types. Illustrative conversion processes are described in more detail below what about the reference to Fig. 2-4. Conversion between different objects may have any degree of complexity and include the formation of intermediate objects. Part of this complexity may include the conversion based on the data in the object and template types associated with the object. For example, what conversions are performed may depend on certain types of objects or names of types, of the existence of certain named or typed property type, the existence of properties with certain attached metadata, name of the object associated with the object, and so the Conversion may be delayed until the formation of the target object in order to reduce the requirements or to avoid buffering, which, otherwise, might be part of a transformation of one object into another.

The modules 140 formation are responsible for the formation of the target object that is created by the module 100 serialization. In the case of the object 150 XML module 140 formation creates this object, it generates the appropriate XML representation for this object, and can write the object to the stream. In the case of instance 170 object module 140 formation creates an instance of an object and fills it.

According to the above, the module 100 serialization known as a means of serialization. As shown in Fig. 1, the tool serialization scampone the ANO from multiple ordered sets of modules. Together, these modules are responsible for all operations. A separate module is known as a means of pairing types, as described in more detail below, the modules perform the conversion from one type to another (or to match different types). The tool mating types, you can convert types and instances at runtime and/or to track information about serializable, deserialization or transform the object. With reference to Fig. 2-4, an ordered set of mating types is known as a pipeline pair types and in General corresponds to an ordered set of modules 130 conversion. For each of the running tool serialization operations can exist separate conveyor pairing types. There is a pipeline for serialization (for example, in Fig. 2), deserialize (for example, in Fig. 3), transformation (for example, in Fig. 4), a copy of the object, etc. Before a separate description of each of Figs. 2-4 below presents information, in General applicable to all three drawings.

For illustrative conveyors shown in Fig. 2-4, the code (one or more modules), which is responsible for serialization, deserialization and the transformation of objects is implemented as a number of predefined tools pairing types. These modules are placed in the appropriate conveyor is used at run time. (Educated dotted lines the squares in Fig. 1 are intended to represent modules pairing types available for use in various conveyors mating types). A large part of the open application programming interface (API) for illustrative tools serialization in Fig. 1 is a packer (a software tool to generate a wrapper for standardization external references) for this pre-defined set of conveyors. This shows how the tool serialization provides the possibility of expanding - tool serialization is a simple set of abstract conveyors. The actual implementation specific logic operations implemented in plug-ins that can be replaced at any time.

For illustrative conveyors pairing types, is shown in Fig. 2-4 setting the tool mating types can convert one of the three types of objects: the object of the original type, intermediate type, and the object of the target type. In Fig. 4 the object of the original type is a managed code object, the target object type represents an XML object based on the standard Infoset consortium the world wide web (W3C). The intermediate object type or intermediate representation shown in all three figures - this design means serialization and as described in more detail below, represents the point of expansion. The intermediate representation is a mutable object, based on the changing type. As such, the variable type is used to determine the behavior and store typed data, with a mutable object is used to store typed data and the impact on the stored data in accordance with the behavior defined for this type.

In Fig. 2 shows an illustrative tool 200 mating types intended for serialization of the original object 240 “memory” of the original type or format 210. (Used in the description and the claims, the term “type” should be interpreted broadly to cover any types or formats of objects.) Using the standard procedure 250, source object 240 is converted into an intermediate representation A having an intermediate type or format 220. As will be described in more detail below, this intermediate representation is volatile, and allows you to modify the types of objects and data objects. However, the intermediate format 220 and the source format 210 can be the same, to be closely related, differ to some extent, be completely different and so on

Specialized procedure 260 expansion converts the tick view A original object 240 in the intermediate representation 260V. This conversion may involve changing object types, object names, object data, etc. Specialized procedure 260 expansion is the expansion means serialization at runtime in General and conveyor 200 mating types in particular. It should be noted that the use of specialized procedures 260 expansion does not require re-implementing standard procedures 250, which is usually the case with traditional implementations of serialization.

Standard procedure 270 converts the intermediate representation 260V in the target object of the target type or format 230. The target object 280 is suitable for transmission to a remote location, save to disk, etc. Respectively the target format 230 of the target object 280 includes a wide range of object types. Here, as in other parts of the description, type, format and presentation of the object are understood in the broad sense of the terms, which include the type and format of the object as a whole and the type, size, names, and data that may be contained in the object.

Fig. 3 shows an illustrative tool 300 pair types, designed to deserialize an object 340 source type or format 330. Similarly to the above Fig. 2 standard procedure 350 converts the original object 340 in the intermediate representation 360 ° with sub is full-time type or format 320. Specialized procedure 360 converts the intermediate representation 360 ° in the intermediate representation V. It should be noted that an intermediate type 320 represents one or more intermediate types. Accordingly, the intermediate representation 360 ° and the intermediate representation V can be of different types, but nevertheless referred to as an intermediate type, especially in relation to the original type 330 and the target type or format 310.

Standard procedure 370 converts the intermediate representation V in the target 380 target type 310. Because the pipeline pairing types designed for deserialization, the target object is an object “in memory”, for which an instance is created and filled. As will be described in more detail below, the conveyor 300 pair of types associated with the code to create and populate instances of objects. This code can be called by the factory or by means of recording copies or writes the factory, and it is in the General case corresponds to the modules 140 a of Fig. 1.

Fig. 4 shows an illustrative conveyor 400 mating types, designed to transform the original object 440 in the target object 480. A separate pair of types presented in Fig. 4, is able to convert one of the three different types or formats of objects: objects 410 to manage the th code/formatted in accordance with the CLR, objects 420 intermediate/formatted in accordance with Flex and objects 430 Infoset/ formatted in accordance with XML. CLR denotes the common language runtime (Common Language Runtime) and is part of the runtime software, managed Microsoft.NET®. Among other things, the advantages of the CLR include cross-language integration, inter-language exception handling, etc. Compilers programming languages form the metadata to describe the types, members, and links. The metadata is stored with the code in mashinostroenia executable CLR. Of course, the CLR is just one example of the type of managed code. As follows from Fig. 4, both objects can be objects “in memory” (for example, objects that are formatted in accordance with the CLR) or, alternatively, both of the object can be serialized objects (such as objects, formatted in accordance with the Infoset). In other words, both the source and the target object can be of the same type.

Objects CLR 410 are instances of the CLR types that contain a combination of data and behavior, although only data essential for the purposes of serialization. As noted above, the object or view 430 Infoset formatted according to the W3C standard for tree-like structure, composed of a predefined set of data nodes with a certain semantics. Object 420 Flex - structures of the first component, in the tool serialization and represents an extension point to the object performing the serialization.

The Flex object is a mutable object, which is based on the changing type. Variable type is known as type Flex. In the illustrative conveyor 400 pairing of the types shown in Fig. 4, the type Flex has the same function as the corresponding CLR type: definition, behavior, and data storage type. Similarly, the Flex object has the same function as the CLR object: storage typed data and the impact of these data through behavior defined for this type. The reason of using Flex and Flex object is that the CLR types are immutable.

For illustrative conveyor pairing of the types shown in Fig. 4, certain restrictions are imposed on the types that can be serialized to stimulate simplicity and extensibility. These restrictions reduce the number of different patterns and permutations that the object performing the serialization must recognize for serialization and deserialization of the specified type. To this end, the tool serialization only understands how to serialize objects CLR types that are consistent with what is known as the base model. Types that are consistent with the base model must either openly expose their data as properties (or the field), or implement a specific interface (which defines explicit methods for reading and writing). In addition, these types must provide a public default constructor (the function is a class member with the same name as the class itself that takes no arguments and creates and initializes the object of this class). For types that are not consistent with the base model, you cannot serialize.

Types of Flex and Flex objects are used to change the shape (members, interfaces, and so on) of the specified object, the CLR to meet the basic model. For a given object, the CLR can be constructed type Flex, which provides a set of information about the members and types that is different from the type of the instance of the CLR. Can be instantiated based on the type Flex Flex object, which delegates some calls to the CLR object. The Flex object can also optionally perform data conversion object the CLR or pre-delegation, or after it. In the CLR object data can be provided in a variety of ways, including the way that is consistent with the base model. Accordingly, the tool mating types can start with an object type that is not consistent with the base model, and create the object type that is consistent with the base model.

The tool mating types can convert CLR objects, about the projects Flex and Infoset representation in different ways. Any given tool mating types has the input type on which it operates, and the output type, which it creates or generates. This output type is passed to the next tool mating types in the pipeline. For illustrative conveyor 400 pair types the following transformation:

Input typeOutput typeDescription
CLRCLRConverts a CLR object in the new object CLR
CLRFlexConverts a CLR object in a Flex object
CLRInfosetConverts a CLR object in the object Infoset
FlexFlexConverts the Flex object in the new object Flex
FlexCLRConverts the Flex object in the CLR object
FlexInfosetConverts the Flex object in the object Infoset
Infoset InfosetConverts the object Infoset in the new object Infoset
InfosetFlexConverts the object Infoset in the Flex object
InfosetCLRConverts the object Infoset in the CLR object

Various classifications of funds mating types have been developed to allow basic operations means of serialization. (Although Fig. 2 and 3 refer to General types, below are the links to these shapes are made with a specific type illustrated in Fig. 4, to provide further context).

1. Serialization converts the CLR object in the object or the representation of the Infoset. To perform this operation is provided with conveyor means mating types (for example, as shown in Fig. 2), which includes the tool mating types to convert CLR Flex (for example, the standard procedure 250), any amount mating types to convert Flex in Flex and a means of coupling types to convert a Flex Infoset (for example, the standard procedure 270).

2. Deserialization converts the representation of the Infoset in the CLR object. To perform this operation is provided with conveyor means mating types (for example, as shown in Fig. 3), which includes environments the creation of mating types to convert Infoset in Flex (for example, standard procedure 350), any amount mating types to convert Flex in Flex and a means of coupling types to convert Flex in the CLR (for example, the standard procedure 370).

3. A copy of the object is used to create detailed (playback of all structure elements) copies of the CLR object. To perform this operation is provided with conveyor means mating types, which includes the tool mating types to convert CLR CLR.

4. Conversion of the object (Fig. 4) creates a detailed copy (target 480) from an object or objects, the CLR (the source object 440), but carried out in an optional order, convert (standard or specialized procedure 460) in relation to instance data (intermediate representations A and 460V). To perform this operation is provided with conveyor means mating types, which includes the tool mating types to convert CLR Flex (standard or specialized procedure 450), optionally one or more means of mating types to convert Flex in Flex (standard or specialized procedure 460)that perform the conversion, and the tool mating types to convert a Flex CLR (standard or specialized procedure 470).

5. The Infoset transformation creates a copy of the volume of the KTA Infoset and optionally, converts it. Similarly, a copy of the object to perform this operation is provided with conveyor means mating types, which includes the tool mating types for conversion in Infoset Infoset.

The last three points are noteworthy because of the way in which they are implemented. While other implementations bufferinput object or data Infoset, embodiments of the present invention can postpone conversion in order to reduce the requirements for buffering or avoid it. As a result, the performance and management of resources significantly improved.

To support the above operations, the tool serialization provides the main or basic connectivity tools, types that perform the appropriate conversion. In Fig. 4 any standard or specialized procedures, 450, 460 and 470 can be an important tool mating types or specialized substitution. Using an extensible mechanism configuration, an appropriate means of mating types are identified and loaded into the conveyor at run time. The tool serialization uses these main conveyors to perform the required operations. However, the main means of coupling types can be replaced at any time since adsto serialization uses the representation of an abstract means of pairing types, and not the specific implementation of the main means of pairing types. In one illustrative embodiment, the conveyor simply contains a list of pair types for this pipeline - changes list changes the pipeline. For this illustrative variant implementation, once for an object made a call to a specific means of pairing types, other means of coupling types for this object is not called.

It should be noted that for illustrative variant implementation CLR Flex 410 420 Infoset and 430 correspond to the original format 210, intermediate 220 format and target format 230 for serialization, as shown in Fig. 2, and correspond to the target type 310, intermediate type 320 and the source type 330 for deserialization, as shown in Fig. 3. The Flex object is an intermediate format between the CLR and the Infoset. In this illustrative embodiment, the tool mating types is not allowed to perform the conversion directly from the CLR to the Infoset, and Vice versa. Among other things, this helps to simplify the illustrative tool serialization. Although the basic functionality or operation means serialization defines the main means of coupling types can be numerous additional functionality (for example, support existing programming models), projection is controlled by the developers. Main means of coupling types can be designed to implement these additional features, but instead there are several main means of mating types to convert Flex in Flex, which serve for this purpose. This approach ensures simplicity and extensibility of the main means of pairing types. As a result, developers can modify the standard functionality and to provide their own new functionality.

For this illustrative case for consider the serialization process for the CLR type name of Person (Personality) and with two properties: FirstName (Name) and LastName (Surname). For serialization (see Fig. 2) an instance of this type requires the pipeline with the main means of mating types to convert CLR Flex and Flex in the Infoset. The tool serialization takes the instance of the Person on the tool mating types to convert CLR Flex. This tool mating types returns a new instance of the object, Flex, based on the Person instance to which it performs the delegation. Then the Flex object is supplied to the tool mating types to convert Flex in the Infoset.

The tool mating types to convert a Flex Infoset is responsible for converting a Flex object in the representation of the Infoset. Before performing this transformation, the main environments the creation of mating types to convert a Flex Infoset defines how according to which you want to display the structure of the Flex object in the Infoset. Implementation of the main means of mating types in this example uses a schema language (logical structure in the database, and determines the display using logical structures defined in this language. Because the mating types are interchangeable, you can enter a new rendering engine, including support for the new schema language, which is another extension point in the tool serialization. After completion of the process of displaying a Flex object is converted to a representation of the Infoset, which is written to the stream.

As mentioned briefly above, the means of coupling types in the tool serialization connected with recording factories. Recording factories are responsible for creating a resource that can write data. Although this resource can write data to any target object, the most common destinations are the data streams (after serialization for transportation) and CLR objects (after deserialization). The main recording factory in the context of this illustrative variant implementation returns the resource that writes to user-provided data stream. Resource created by this factory, can write to the stream in any desired format. As such, it is not Pref is Zan to the XML serialization format, that makes recording a factory remanufactured and introduces another extensibility point in the tool serialization.

Deserialization (see, for example, Fig. 3) representation of the Infoset in the context of this illustrative variant implementation uses a conveyor, which includes a main means of mating types to convert Infoset in Flex and Flex in the CLR. The tool serialization takes the user-supplied stream representing the source Infoset type, and the CLR type (Person), deserialization which is the first tool pair types (Infoset in Flex). This tool mating types creates a new instance of the Flex object based on the type of Person who performs the delegation stream. The resulting Flex object is supplied to the tool mating types to convert Flex in the CLR, which fills a Person instance data of the object Flex (Flex object is actually in the thread, because the Flex object is delegating). As in the case of serialization, the conveyor deserialization is responsible for creating an instance of the CLR type that is being deserialized.

In addition to serialization and deserialization, you may need to convert the type of Person. In accordance with the foregoing, the shape of the Person object contains two properties: FirstName and LastName. Suppose, for example, one application that uses this definition wide-angle the Person, interacts with another application using a different definition of Person (for example, a Person with one property FullName (Name)). Although one option is to order both applications to use the same type of Person, this may not always be possible (both applications can be written).

According to the described illustrative variant implementation, you can create a tool mating types, which converts the form of an instance of Person in the same application into a form that is expected in another application. To perform this conversion (see Fig. 2) you must create a new tool mating types to convert Flex in Flex (for example, a specialized procedure 260 extension) and place it in the pipeline serialization after the main means of mating types to convert CLR Flex (for example, standard procedures 250). During the serialization process on the tool mating types is Flex object that implements the delegate to the Person object. The tool mating types creates a new type Flex the other forms (one property FullName). On the basis of this type Flex creates a new object that concatenates the FirstName and LastName properties of the original object Flex (which also represents an instance of Person). This Flex object is served in the main tool mating types to convert a Flex Infoset (for example, the conventional procedure 270), which serializes a single property instead of two. It should be noted that actually mentioned the clutch can not be performed until such time as the tool mating types to convert a Flex Infoset will not prompt for the value of the new property FullName. Accordingly, the conversion is delayed to create Infoset object or the target object.

Accordingly, the tool mating types, corresponding to the present invention can provide an extensible architecture for transformations between systems and types, including support for plug type conversion and data support for mutable types and objects, support for pluggable type systems, schemes, support for pluggable data formats, etc.

The present invention also can be described in terms of methods containing functional steps and non-functional actions. Below is a description of the actions and steps that can be implemented in the practical application of the present invention. Usually the functional stages describe the invention in terms of the achieved results, while non-functional steps describe more specific actions to achieve a specific result. Although the functional steps and non-functional actions can be described or claimed in a particular order, does not imply that the crust is ASEE the invention necessarily limited to the specific order or combination of actions and/or steps.

In Fig. 5A-5B shows illustrative steps and stages for ways to serialize and deserialize objects according to the present invention, which may include action (512) receiving the source object, the source type to be processed by means of serialization at runtime. Step (520) identification type information in relation to the original object may include action (522) receiving type information. Type information can be provided as metadata associated with managed code. Step (530) transformation of the original object into an intermediate representation based on the information about the original type may include the steps of forming (not shown) intermediate representation based on the type information and call (534) one or more standard procedures for modifying the intermediate representation. Mentioned one or more extension procedures make changes to the tool serialization at runtime.

It should be noted that the intermediate representation may include the object name, object type and/or object data. Although not shown, the stage (540) modifying the intermediate representation may additionally include the steps of the call (not shown) one or more specialized procedures extension and challenge (not shown) one or more with Antartic procedures for modifying the intermediate representation. Stage (540) changes may further include the step (542) change the name, type and/or object data. Step (550) delaying changes may include action (552) specify how to modify the intermediate representation without actually changing the intermediate representation. Procrastinating may contribute to reduced requirements for buffering and processing, which would otherwise occur when modifying the intermediate representation.

Step (560) converting the intermediate representation of the source object to the target object of the target type or format may include the following steps. In the case of serialization (563) this step may include the step (565) create or form the final object. In one of the above-described illustrative embodiment, the target object is formatted in accordance with XML for transport. Therefore, the creation or formation (565) of the target object may include forming a corresponding XML representation and writes the target object in the stream. Alternatively, the target object may be formatted for storage on disk or in accordance with any other format suitable for presentation serialized original object. In the case of deserialization (564) this step can include on istia create (566) instance of the target object and fill it (568). During phase (560) conversion of specialized and standard procedures are invoked for any pending changes that specify how to implement change, but the changes themselves are not actually executed.

Options for implementation within the scope of the present invention also include computer-readable media to store mashinostryenia commands or data structures. Such machine-readable media can be any available media that the computer General or special purpose can access. As an example, but not limitation, such computer-readable media may be a RAM, ROM, electrically erasable programmable ROM (EEPROM), a ROM on the CD-ROM (CD-ROM), or other media in the form of optical disk media as a magnetic disk or other magnetic storage devices, or any other medium that can be used to store the necessary program code means in the form mashinostryenia commands or data structures and which the General-purpose computer or special purpose can access. When the information is sent or transmitted over a network or another communications connection (either wired, wireless, or a combination of wired and the devil is Romagnolo) on the computer, the computer adequately treats the connection as a computer-readable medium. Thus, any such connection also applies to machine-readable media. Combinations of these media and compounds also fall within the range of machine-readable media. Mashinostroenie commands include, for example, the commands and data that require a General-purpose computer, special purpose computer or processing unit of special purpose to perform a specific function or set of functions.

Fig. 6 and the following description are intended to provide a brief General description of a suitable computing environment in which it is possible to implement the present invention. Although this is not a strict requirement, the invention will be described in the General context mashinostryenia commands, such as program modules, executed by computers in network environments. In the General case, the software modules include procedures, programs, objects, components, data structures, etc. that perform particular tasks or implement certain abstract data types. Mashinostroenie commands associated data structures, and program modules represent examples of program code means for performing the steps disclosed here. Con is the specific sequence of such executable commands or associated data structures represents examples of corresponding acts for implementing the functions, described in these steps.

Specialists in the art will appreciate that the invention can be implemented in practice in network computing environments with many types of configurations of computer systems, including personal computers, handheld devices, multiprocessor systems, programmable consumer electronics or consumer electronics microprocessor-based, network personal computers, minicomputers, universal computers, and the like, the Invention can also be implemented in practice in distributed computing environments where tasks are performed local and remote data processing devices that are linked (either through a wired communication links, wireless communication links, or through a combination of wired and wireless communication lines) through the communication network. In a distributed computing environment, program modules can be placed on both local and remote storage devices.

According Fig. 6 illustrative system for implementing the invention includes a computing device for General purposes in the form of a conventional computer 620 containing the processor 621, system memory 622 and the system bus 623, which connects various system components including the system memory 622, the processor 621. The system bus may apply to any of the C multiple bus structures, including a memory bus or memory controller, a peripheral bus and a local bus using any of a variety of bus architectures. System memory 622 includes permanent memory (ROM) 624 and random access memory (RAM) 625. Basic system 626 input/output (BIOS)containing the basic procedures that help to transfer information between elements of the personal computer 620, for example, during startup, is stored in ROM 624.

The computer 620 may also include the drive 627 hard disk drives for reading from the magnetic hard disk 639 and write on it, the drive 628 magnetic disk to read from a removable magnetic disk 629 or write to it, and actuator 630 of the optical disk to read from a removable optical disk 631, such as CD-ROM or other optical media, or write to it. Drive 627 hard disk drive 628 magnetic disk and the actuator 630 optical drive connected to the system bus 623 through an interface 632 drive hard disk drives, interface 633 actuator of a magnetic disk and interface 634 optical drive, respectively. The drives and their corresponding machine-readable media provide nonvolatile storage device of the computer 620 to store mashinostryenia instructions, data structures, program modules and other data. Although OPI the data, the preferred embodiment uses a magnetic hard disk 639, removable magnetic disk 629 and removable optical disk 631, it is possible to use other types of computer-readable media, such as magnetic cassettes, flash memory cards, digital versatile disks, Bernoulli cartridges, RAM, ROM, etc.

Software code includes one or more software modules may be stored on the hard disk 639, magnetic disk 629, optical disk 631, in ROM 624 or RAM 625, including the operating system 635, one or more application programs, 636, other program modules 637 and data 638 programs. The user can enter commands and information into the personal computer 620 via the keyboard 640, pointing device 642 or other input devices (not shown), such as a microphone, joystick, game pad, satellite dish, scanner, etc. To connect these and other input devices to the processor 621 is commonly used interface 646 serial port connected to the system bus 623. Alternatively, the input devices can be connected through other interfaces such as a parallel port, game port or a universal serial bus (USB). Monitor 647 or a display device of another type is also connected to the system bus 623 via the interface, for example, the adapter 648. In addition to the monitor, personal computers typically include other PE is epherine output device (not shown), such as speakers or printers.

The computer 620 may operate in a networked environment using logical connections to one or more remote computers, such as remote computers a and 649b. Each of the remote computers a and 649b can represent another personal computer, a server, a router, a network PC, a peer device or other common network device, and typically includes many or all of the elements described in relation to a personal computer 620, although in Fig. 6 shows only storage device a and 650b and their associated application programs a and 636b. Logical connection shown in Fig. 6, include a local area network (LAN) 651 and a global network (HS) 652 listed here as examples and not limitations. Such networking environments are usually in computer networks scale office or enterprise intranets and the Internet.

When using a network environment LAN personal computer 620 is connected to the LAN 651 through a network interface 653. When using in a network environment HS personal computer 620 typically contains a modem 654 or other means of communication through HS 652, such as the Internet. Modem 654, which may be internal or external, is connected to the system bus 623 interface 646 p is consistent port. In a networked environment, program modules specified in relation to the computer 620, or some of them can be stored in a remote storage device. It should be understood that the illustrated network connections are of an illustrative character and that you can use other means of establishing communication lines through a global network 652.

The present invention can be implemented in other specific forms without departing from its essence or essential features. Describes the options for implementation in all respects should be considered only as illustrative, but not restrictive. Therefore, the scope of the invention defined by the attached claims and not the foregoing description. All changes carried out in the framework of the design and range of equivalents corresponding to present the claims are within the scope defined by the present claims.

1. The way to convert the source object, the source type to the target object of the target type in a computer system, comprising extensible means serialization adapted for serialization and deserialization of data objects of different types, this method allows you to make changes in the work of the extensible means serialization at runtime by one or more procedures to expand the rhenium without having to replace the entire implementation of the extensible means serialization moreover, the method comprises steps according to which
take the original object of the original type to handle run-time extensible serialization;
take type information for the source type of the source object;
based on the information about the type of form the intermediate representation of the source object, which is applicable to change at run time;
cause one or more extension procedures for modifying the intermediate representation of the source object, thereby contributing to changes in extensible means serialization at runtime;
based on the modified intermediate representation of the source object form target target object type,
however, changing the intermediate representation lay to until the intermediate representation is converted to the target, with the aim to avoid buffering when changing the intermediate representation.

2. The method according to claim 1, wherein the intermediate representation contains the type of the source object as a whole and for one or more objects contained in the original object, the object name, object type and object data.

3. The method according to claim 2, additionally containing action, according to which changing either the type of the object as a whole or for one or more objects contained in the source on which the target, the object name, object type and object data, or both.

4. The method according to claim 1, wherein modifying the intermediate representation of the source object based on a specific template from the type information.

5. The method according to claim 1, wherein modifying the intermediate representation of the source object based on the data objects in the source object.

6. The method according to claim 1, in which the extensible means serialization is part of a messaging system for distributed application that sends and receives one or more messages, the source object and the target object is present at least part of the message.

7. The method according to claim 1, in which the source object is an object in memory, with expandable tool serialization serializes the original object formation target object.

8. The method according to claim 1, in which the target object is an object "in memory", a copy of which is subject to creation and filling on the basis of the original object, while extensible tool serialization deserializes the original object formation target object.

9. The method according to claim 1, in which one or more extension procedures called for the purpose of modifying the intermediate representation, ask how to modify the intermediate representation is representation without actually changing the intermediate representation, so to modify the intermediate representation has been postponed until the formation of the target to reduce the buffering requirements.

10. Machine-readable media designed for a computer system, comprising extensible means serialization adapted for serialization and deserialization of data objects of different types, and contains Mashinostroenie commands that implement a method of converting a source object, the source type to the target object of the target type, this method allows you to make changes in the work of the extensible means serialization at runtime by one or more extension procedures without having to replace the entire implementation of the extensible means serialization, and the method comprises steps according to which
take the original object of the original type to handle run-time extensible serialization;
take type information for the source type of the source object;
based on the information about the type of form the intermediate representation of the source object, which is applicable to change at run time;
cause one or more extension procedures for modifying the intermediate representation of the source object, thereby making changes in the work of the extensible means to be serialized at the time you is filling up;
based on the modified intermediate representation of the source object form target target object type,
however, changing the intermediate representation lay to until the intermediate representation is converted to the target, with the aim to avoid buffering when changing the intermediate representation.

11. Machine-readable medium of claim 10, in which the intermediate representation contains the type of the source object as a whole and for one or more objects contained in the original object, the object name, object type and object data.

12. Machine-readable medium according to claim 11, in which the method further comprises the step according to which the change or the type of the object as a whole or for one or more objects contained in the original object, the object name, object type and object data, or both.

13. Machine-readable medium of claim 10, in which the intermediate representation of the source object is based on at least one of the specific pattern from the type information, metadata and data object in the source object.

14. Machine-readable medium of claim 10, in which if the source object is an object in memory, extensible tool serialization serializes the original object formation target object is a, and if the target object is an object "in memory", a copy of which is subject to creation and filling on the basis of the original object, extensible tool serialization deserializes the original object formation target object.

15. Machine-readable medium of claim 10, in which both the source object and the target object are objects "in memory".

16. Machine-readable medium of claim 10, in which one or more extension procedures called for the purpose of modifying the intermediate representation, ask how to modify the intermediate representation without actually changing the intermediate representation, so that the change in the intermediate representation has been postponed until the formation of the target to reduce the buffering requirements.

17. The way to convert the source object, the source type to the target object of the target type in a computer system, comprising extensible means serialization handles serialization and deserialization of data objects of different types, this method allows you to make changes in the work of the extensible means serialization at runtime by one or more extension procedures without requiring replacement of one or more other available procedures extensible means serialization in a way with the holding stages, which
identify the type information for the source object, the source type accepted for processing run-time extensible serialization;
based on the information about the type of transform the original object in the intermediate representation of the source object, which is applicable to change at run time;
modify the intermediate representation of the source object in accordance with one or more extension procedures, thereby contributing to changes in extensible means serialization at runtime;
transforming the intermediate representation of the source object to the target object of the target type,
however, changing the intermediate representation lay to until the intermediate representation is converted to the target, with the aim to avoid buffering when changing the intermediate representation.

18. The method according to 17, in which the intermediate representation contains at least one object name, object type and object data.

19. The method according to p, in which the step of modifying the intermediate representation of the source object in accordance with one or more extension procedures contains the stage at which change at least one of the object name, object type and object data.

20. The method according to 17, in which the change prom is mediate representation of the original object is based either on a specific template from the type information, or data objects in the source object, or both on that and the other.

21. The method according to 17, in which the source object is an object "in memory", and extensible tool serialization serializes the original object formation target object.

22. The method according to 17, in which the source object and the target object are objects "in memory".

23. Machine-readable media designed for a computer system, comprising extensible means serialization handles serialization and deserialization of data objects of different types, and contains Mashinostroenie commands that implement a method of converting a source object, the source type to the target object of the target type, this method allows you to make changes in the work of the extensible means serialization at runtime by one or more extension procedures without requiring replacement of one or more other available procedures extensible means serialization, and the method comprises the steps on which
identify the type information for the source object, the source type accepted for processing run-time extensible serialization;
based on the information about the type of transform the original object in the intermediate representation of the source object, which is applicable for the modify at run time;
modify the intermediate representation of the source object in accordance with one or more extension procedures, thereby contributing to changes in extensible means serialization at runtime;
transforming the intermediate representation of the source object to the target object of the target type,
however, changing the intermediate representation lay to until the intermediate representation is converted to the target, with the aim to avoid buffering when changing the intermediate representation.

24. Machine-readable medium according to item 23, in which the intermediate representation of the source object contains at least one object name, object type and object data.

25. Machine-readable medium according to item 23, in which the step of modifying the intermediate representation of the source object in accordance with one or more extension procedures contains the stage at which change at least one of the object name, object type and object data.

26. Machine-readable medium according to item 23, in which the intermediate representation of the source object is based either on a specific template from the type information, or data objects in the source object, or both on that and the other.

27. Machine-readable medium according to item 23, in which the target object is particularly the object in memory a copy of which is subject to creation and filling on the basis of the original object, while extensible tool serialization deserializes the original object formation target object.

28. Machine-readable medium according to item 23, in which the source object and the target object are objects "in memory".

29. Machine-readable media containing a computer program, which when executed implements an extensible tool serialization to convert one or more source objects to one or more source types in one or more target objects one or more of the target types, with the work of the extensible means serialization, you can make changes at run time without having to re-implement the existing parts of the extensible means serialization, and computer program contains Mashinostroenie commands in the form of software modules that contain
replaced at run time module reflection to be used for identifying type information for the source object, the source type accepted for processing run-time extensible serialization;
one or more replaceable during execution of the conversion modules for forming and modifying the intermediate representation of the source object is and the basis of the identified type information, these one or more replaceable during execution of the conversion modules contain one or more extension procedures, which make changes in the work of the extensible means serialization at runtime;
replaced at run time module arrangement to create the target object of the target type from the intermediate representation generated by the conversion module,
these one or more replaceable during execution of the conversion modules are adapted to delay one or more changes in the intermediate representation of the source object to convert the intermediate representation of the target object, in order to avoid buffering requirements associated with the execution of the abovementioned one or more changes in the intermediate representation.

30. Machine-readable media according to clause 29, in which the intermediate representation contains the object name, object type and data object for the original object and any objects contained in the source object.

31. Machine-readable media according to clause 29, which referred to one or more replaceable during execution of the conversion modules are adapted to modify at least one of the object name, object type and data object for the original object and any objects contained in the source volume is regarding subsection.

32. Machine-readable media on p, which referred to one or more replaceable during execution of the conversion modules are adapted to track information about the original object without modifying the intermediate representation.

33. Machine-readable media according to clause 29, which referred to one or more replaceable during execution of the conversion modules are adapted to modify the intermediate representation of the source object based on a specific template type information, or data objects in the source object, or both.

34. Machine-readable media according to clause 29, which replaced during the execution of the module formation is adapted to create the target object in the format of extensible markup language (XML).

35. Machine-readable media according to clause 29, which replaced during the execution of the module formation adapted to create an instance of the target object and populate it based on the intermediate representation.



 

Same patents:

FIELD: physics; communication.

SUBSTANCE: present invention relates to mobile terminals. The mobile terminal has a user interface, which is at least partially given by the user himself. This mobile terminal also has a unit for specifying the user interface, which is controlled by a programmed processor for selecting, in conjunction with the user, at least one trigger and action, which jointly make the rule; for automatic creation of a catalogue structure, comprising a set of accessible events in accordance with a hierarchical information model; for selecting, in conjunction with the user, at least one trigger value from the accessible set of events and for determining action, which will be executed by the mobile terminal in response to at least one trigger value.

EFFECT: increased efficiency when a user is operating the device.

24 cl, 9 dwg

FIELD: physics, computer technology.

SUBSTANCE: invention concerns computer technology. Data for insertion to the second document are selected in the first document. Selected data are stored in memory, such as clipboard. Together with selected data, related information or data is copied for presentation of any data types related to selected data to application performing insertion or to data user application. User application can respectively obtain name space and related resource, e.g. extensible style language transformation file, for transformation of selected data from first data type related to the first document to another data type for insertion of selected data to the second document with preservation of data structure and format applied in selected data before insertion in inserted data.

EFFECT: prevention of incompatibility of insertion.

33 cl, 6 dwg

FIELD: physics; computer technology.

SUBSTANCE: present invention pertains to computer technology. According to the invention, message is sent with a report of the event from the first program to the second program, so as to indicate that, a certain event has taken place in the first program. The message with the report of the event comprises a parameter, which serves to indicate that, that action is one of a group of possible actions. For this purpose, in the application, customised for editing XML documents, actions related to XML trigger off sending of a message with a report of the event. The action related to XML can either be related to XML movement action, or to XML insert action, or with XML deletion action. That way, a message with a report for a single event can be used indicating three different types of actions when editing an XML document.

EFFECT: provision for sending a message with a report of the event from one program to another.

26 cl, 6 dwg

FIELD: physics.

SUBSTANCE: invention pertains to computer technology, in particular to devices that provide for a single implementation of operations, which are common processing in the kernel mode as well as for processing in the user mode. For the given process procedure, access to the general purpose interface is reflected on implementation of the kernel mode for processing the kernel mode and on implementation of the user mode for processing the user mode. The reflection can take place during processing or it can be static. The general operation can provide for the processing procedure of the user mode with indirect access to the hardware adapter, for example, for transmission and receiving of information, without switching into the kernel mode. There can also be provision for implementation of the kernel mode for operations which are unique for processing the kernel mode, for example, determination of security parameters for compulsory use of the hardware adapter or initialisation and termination of a connection through the hardware adapter.

EFFECT: provision for a single implementation of operations relative the hardware adapter.

26 cl, 6 dwg

FIELD: technology for delivering notifications from several sources in accordance with user context.

SUBSTANCE: user context, which at least partially indicates current accessibility of user for incoming notifications, consists of condition, which may be true or false, and instructions, which should be followed when the condition is true. User contexts are declared by operation system and optional software applications (204). User contexts may be presented to the user for modification in accordance to user preferences (204). The user may also define rules, which dictate how to process notifications (204), containing mentioned elements, and may provide exceptions for instructions of user contexts.

EFFECT: the system harmonizes and orders delivery of notifications (206) from several sources; also, shared use representation of user context is provided, to determine proper processing for each notification.

6 cl, 10 dwg

FIELD: computer engineering, namely processors meant for operation in multitask mode and containing hardware for automatically switching context of tasks and procedures.

SUBSTANCE: in accordance to the method, for each new task or procedure free resources are allocated in circular buffer of general purpose registers for data being processed, and in circular stack for switching contexts for data which characterize predetermined location for contexts in external memory. When circular buffer of general purpose registers or circular context switching stack are overflowed, saved contexts at hardware level are fully automatically displaced into memory, without using software means. The data from circular context switching stack make it possible to organize contexts displaced into memory in form of connected list, and to restore saved contexts when necessary.

EFFECT: increased speed when switching context of tasks and procedures with lesser amount of used hardware resources.

21 cl, 5 dwg

FIELD: telecommunications.

SUBSTANCE: device contains a set of central processor units, which are assigned a common external up address in telecommunication network which allows packet data. IP messages, addressed to a network element, are received, and received IP messages which contain first messages are identified. First value is identified in first message and first message is transmitted to central processor unit on basis of identified first value, if identified first value is not equal to zero.

EFFECT: ensured load balancing for central processor when using several types of traffic.

3 cl, 3 dwg

FIELD: method and system for providing user interface information to client.

SUBSTANCE: in accordance to the invention, access system contains registration mechanism. Client environment for automatic processing of user interface receives registration information from the client and transmits user interface information after receipt. Server for automatic processing of user interface receives registration information from client environment for automatic processing of user interface and notifies processor of user interface about registration, and also receives user interface information from user interface processor. The server contains filtration device for filtering out information of no interest to client, and notification device for notifying the client about information which is of interest to the client.

EFFECT: ensured capacity for filtration and coordination of excessive and disorienting notifications.

2 cl, 11 dwg

FIELD: methods for automatic execution of a program, connected to data file, when data file and program being executed are positioned on different computer units.

SUBSTANCE: in methods, program being executed is accessed through graphic image of data file type, realized in the network, which includes client system and a set of server systems. Client system receives the scheme, which determines connection between the set of programs being executed and corresponding set of data file types. Graphic image of data files is displayed, information about selection of graphic image of data file is received from server system, on basis of it program to be executed is selected and executed.

EFFECT: increased productivity of system due to distributed execution of programs.

9 cl, 19 dwg, 3 tbl

FIELD: engineering of means for pausing execution of a stream until certain memory access occurs.

SUBSTANCE: in one variant of realization, processor contains a set of executive devices, capable of executing a set of streams. First stream includes a command, which determines the address being tracked. Logical pausing means pause execution of first stream, and monitor causes renewal of first flow as reaction to access of given address being tracked.

EFFECT: increased processor productiveness.

5 cl, 14 dwg

FIELD: computer engineering.

SUBSTANCE: present invention relates to a system and method of supporting several languages for an application. The system of several languages comprises a system for supporting several languages for an application. The system comprises a unit for generating resource data in the language of the application, a unit for processing resource data, so as to extract resource data from the generated data in the language of the system environment, in which the application is executed, and converting the extracted data into the language of the application, and a unit for controlling resource data, used in the application. The method describes the operation of the given system.

EFFECT: possibility of executing an application regardless of the language supported by the system environment.

20 cl, 15 dwg

FIELD: engines and pumps.

SUBSTANCE: invention can be used to protect software of the ICE control unit against unauthorised changing. Proposed method of developing software of the running ICE control unit consists in rewriting the software of the ICE control unit into external two-port RAM, restarting ICE, specifying the software data array including calibration tables and constants for ICE running under various operating conditions. The data made more specific is entered into aforesaid two-port external RAM. The development made, the improved software is written into ERPOM of the ICE control unit microcontroller. Note here that, prior to starting ICE, software is divided into an executable code and data array including calibration tables and constants and rewritten into the said two-port RAM. The executable code is written into EPROM, reading out from EPROM is locked by program means. Finally, the data array with calibration tables and constants is changed. The changed data addresses are added to said executable code. Now, improved software is written into EPROM of the ICE control unit microcontroller and reading out from EPROM is locked by program means.

EFFECT: improved software protection.

2 cl, 1 dwg

FIELD: physics; computer engineering.

SUBSTANCE: present invention pertains to computer technology. The elements of each schema can be arbitrarily embedded in the elements of another schema and each set of elements remains correct within the limits of its intrinsic schema. Elements of the second schema are "transparent" to the elements of the first schema, when the text processor checks correctness of elements of the first schema. Elements of the second schema are verified separately so that, elements of the first schema are "transparent" for verification of elements, corresponding to the second schema.

EFFECT: provision for validity checking of an extensible mark-up language (XML) document, with elements, linked to two or more schemata, where elements of each schema can be arbitrarily embedded in the elements of another schema and each set of elements remains correct within the limits of its intrinsic schema.

16 cl, 6 dwg

FIELD: physics, processing of images.

SUBSTANCE: invention is related to facilities for image processing. Device of data processing has interpreter medium for dynamic realisation of program formed on the basis of group of commands, determined independently on inherited group of commands, in inherited medium created on the basis of inherited group of commands handled by processor that configures hardware. Device generates intermediate data flow in every of multiple units, into which input data flow is divided during interpretation in inherited medium and filters intermediate data flow for generation of filtered data flow in interpreter medium. Method describes operation of devices.

EFFECT: higher efficiency of image processing.

32 cl, 19 dwg

FIELD: information technology.

SUBSTANCE: non-proprietary parameter data format justification is performed in accordance with proprietary paradigm of the proprietary computer platform. The parameter data is written to a dedicated memory block, where information is justified along the word border. In case it is determined that the parameters in question are not justified, then a reference to this memory block is sent to the proprietary computer platform. In case it is determined that the parameters in question are justified properly, then a reference to original parameters is sent to the platform.

EFFECT: mitigation of non-proprietary software components operation on the proprietary computer platform.

17 cl, 6 dwg

FIELD: automation of processes with usage of field devices.

SUBSTANCE: method is realized in control device by means of operation program, which for parameterization in dialog mode is connected to field device via data transfer bus, and which has no access to device description, which describes behavior of field device in autonomous mode. Technical result is achieved because operation program connects to copy of software program of device executed in field device, realizing imitation of field device in dialog mode.

EFFECT: simplification and lower costs of programming.

8 cl, 3 dwg

FIELD: data processing systems.

SUBSTANCE: data processing device has processing core, having bank of registers, which includes a set of registers, which are utilized for storing stack operands. Commands from second set of commands, determining stack operands, are translated by translator of commands to commands of first set of commands or controlling signals, appropriate for these commands, and determining register operands. These translated commands are then performed by processor core. Commands translator has multiple display states for controlling which registers match which stack operands in stack. Changes between display states are performed dependently on stack operands added to set of registers or removed from there.

EFFECT: improved system operation speed.

2 cl, 13 dwg

The invention relates to a method and system emulation commands one microprocessor commands the other microprocessor with an incompatible system commands

The invention relates to compilers, engaged in removing excess download

In-circuit emulator // 2214621
The invention relates to computing, and is intended for debugging microprocessor systems based on microprocessors, microcontrollers, processors, digital signal processing

FIELD: physics, computer engineering.

SUBSTANCE: invention is related to processing of electronic ink. Method of the first data structure matching with the second data structure consists in the following: for every unit of the second data structure it is defined whether this unit received change from appropriate unit in the first data structure; for every unit in the second data structure, for which it has been defined that it received change from appropriate unit in the first data structure, attempt of access is realised to this unit in the first data structure; if mentioned unit in the first data structure is unachievable, realisation of mentioned change is prevented in the second data structure; if it is achievable - it is defined, when mentioned change in relation to the second data structure creates optional collision, and sometimes obligatory collision; if change creates optional collision, it is defined whether it is prohibited by collision criteria; if optional collision is not prohibited, mentioned change is performed; if it is prohibited - realisation of mentioned change is prevented, at that mentioned collision criteria prohibit removal of ink strokes from end unit under fixed unit.

EFFECT: expansion of method functional resources.

12 cl, 49 dwg

Up!