Virtual Server 2005 is a multithreaded application that runs as a system service, with each virtual machine running in its own thread of execution. Input/output (I/O) occurs in child threads. Virtual Server derives two core functions from the host operating system: the underlying host operating system kernel schedules CPU resources, and device drivers of the host operating system provide access to system devices. Virtual Server’s Virtual Machine Monitor (VMM) provides the software infrastructure to create virtual machines, manage instances, and interact with guest operating systems. 

A description of the hardware that Virtual Server 2005 emulates is contained in the Technical Overview below in Figure 1.

Virtual Server Architecture

Figure  1. Virtual Server 2005 Architecture 

Above figure describes Virtual Server 2005 architecture on x86 or x64 based physical Server with Windows Server 2003 as host Operating System.

Figure 2

Figure 2. Virtual Server 2005 Architecture 

The following are the key features of the Virtual Server Architecture.

Isolation

To prevent the unauthorized virtual machine access from other virtual machines and host operating system, Virtual Server isolates the virtual machines from others. In case of software problem in a virtual machine, this isolation feature enables the other virtual machines and host operating system to continue running, which result in stable and secure environment. 

Encapsulation

Encapsulation means to package data and processing within a single object. In the case of virtual machines, this means that virtual machines are packaged into a single file, a virtual hard disk file, which you can easily move among host operating systems running Virtual Server. Decoupling applications from hardware through encapsulation simplifies capacity planning, deployment, and management tasks. 

Compatibility

Just like a physical computer, a virtual machine hosts its own guest operating system and applications, and has all the components found in a physical computer (motherboard, VGA card, network card controller, etc). As a result, virtual machines are completely compatible with all standards x86 operating systems, applications and device drivers, so you can use a virtual machine to run all the same software that you would run on a physical x86 computer. 

Hardware Independence

Virtual machines are completely independent from their underlying physical hardware. For example, you can configure a virtual machine with virtual components (e.g. CPU, network card, SCSI controller) that are completely different from the physical components that are present on the underlying hardware. Virtual machines on the same physical server can even run different kinds of operating systems. 

When coupled with the properties of encapsulation and compatibility, hardware independence gives you the freedom to move a virtual machine from one type of x86 computer to another without making any changes to the device drivers, operating system, or applications. Hardware independence also means that you can run a heterogeneous mixture of operating systems and applications on a single physical computer. 

With the same scenario, a software architect also thinks the same way. While designing the application design, the architect concentrates the following things.

• Make the building process as simple as can for future understandings.
• Consider the implementation cost (e.g. time, budget etc.)
• Most important factor is reusability.
• Improve the system integration.

The most common architecture styles are as follows.
• Layering
• Pipe and Filter
• Client/Server
• Object Oriented

Layering

The layers are hierarchical; each layer provides services to the layer outside and acts as a client to the layer inside it. The design includes protocols that explain how each pair of layers will interact.

Pros
- Easy reuse of layers
- Support for standardization
- Dependencies are kept local – modification local to a layer
- Supports incremental development and testing

Cons
- Could give performance penalties

Pipe and Filter

A component in a pipe-and-filter system has streams of data, called pipes, for input and output. Often the transformation of the data from input to output is begun before the component, called a filter, finishes reading the input stream. The filters are independent of each other and are not aware of the existence or functions the other filters. The correctness of the system’s output is not dependent on the order in which the filters are applied.

Pros
- Understandable, easy to reason about, in-out
- Expendable – easy to add remove filters
- Easy to simulate and analyze properties, e.g. throughput
- Concurrent execution

Cons
- Limited to batch processing (not good for interactive applications)
- Duplicated execution, e.g. format checking
- Error handling

Client/Server

Client requests an action or service, and a server responds to the request. The server doesn’t know in advance how many clients that will connect to it, neither does it know the clients’ identities. Clients know server’s identity and sends messages to server by using a procedure call.

Pros
- Users get the information they need only when the need it
- Different clients can view data in different ways

Cons
- Need more sophisticated security, safety management, and application development, so they may need more resources to implement and support.

Object-Oriented Design

This design builds around abstract data types, that is each component is an instance of an abstract data type.
Two important characteristics:
i. The object must preserve the integrity of the data representation
ii. The data representation must be hidden from other objects
The latter characteristic makes it easy to change the implementation without perturbing the rest of the system.

There are also some other architecture styles like but these are not used much as above.

• Interpreters
• Repositories
• Process Control
• Implicit Invocation

Invalid postback or callback argument. Event validation is enabled using <pages enableEventValidation=”true”/> in configuration or <%@ Page EnableEventValidation=”true” %> in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.

Solution:
Simply set EnableEventValidation=“false” in the page tag top of asp page.

The solution is below.

GridViewRow row = (GridViewRow)(((Button)e.CommandSource).NamingContainer);
Label lblLabel = (Label)row.FindControl(“GridViewLabelName”);

Note: The “Button” in the above row is the source, means from which action you want to get the control within the GridView.