Monday, 24 September 2012

Asp.Net Pagination

Introduction To Pagination

Pagination is the process of displaying a huge records by splitting them into different pages. This can be better explained by a example. Consider you have 10000 records in a table you want to show them to the end user when he requests. The very simple thing is to display all of them by fetching from database with a simple select * from <Table> query. OK fine you are done and your job is over. You have checked in the code and your Lead or some testing team person is verifying your features implementation. Suppose your Manager saw the application and the particular feature. Can you imagine what might be his reaction to that.

I can explain the situation how it will be, as I have faced this situation in earlier days of coding.

Question-I: What is this?
Question-II: What have you done?
Question-III: Does end user is able to read such a long list?
Question-IV:  How much time it is taking to load all these records?
Question-V: Did you mind the usability of this application while implementing this feature?

Thursday, 20 September 2012

.NET Interview Questions - Seniors and Tech Leads

Its been a year back I got call from Microsoft regarding a job opening. Obviously I accepted and my interview scheduled. The day came and the person started interviewing me.

I was totally excited and very much happy to answer his questions. those were very normal questions as like most of the companies do.

Q. What is page life cycle?

A. The answer is very simple most of the .net guys know as it described here

Q. What are validation controls and what is your experience with them

A. As a regular practice every developer use them as explained here

Q. Do the server controls has state and state management in

A. Yes all the server controls are state enabled control the maintain state with the help of ViewState. The state management in is is clearly described here

Q.SQL Server Joins and query optimization steps

A. I explained the SQL Server joins weel as per my knowledge like here
     Query Performance Optimization Tips:
  1. Do not put * in the select queries mention the columns only that you need.
  2. Use joins carefully
  3. Index your records according to your where clause columns
  4. Use profiling tools
After all explaining these I got through 1st round of interview. So I was promoted second round and was asked same set of questions with little extra questions. 

Q. What are the oops concepts, difference between Abstract class and Interface.

Encapsulation: Wrapping up of attributes and methods into class is called encapsulation, which means when you want explain any entity or item in object oriented manner you declare a class as your entity and all its properties like height, weight and etc. as attributes for it and entity behaviors as methods.

Abstraction: Hiding the high level details. Which means a driver does not need to know how the engine is manufactured and its attributes. The only thing he needs is how to drive the car.

Interface: Acquiring parent class properties to child class

Polymorphism: This is another one which explains existing in many forms. its has two categories again. One is compile time another is run-time. Compile time is the one which can be used for two kinds of use. like + operator it can be used to add two number and can be used to concatenate two strings. The run-time one is executes on the current context. If you have a interface and the there are two child classes define for it the run-time will choose on the current value to execute which one.

The more about Abstract vs Interface 

After explaining all these again I was promoted to 3rd round of interview. This was my last round with microsoft. Most of the questions were repeated again but few questions were really great and we had great conversation over that.

Finally The Most Interesting Conversation Went As Below

Q. I have page with grid view which will display records for a particular query. It is working fine with 1000 records. It is loading very quickly. But the as the time passes my table grown and records count also increased. Now I have 10000 records page is loading bit slow. What to do to make the page perform well.

A. We should check entire page and verify whether we can replace any server controls with normal html controls. We should consider ViewState too. And finally we can implement gridview pagination.

Q. Ok now my data grown to 1,000,000 records does you tips will give the same performance?

A. Surely not, because the memory to handle this much of data will not be sufficient. or making database calls on each page postback and this much data, will be a great overhead. So I will implement proper caching. I will modify my query, I will select only required columns & implement proper indexing on the table and pooling for the connections database pools everything I will implement to provide the better performance.

     And I will return only a set of required rows by implementing server side paging. This will give good performance to handle one million records.

Q. Ok nice answer what if my records grown to 1,000,000,000 records
A. This is the time to think about implementing scale-out and scale-up options. We should go for very good hardware. We should implement very good indexing, the very good normalized database schema, proper optimized queries and all the above are required to get good performance.

Q. Ok fine what if my table has grown even more????
A. I got angry and shouted on him what else is there to implement I explained everything I knew upto my knowledge.
Q. He gently asked that's it there is nothing more to implement?
A. Shouted again and told that's all what ever I knew I explained. If there is anything else you only tell me.
Q. So yours is final there is nothing..?
A. Yes there is nothing I explained from page to server levele. Scale-Out and Scale-Up Options. Increasing the hard and partitioning the table data I have explained everything. If you know more than that kindly tell me. Like this I shouted.
Q. The other option what have you said?
A. Increasing the hardware and data partitioning.
Interviewer: Yes I am expecting this answer from you. That's why over call went this much long. ok Fine.
Me: I have already told you. Scale-Up & Scale-Out options. What does mean by Scale-Out.??
Interviewer: Ok Nice talking to you srinivasu. you have very good experience and vast knowledge. Nice talking to you my HR will get back to you..

The HR not yet get back....

Tuesday, 11 September 2012

Windows Azure

Windows Azure is an open cloud platform that enables you to quickly build, deploy and manage applications across a global network of Microsoft-managed datacenters.

You can build applications using any language, tool or framework.

Windows Azure is Microsoft's application platform for the public cloud. You can use this platform in many different ways. For instance, you can use Windows Azure to build a web application that runs and stores its data in Microsoft datacenters. You can use Windows Azure just to store data, with the applications that use this data running on-premises (that is, outside the public cloud). You can use Windows Azure to create virtual machines for development and test or to run SharePoint and other applications. You can use Windows Azure to build massively scalable applications with lots and lots of users. Because the platform offers a wide range of services, all of these things-and more-are possible.
To do any of them, though, you need to understand the basics. Even if you don't know anything about cloud computing, this article will walk you through the fundamentals of Windows Azure. The goal is to give you a foundation for understanding and using this cloud platform.

The Components Of Windows Azure

To understand what Windows Azure offers, it's useful to group its services into distinct categories. Figure 1 shows one way to do this.
Windows Azure Components
To get started with Windows Azure, you need to know at least the basics about each of its components. The rest of this article walks through the technologies shown in the figure, describing what each one offers and when you might use it.

Execution Models

One of the most basic things a cloud platform does is execute applications. Windows Azure provides three options for doing this.

Execution Model
Each of these three approaches-Virtual Machines, Web Sites, and Cloud Services-can be used separately. You can also combine them to create an application that uses two or more of these options together.

Virtual Machines

The ability to create a virtual machine on demand, whether from a standard image or from one you supply, can be very useful. Add the ability to pay for this VM by the hour, and it's even more useful. This approach, commonly known as Infrastructure as a Service (IaaS), is what Windows Azure Virtual Machines provides.

To create a VM, you specify which VHD to use and the VM's size. You then pay for each hour the VM is running. As Figure 2 shows, Windows Azure Virtual Machines offers a gallery of standard VHDs. These include Microsoft-provided options, such as Windows Server 2008 R2, Windows Server 2012, and Windows Server 2008 R2 with SQL Server, along with Linux images provided by Microsoft partners. You're free to upload and create VMs from your own VHDs as well.
Wherever the image comes from, you can persistently store any changes made while a VM is running. The next time you create a VM from that VHD, things pick up where you left off. It's also possible to copy the changed VHD out of Windows Azure, then run it locally.
Windows Azure VMs can be used in many different ways. You might use them to create an inexpensive development and test platform that you can shut down when you've finished using it. You might also create and run applications that use whatever languages and libraries you like. Those applications can use any of the data management options that Windows Azure provides, and you can also choose to use SQL Server or another DBMS running in one or more virtual machines. Another option is to use Windows Azure VMs as an extension of your on-premises datacenter, running SharePoint or other applications. To support this, it's possible to create Windows domains in the cloud by running Active Directory in Windows Azure VMs. This quite general approach to cloud computing can be used to address many different problems. What you do is up to you.

Web Sites

One of the most common things that people do in the cloud is run websites and web applications. Windows Azure Virtual Machines allows this, but it still leaves you with the responsibility of administering one or more VMs. What if you just want a website where somebody else takes care of the administrative work for you?
This is exactly what Windows Azure Web Sites provides. This execution model offers a managed web environment using Internet Information Services (IIS). You can move an existing IIS website into Windows Azure Web Sites unchanged, or you can create a new one directly in the cloud. Once a website is running, you can add or remove instances dynamically, relying on Web Sites to load balance requests across them. And as Figure 2 shows, Windows Azure Web Sites offers both a shared option, where your website runs in a virtual machine with other sites, and a way for a site to run in its own VM.
Windows Azure Web Sites is intended to be useful for both developers and web design agencies. For development, it supports .NET, PHP, and Node.js, along with SQL Database and (from ClearDB, a Microsoft partner) MySQL for relational storage. It also provides built-in support for several popular applications, including WordPress, Joomla, and Drupal. The goal is to provide a low-cost, scalable, and broadly useful platform for creating websites and web applications in the public cloud.

Cloud Services

Suppose you want to build a cloud application that can support lots of simultaneous users, doesn't require much administration, and never goes down. You might be an established software vendor, for example, that's decided to embrace Software as a Service (SaaS) by building a version of one of your applications in the cloud. Or you might be a start-up creating a consumer application that you expect will grow fast. If you're building on Windows Azure, which execution model should you use?
Windows Azure Web Sites allows creating this kind of web application, but there are some constraints. You don't have administrative access, for example, which means that you can't install arbitrary software. Windows Azure Virtual Machines gives you lots of flexibility, including administrative access, and you certainly can use it to build a very scalable application, but you'll have to handle many aspects of reliability and administration yourself. What you'd like is an option that gives you the control you need but also handles most of the work required for reliability and administration.
This is exactly what's provided by Windows Azure Cloud Services. This technology is designed expressly to support scalable, reliable, and low-admin applications, and it's an example of what's commonly called Platform as a Service (PaaS). To use it, you create an application using the technology you choose, such as C#, Java, PHP, Python, Node.js, or something else. Your code then executes in virtual machines (referred to as instances) running a version of Windows Server.
But these VMs are distinct from the ones you create with Windows Azure Virtual Machines. For one thing, Windows Azure itself manages them, doing things like installing operating system patches and automatically rolling out new patched images. (This implies that your application shouldn't maintain state in web or worker role instances; it should instead be kept in one of the Windows Azure data management options described in the next section.) Windows Azure also monitors the VMs, restarting any that fail.
As Figure shows, you have two roles to choose from when you create an instance, both based on Windows Server. The main difference between the two is that an instance of a web role runs IIS, while an instance of a worker role does not. Both are managed in the same way, however, and it's common for an application to use both. For example, a web role instance might accept requests from users, then pass them to a worker role instance for processing. To scale your application up or down, you can request that Windows Azure create more instances of either role or shut down existing instances. And just like Windows Azure Virtual Machines, you're charged by the hour for each web or worker role instance.
Each of the three Windows Azure execution models has its own role to play. Windows Azure Virtual Machines provides a general-purpose computing environment, Windows Azure Web Sites offers low-cost web hosting, and Windows Azure Cloud Services is the best choice for creating scalable, reliable applications with low administration costs. And as mentioned earlier, you can use these technologies separately or combine them as needed to create the right foundation for your application. The approach you choose depends on what problems you're trying to solve.

Data Management

Applications need data, and different kinds of applications need different kinds of data. Because of this, Windows Azure provides several different ways to store and manage data.
One of these has already been mentioned: the ability to run SQL Server or another DBMS in a VM created with Windows Azure Virtual Machines. (It's important to realize that this option isn't limited to relational systems; you're also free to run NoSQL technologies such as MongoDB and Cassandra.) Running your own database system is straightforward-it replicates what we're used to in our own datacenters-but it also requires handling the administration of that DBMS. To make life easier, Windows Azure provides three data management options that are largely managed for you. Figure 3 shows the choices.
Azure Storage
Each of the three options addresses a different need: relational storage, fast access to potentially large amounts of simple typed data, and unstructured binary storage. In all three cases, data is automatically replicated across three different computers in a Windows Azure datacenter to provide high availability. It's also worth pointing out that all three options can be accessed either by Windows Azure applications or by applications running elsewhere, such as your on-premises datacenter, your laptop, or your phone. And however you apply them, you pay for all Windows Azure data management services based on usage, including a gigabyte-per-month charge for stored data.

SQL Database

For relational storage, Windows Azure provides SQL Database. Formerly called SQL Azure, SQL Database provides all of the key features of a relational database management system, including atomic transactions, concurrent data access by multiple users with data integrity, ANSI SQL queries, and a familiar programming model. Like SQL Server, SQL Database can be accessed using Entity Framework, ADO.NET, JDBC, and other familiar data access technologies. It also supports most of the T-SQL language, along with SQL Server tools such as SQL Server Management Studio. For anybody familiar with SQL Server (or another relational database), using SQL Database is straightforward.
But SQL Database isn't just a DBMS in the cloud-it's a PaaS service. You still control your data and who can access it, but SQL Database takes care of the administrative grunt work, such as managing the hardware infrastructure and automatically keeping the database and operating system software up to date. SQL Database also provides a federation option that distributes data across multiple servers. This is useful for applications that work with large amounts of data or need to spread data access requests across multiple servers for better performance.
If you're creating a Windows Azure application (using any of the three execution models) that needs relational storage, SQL Database can be a good option. Applications running outside the cloud can also use this service, though, so there are plenty of other scenarios. For instance, data stored in SQL Database can be accessed from different client systems, including desktops, laptops, tablets, and phones. And because it provides built-in high availability through replication, using SQL Database can help minimize downtime.


Suppose you want to create a Windows Azure application that needs fast access to typed data, maybe lots of it, but doesn't need to perform complex SQL queries on this data. For example, imagine you're creating a consumer application that needs to store customer profile information for each user. Your app is going to be very popular, so you need to allow for lots of data, but you won't do much with this data beyond storing it, then retrieving it in simple ways. This is exactly the kind of scenario where Windows Azure Tables makes sense.
Don't be confused by the name: this technology doesn't provide relational storage. (In fact, it's an example of a NoSQL approach called a key/value store.) Instead, Windows Azure Tables let an application store properties of various types, such as strings, integers, and dates. An application can then retrieve a group of properties by providing a unique key for that group. While complex operations like joins aren't supported, tables offer fast access to typed data. They're also very scalable, with a single table able to hold as much as a terabyte of data. And matching their simplicity, tables are usually less expensive to use than SQL Database's relational storage.


The third option for data management, Windows Azure Blobs, is designed to store unstructured binary data. Like Tables, Blobs provides inexpensive storage, and a single blob can be as large as one terabyte. An application that stores video, for example, or backup data or other binary information can use blobs for simple, cheap storage. Windows Azure applications can also use Windows Azure drives, which let blobs provide persistent storage for a Windows file system mounted in a Windows Azure instance. The application sees ordinary Windows files, but the contents are actually stored in a blob.


Windows Azure runs today in several datacenters spread across the United States, Europe, and Asia. When you run an application or store data, you can select one or more of these datacenters to use. You can also connect to these datacenters in various ways:
  • You can use Windows Azure Virtual Network to connect your own on-premises local network to a defined set of Windows Azure VMs.
  • You can use Windows Azure Connect to link one or more on-premises Windows servers to a specific Windows Azure application.
  • If your Windows Azure application is running in multiple datacenters, you can use Windows Azure Traffic Manager to route requests from users intelligently across instances of the application.

Azure Networking

Virtual Network

One useful way to use a public cloud is to treat it as an extension of your own datacenter. Because you can create VMs on demand, then remove them (and stop paying) when they're no longer needed, you can have computing power only when you want it. And since Windows Azure Virtual Machines lets you can create VMs running SharePoint, Active Directory, and other familiar on-premises software, this approach can work with the applications you already have.
To make this really useful, though, your users ought to be able to treat these applications as if they were running in your own datacenter. This is exactly what Windows Azure Virtual Network allows. Using a VPN gateway device, an administrator can set up a virtual private network (VPN) between your local network and a defined group of VMs running in Windows Azure. Because you assign your own IP v4 addresses to the cloud VMs, they appear to be on your own network. Users in your organization can access the applications those VMs contain as if they were running locally.


Creating a VPN between your local network and a group of VMs in the cloud is useful, but it also requires VPN gateway hardware and the services of a network administrator. Suppose you're a developer who just wants to connect a single Windows Azure application to a specific group of Windows machines within your organization. Perhaps you've built a Cloud Services application that needs to access a database on one of those servers, for example, and you don't want to go to the trouble of configuring a VPN gateway.
Windows Azure Connect is designed for this situation. Connect provides a simple way to establish a secure connection between a Windows Azure application and a group of computers running Windows. A developer just installs the Connect software on the on-premises machines-there's no need to involve a network administrator-and configures the Windows Azure application. Once this is done, the application can communicate with the on-premises computers as if they were on the same local network.

Traffic Manager

A Windows Azure application with users in just a single part of the world might run in only one Windows Azure datacenter. An application with users scattered around the world, however, is more likely to run in multiple datacenters, maybe even all of them. In this second situation, you face a problem: How do you intelligently assign users to application instances? Most of the time, you probably want each user to access the datacenter closest to her, since it will likely give her the best response time. But what if that copy of the application is overloaded or unavailable? In this case, it would be nice to route her request automatically to another datacenter. This is exactly what's done by Windows Azure Traffic Manager.
The owner of an application defines rules that specify how requests from users should be routed to datacenters, then relies on Traffic Manager to carry out these rules. For example, users might normally be routed to the closest Windows Azure datacenter, but get sent to another one when the response time from their default datacenter exceeds a certain threshold. For globally distributed applications with many users, having a built-in service to handle problems like these is useful.

Business Analytics

Analyzing data is a fundamental part of how businesses use information technology. A cloud platform provides a pool of on-demand, pay-per-use resources, which makes it a good foundation for this kind of computing. Accordingly, Windows Azure provides two options for business analytics.
Business Analytics
Analyzing data can take many forms, and so these two options are quite different. It's worth looking at each one separately.

SQL Reporting

One of the most common ways to use stored data is to create reports based on that data. To let you do this with data in SQL Database, Windows Azure provides SQL Reporting. A subset of the reporting services included with SQL Server, SQL Reporting lets you build reporting into applications running on Windows Azure or on premises. The reports you create can be in various formats, including HTML, XML, PDF, Excel, and others, and they can be embedded in applications or viewed via a web browser.
Another option for doing analytics with SQL Database data is to use on-premises business intelligence tools. To a client, SQL Database looks like SQL Server, and so the same technologies can work with both. For example, you're free to use on-premises SQL Server Reporting Services to create reports from SQL Database data.


For many years, the bulk of data analysis has been done on relational data stored in a data warehouse built with a relational DBMS. This kind of business analytics is still important, and it will be for a long time to come. But what if the data you want to analyze is so big that relational databases just can't handle it? And suppose the data isn't relational? It might be server logs in a datacenter, for example, or historical event data from sensors, or something else. In cases like this, you have what's known as a big data problem. You need another approach.
The dominant technology today for analyzing big data is Hadoop. An Apache open source project, this technology stores data using the Hadoop Distributed File System (HDFS), then lets developers create MapReduce jobs to analyze that data. HDFS spreads data across multiple servers, then runs chunks of the MapReduce job on each one, letting the big data be processed in parallel.
As Figure suggests, the Apache Hadoop-based Service for Windows Azure lets HDFS distribute data across multiple virtual machines, then spreads the logic of a MapReduce job across those VMs. Just as with on-premises Hadoop, data is processed locally-the logic and the data it works on are in the same VM-and in parallel for better performance. The Apache Hadoop-based Service for Windows Azure supports other components of the technology as well, including Hive and Pig, and Microsoft has also created an Excel plug-in for issuing Hive queries.


No matter what it's doing, code frequently needs to interact with other code. In some situations, all that's needed is basic queued messaging. In other cases, more complex interactions are required. Windows Azure provides a few different ways to solve these problems. Figure  illustrates the choices.
Azure Messaging


Queuing is a simple idea: One application places a message in a queue, and that message is eventually read by another application. If your application needs just this straightforward service, Windows Azure Queues might be the best choice.
One common use of Queues today is to let a web role instance communicate with a worker role instance within the same Cloud Services application. For example, suppose you create a Windows Azure application for video sharing. The application consists of PHP code running in a web role that lets users upload and watch videos, together with a worker role implemented in C# that translates uploaded video into various formats. When a web role instance gets a new video from a user, it can store the video in a blob, then send a message to a worker role via a queue telling it where to find this new video. A worker role instance-it doesn't matter which one-will then read the message from the queue and carry out the required video translations in the background. Structuring an application in this way allows asynchronous processing, and it also makes the application easier to scale, since the number of web role instances and worker role instances can be varied independently.

Service Bus

Whether they run in the cloud, in your data center, on a mobile device, or somewhere else, applications need to interact. The goal of Windows Azure Service Bus is to let applications running pretty much anywhere exchange data.
As Figure 6 shows, Service Bus provides a queuing service. This service isn't identical to the Queues just described, however. Unlike Windows Azure Queues, for example, Service Bus provides a publish-and-subscribe mechanism. An application can send messages to a topic, while other applications can create subscriptions to this topic. This allows one-to-many communication among a set of applications, letting the same message be read by multiple recipients. And queuing isn't the only option: Service Bus also allows direct communication through its relay service, providing a secure way to interact through firewalls.
Applications that communicate through Service Bus might be Windows Azure applications or software running on some other cloud platform. They can also be applications running outside the cloud, however. For example, think of an airline that implements reservation services in computers inside its own datacenter. The airline needs to expose these services to many clients, including check-in kiosks in airports, reservation agent terminals, and maybe even customers' phones. It might use Service Bus to do this, creating loosely coupled interactions among the various applications.


Applications tend to access the same data over and over. One way to improve performance is to keep a copy of that data closer to the application, minimizing the time needed to retrieve it. Windows Azure provides two different services for doing this: in-memory caching of data used by Windows Azure applications and a content delivery network (CDN) that caches blob data on disk closer to its users. Figure shows both.
Azure Caching


Accessing data stored in any of Windows Azure's data management services-SQL Database, Tables, or Blobs-is quite fast. Yet accessing data stored in memory is even faster. Because of this, keeping an in-memory copy of frequently accessed data can improve application performance. You can use Windows Azure's in-memory Caching to do this.
A Cloud Services application can store data in this cache, then retrieve it directly without needing to access persistent storage. As Figure 7 shows, the cache can be maintained inside your application's VMs or be provided by VMs dedicated solely to caching. In either case, the cache can be distributed, with the data it contains spread across multiple VMs in a Windows Azure datacenter.
An application that repeatedly reads a product catalog might benefit from using this kind of caching, for example, since the data it needs will be available more quickly. The technology also supports locking, letting it be used with read/write as well as read-only data. And ASP.NET applications can use the service to store session data with just a configuration change.


Suppose you need to store blob data that will be accessed by users around the world. Maybe it's a video of the latest World Cup match, for instance, or driver updates, or a popular e-book. Storing a copy of the data in multiple Windows Azure datacenters will help, but if there are lots of users, it's probably not enough. For even better performance, you can use the Windows Azure CDN.
The CDN has dozens of sites around the world, each capable of storing copies of Windows Azure blobs. The first time a user in some part of the world accesses a particular blob, the information it contains is copied from a Windows Azure datacenter into local CDN storage in that geography. After this, accesses from that part of the world will use the blob copy cached in the CDN-they won't need to go all the way to the nearest Windows Azure datacenter. The result is faster access to frequently accessed data by users anywhere in the world.


Working with identity is part of most applications. For example, knowing who a user is lets an application decide how it should interact with that user. To help you do this, Microsoft provides Windows Azure Active Directory.
Like most directory services, Windows Azure Active Directory stores information about users and the organizations they belong to. It lets users log in, then supplies them with tokens they can present to applications to prove their identity. It also allows synchronizing user information with Windows Server Active Directory running on premises in your local network. While the mechanisms and data formats used by Windows Azure Active Directory aren’t identical with those used in Windows Server Active Directory, the functions it performs are quite similar.
It's important to understand that Windows Azure Active Directory is designed primarily for use by cloud applications. It can be used by applications running on Windows Azure, for example, or on other cloud platforms. It's also used by Microsoft's own cloud applications, such as those in Office 365. If you want to extend your datacenter into the cloud using Windows Azure Virtual Machines and Windows Azure Virtual Network, however, Windows Azure Active Directory isn't the right choice. Instead, you'll want to run Windows Server Active Directory in cloud VMs, as described earlier.
To let applications access the information it contains, Windows Azure Active Directory provides a RESTful API called Windows Azure Active Directory Graph. This API lets applications running on any platform access directory objects and the relationships among them. For example, an authorized application might use this API to learn about a user, the groups he belongs to, and other information. Applications can also see relationships between users-their social graph-letting them work more intelligently with the connections among people.
Another capability of this service, Windows Azure Active Directory Access Control, makes it easier for an application to accept identity information from Facebook, Google, Windows Live ID, and other popular identity providers. Rather than requiring the application to understand the diverse data formats and protocols used by each of these providers, Access Control translates all of them into a single common format. It also lets an application accept logins from one or more Active Directory domains. For example, a vendor providing a SaaS application might use Windows Azure Active Directory Access Control to give users in each of its customers single sign-on to the application.
Directory services are a core underpinning of on-premises computing. It shouldn't be surprising that they're also important in the cloud.

High-Performance Computing

One of the most attractive ways to use a cloud platform is for high-performance computing (HPC), The essence of HPC is executing code on many machines at the same time. On Windows Azure, this means running many virtual machines simultaneously, all working in parallel to solve some problem. Doing this requires some way to schedule applications, i.e., to distribute their work across these instances. To allow this, Windows Azure provides the HPC Scheduler.
This component can work with HPC applications built to use the industry-standard Message Passing Interface (MPI). Software that does finite element analysis, such as car crash simulations, is one example of this type of application, and there are many others. The HPC Scheduler can also be used with so-called embarrassingly parallel applications, such as Monte Carlo simulations. Whatever problem is addressed, the value it provides is the same: The HPC Scheduler handles the complex problem of scheduling parallel computing work across many Windows Azure virtual machines. The goal is to make it easier to build HPC applications running in the cloud.


Video makes up a large part of Internet traffic today, and that percentage will be even larger tomorrow. Yet providing video on the web isn't simple. There are lots of variables, such as the encoding algorithm and the display resolution of the user's screen. Video also tends to have bursts in demand, like a Saturday night spike when lots of people decide they'd like to watch an online movie.
Given its popularity, it's a safe bet that many new applications will be created that use video. Yet all of them will need to solve some of the same problems, and making each one solve those problems on its own makes no sense. A better approach is to create a platform that provides common solutions for many applications to use. And building this platform in the cloud has some clear advantages. It can be broadly available on a pay-as-you-go basis, and it can also handle the variability in demand that video applications often face.
Azure Media
Windows Azure Media Services addresses this problem. It provides a set of cloud components that make life easier for people creating and running applications using video and other media. Figure illustrates the technology.
As the figure shows, Media Services provides a set of components for applications that work with video and other media. For example, it includes a media ingest component to upload video into Media Services (where it's stored in Windows Azure Blobs), an encoding component that supports various video and audio formats, a content protection component that provides digital rights management, a component for inserting ads into a video stream, components for streaming, and more. Microsoft partners can also provide components for the platform, then have Microsoft distribute those components and bill on their behalf.
Applications that use this platform can run on Windows Azure or elsewhere. For example, a desktop application for a video production house might let its users upload video to Media Services, then process it in various ways. Alternatively, a cloud-based content management service running on Windows Azure might rely on Media Services to process and distribute video. Wherever it runs and whatever it does, each application chooses which components it needs to use, accessing them through RESTful interfaces.
To distribute what it produces, an application can use the Windows Azure CDN, another CDN, or just send bits directly to users. However it gets there, video created using Media Services can be consumed by various client systems, including Windows, Macintosh, HTML 5, iOS, Android, Windows Phone, Flash, and Silverlight. The goal is to make it easier to create modern media applications.


The rise of Software as a Service is transforming how we create applications. It's also transforming how we sell applications. Since a SaaS application lives in the cloud, it makes sense that its potential customers should look for solutions online. And this change applies to data as well as to applications. Why shouldn't people look to the cloud for commercially available datasets? Microsoft addresses both of these concerns with Windows Azure Marketplace, illustrated in Figure
Azure Commerce
Potential customers can search the Marketplace to find Windows Azure applications that meet their needs, then sign up to use them either through the application's creator or directly through the Marketplace. Customers can search the Marketplace for commercial datasets as well, including demographic data, financial data, geographic data, and more. When they find something they like, they can access it either from the vendor or directly through the Marketplace. Applications can also use the Bing Search API through the Marketplace, giving them access to the results of web searches.


Back in 2008, the very first pre-release version of Windows Azure supported only .NET development. Today, however, you can create Windows Azure applications in pretty much any language. Microsoft currently provides language-specific SDKs for .NET, Java, PHP, Node.js, and Python. There's also a general Windows Azure SDK that provides basic support for any language, such as C++.
These SDKs help you build, deploy, and manage Windows Azure applications. They're available either from or GitHub, and they can be used with Visual Studio and Eclipse. Windows Azure also offers command line tools that developers can use with any editor or development environment, including tools for deploying applications to Windows Azure from Linux and Macintosh systems.
Along with helping you build Windows Azure applications, these SDKs also provide client libraries that help you create software running outside the cloud that uses Windows Azure services. For example, you might build an application running at a hoster that relies on Windows Azure blobs, or create a tool that deploys Windows Azure applications through the Windows Azure management interface

Wednesday, 5 September 2012

Developer Guide Lines Part - I

Things to be taken care by developers while writing code or designing different layers

Presentation Layer:

  1. Choose your UI elements carefully
  2. Optimize Viewstate
  3. State management should be effective and optimized well
  4. Well Managed Caching
  5. Reduce round trips to server
  6. Utilize client side script effectively
  7. Consider Asynchronous calls
  8. Consider Partial / Ajax calls to make the portion of the page update
  9. Consider pagination for large record sets and provide server side pagination if possible

Choose UI Elements Carefully

        The control selection is one important part in ASP.NET web page performance. As you know the Page Life Cycle and Server Control Life Cycle it has to load after executing few events which will take some more extra time for control processing and rendering. So choose your controls wisely.

         First we should discuss about data controls, these are most used controls in any web application to show data sets or records.
         There are majorly four data controls in those are
  • DataList
  • GridView
  • ListView and
  • Repeater
          Who have these controls to show data records in their own passion. Each has its own advantages and disadvantages according to features. When we consider performance the order of these controls would be Repeater, ListView, DataList, and GridView


          Repeater control is derived from Control class. Repeater simply repeats data given in templates. Repeated data is usually HTML code mixed with records from data source. Repeater's output is not predefined. Because of that, Repeater demands most work to define template. In return it gives us most flexibility to build layout and optimize presentation.

With same template and same data set, Repeater usually works faster of DataList or GridView controls. This is mostly because of DataReader class, which is used for read only access. DataReader is faster than DataSet or DataTable classes commonly used with GridView.

Compared to GridView and DataList control, Repeater has limited features. By default, Repeater is good for displaying of data. It is not best choice if you need editing of data. Also, by default it doesn't provide paging and sorting of records.


           ListView control is newest data presentation control, introduced in ASP.NET 3.5. Previous controls (Repeater, DataList and GridView) logically follow each other. For example, Repater is simplest but fastest, then DataList has more features but more overheads too, and finally GridView is most complex, has most features, but heaviest and thus slowest on page.

           Now, there is new ListView control which tries to provide best from both sides: speed and flexibility in design, and also a lot of features like paging, updating or deleting of records etc. Because of this, ListView control is often better choice than Repeater or DataList.

           Flexibility in design comes with price. To use ListView, you'll probably have to write a lot of markup code. For simple table layout, GridView requires much less work.

           ListView has new LayoutTemplate. Instead of Header and Footer templates, ListView has just LayoutTemplate. Main advantage of LayoutTemplate when compared to Header and Footer templates is that LayoutTemplate makes markup code looks more object oriented. So, it is not a big difference between these two models. It is possible to achieve same results with LayoutTemplate on ListView like with HeaderTemplate and FooterTemplate on Repeater, DataList and GridView.


           Unlike Repeater, DataList control is derived from WebControl class. That gives it a number of style properties like BorderStyle, BackColor, ForeColor etc.

           DataList is somewhere between Repeater and GridView, in many ways looks like a compromise between these two. DataList has more features but more limited in design when compared to Repeater. In the other hand, it has more flexibility and less features than GridView.

           Also, DataList has RepeatDirection, RepeatColumns and RepeatLayout properties, which are unique for DataList control. These properties are useful when you need to create presentation with more than one record per row, like image gallery, product catalog etc. For example, let say you are creating an image gallery and want to show 5 images per row. Repeater would require checking of record position and manipulating HTML. With DataList, just use RepeatDirection="Horizontal" and RepeatColumns="5". RepeatLayout could be Table or Flow, depending of do you need HTML table structure in layout.


            Like DataList control, GridView is derived from WebControl class and includes numerous style properties. In addition to this, GridView is most complex control and have most properties. Numerous features include data paging, sorting, updating and deleting of records. First versions of ASP.NET had DataGrid control. GridView is replaced DataGrid in ASP.NET 2.0 as improved version of old DataGrid control.

            GridView displays data in form of grid. Rows and columns are represented as HTML table. This is very useful if you need grid-like presentation. If you need to present data in table layout, then GridView requires a minimum of effort. In same time, if you want more customizable flow layout, GridView is not best option.

            Common problem when using GridView control could be large ViewState which makes page loads slower and requires more bandwidth. This could be insignificantly on low traffic website, but keep in mind that for each second while the page loads, the percentage of visitors will become impatient and leave website. Also, massive view state is not good for SEO (search engine optimization).

            One more problem is using of default pager on large tables or high traffic websites. If default paging is used, GridView will load complete dataset in memory, which descreases website's performances.

HTML Elements VS ASP.NET Server Controls

             When compared both the controls HTML are pretty fast. On other hand the server controls are slow because of their rendering process. all server controls when the actual page loads they will render as normal html elements. ASP.NET rendering engine has to render the server controls equivalent html text according to the browser to where the content should render. This is an extra process when compared with normal HTML elements.

             The benefits of server controls are very high when compared with normal HTML elements
  1. They have state, so on each page post back we can preserve the value of the control and will be bind after post back.
  2. They are object oriented so we can handle the public properties of the controls from code behind.
  3. They provide caching feature so that we can preserve the value across page navigation
  4. We can attach server events to server controls where we can not attach them to html controls directly.

ViewState Optmization

             ViewState is hidden field, which holds all other controls values in BASE64 format and resides on same page. The scope of ViewState is limited to the page. All server controls in a page maintain their state by means of ViewState.

             The ViewState process is very simple. Whenever page postback occurs all the server control values and their state will be saved in ViewState. Once the postback is over the respective values will be binded to controls. To understand this cycle refer Page Life Cycle. The below figure explains how what are the values saved in ViewState with respect each server control

Control Life Cycle

For more information on ViewState Optimization please click Here

Monday, 3 September 2012

Domain Driven Design Architectural Style

Domain Driven Design (DDD) is an object-oriented approach to designing software based on the business domain, its elements and behaviors, and the relationships between them. It aims to enable software systems that are a realization of the underlying business domain by defining a domain model expressed in the language of business domain experts. The domain model can be viewed as a framework from which solutions can then be rationalized.

To apply Domain Driven Design, you must have a good understanding of the business domain you want to model, or be skilled in acquiring such business knowledge. The development team will often work with business domain experts to model the domain. Architects, developers, and subject matter experts have diverse backgrounds, and in many environments will use different languages to describe their goals, designs and requirements. However, within Domain Driven Design, the whole team agrees to only use a single language that is focused on the business domain, and which excludes any technical jargon.

As the core of the software is the domain model, which is a direct projection of this shared language, it allows the team to quickly find gaps in the software by analyzing the language around it. The creation of a common language is not merely an exercise in accepting information from the domain experts and applying it. Quite often, communication problems within development teams are due not only to misunderstanding the language of the domain, but also due to the fact that the domain’s language is itself ambiguous. The Domain Driven Design process holds the goal not only of implementing the language being used, but also improving and refining the language of the domain. This in turn benefits the software being built, since the model is a direct projection of the domain language.

In order to help maintain the model as a pure and helpful language construct,
you must typically implement a great deal of isolation and encapsulation within the domain model. Consequently, a system based on Domain Driven Design can come at a relatively high cost. While Domain Driven Design provides many technical benefits, such as maintainability, it should be applied only to complex domains where the model and the linguistic processes provide clear benefits in the communication of complex information, and in the formulation of a common understanding of the domain.

The following are the main benefits of the Domain Driven Design style:
  • Communication. All parties within a development team can use the domain model and the entities it defines to communicate business knowledge and requirements using a common business domain language, without requiring technical jargon.
  • Extensible. The domain model is often modular and flexible, making it easy to update and extend as conditions and requirements change.
  • Testable. The domain model objects are loosely coupled and cohesive, allowing them to be more easily tested.

Consider DDD if you have a complex domain and you wish to improve communication and understanding within your development team, or where you must express the design of an application in a common language that all stakeholders can understand. DDD can also be an ideal approach if you have large and complex enterprise data scenarios that are difficult to manage using other techniques.

Asynchronous Calls

Asynchronous calls provide a mechanism for increasing the concurrency of your application. Asynchronous calls are nonblocking and when you call a method asynchronously, the calling thread returns immediately and continues execution of the current method.
There are a number of ways to make asynchronous method calls:
  • Calling asynchronous components. Certain classes support the .NET Framework asynchronous invocation model by providing BeginInvoke and EndInvoke methods. If the class expects an explicit call to EndInvoke at the end of the unit of work, then call it. This also helps capture failures if there are any in your asynchronous calls.
  • Calling nonasynchronous components. If a class does not support BeginInvoke and EndInvoke, you can use one of the following approaches:
                    1. Use the .NET thread pool.
                    2. Explicitly create a thread.
                    3. Use delegates.
                    4. Use timers.

Asynchronous Guidelines

This section summarizes guidelines for optimized performance when you are
considering asynchronous execution:

  • Consider client-side asynchronous calls for UI responsiveness.
  • Use asynchronous methods on the server for I/O bound operations.
  • Avoid asynchronous calls that do not add parallelism.

Consider Client-Side Asynchronous Calls for UI Responsiveness

You can use asynchronous calls to increase the responsiveness of client applications. However, think about this carefully because asynchronous calls introduce additional programming complexity and require careful synchronization logic to be added to your graphical interface code.
The following code shows an asynchronous call followed by a loop that polls for the asynchronous call’s completion. You can add an exit criteria to the while condition in case you need to exit from function before call is completed. You can use the callback mechanism or wait for completion if you do not need to update the client.

                IAsyncResult CallResult = SlowCall.BeginInvoke(slow,null,null);
                while ( CallResult.IsCompleted == false)
                    ... // provide user feedback

Use Asynchronous Methods on the Server for I/O Bound Operations

You can increase the performance of your application by executing multiple operations at the same time. The two operations are not dependent on each other. For example, the following code calls two Web services. The duration of the code is the sum of both methods.

              // get a reference to the proxy
              EmployeeService employeeProxy = new EmployeeService();
             // execute first and block until complete
              employeeProxy.CalculateFederalTaxes(employee, null, null);
            // execute second and block until complete

You can refactor the code as follows to reduce the total duration of the operation. In the following code, both methods execute simultaneously, which reduces the overall duration of the operation. Note that the following example uses the BeginCalculateFederalTaxes method, an asynchronous version of
CalculateFederalTaxes; both of these methods are automatically generated when you reference a Web service from your client application in Visual Studio .NET.

             // get a reference to the proxy
             EmployeeService employeeProxy = new EmployeeService();
             // start async call, BeginCalculateFederalTaxes
             // call returns immediately allowing local execution to continue
             IAsyncResult ar = employeeProxy.BeginCalculateFederalTaxes(employee, null, null);
             // execute CalculateStateTaxes synchronously
             // wait for the CalculateFederalTaxes call to finish

Avoid Asynchronous Calls That Do Not Add Parallelism

Avoid asynchronous calls that will block multiple threads for the same operation. The following code shows an asynchronous call to a Web service. The calling code blocks while waiting for the Web service call to complete. Notice that the calling code performs no additional work while the asynchronous call is executing.

            // get a proxy to the Web service
            customerService serviceProxy = new customerService ();
            //start async call to CustomerUpdate
            IAsyncResult result = serviceProxy.BeginCustomerUpdate(null,null);
            // Useful work that can be done in parallel should appear here
            // but is absent here
            //wait for the asynchronous operation to complete
           // Client is blocked until call is done

When code like this is executed in a server application such as an ASP.NET application or Web service, it uses two threads to do one task and offers no benefit; in fact, it delays other requests being processed. This practice should be avoided.

Sunday, 2 September 2012

Threading Explained

The .NET Framework exposes various threading and synchronization features. Your use of multiple threads can have a significant impact on application performance and scalability.

Managed Threads and Operating System Threads

The CLR exposes managed threads, which are distinct from Microsoft Win32® threads. The logical thread is the managed representation of a thread, and the physical thread is the Win32 thread that actually executes code. You cannot guarantee that there will be a one-to-one correspondence between a managed thread and a Win32 thread.
If you create a managed thread object and then do not start it by calling its Start method, a new Win32 thread is not created. When a managed thread is terminated or it completes, the underlying Win32 thread is destroyed. The managed representation (the Thread object) is cleaned up only during garbage collection some indeterminate time later.
The .NET Framework class library provides the ProcessThread class as the representation of a Win32 thread and the System.Threading.Thread class as the representation of a managed thread. Poorly-written multithreaded code can lead to numerous problems including deadlocks, race conditions, thread starvation, and thread affinity. All of these issues can negatively impact application performance, scalability, resilience, and correctness.

Threading Guide Lines

This section summarizes guidelines to improve the efficiency of your threading code:
  • Minimize thread creation.
  • Use the thread pool when you need threads.
  • Use a Timer to schedule periodic tasks.
  • Consider parallel vs. synchronous tasks.
  • Do not use Thread.Abort to terminate other threads.
  • Do not use Thread.Suspend and Thread.Resume to pause threads.

Minimize Thread Creation

Threads use both managed and unmanaged resources and are expensive to initialize. If you spawn threads indiscriminately, it can result in increased context switching on the processor. The following code shows a new thread being created and maintained for each request. This may result in the processor spending most of its time performing thread switches; it also places increased pressure on the garbage collector to clean up resources.
                               private void Page_Load(object sender, System.EventArgs e)
                                 if (Page.IsPostBack)
                                    // Create and start a thread
                                    ThreadStart ts = new ThreadStart(CallMyFunc);
                                    Thread th = new Thread(ts);

Use the Thread Pool When You Need Threads

Use the CLR thread pool to execute thread-based work to avoid expensive thread initialization. The following code shows a method being executed using a thread from the thread pool.

                              WaitCallback methodTarget = new WaitCallback( myClass.UpdateCache );
                              ThreadPool.QueueUserWorkItem( methodTarget );

When QueueUserWorkItem is called, the method is queued for execution and the calling thread returns and continues execution. The ThreadPool class uses a thread from the application’s pool to execute the method passed in the callback as soon as a thread is available.

Use a Timer to Schedule Periodic Tasks

Use the System.Threading.Timer class to schedule periodic tasks. The Timer class allows you to specify a periodic interval that your code should be executed. The following code shows a method being called every 30 seconds.
TimerCallback myCallBack = new TimerCallback( myHouseKeepingTask );
Timer myTimer = new System.Threading.Timer( myCallBack, null, 0, 30000);
static void myHouseKeepingTask(object state)

When the timer elapses, a thread from the thread pool is used to execute the code indicated in the TimerCallback. This results in optimum performance because it avoids the thread initialization incurred by creating a new thread.

Consider Parallel vs. Synchronous Tasks

Before implementing asynchronous code, carefully consider the need for performing multiple tasks in parallel. Increasing parallelism can have a significant effect on your performance metrics. Additional threads consume resources such as memory, disk I/O, network bandwidth, and database connections. Also, additional threads may cause significant overhead from contention, or context switching. In all cases, it is important to verify that adding threads is helping you to meet your objectives rather then hindering your progress.

The following are examples where performing multiple tasks in parallel might be appropriate:
  • Where one task is not dependent on the results of another, such that it can run without waiting on the other.
  • If work is I/O bound. Any task involving I/O benefits from having its own thread, because the thread sleeps during the I/O operation which allows other threads to execute. However, if the work is CPU bound, parallel execution is likely to have a negative impact on performance.

Do Not Use Thread.Abort to Terminate Other Threads

Avoid using Thread.Abort to terminate other threads. When you call Abort, the CLR throws a ThreadAbortException. Calling Abort does not immediately result in thread termination. It causes an exception on the thread to be terminated. You can use Thread.Join to wait on the thread to make sure that the thread has terminated.

Do Not Use Thread.Suspend and Thread.Resume to Pause Threads

Never call Thread.Suspend and Thread.Resume to synchronize the activities of multiple threads. Do not call Suspend to suspend low priority threads — consider setting the Thread.Priority property instead of controlling the threads intrusively.
Calling Suspend on one thread from the other is a highly intrusive process that can result in serious application deadlocks. For example, you might suspend a thread that is holding onto resources needed by other threads or the thread that called Suspend.
If you need to synchronize the activities of multiple threads, use lock(object), Mutex, ManualResetEvent, AutoResetEvent, and Monitor objects. All of these objects are derivatives of the WaitHandle class, which allows you to synchronize threads within and across a process.

Note: lock(object) is the cheapest operation and will meet most, if not all, of your synchronization needs.

Component-Based Architectural Style

Component-based architecture describes a software engineering approach to system design and development. It focuses on the decomposition of the design into individual functional or logical components that expose well-defined communication interfaces containing methods, events, and properties. This provides a higher level of abstraction than object-oriented design principles, and does not focus on issues such as communication protocols and shared state.

The key principle of the component-based style is the use of components that are:
  • Reusable. Components are usually designed to be reused in different scenarios in different applications. However, some components may be designed for a specific task.
  • Replaceable. Components may be readily substituted with other similar components. l Not context specific. Components are designed to operate in different environments and contexts. Specific information, such as state data, should be passed to the component instead of being included in or accessed by the component.
  • Extensible. A component can be extended from existing components to provide new behavior.
  • Encapsulated. Components expose interfaces that allow the caller to use its functionality, and do not reveal details of the internal processes or any internal variables or state.
  • Independent. Components are designed to have minimal dependencies on other components. Therefore components can be deployed into any appropriate environment without affecting other components or systems.

Common types of components used in applications include user interface components such as grids and buttons (often referred to as controls), and helper and utility components that expose a specific subset of functions used in other components. Other common types of components are those that are resource intensive, not frequently accessed, and must be activated using the just-in-time (JIT) approach (common in remoting or distributed component scenarios); and queued components whose method calls may be executed asynchronously using message queuing and store and forward.
Components depend upon a mechanism within the platform that provides an environment in which they can execute, often referred to as component architecture. Examples are the component object model (COM) and the distributed component object model (DCOM) in Windows; and Common Object Request Broker Architecture (CORBA) and Enterprise JavaBeans (EJB) on other platforms. Component architectures manage the mechanics of locating components and their interfaces, passing messages or commands between components, and—in some cases—maintaining state. 
However, the term component is often used in the more basic sense of a constituent part, element, or ingredient. The Microsoft .NET Framework provides support for building applications using such a component based approach. For example, this guide discusses business and data components, which are commonly code classes compiled into .NET Framework assemblies. They execute under the control of the .NET Framework runtime, and there may be more than one such component in each assembly.

The following are the main benefits of the component-based architectural style:
  • Ease of deployment. As new compatible versions become available, you can replace existing versions with no impact on the other components or the system as a whole.
  • Reduced cost. The use of third-party components allows you to spread the cost of development and maintenance.
  • Ease of development. Components implement well-known interfaces to provide defined functionality, allowing development without impacting other parts of the system.
  • Reusable. The use of reusable components means that they can be used to spread the development and maintenance cost across several applications or systems.
  • Mitigation of technical complexity. Components mitigate complexity through the use of a component container and its services. Example component services include component activation, lifetime management, method queuing, eventing, and transactions.
Design patterns such as the Dependency Injection pattern or the Service Locator pattern can be used to manage dependencies between components, and promote loose coupling and reuse. Such patterns are often used to build composite applications that combine and reuse components across multiple applications.

Consider the component-based architectural style if you already have suitable components or can obtain suitable components from third-party suppliers; your application will predominantly execute procedural-style functions, perhaps with little or no data input; or you want to be able to combine components written in
different code languages. Also, consider this style if you want to create a pluggable or composite architecture that allows you to easily replace and update individual components.