Patent Publication Number: US-8972955-B2

Title: Reducing network trips for remote expression evaluation

Description:
BACKGROUND 
     When debugging a process executing on a remote computer, typically information has to be passed back and forth several times between the two computers because neither computer has all the information it needs for the debug operation. Suppose for example, a client computer is debugging a process executing on a server computer. Suppose the user is stopped at a breakpoint and wants to evaluate an expression in the debuggee process. Several pieces of state in the remote process such as register values, or other information stored in memory, has to be obtained in order for an expression evaluator on the local machine to evaluate the expression. If each time a piece of state is read from the remote machine, a request is sent and the user has to wait for a response, the process of debugging can be very slow. For example, evaluation of the expression “a+b+c+d” would involve at a minimum 4 round trips across the network to complete. 
     Alternatively, the expression could be evaluated completely on the remote machine. This would entail having the expression evaluator, the language-specific components and all the symbolic information on the remote computer. This approach typically involves sending large files over the network. Moreover, it may not even be possible to copy all the language-specific components to the remote machine, because, for example, permissions are lacking, or because the language components are not compatible with the operating system or processor of the remote machine. 
     SUMMARY 
     An expression can be evaluated in a remote debugging environment with one single round trip across the network. Expressions can be evaluated in two stages. In the first stage, the expression evaluator can compile the expression into a language-independent intermediate language (IL) in which symbols or other concepts that cannot be resolved by the remote computer are removed. In the second stage, the IL can be sent to the remote computer and can be interpreted on the remote computer. The IL can encode all the information needed to evaluate the expression, including all the reads and writes regarding state inside the debuggee process, as well as logical operations needed to process the information. The IL language can be turing complete so that any computation needed to determine the state to read and write or to combine or process the data can be performed. The IL can be interpreted on the remote computer, without the need to access symbolic information on the local computer. 
     IL can be compiled and sent to the remote computer once, and can be evaluated one or more times without requiring repeated compilation and thus repeatedly receiving an IL stream from the debugger machine. The IL can be encoded as a sequence of bytes that are saved on the remote computer and decoded at interpretation. For example, debuggers can support conditional breakpoints, in which an expression is to be evaluated when a breakpoint is hit. A conditional breakpoint can stop the debuggee only when the expression evaluates to a specified value. That is, conditional breakpoints can be implemented by compiling the expression into IL and sending it to the remote computer when the breakpoint is set. Then, each time the breakpoint is encountered, the remote computer can interpret the IL. No information needs to be sent to the client and no round trips across the network are required unless the process is stopped. 
     This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       In the drawings: 
         FIG. 1  illustrates an example of a system  100  that reduces network trips for remote expression evaluation in accordance with aspects of the subject matter disclosed herein; 
         FIG. 2   a  is an illustration of an example of a syntax tree  250  as is known in the art. 
         FIG. 2   b  is an illustration of an intermediate language (IL) stream in accordance with aspects of the subject matter disclosed herein; 
         FIG. 2   c  is a flow diagram of an example of a method  200  for reducing network trips for remote expression evaluation in accordance with aspects of the subject matter disclosed herein; 
         FIG. 3  is a block diagram of an example of a computing environment in accordance with aspects of the subject matter disclosed herein; and 
         FIG. 4  is a block diagram of an example of an integrated development environment in accordance with aspects of the subject matter disclosed herein. 
     
    
    
     DETAILED DESCRIPTION 
     Overview 
     Communication over a network can be an expensive operation. In accordance with aspects of the subject matter disclosed herein, network trips in a remote debugging environment can be reduced by sending an expression evaluated by an expression evaluator on a local debugger machine and compiled into a form that can be interpreted by the remote computer (e.g., into a form in which concepts such as symbols that the remote computer cannot resolve have been removed and replaced with a series of instructions that enable the remote computer to resolve the symbols). The expression can be compiled into an intermediate language (IL) and an IL stream or a data structure representative thereof can be sent to the remote debuggee machine. An abstract syntax tree created from the expression being evaluated can be used to generate the IL stream that is sent to the remote machine. The semantics of the IL into which the evaluated expression is compiled can comprise a turing complete linear sequence of instructions. The instructions can be interpreted on the remote machine. This can be implemented by maintaining a value stack on the remote machine where each item on the stack comprises a sequence of bytes of variable length. As each instruction in the IL is interpreted, any parameters needed by the instruction can be popped off the value stack, the operation can be performed, and the results of the operation (if applicable) can be pushed back onto the stack. 
     Alternatively, state can be maintained by an array of values. Instructions can take parameters that specify the indices of the location in the array from which the inputs are read and to which outputs are written. Alternatively, an instruction can read inputs from fixed locations and write outputs to fixed locations, assuming the availability of an instruction that copies values between locations. The result of an operation performed on one instruction (e.g., a first instruction) can be used to generate a result that is used as an input to another instruction (e.g., a second instruction). An intermediary result that is input to another instruction in the linear sequence of instructions can be generated. An operation performed on the second instruction can be used to generate a result that is used as an input to a third instruction and so on. Instructions that are batched together in a single transmission and sent across a network can include instructions that depend on results of other instructions sent in the single transmission. The final result, which can include a set of items, can be sent back to the local debugger computer. Thus, an expression evaluation can be performed using a single transmission from a first computer to a second computer and a single transmission response back from the second computer to the first computer (that is, a single round trip across the network). 
     The IL instruction set can be a turing complete set of operations that include primitives to read and write state in the debuggee. Primitives can include an operation that reads a register, writes a register, allowing the prior computation to determine a value to store in the register, read memory, allowing a prior computation to specify the address of the memory to read, write memory, allowing a prior computation to specify the address in memory to write and the data to be written, and add a previously computed value to the list of end results to be returned back to the requester. 
     Value stack manipulation operations can include an operation that pushes a constant sequence of bytes onto the stack, an operation that duplicates the top of the stack, an operation that pops the top item off the stack and discards it, an operation that pops the top item off the stack and saves it in an external storage location outside the stack, an operation that loads an item from an external storage location and pushes it onto the value stack. Control flow operations can include a conditional jump to another location in the IL stream, an unconditional jump to another location in the IL stream, and an operation that terminates the IL instruction stream, etc. In a stack-based implementation, the condition value can be popped off the value stack. Logical and arithmetic operations can include add, subtract, multiply and divide operations for integer or floating-point values. Other arithmetic operations can include a modulus operation, an equality comparison and an inequality comparison. Logical operations can include a bitwise “and” operation, a bitwise “or” operation, a bitwise “xor” operation, a bitwise “not” operation, a bit shift left or right, conversion operations between integer and floating-point types, or between combinations of integer types. In a stack-based implementation each logical/arithmetic operation can pop operands from the value stack, and then push the result of the logical/arithmetic operation back onto the value stack. The bits popped off the value stack can be integer or floating-point values. 
     Code can be implemented on the remote machine to interpret the IL. The code implemented on the remote machine can maintain the value stack in a stack-based implementation and can walk the list of instructions in the IL, performing the task indicated by each instruction. The compiled or interpreted IL can be evaluated repeatedly without re-compilation or re-interpretation. 
     Reducing Network Trips for Remote Expression Evaluation 
       FIG. 1  illustrates an example of a system  100  for reducing network trips for remote expression evaluation in accordance with aspects of the subject matter disclosed herein. All or portions of system  100  may reside on one or more computers such as the computers described below with respect to  FIG. 3 . System  100  or portions thereof may execute on a software development computer such as the software development computer described with respect to  FIG. 4 . System  100  or portions thereof may execute within an IDE such as IDE  104  or may execute in a standalone fashion, outside of an IDE. IDE  104  can be an IDE such as the one described with respect to  FIG. 4  or can be any other IDE. All or portions of system  100  may be implemented as a plug-in or add-on. 
     System  100  may include one or more computing devices or computers such as a remote computer and a local computer. The remote computer can be a server computer and the local computer can be a client computer or vice versa. System  100  can include a computer such as computer  102  and/or another or second computer such as computer  103 . Computer  102  can comprise one or more processors such as processor  142 , etc., a memory such as memory  144 , a program being debugged (e.g., debuggee  108 ) executing in a debuggee process  106 . Computer  102  can also include an interpreter or interpreter module or modules such as interpreter  110 . Computer  102  can also include a results collector such as result collector  112 . Other components well known in the arts may also be included but are not here shown. It will be appreciated that one or more of the above can be loaded into memory  144  to cause one or more processors such as processor  142 , etc. to perform the actions attributed to the one or more modules that contribute to the operation to reduce network trips when evaluating an expression in a remote debugging environment. 
     Computer  103  can comprise one or more processors such as processor  143 , etc., a memory such as memory  145 , and one or more modules that comprise a debugger such as debugger  116 . Alternatively, the debugger may not exist in an IDE and can execute in a non-IDE environment. Debugger  116  can include an expression evaluator such as expression evaluator  118 , an IL generator such as IL generator  120  and one or more language formatters such as language formatter  122 . A language formatter may correspond to a language compiler (e.g., compiler  126 ). That is, for example, if the program being debugged (the debuggee) is written in the programming language C++, the language formatter  122  may format debug results into C++ statements. The language formatter  122  can format debug results in any programming language. Other components well known in the arts may also be included but are not here shown. It will be appreciated that one or more of the above can be loaded into memory  145  to cause one or more processors such as processor  143 , etc. to perform the actions attributed to the one or more modules that contribute to the operation to reduce network trips when evaluating an expression in a remote debugging environment. 
     The computers of system  100  may communicate via a network  114 . Network  114  can be any network, as described more fully below. On computer  103 , a source program such as source program  124  can be compiled by a compiler such as compiler  126 , generating a symbol file such as symbol file  128  and executable program code, not shown, (e.g., the program code executing in debuggee process  106  comprising debuggee  108  on computer  102 ). The symbol file  128  can include information such as but not limited to an offset for a memory address at which expression variables, functions, parameters, constants and so on are stored.  FIG. 1  illustrates a remote debug session in which a user can be debugging the program, the source code of which is source program  124  on computer  103  and the executable of which is executing in debuggee process  106  executing on computer  102 . Debug communications are sent and received between computers via network  114 . In the course of debugging a program, a user can set breakpoints in the source code. When the breakpoint is executed, the program execution can be stopped and the user may be given the opportunity to perform debugging operations including but not limited to expression evaluation. 
     When a remote debug session is initiated on a computer, static state (e.g., static state  146 ) associated with the debuggee process can be sent to the debugger computer (e.g., in  FIG. 1  computer  103 ). In the course of debugging a program, a user can input or otherwise provide an expression such as expression  130  to debugger  116 . In accordance with aspects of the subject matter disclosed herein, the expression evaluator  118  may receive expression  130 , symbol file  128  and static state such as static state  146  from debuggee process  106  and can generate therefrom an abstract syntax tree such as abstract syntax tree  132 . Static state information can include information including but not limited to a location in memory at which an executable or module has been loaded and so on. The IL generator  120  can receive the abstract syntax tree  132  and generate an IL stream such as IL stream  134  from the abstract syntax tree  132 . The IL stream  134  can comprise a linear sequence of instructions that are batched together into a single transmission and sent to a computer on which the debuggee  108  is running. The IL can define a series of operations to be performed on computer  102  that evaluate the expression in the absence of a symbol file on computer  102 . IL stream  134  can be sent to interpreter  110  executing on computer  102 . The interpreter  110  can receive the IL stream  134  and execute the instructions comprising the IL stream  134 , as described more fully below. The results of executing the instructions can be collected by a result collector  112  and the result  148  can be sent back to computer  103 . Result  148  can be received by a language formatter such as language formatter  122  and displayed on a display screen, printed by a printer or otherwise presented as formatted result  150 . Result  148  can be an ordered list of items whose return to the debugger machine is triggered by a final return instruction coded into the IL stream  134 . 
     It will be appreciated that IL generator can be incorporated into the expression evaluator or debugger or can be a standalone, plug-in or add-in module or modules. Similarly, the language formatter can be incorporated into the debugger or can be a standalone, plug-in or add-in module or modules. It will be appreciated that the language formatter can be a language formatter for the programming language in which the source program was compiled. 
     In operation, in response to user input initiating a debug session provided to computer  103 , a debug session can be initiated on a program (e.g., debuggee  108 ) executing on a remote computer (e.g., computer  102 ). When the remote debug session is initiated, static state  146  can be received from computer  102  by computer  103 . At some point in the debugging process a request for an evaluation of an expression (e.g., expression  130 ) can be received by debugger  116 . For example the source expression:
 
 p Squid-&gt;Swim(1 +i );
 
can be received.
 
     An expression evaluator  118  of debugger  116  can receive the expression  130 , a symbol file  128 , some or all of the static state associated with the debuggee process  106  and can generate therefrom an abstract syntax tree  132 . That is, the expression  130  can be the expression “pSquid-&gt;Swim((1+i);” which can be parsed into an abstract syntax tree such as the abstract syntax tree  250  illustrated in  FIG. 2   a . For example, the abstract syntax tree  250  illustrated in  FIG. 2   a  can be compiled into IL such as the IL  260  illustrated in  FIG. 2   b . The abstract syntax tree  250  indicates that a function such as the function Swim  252  has been called, that the first parameter to the function Swim  252  is a parameter that is a pointer to pSquid  254 , and that the second parameter is a plus operation  256 . The operands to the plus operation  256  can follow (e.g., constant  1   258  and read variable  1   259 ). The abstract syntax tree can be walked and can be compiled into IL by the IL generator  120 . For example, the IL generator  120  can receive the abstract syntax tree  250  and generate therefrom an IL stream such as the IL stream  260  illustrated in  FIG. 2   b . Step  1   261  can obtain the memory address of “i” (read value of ebp, add 4), instructions  262 ,  264  and  266 . Step  2   263  can read the memory at the address from step  1   261  to get the value of “i” (instruction  268 ). Step  3   265  can add 1 to the value of “i” obtained from step  2   263  (instructions  270  and  272 ). Step  4   267  can obtain the memory address of pSquid (read value of ebp, add 8), instructions  274 ,  276  and  278 . Step  5   269  can read memory at the address from step  4   267  to get the value of pSquid (instruction  280 ). Step  6   271  can invoke the function CSquid::Swim, passing in the result of step  5   269  as the “this” parameter and the result of step  3   265  as an argument (instructions  282  and  284 ) and step  7   273  can append the result of step  6   271  (the return value of the function) to the list of final results to be returned back to the caller (instruction  286 ). The IL stream generated by the IL generator  120  can be sent to another computer (e.g., computer  102 ), comprising the remote computer. 
     The semantics of the IL into which the evaluated expression is compiled on computer  103  can comprise a turing complete linear sequence of instructions. The instructions can be interpreted on computer  102 . Computer  102  can maintain a value stack such as value stack  140  in memory  144  on computer  102 . Each item on the value stack  140  can comprise a sequence of bytes of variable length. As each instruction in the IL is interpreted, any parameters generated by instructions in the IL can be pushed onto the value stack  140  and any parameters needed by the next instruction can be popped off the value stack  140 . The operation can be performed, and the results of the operation (if applicable) can be pushed back onto the value stack  140 . 
     The IL instruction set can be a turing complete set of operations that include primitives to read and write state in the debuggee. Primitives can include an operation that reads a register from the debuggee, and pushes the result onto the value stack, an operation that writes a register to the debuggee, popping the bytes to write off the value stack. Further primitives can include an operation that reads memory from the debuggee, popping the address to read from off the value stack, and pushing the result onto the value stack and an operation that writes memory to the debuggee, popping the address and bytes to write off the value stack, and pushing the result back onto the value stack. Further primitives can include an operation that can pop the top item off the value stack and add this value to a collection of results to be returned to the debugger. The final result of the IL execution operation can be an ordered list of items returned to the local debugger machine through a return instruction. 
     Value stack manipulation operations can include an operation that pushes a constant sequence of bytes onto the stack, an operation that duplicates the top of the stack, an operation that pops the top item off the stack and discards it, an operation that pops the top item off the stack and saves it in an external storage location outside the stack, an operation that loads an item from an external storage location and pushes it onto the value stack, control flow operations, a conditional jump to another location in the IL stream, where the condition value is popped off the value stack, an unconditional jump to another location in the IL stream, an operation that terminates the IL instruction stream, and logical/arithmetic operations. Each logical/arithmetic operation can pop operands from the value stack, and then push the result of the logical/arithmetic operation back onto the value stack. Arithmetic operations can include add, subtract, multiply and divide. The bits popped off the value stack can be integer or floating-point values. Other arithmetic operations can include a modulus operation, an equality comparison and an inequality comparison. Logical operations can include a bitwise “and”operation, a bitwise “or” operation, a bitwise “xor” operation, a bitwise “not” operation, a bit shift left or right, conversion operations between integer and floating-point types, or between combinations of integer types. 
     Code can be implemented on the remote machine to interpret the IL. The code implemented on the remote machine can maintain the value stack and walk the list of instructions in the IL, and performing the task indicated by each instruction. A result collector  112  can collect the result  148  and send result  148  to computer  103 . Thus, it will be apparent that an expression has been evaluated and a result returned in a single round trip across the network. 
       FIG. 2   c  illustrates an example of a method  200  for reducing network trips for remote expression evaluation in accordance with aspects of the subject matter disclosed herein. The method described in  FIG. 2   c  can be practiced by a system such as but not limited to the one described with respect to  FIG. 1 . Some of the actions described below can be optional. Some of the actions described below can be executed in a sequence that differs from that described below. At  202  a debugger expression evaluator can be invoked on a local machine for a program being debugged on a remote machine. At  204  an expression evaluator can parse the expression into an abstract syntax tree. At  206  the abstract syntax tree can be converted into intermediate language on the local machine. The intermediate language may comprise a linear sequence of instructions that encodes all the information needed to evaluate an expression in a single round trip across the network. The linear sequence of instructions can define operations to manipulate the state of a debuggee process executing on the second computer. The linear sequence of instructions can include logical operations performed on the state of the debuggee process that are needed to evaluation the expression on the remote computer without accessing the debugger machine. Alternatively, instead of generating a linear sequence of instructions, the intermediate language may be represented by a data structure that can be processed by the remote machine. At  208  the intermediate language stream or data structure can be sent to the remote machine in a single transmission. At  210  the remote machine can receive the intermediate language stream and can interpret the IL stream or data structure representing the IL, reading and writing values from the debuggee process and maintaining the value stack. A result of executing a first instruction can comprise an input to a second instruction and so on. At  212  the results of  210  can be collected and sent to the local machine. At  214  the local machine can receive the results, format the results and display the formatted results on a display screen, route the formatted results to a printer or otherwise present the formatted results. 
     Example of a Suitable Computing Environment 
     In order to provide context for various aspects of the subject matter disclosed herein,  FIG. 3  and the following discussion are intended to provide a brief general description of a suitable computing environment  510  in which various embodiments of the subject matter disclosed herein may be implemented. While the subject matter disclosed herein is described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other computing devices, those skilled in the art will recognize that portions of the subject matter disclosed herein can also be implemented in combination with other program modules and/or a combination of hardware and software. Generally, program modules include routines, programs, objects, physical artifacts, data structures, etc. that perform particular tasks or implement particular data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments. The computing environment  510  is only one example of a suitable operating environment and is not intended to limit the scope of use or functionality of the subject matter disclosed herein. 
     With reference to  FIG. 3 , a computing device in the form of a computer  512  is described. Computer  512  may include a processing unit  514 , a system memory  516 , and a system bus  518 . The processing unit  514  can be any of various available processors. Dual microprocessors and other multiprocessor architectures also can be employed as the processing unit  514 . The system memory  516  may include volatile memory  520  and nonvolatile memory  522 . Nonvolatile memory  522  can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM) or flash memory. Volatile memory  520  may include random access memory (RAM) which may act as external cache memory. The system bus  518  couples system physical artifacts including the system memory  516  to the processing unit  514 . The system bus  518  can be any of several types including a memory bus, memory controller, peripheral bus, external bus, or local bus and may use any variety of available bus architectures. 
     Computer  512  typically includes a variety of computer readable media such as volatile and nonvolatile media, removable and non-removable media. Computer storage media may be implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other transitory or non-transitory medium which can be used to store the desired information and which can be accessed by computer  512 . 
     It will be appreciated that  FIG. 3  describes software that can act as an intermediary between users and computer resources. This software may include an operating system  528  which can be stored on disk storage  524 , and which can allocate resources of the computer system  512 . Disk storage  524  may be a hard disk drive connected to the system bus  518  through a non-removable memory interface such as interface  526 . System applications  530  take advantage of the management of resources by operating system  528  through program modules  532  and program data  534  stored either in system memory  516  or on disk storage  524 . It will be appreciated that computers can be implemented with various operating systems or combinations of operating systems. 
     A user can enter commands or information into the computer  512  through an input device(s)  536 . Input devices  536  include but are not limited to a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, and the like. These and other input devices connect to the processing unit  514  through the system bus  518  via interface port(s)  538 . An interface port(s)  538  may represent a serial port, parallel port, universal serial bus (USB) and the like. Output devices(s)  540  may use the same type of ports as do the input devices. Output adapter  542  is provided to illustrate that there are some output devices  540  like monitors, speakers and printers that require particular adapters. Output adapters  542  include but are not limited to video and sound cards that provide a connection between the output device  540  and the system bus  518 . Other devices and/or systems or devices such as remote computer(s)  544  may provide both input and output capabilities. 
     Computer  512  can operate in a networked environment using logical connections to one or more remote computers, such as a remote computer(s)  544 . The remote computer  544  can be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer  512 , although only a memory storage device  546  has been illustrated in  FIG. 3 . Remote computer(s)  544  can be logically connected via communication connection  550 . Network interface  548  encompasses communication networks such as local area networks (LANs) and wide area networks (WANs) but may also include other networks. Communication connection(s)  550  refers to the hardware/software employed to connect the network interface  548  to the bus  518 . Connection  550  may be internal to or external to computer  512  and include internal and external technologies such as modems (telephone, cable, DSL and wireless) and ISDN adapters, Ethernet cards and so on. 
     It will be appreciated that the network connections shown are examples only and other means of establishing a communications link between the computers may be used. One of ordinary skill in the art can appreciate that a computer  512  or other client device can be deployed as part of a computer network. In this regard, the subject matter disclosed herein may pertain to any computer system having any number of memory or storage units, and any number of applications and processes occurring across any number of storage units or volumes. Aspects of the subject matter disclosed herein may apply to an environment with server computers and client computers deployed in a network environment, having remote or local storage. Aspects of the subject matter disclosed herein may also apply to a standalone computing device, having programming language functionality, interpretation and execution capabilities. 
       FIG. 4  illustrates an integrated development environment (IDE)  600  and Common Language Runtime Environment  602 . An IDE  600  may allow a user (e.g., developer, programmer, designer, coder, etc.) to design, code, compile, test, run, edit, debug or build a program, set of programs, web sites, web applications, and web services in a computer system. Software programs can include source code (component  610 ), created in one or more source code languages (e.g., Visual Basic, Visual J#, C++. C#, J#, Java Script, APL, COBOL, Pascal, Eiffel, Haskell, ML, Oberon, Perl, Python, Scheme, Smalltalk and the like). The IDE  600  may provide a native code development environment or may provide a managed code development that runs on a virtual machine or may provide a combination thereof. The IDE  600  may provide a managed code development environment using the .NET framework. An intermediate language component  650  may be created from the source code component  610  and the native code component  611  using a language specific source compiler  620  and the native code component  611  (e.g., machine executable instructions) is created from the intermediate language component  650  using the intermediate language compiler  660  (e.g. just-in-time (JIT) compiler), when the application is executed. That is, when an IL application is executed, it is compiled while being executed into the appropriate machine language for the platform it is being executed on, thereby making code portable across several platforms. Alternatively, in other embodiments, programs may be compiled to native code machine language (not shown) appropriate for its intended platform. 
     A user can create and/or edit the source code component according to known software programming techniques and the specific logical and syntactical rules associated with a particular source language via a user interface  640  and a source code editor  651  in the IDE  600 . Thereafter, the source code component  610  can be compiled via a source compiler  620 , whereby an intermediate language representation of the program may be created, such as assembly  630 . The assembly  630  may comprise the intermediate language component  650  and metadata  642 . Application designs may be able to be validated before deployment. 
     The various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of both. Thus, the methods and apparatus described herein, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing aspects of the subject matter disclosed herein. As used herein, the term “machine-readable medium” shall be taken to exclude any mechanism that provides (i.e., stores and/or transmits) any form of propagated signals. In the case of program code execution on programmable computers, the computing device will generally include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. One or more programs that may utilize the creation and/or implementation of domain-specific programming models aspects, e.g., through the use of a data processing API or the like, may be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations. 
     Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.