Syntactic program language translation

The subject disclosure pertains to computer programming languages and translation or conversion thereof. Rather than a complicated semantics preserving translation or conversion from a first source language to a second target language, the conversion can be one of syntax. The conversion can be accomplished, for example, via employment of a map that defines the relation between the syntax of the first language and the second language. The semantics of at least a part of the first language can be defined by the second target language. Thus, the first language can be open-ended and/or semantically extensible based on the second language.

BACKGROUND

Computer programs are lists of instructions that describe actions to be performed by a computer or processor-based device. When a computer program is loaded and executed on computer hardware, the computer will behave in a predetermined manner by following the instructions of the computer program. Accordingly, the computer becomes a specialized machine that performs the tasks prescribed by the instructions. A programmer using a programming language creates the instructions comprising a computer program. As computer programs became more sophisticated, programming languages have evolved from low-level machine code languages, easily understood by computers, to high-level source code languages more readily comprehensible to humans.

Programming languages are typically classified into categories based upon the characteristics and features of the language. For example, C is often described as a procedural programming language as it is based upon the concept of modularity and scope of program code. C# and Java are object-oriented programming languages tuned to the creation and manipulation of program code as object classes. Data-oriented languages including SQL (Structured Query Language) and XPath are drawn toward search and manipulation of stored data such as relational or XML (Extensible Markup Language) data. As a consequence of this specialization, individual programming languages have particular strengths and weaknesses.

Programmers today often prefer developing a computer program in a specific language with which they have extensive experience or is most appropriate for a large portion of a project. However, programmers appreciate the specialization among programming languages and would like to utilize the best language for particular tasks. For instance, a C# programmer may wish to interface with a relational database using SQL, thus benefiting from the data-oriented aspects and efficiencies of SQL. One way to accomplish this could be to translate a C# query expression into a SQL query expression. Integration of programming languages requires a semantic translation from a first language to a second language. This ensures the meaning of all programmatic statements, expressions and the like specified in the first language are translated to the syntax of the second language that has the same meaning specified by the first language. Often this involves a very different syntax as well as many data conversions to preserve the first language semantics.

SUMMARY

Briefly described, programming language translation systems and methods are provided herein. In particular, language elements or constructs including but not limited to expressions can be subjected to a syntactic translation from a first source language to a second target language. The translation or expansion can be syntactic, guided by a map or mapping rather than completely semantic. At least a portion of an expression or sub-expression, for instance, can be translated one-to-one such that what is denoted in the source language expression is translated verbatim to the target language. This type of translation enables semantics to be defined by the target language rather than the source and produces predictable translations, among other things.

Furthermore, systems and methods are provided for generating a map used in the syntactic translation. The map can be populated based on the matching program syntax of the source and target language as well as context or implementation specific information. Maps can be generated by a translation system author or vendor. Additionally or alternatively, non-native maps can be provided by others, plugged-in, and utilized like native maps to facilitate translation or expansion from one language to another.

DETAILED DESCRIPTION

Turning initially toFIG. 1, a program code translation system100is depicted. System100includes a parser component110, a translation component120and a map130. Parser component110receives programmatic code and parses it into tokens and parse trees representing base elements in a language such as symbols, operators (e.g., +, −, *, =, ==, &, % . . . ), types and the like. These tokens are passed individually or as a collection, parse tree, to the translation component120. The translation component120receives the tokens or collection of tokens and expands or translates them from the first source program language to corresponding elements in a second target language. For example, an equal sign “=” in the first language could be mapped to an equal sign in the second language. To facilitate such translation or expansion, the translation component120can interact with and be guided by map130. Map130provides a map or mapping between the syntax, operations, and names of the first language and the syntax, operations and names of the second language. The map130can include a record of not only base elements that are common to programming languages but also context or implementation specific information such as field, variable and/or table names. Accordingly, upon receiving a particular token or language element from the parser110the translation component120can identify such element in the map130and retrieve the corresponding element or elements in the second language. The transformation or translation from the input or source code to the target code can be purely syntactic. However, the map130can embody at least some language semantics.

FIG. 2aillustrates a simple exemplary translation200ato facilitate clarity in understanding the translation provided by system100ofFIG. 1. It should be noted that although, expressed as a translation from C# to SQL, the invention is by no means limited thereto. Any other languages can be employed. The example could have just as easily utilized different languages (e.g., XPath/XQuery to SQL . . . ). By way of example and not limitation, an object-oriented language expression or code can be received for example by parser110and ultimately translated or expanded to SQL code by the translation component120. Here, the expression is a query expression that corresponds to cs.where (|c| c.name=“Jones”). The exemplary expression includes typical object-oriented dot operators as well as a lambda filter expression or sub-expression. The statement declares find all customers (cs) where the customer's name is Jones. There are two main expansions that happen here. First, the main expression “cs.where” can be translated or expanded based on the syntactic map130to “Select*From Customers Where.” The object-oriented statement corresponds to making a selection from “cs” which can correspond to a customer or customers table. Next, the sub-expression, here a lambda expression, can be translated and utilized to populate the expanded main expression. In this case, the filter or selection expression says select a customer (c) from customers (cs) where the name is Jones. This can be translated to simply name=“Jones” and inserted as an argument to the Where parameter of the Select statement. It should be noted that there is a direct translation of name=“Jones” in the source language to name=“Jones” in the target or destination language without consideration of the semantic meaning.

FIG. 2billustrates an exemplary translation or expansion200bto further facilitate clarity in understanding the operation of system100ofFIG. 1. Expansion200bis similar to that of translation200aexcept that a different result is produced. Again, there is the expression “cs.where(|c| c.name=“Jones”).” The main expression is then expanded to a SQL type expression namely “Select*From Customers Where.” This denotes select from the customers table where some condition is satisfied. The condition is specified in the sub-expression, which happens to be specified as a lambda expression. In this instance, the condition name=“Jones” is translated or expanded to some other condition expression where some function is performed on name and some conversion is executed on the string Jones, for example a Unicode string can be converted to an ASCII string or the like. In other words, the same condition expression is not placed as a condition argument to the Where clause or parameter. Rather, some semantic conversion or translation is performed to ensure that the expanded expression or sub-expression in this case has the same meaning that is specified in the source language. Here the semantics of the source language are maintained.

Although expansion200brepresents a viable option for translation of source language expressions to target language expressions, statements and the like, there is at least one problem associated therewith. In particular, a programmer may be programming utilizing a source language, which is later translated to the target or destination language to insulate themselves from the details of the destination language, amongst other reasons. For example, a user may program in C# or XQuery/XPath as shorthand but the target language could be SQL for relational data access. Programmers know that a particular expression is going to be translated to a particular target language. Accordingly, they will often view what is generated and to their surprise, it may not look anything like what they expected. As illustrated with expansion200b, all sorts of conversions and data manipulation may be necessary to maintain the semantics of the source language. In addition to surprising results, the converted expressions will likely cause execution to be slow and inefficient due to the functionality supporting semantic preservation. Still further yet, such a translation can wreak havoc on a debug process, as one minor change in the source language expression can cause dramatic changes to occur in the target language. Further, programmers will be clueless on how to tweak the produced results, as changes in the target language are non-linear as well as unpredictable in response to alterations of the source language code. The translation or expansion is essentially a black box to users or programmers.

Expansion200adoes not suffer from the same problems. Expansion200ais not a complete semantic maintaining translation. Here, at least a portion of the expression, name=“Jones” is translated one-to-one or from another viewpoint not translated at all but copied as specified in the source. This provides predictability for programmers so that they know when they specify name=“Jones” this condition will be translated to name=“Jones” in the destination language. There are no unexpected conversions produced to preserve the semantics of the source language. In fact, semantics are understood to come from the target language rather than the source. This provides, among other things, semantic extensibility from the target language. Thus, the translation is kind of a macro expansion that does not enforce any semantic rules of the source language. By way of example, if the expression a*b+c is written in a source language the precedent and associativity rules from the destination language will apply. Thus, if the source language semantics specify that the multiplication happen first followed by the addition and the destination language semantics specify that the addition be performed first, there will be not be any conversions or alterations to the expression such as (a*b)+c to preserve the semantics of the source language.

Turning toFIG. 3, a map production system300is depicted. The system includes a syntax match component310, a user interface component320and a map generation component330. Two languages sought to be mapped are provided to the syntax match component310. Here, languages A and B supply input to the match component310. The match component310provides a mechanism to enable the syntax of language A and language B to be matched. For example, numbers, symbols, and operators of language A can be matched to the same or corresponding numbers, symbols, and operators of language B. In addition, syntax match component can receive context information such as the names of fields, tables, variables, and the like. In this manner, a name in language A such as “cs” can be matched to “customers” table in language B, for instance. Furthermore, a user interface component320can be communicatively coupled to the syntax match component. The user interface component320provides a mechanism for a user, possibly an administrative type, to control, coordinate, or otherwise affect matching of language syntax. For example, a user could ensure that proper context information is matched and/or that like functions or operations are properly matched. The match information can be provided to the map generation component330. The map generation component can generate a map from the match information. For example, the map can be a computer readable map or mapping file that includes the matching syntax. It should be appreciated that the map can be provided in any form, however in one instance the map can be an XML file.

FIG. 4is a language translation system400that obtains non-native or plug-in maps. A translation system such as that ofFIG. 1can include one or more maps for a plurality of languages. However, the system is extensible in that it can obtain new non-native maps for new languages, extensions, alternative versions of other languages and/or different context. System400includes a receiver component410, a registration component420and a store430. Receiver component410receives, retrieves or otherwise obtains a computer readable map. The map can include a mapping of the syntax of a first language to the syntax of a second language, such as from XQuery to SQL. Once received, the map can be provided to the registration component420. Registration component420receives the map and can initiate storage of the map to a computer readable store430. The registration component420can also generate and store an entry in a registry or log440to identify the map, for example by source and target language, and its location in the store430. Upon registration, the map is available for use by a translation or expansion system such as system100described supra with respect toFIG. 1.

Turning toFIG. 5, a language translation system500is provided that locates a map for employment. System500includes a language identification component510, a map retrieval component520, and a store430. Language identification component510analyzes a plurality of languages presented thereto to identify the language in question. The language identification component510provides the identity of the languages to the map retrieval component520. The map retrieval component can subsequently identify the appropriate map given the identities of the languages and optionally some context information. For example, map retrieval component520can interact with the registry440to identity a map with particular source and target languages. The registry440can also identify the location or provide a pointer to an appropriate map. The map can then be retrieved from the computer readable store430and provided to a language translation or expansion system.

FIG. 6illustrates an interface system600for interacting with a translation or expansion system. System600includes an application interface component610and a translation interface component620. Application interface component610can interact with a first computer language application. For example, the application interface component610can receive programmatic elements such as expressions, statements, blocks and the like. Application interface610can transmit or provide such programmatic elements to the translation interface component620. The transformation interface component620can be communicatively coupled to or included within a translation system such that it can provide such programmatic elements for translation or expansion. Translated programmatic elements and/or other data such as results of a query can be transmitted back from the translation interface component620to the application interface component610. It should be appreciated that application interface component610and/or translation interface620can form all or part of an application-programming interface (API) for interacting with a translation system. Accordingly, the interfaces can transmit any and all information related to translation or expansion of programmatic code.

To further facilitate appreciation of aspects of the disclosed subject matter, an exemplary scenario and solution thereto are provided. It should be noted that this scenario and solution is provided solely for the purpose of providing clarity with respect to particular subject matter disclosed herein and is not meant to limit the scope of the disclosed subject matter in any way. The systems and methods provided herein are applicable to a variety of different situations only one of which is described hereinafter.

It is often desirable to provide relational data as XML to database users, for instance through a web service or other type of application. In other words, provide XML views over relational data. The main attraction of using XML views over relational data is that it provides users with hierarchical views of their flat relational data and consequently makes it much simpler for them to navigate this hierarchy. In such a scenario, it has been discovered that there are several important features that determine whether users employ such technology.

First, it is important to users that there is a mechanism for simple retrieval, update, and manipulation of XML data. Database providers or owners typically establish a contract with users through some XML schema (XSD-XML Schema Definition) and allow users to get data back from the backend as XML, which is described in the XSD schema. Users prefer to be empowered to interact quickly with a database without the need to write complicated SQL queries manually.

Furthermore, it is important to provide users with efficient queries with high performance as well as predicable behavior. Users rightfully expect that conversion will not be applied that hurts performance. For example, users expect that columns that are indexed will not be converted as this substantially impairs performance. Users also do not appreciate and will often not utilize an application or technology that provides non-deterministic or non-monotonic behavior, for example, where a query behaves completely different in response to a minor change.

In addition, users have a strong perception that since their data is stored in a relational database, they should be able to use the intrinsic functionality provided by the database. When a similar function is available in XQuery and SQL, the user often expects that the SQL function be directly mapped to a corresponding XQuery function. In other words, the SQL function will be used when the query is executed.

In response to the aforementioned concerns, a language can be designed or translated such that XML views of data can be queried by transliterating path and filter expressions to the query language of the data source based on mapping information. For example, XPath/XQuery or a subset thereof can be employed to provide the ability to locate a map target such as an XML node and apply a predicate to this node. Within the predicate, any relative XML node on the self and child axes can be used to filter expressions. The expressions can be translated from XPath/XQuery to SQL where the XML items are replaced with the mapped SQL entities (e.g., table, column) and child and attribute traversal is translated to a join over the appropriate relationship between mapped tables. Queries can be translated into SQL guided by a relational to XML map or mapping to refer to appropriate tables/columns based on the location path and the node information used in the predicates. The records that result form execution of the SQL query can then be materialized into the mapped XML nodes.

Location paths are part of XQuery grammar or BNF (Backus-Naur Form or Backus Normal Form) that has the needed information on the path and predicate to facilitate translation to SQL. A relative location path can consist of a sequence of one or more locations steps separated by a delimiter such as “/.” The steps in a relative location path are composed together from left to right. Each step in turn selects a node, which is a child of the node of the prior step. An absolute location path consists of “/” optionally followed by a relative location path. A “/” by itself selects the root node of the document containing the context node. If it is followed by a relative location path, then the location path selects the set of nodes that would be selected by the relative location path relative to the root node of the document containing the context node. In BNF form:

A location step either selects a named child, attribute, or itself. For instance, consider the following BNF:

A predicate filters a node-set with respect to the path to produce a new node-set. The predicate expression is translated to SQL based on the node the path specifies that serves as the context node. In BNF:

Expressions are needed for filter-expressions. Parentheses may be used for grouping. Consider the following BNF for expressions:

Consider the example presented hereinafter. The following sets forth a SQL query into the XML data type:

The relevant mapping file is:

The aforementioned systems have been described with respect to interaction between several components. It should be appreciated that such systems and components can include those components or sub-components specified therein, some of the specified components or sub-components, and/or additional components. For example, a system could include parser component110, translation component120, syntax match component310, user interface component320, map generation component330, receiver component410, registration component420, language identification component510, and map retrieval component520, or a combination thereof. Additionally, it should be noted that one or more components may be combined into a single component providing aggregate functionality or divided into several sub-components. The components may also interact with one or more other components not specifically described herein but known by those of skill in the art.

Furthermore, as will be appreciated various portions of the disclosed systems above and methods below may include or consist of artificial intelligence or knowledge or rule based components, sub-components, processes, means, methodologies, or mechanisms (e.g., support vector machines, neural networks, expert systems, Bayesian belief networks, fuzzy logic, data fusion engines, classifiers . . . ). Such components, inter alia, can automate certain mechanisms or processes performed thereby to make portions of the systems and methods more adaptive as well as efficient and intelligent. For example, translation component120could utilize artificial intelligence, machine learning or like mechanisms to facilitate expansion or translation of code. Additionally or alternatively, syntax match component310can employ such intelligent mechanisms to facilitate matching of the syntaxes of a plurality of languages.

Additionally, it should be further appreciated that the methodologies disclosed hereinafter and throughout this specification are capable of being stored on an article of manufacture to facilitate transporting and transferring such methodologies to computers. The term article of manufacture, as used, is intended to encompass a computer program accessible from any computer-readable device, carrier, or media.

Turning toFIG. 7, a language translation methodology700is depicted. At710, code is obtained in a first or source language. By way of example and not limitation, the first language could be an object-oriented language or a markup query language. At720, a translation or syntax map is located. The map can provide syntactic information regarding translation from the syntax of the first source language to syntax of a second target language. The map can be stored on a computer readable medium or stored within a translation system. At730, the code obtained from the first language is expanded to code of a second language utilizing the syntax map. Methodology700can be utilized, for instance, to translate an XML based query to a relational based query, perhaps in SQL. The query could be executed by a query processor and relational results generated. A similar methodology can be employed to subsequently pass the results back in XML. For example, the same map can be employed, or another map located, where SQL is the source and XML is the target language. The results can then be translated back to XML utilizing the map.

FIG. 8is a flow chart diagram of a method800of expression translation. At reference numeral810, an expression (e.g., query expression) in a source language is received, retrieved, or otherwise obtained. The expression can include a sub-expression as an argument. For example, the expression can specify a path or location of data and the sub-expression can specify some filter logic or predicate. At820, the expression is translated to an expression of related syntax of a target language. This translation action can relate to the main expression, for instance, an object oriented or mark-up language expression identify data to be queried such that the expression is translated to a target language such as SQL. By way of example, the expression “cs.where” of “cs.where(|c| c.name=“Jones”)” can be translated to Select*From Customers Where. In this case, the Where clause does not include any logic or expressions, as that is provided by the sub-expression. At820, the syntax of the sub-expression is translated from the source language to the target language and populates the syntax or structure generated from the main expression. The translation of the sub-expression does not need to preserve the semantics of the source language. Accordingly, the sub-expression or a portion thereof can be translated verbatim thereby preserving solely the syntax of the sub-expression. In the previous example, the sub-expression “|c| c.name=“Jones”” can be translated simply to “name=“Jones”” and provided as an argument to the Where clause.

FIG. 9illustrates a translation or expansion map method900. At reference numeral910, the program syntax of a first language is matched to program syntax of a second language. This act can be automatic, semi-automatic or manual. At920, a map can be generated based on the matching information. The map can include mapping of corresponding fundamental elements such as operators and also include data or implementation specific information, for example, “cs” corresponds to the table named “customers.” At930, the generated map can be provided to a language expansion/translation system for employment. Method900can be utilized to produce both native and non-native maps. Accordingly, a translation system vendor may employ method900to produce maps to be included by the system. Additionally or alternatively, third parties may create their own maps, which can be added or plugged-in to the system.

FIG. 10illustrates an expansion or translation system map registration methodology1000. By way of example and not limitation, method1000can be utilized for support of plug-in or non-native maps. At1010, a syntax map is received, retrieved or otherwise obtained. As described previously, the map can record corresponding syntax from a plurality of languages including, among other things, operators and context specific information (e.g., data schema). At1020, the map is persisted to a computer readable store. At1030, the map is registered. Registration can include, inter alia, recording the location of the map or a pointer thereto as well as information pertaining to the languages on which the map can operate. Once the map is registered, it is available for use. Method1000provides a means for receiving and operating on native as well as non-native maps.

Turning toFIG. 11, a flow chart of a translation methodology1100is depicted. At reference numeral1110, source and target languages are identified. For example, XPath could be the source and SQL could be the target, or vice versa. At1120, a syntax map is located that maps the source and target languages. This could be accomplished by consulting a registry and retrieving a pointer to the location of the appropriate map to perform the expansion. Finally, at1130, one or more expressions or other program units or elements are translated utilizing the map. The translation is a translation from the syntax of the source to the syntax of the target without complete enforcement of the semantics of the source language. Semantics can be defined by the target language.

In order to provide a context for the various aspects of the disclosed subject matter,FIGS. 12 and 13as well as the following discussion are intended to provide a brief, general description of a suitable environment in which the various aspects of the disclosed subject matter may be implemented. While the subject matter has been described above in the general context of computer-executable instructions of a computer program that runs on a computer and/or computers, those skilled in the art will recognize that the invention also may be implemented in combination with other program modules. Generally, program modules include routines, programs, components, data structures, etc. that perform particular tasks and/or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the inventive methods may be practiced with other computer system configurations, including single-processor or multiprocessor computer systems, mini-computing devices, mainframe computers, as well as personal computers, hand-held computing devices (e.g., personal digital assistant (PDA), phone, watch . . . ), microprocessor-based or programmable consumer or industrial electronics, and the like. The illustrated aspects may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. However, some, if not all aspects of the invention can be practiced on stand-alone computers. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

With reference toFIG. 12, an exemplary environment1210for implementing various aspects disclosed herein includes a computer1212(e.g., desktop, laptop, server, hand held, programmable consumer or industrial electronics . . . ). The computer1212includes a processing unit1214, a system memory1216, and a system bus1218. The system bus1218couples system components including, but not limited to, the system memory1216to the processing unit1214. The processing unit1214can be any of various available microprocessors. Dual microprocessors and other multiprocessor architectures also can be employed as the processing unit1214.

The system memory1216includes volatile memory1220and nonvolatile memory1222. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer1212, such as during start-up, is stored in nonvolatile memory1222. By way of illustration, and not limitation, nonvolatile memory1222can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory1220includes random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM).

It is to be appreciated thatFIG. 12describes software that acts as an intermediary between users and the basic computer resources described in suitable operating environment1210. Such software includes an operating system1228. Operating system1228, which can be stored on disk storage1224, acts to control and allocate resources of the computer system1212. System applications1230take advantage of the management of resources by operating system1228through program modules1232and program data1234stored either in system memory1216or on disk storage1224. It is to be appreciated that the present invention can be implemented with various operating systems or combinations of operating systems.

A user enters commands or information into the computer1212through input device(s)1236. Input devices1236include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, and the like. These and other input devices connect to the processing unit1214through the system bus1218via interface port(s)1238. Interface port(s)1238include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device(s)1240use some of the same type of ports as input device(s)1236. Thus, for example, a USB port may be used to provide input to computer1212and to output information from computer1212to an output device1240. Output adapter1242is provided to illustrate that there are some output devices1240like displays (e.g., flat panel, CRT, LED, LCD . . . ), speakers, and printers, among other output devices1240that require special adapters. The output adapters1242include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device1240and the system bus1218. It should be noted that other devices and/or systems of devices provide both input and output capabilities such as remote computer(s)1244.

Computer1212can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s)1244. The remote computer(s)1244can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a peer device or other common network node and the like, and typically includes many or all of the elements described relative to computer1212. For purposes of brevity, only a memory storage device1246is illustrated with remote computer(s)1244. Remote computer(s)1244is logically connected to computer1212through a network interface1248and then physically connected via communication connection1250. Network interface1248encompasses communication networks such as local-area networks (LAN) and wide-area networks (WAN). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet/IEEE 802.3, Token Ring/IEEE 802.5 and the like. WAN technologies include, but are not limited to, point-to-point links, circuit-switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet switching networks, and Digital Subscriber Lines (DSL).

Communication connection(s)1250refers to the hardware/software employed to connect the network interface1248to the bus1218. While communication connection1250is shown for illustrative clarity inside computer1212, it can also be external to computer1212. The hardware/software necessary for connection to the network interface1248includes, for exemplary purposes only, internal and external technologies such as, modems including regular telephone grade modems, cable modems, power modems and DSL modems, ISDN adapters, and Ethernet cards or components.

FIG. 13is a schematic block diagram of a sample-computing environment1300with which the present invention can interact. The system1300includes one or more client(s)1310. The client(s)1310can be hardware and/or software (e.g., threads, processes, computing devices). The system1300also includes one or more server(s)1330. Thus, system1300can correspond to a two-tier client server model or a multi-tier model (e.g., client, middle tier server, data server), amongst other models. The server(s)1330can also be hardware and/or software (e.g., threads, processes, computing devices). The servers1330can house threads to perform transformations by employing the present invention, for example. One possible communication between a client1310and a server1330may be in the form of a data packet adapted to be transmitted between two or more computer processes.

The environment1300includes a communication framework1350that can be employed to facilitate communications between the client(s)1310and the server(s)1330. The client(s)1310are operably connected to one or more client data store(s)1360that can be employed to store information local to the client(s)1310. Similarly, the server(s)1330are operably connected to one or more server data store(s)1340that can be employed to store information local to the servers1330.