C# Optimizing Compiler

Let me share nice thing that I noticed about C# compilation model. What I did was, I created a small program to print an Int32 array to console. Then I went into IL and checked out various function calls that C# compiler has made. There was one nice thing that I noticed. C# compiler sometimes optimizes your code by itself. Let me show you,

Software Requirements Analysis: Five Use Case traps to avoid

Use cases have become a popular requirements development technique. Focusing on users and their goals, rather than on product features, improves the chances of developing a software package that truly meets customer needs. However, a mystique has grown up around use cases, and many organizations struggle to use them successfully. Here are several traps to avoid as your requirements analysts begin to apply the use case technique.

Trap #1: Use cases that users don’t understand
Use cases are a way to represent user requirements, which describe what the user needs to be able to do with the product. Use cases should focus on tasks a user needs to accomplish with the help of the system, so they should relate to the user’s business processes. Your users should be able to read and review use cases to find possible problems, such as missing alternative flows or incorrectly handled exceptions. If users cannot relate to use cases, there’s a problem. Perhaps they’re written too much from a technical, rather than business, perspective.

Trap #2: Too many use cases
When analysts are generating scores or hundreds of use cases, something’s wrong. This normally means that the use cases are written at too low an abstraction level. Each use case should be general enough to cover several related scenarios on a common theme. Some of these will be success scenarios, and others represent conditions in which the use case might not succeed — exceptions. If you are caught in a use case explosion, try moving up the abstraction level to group together similar use cases, treating them as alternative flows of a single, more abstract use case.

Trap #3: Overly complex use cases
The general guideline is that the number of steps in the normal flow of a use case should not exceed approximately a dozen. I once read a use case with nearly 50 steps in the normal flow. The problem was that the “normal flow” included many branching possibilities and error conditions that could arise, along with how to handle them. That is, the normal flow actually included alternative flows and exceptions. A better strategy is to pick a simple, default, well-behaved path through the use case and call that the normal flow. Then write separate alternative flows to cover variations on this and exception flows to describe the error conditions. This gives you a use case with multiple small packages of information, which is much easier to understand and manage than a huge use case that tries to handle every possibility in a single flow description.

Trap #4: Describing specific user interface elements and actions
Write “essential” use cases that describe the interactions between the user and the system at an abstract level, without incorporating user interface specifics. The use case description should not include a screen design, although simple user interface prototypes can be valuable to facilitate the use case exploration. I don’t even like to hear terminology in the use case that alludes to specific user interface controls. Saying “User clicks on OK” implies a GUI interface using a mouse and buttons. But what if it would make more sense to use a touch screen or speech recognition interface? Imposing premature design constraints in the use case can lead to a suboptimal design, unless you’re adding a new capability to an existing application where the screens already exist.

Trap #5: Not using other requirement models
Analysts who begin employing use cases sometimes seem to forget everything else they know about requirements specification. Use cases are a great aid for exploring requirements for interactive systems, kiosks and Web sites. However, they do not work as well for event-driven real-time systems, data warehouses or batch processes.

Avoid the temptation to force fit all of your functional requirements into use cases. Supplement the use case descriptions with a detailed list of functional requirements, nonfunctional requirements, graphical analysis models, prototypes, a data dictionary and other representations of requirements information. Use cases are valuable in many situations, but add them to your analyst toolkit instead of replacing your current tools with them

Object – Oriented Javascript

A lot of people (including myself, until recently!) think of that JavaScript is the language, they’re good at, just because they know C/C++/C# or they have some prior programming knowledge. This experience is not incorrect because it is easy to do simple things with JavaScript or to say with even little programming knowledge, we can start working with JavaScript. As the complexity and interactivity of this new generation of Web applications increasing, writing JavaScript code requires an entirely different approach.Recently, I have come across an Article on MSDN Magazine, which discuss about Object Oriented JavaScript and how one can use this support to do object-oriented development effectively in JavaScript. I found this concept very useful and thought to discuss with all. 

Object-oriented programming (OOP) is one popular approach that is used in many JavaScript libraries to make a codebase more manageable and maintainable. JavaScript supports OOP, but it does so in a very different manner from the way popular Microsoft .NET Framework compliant languages like C++, C#, or Visual Basic do it.

Get Linked with LINQ

With the release of Visual Studio 2008 , its been easier for developers to build richer data driven applications. One of the most significant feature of VS2008  is the introduction of LINQ which is an exciting evolution in data programming that provides common query capabilities within the programming language.  LINQ closes the gap between the programming world and the data world by providing a common query facility for in-memory and external data.  Integrating query capabilities into the programming language provides a simple, natural way to build strongly typed queries that benefit from design-time features like IntelliSense.  This is an exciting leap forward to bridge the gap between Data and Programming

Basically LINQ address the current database development model in the context of Object Oriented Programming Model. If some one wants to develop database application on .Net platform the very simple approach he uses ADO.Net. ADO.Net is serving as middle ware in application and provides complete object oriented wrapper around the database SQL. Developing application in C# and VB.Net so developer must have good knowledge of object oriented concept as well as SQL, so it means developer must be familiar with both technologies to develop an application. If here I can say SQL statements are become part of the C# and VB.Net code so it’s not mistaken in form of LINQ. According to Anders Hejlsberg the chief architect of C#.

             “Microsoft original motivation behind LINQ was to address the impedance mismatch between programming languages and database.”

LINQ has a great power of querying on any source of data, data source could be the collections of objects, database or XML files. We can easily retrieve data from any object that implements the IEnumerable<T> interface. Microsoft basically divides LINQ into three areas and that are give below.

·         LINQ to Objects {Queries performed against the in-memory data}

  ·         LINQ to SQL (formerly DLinq) {Queries performed against the relation database only Microsoft SQL Server Supported}

·         LINQ to XML (formerly XLinq) { Queries performed against the XML source}

 Here , I am putting some light over LINQ to Objects .I will surely take LINQ to SQL and LINQ to XML later in my next post.

 

LINQ to Objects

LINQ to Objects allows .NET developers to write “queries” over collections of objects. Traditionally, working with collections of objects meant writing a lot of looping code using for loops or foreach loops to iterate through a list carrying out filtering using if statements, and some action like keeping a running sum of a total property. LINQ frees you from having to write looping code; it allows you to write queries that filter a list or calculate aggregate functions on elements in a collection as a set.

We can write queries against any collection type that implements an interface called IEnumerable. This is almost any collection type built into the .NET class libraries including simple arrays like string[], or int[], and any List<T> collection.

 

        int[] nums = new int[] (0,4,2,6,3,8,3,1);

         var result = from n in nims

                          where n < 5

                          orderby n

                          select n;

foreach (int i in result)

console.writeline(i);

 

Output:

0

1

2

3

3

4

The backbone of LINQ to Objects is the Standard Query Operators that provide query operators similar to those found in a SQL like language.For example Aggregate,Sum,Cast,GroupBy etc.

  int[] nums = new int[] (0,4,2,6,3,8,3,1);

  int result = nums.Sum();

  console.writeline(result);

 

Output:

27

 Features at a glance:

• Query language over collections of objects
• Standard SQL like set of query operators, including joins and grouping
• New query operators can be added, fully extensible
• Intellisense and compiler syntax checking support in Visual Studio

To Get Started with LINQ you can look into this video :

            http://www.asp.net/learn/videos/video-212.aspx

   

How to document Use Cases

A use case represents a case of use of a system, ideally one that captures a functional requirement in terms of an identifiable and testable goal. So, what is the best way to document a use case? Approaches to content range from diagrammatic to textual, formal to free form, expansive and detailed to brief and abstract. The approaches to tool usage and authoring are just as varied. Here are some suggestions for a simple and streamlined, yet reasoned and thorough, approach to use case documentation.

First things first

In his classic paper, “Structuring Use Cases with Goals,” Alistair Cockburn made the following observation:

Use cases are wonderful but confusing. People, when asked to write them, do not know what to include or how to structure them.

Perhaps the first thing to clarify is what we mean by the term use case. A simple and literal reading is that a use case is simply a case of use: someone or something uses a system in a particular way.

 

When a user uses a system, she or he will perform a behaviorally related sequence of transactions in a dialogue with the system. We call such a special sequence a use case.

This description neatly captures the essence of use cases. A set of use cases can be used to capture the functional requirements of a system by slicing it up into its externally driven uses. Instead of identifying requirements as a disconnected and potentially incoherent laundry list of features, utility and usage are the principal drivers. However, framing a system’s functional requirements in terms of a sequence of actions raises a number of questions that affect how, when and by whom a use case is documented:

1. How should use cases be partitioned?

2. Who should be interested in and able to read use cases?

3. Who should write use cases?

4. Beyond requirements, what role can use cases play?

Without some answers to those questions concerning purpose and audience, we would be guilty of placing the cart before the horse if we tried to nail down how best to document a use case. Put another way, what are the requirements for this requirements approach?

How should use cases be partitioned?
In spite of the strong narrative feel of a sequence of transactions and a dialog with a system, and the implication of related concepts such as scenarios and user stories, documentation that focuses on use cases as scripts is tedious for both the reader and the use case’s author. There is more value in thinking about use cases with respect to goals rather than narratives: a use case is a usage of a system that is intended to achieve a particular outcome. The goal lends a clear focus to what is in (and not in) a given use case.

The emphasis on the goal begins with the name: A use case should have a definite name that clearly reflects its goal, and this should take the form of an imperative. For example, Open Account tells you clearly and actively what the goal is, whereas Account Opening is too passive and describes an ongoing state, Accounts describes a general heading rather than a single goal, Open/Close/Suspend/Modify Account describes four quite distinct goals, and Manage Accounts covers an indistinct number of goals, in spite of the apparent directness of its name.

Beyond a use case’s name, the goal can be elaborated in more detail, but this is not an excuse to break into essay-writing mode. A short paragraph is all that is needed. Beyond this, we can identify other features that add detail and precision to a use case, ideally following an inverted-pyramid style of presentation. But to better understand what we should include and exclude, we really need to know our audience.

Who should be interested in and able to read use cases?
Who cares about what a system should do? Well, put like that, it might be easier to identify who should not be interested! A use case offers common ground for technical and non-technical people to meet and agree on what a system should do. This includes developers, project managers, customers, and so on — in other words, pretty much all of the roles that have some kind of stake or direct involvement in a system’s development. What follows from this is that the documentation for a use case should be comprehensible to any of the parties involved; it should be no more technical than the domain it describes.

The sometime fashion for plastering use case documentation with UML diagrams — especially sequence diagrams — is deeply misguided. Such documentation has little bearing on the system’s externally visible behavior, and it alienates a significant part of the potential readership. It is a waste of everyone’s time. Use case descriptions should be concise, precise, readable and goal focused. They should not include parts that are optionally readable by different audiences — these just add clutter.

Who should write use cases?
This is an interesting question and one that ties back to the audience. In principle, anyone who can read a use case should be able to write a use case. The stakeholders who want the system developed conceptually own the requirements, and it is in their interest to be involved in formulating. On the other hand, project managers, developers, business analysts and other domain experts each hold different perspectives on a system and are likely to raise different questions and make different connections. In other words, it is not simply that anyone who cares about reading a use case should be able to write it; the combined perspectives and the mixture of skills of all these parties has the potential to offer a clearer understanding of a system’s requirements than the perspective of any one individual.

There is, in fact, a hidden question lurking in here: How should use cases be written? If all these different roles can contribute, then what is the most appropriate vehicle for doing so? Let’s first consider one of the least effective: The analyst writes all the use cases in a single document and emails this to the other parties for comments. This is typically an exercise in shared indifference that can stretch out over weeks and months with minimal involvement and correspondingly little feedback.

If you want to get people involved, then they need to be involved. If use cases offer common ground for technical and non-technical people to meet and agree on what a system should do, then they should meet and agree. A representative selection of individuals in a meeting room, armed with index cards, whiteboards and a shared goal will cover far more ground and to greater depth. How the use cases are recorded for posterity is a separate matter — a traditional document, a wiki, the index cards they were first scribbled on — but the simple act of collaborating is likely to make the single greatest difference to the quality of the resulting use cases.

Beyond requirements, what role can use cases play?
If you are thinking about use cases from the perspective of a sequential development life cycle, such as the waterfall model, you are likely to restrict their role to an early phase of development. They are likely to be treated as an output of requirements gathering and an input to a more comprehensive analysis, the output of which is fed into a design phase, and so on down the line. That approach misses one of the original goals and key strengths of a use-case-driven approach: incremental development.

In observing that a use case represents a slice of a system’s behavior, this is not simply a metaphor; it is a guide to how the system can be developed: a use case at a time. Use cases help to define scope and they help to define tests, especially if use cases are documented with respect to the preconditions and post-conditions that define goal fulfillment.

Not all requirements are created equally, which means that different use cases have different priorities, technical challenges and levels of risk. In looking to grow a system incrementally, it is those different aspects that need to be balanced over time. Incremental development by use case ensures that a system is developed in functionally complete slices, offering stability, certainty and visible signs of progress — or, to be realistic and evenhanded, early signs of trouble if there are problems.

Developing by use case also allows the development to respond to new needs and discoveries as the system unfolds. Importantly, trying to document all of the use cases up front is not only unnecessary, but it is likely to be harmful. Start with a kernel of key use cases and grow from there.

Crazy Enums

There is one intresting thing that I want to share. Almost all of us have worked with .Net Enums. Let me show you something,
Create a project and add one Enum to it,
enum MyEnum
{
  Orange=0,
  Red=1,
  Green=2
}
Now create another class where we will use this Enum,
class Program
{
  static void Main(string[] args)
  {
     MyEnum obj;
     obj = (MyEnum)5;
     Console.WriteLine(obj.ToString());
     Console.ReadLine();
   }
}
Did you noticed something? Our Enum only had 0,1 and 2 as valid values. I went on and assigned 5 to it. Now try compiling this code. Aha! no compilation errors. Now try running this. Everything goes well and 5 gets printed on console. Did you expected this?
I never expected this. Did Microsoft forget about type safety and type checking issues while copying from Java Enums? I think Java enums works fine.
If you ever worked with Bit Flags you will some how realize that all of this is due to them. Bit flags can actually take up values which are a combination of values that are defined in Bit Flag Enum. Here is an example:
[Flags]
internal enum Actions
{
  None = 0,
  Read = 0X0001,
  Write = 0X0002,
  ReadWrite = Actions.Read Actions.Write
  …
}
There are number of threads going on in forums related to this. Just keep this in mind before using Enums.

YouTube API

Hi everyone,

If you remember my previous post, I explained about the Mashups. What’s hot online these days? Video. What’s hot in web mashups? Video. You Tube provides an API that can be integrated into our own application.

The YouTube Data API allows client applications to view YouTube content in the form of Google Data API feeds. Your client application can use the YouTube Data API feeds to fetch video feeds, comments, responses, and play lists, as well as query for videos that match particular criteria.

How to integrate YouTube API in your own Application

1. For using the YouTube API, Firstly u have to register yourself on http://www.youtube.com/index

2. After getting registered click on the Developer Profile http://www.youtube.com/my_profile_dev

3. This will generate a Developer Id.

Testing for security in the age of AJAX Programming.

Ajax programming is one of the most exciting new technologies in recent history. Ajax (Asynchronous JavaScript and XML) allows a Web page to refresh a small portion of its data from a Web server, rather than being forced to reload and redraw the entire page as in traditional Web programming. Since they can make frequent, small updates, Web applications written with Ajax programming can present user interfaces that are more like desktop applications, which are more natural and intuitive interfaces for most users. Web applications have become prime targets for malicious users and hackers performing SQL Injection and similar attacks.

The flexibility and creativity that Ajax programming affords the developer also places a corresponding burden on him to ensure that his code is secure against these new threats. Also, since delivering a secure application is part of delivering a quality application, the burden is probably felt even greater by the Quality Assurance (QA) team. The QA team will now need to develop an entirely new set of functional, performance and security testing methods in order to thoroughly test the quality of applications using Ajax programming against SQL injection attacks and other security concerns.

It’s in the Code
As an example; consider a hypothetical gourmet food e-commerce Web site. This site displays a map of the world to the user, and as the user navigates the mouse pointer over each country, the page uses Ajax programming to connect back to the Web server and retrieve a list of goods originating in that country. The following C# code snippet shows the Web method in which the database is queried:[System.Web.Services. WebMethod]
public System.Collections.IEnumerable GetProducts(string country)
{
   // update the select command to use the country parameter
  this.SqlDataSource1.SelectCommand = “SELECT * FROM [Product] WHERE Country = ‘” + country + “‘”;
   // query the database and return the results
   return this.SqlDataSource1.Select(DataSourceSelectArguments.Empty);
}

Some readers may notice a glaring security hole in this code. The database query is being constructed on the fly with un-validated user input being sent directly to the database. This insecure programming technique creates a vulnerability to SQL injection attacks, which are potentially devastating to the Web application and its users. SQL injection vulnerabilities allow attackers to execute their own SQL queries and commands against the database, rather than those that the developers of the Web site intended. The entire database, including customer names, addresses, and credit card numbers, could be downloaded by such a command. The prices of the products could be modified. The entire database itself could be permanently deleted. Clearly, this is a very serious issue. If the developer fails to notice the problem, the next line of defense is the QA team.

The average developer will probably do a quick, cursory test of the application before passing it to the QA department, without checking thoroughly for SQL injection vulnerabilities or other important problems. Instead, he will mouse over a few countries on the map, check that the displayed results match those in the database, and then pass the code off. The average QA engineer typically will be much more thorough. He will mouse over every country on the map and check that the results match. He might even set up an automated test script that will mouse over every single pixel on the screen, and he will check to see if there are any errors in the Ajax programming or underlying page code.

But even this extreme level of thoroughness won’t be enough to find the SQL injection vulnerability. By using a Web browser (or automated script recorded from a Web browser) as his test tool, the tester has limited his potential requests to only those which the browser can send, and the browser is itself limited by the source code of the Web page. In the example above, the browser would be limited to sending only valid country parameters to the GetProducts method, since only valid countries are present in the page code. In other words, no matter where the user (or QA engineer) navigates with the mouse, the only parameters that would be sent are “GBR”, “FRA”, “USA”, etc. Using only these valid, well-formed parameters will never reveal the SQL injection vulnerability. To do that, the QA team needs to expand their arsenal of test tools beyond browsers alone.

Since browsers are so limited, hackers generally don’t use them to break into Web applications or execute their SQL injection attacks and other hacks. They use tools that operate at a much lower level, tools that are capable of sending raw HTTP requests to an address and displaying the raw HTTP response. Netcat is a popular tool for this purpose, as is telnet, which has the benefit of being installed by default with virtually every modern operating system. So, instead of opening a browser, navigating to a page, and viewing the rendered HTML response, the hacker types:nc 172.16.60.250 80 GET / HTTP/1.0

and then receives the response:HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Wed, 10 May 2006 18:04:56 GMT
…

While interacting with Ajax programming may not seem like it would generate a round-trip request to the server since it doesn’t refresh the entire page, under the covers it’s doing exactly that. Like programming in standard hyperlink navigation or form submission, Ajax programming actions always have an HTTP request and response. So, armed with his low-level HTTP requestor tool, the hacker is now free to make attacks on the application that could never be possible with a browser alone. Instead of sending “GBR” or “FRA”, he could send “XXX”, or “!@#$%”, or “x’ OR ‘1′ = ‘1″, which in this case would successfully exploit the SQL injection vulnerability.

Thinking like a Hacker
In order to successfully defend against the hacker using SQL injection or some other attack, the QA engineer has to think like the hacker. Since the hacker doesn’t restrict himself to using just a browser to attack a Web application (with or without Ajax programming), neither should the QA engineer use just a browser to test it. At a minimum, the application should be tested with the same type of raw HTTP tool that the hacker uses. An even better approach is to use an automated security analysis tool that performs these tests. Automated tools can make thousands of test requests in an hour; work that would take a QA engineer a week or more to perform manually. Additionally, these tools generally have an extensive set of techniques that they use to detect security defects such as SQL injection vulnerabilities QA engineers would unlikely be aware of these techniques unless they had a background in information security. There are several excellent security analysis tools available commercially. Additional resources for learning about Web application security and security analysis tools include the Web Application Security Consortium (WASC) (www.Webappsec.org), the Open Web Application Security Project (OWASP)(www.owasp.org), and the SANS (SysAdmin, Audit, Network, Security) Institute (www.sans.org).

It seems likely that Web applications using Ajax programming are the future of Web development. The robust user interface that Web pages comprised of Ajax programming can provide represents a huge leap in usability over traditional Web pages. But, this power comes with a price: the programmers and QA engineers must move beyond browsers alone when testing the application. Security vulnerabilities can lurk in code that is accessible only by specialized low-level request tools. Hackers will be more than willing to use these tools against the Web applications, so the QA team must use the same tactics to find the vulnerabilities first.

AJAX (Anatomy of its operation and the technologies used)

In case one has heard about the AJAX hype, but still has missed out some technical working or concept, don’t look beyond this  This is a brief write – up on the Anatomy of the Ajax operation and the technologies used here.  

What is AJAX?   Ajax is nothing more than an approach to web interaction. This approach involves transmitting only a small amount of information to and from the server in order to give the user the most responsive experience possible.

Is AJAX New?  

Not really. Remote JavaScript, of which AJAX is one example of, has garnered the most attention as of late, provides the ability to interact with a server with XML data. AJAX is possible because of the  Internet Explorer 5  and later offer an XMLHTTP object while Mozilla based browsers provide an XMLHttpRequest object.    

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               Both Both of these objects offer essentially the same ability to request XML data from a server and process the data in a similar fashion. The server-side AJAX component can be in any technology providing XML can be delivered dynamically.  

Technologies Behind Ajax  are: 
HTML/XHTML  : This is used for primary content representation.
CSS                   :  It provides stylistic formatting to XHTML
DOM                  :  This is for dynamic updating of a loaded page
XML                   : This is for data exchange format.
XSLT                 : It transforms XML into XHTML (styled by CSS)
XMLHttp            : Primary Communication Broker 
JavaScript        : Scripting language used to program an Ajax engine .
 
The two core technologies that makes AJAX work are:
Ø       A JavaScript enabled browser that supports either XMLHTTP or XMLHttpRequest objects.
Ø       An HTTP Server technology that can respond in XML.  
 An AJAX application in its simplest form is essentially a standard HTML user interface with JavaScript functions to interact with an HTTP server that can generate XML dynamically. Any dynamic Web technology ranging from CGI to servlets even including Java Server Faces, .Net Components can serve as a server-side AJAX technology.  Suppose there is an HTML user interface with elements such as an input field .The input field “searchField” will call the Javascript function “lookup( )” on the onkeyup event.
 <input type=”text” id=”searchField” size=”20″ onkeyup=”lookup (’search Field’);”>   
How to issue an XMLHTTP Request?? 
The actual code in Javascript that can issue an XMLHTTP request:   
if (window.XMLHttpRequest)
 {  
req = new XMLHttpRequest();
 }
else if (window.ActiveXObject)
{  
req = new ActiveXObject(“Microsoft.XMLHTTP”);
} 
This code snippet allows both major browser families (Internet Explorer and Mozilla/Safari) to make independent HTTP requests to servers. This code first checks to see if the browser supports either of the supported XMLHTTP objects and then instantiates one.  Using XMLHttp After creating the xmlHttp object, the object is initialized with the open () method;
It accepts three arguments:
 a.)    Request Type  : It is the HTTP request method (GET or POST)
 b.)    URL : It is the URL of the server where the request is send
 c.)    Async : Boolean value to indicate asynchronous call                                  
E.g : req.open (“GET”, url, true);  
In the above example the Async argument denotes a TRUE value which denotes asynchronous call (The “A” in AJAX). (This means that the browser can continue doing other things while the request is being fulfilled. A false value in the open method denotes a non-asynchronous or serial processing. This is not recommended, since the browser will cease operations until the response has been returned. ) 
After initializing a connection using open, the onreadystatechange call is made (only for asynchronous calls). This registers a callback function, which will be invoked once the request is complete:
 req.onreadystatechange = processXMLResponse;  
The function processXMLResponse( ), which processes the XML response, is invoked when the request is fulfilled. A callback function can also be declared inline in the onreadystatechange statement:  
req.onreadystatechange = processXMLResponse (){   // process request };  
Any header content can also be specified using req.setRequestHeader. Such as:   req.setRequestHeader(“Cookie”, “someKey=true”);  
Once the XMLHTTP request object (req) has been fully initialized, initiating a call to the server can be done using send( ):  
   req.send (null);
For GET requests, a null value or empty string “” is used.  POST requests contain a string argument with form data. They also require the Content-Type to be set in the header of the request.  The callback function, which is called once the request has been fulfilled, usually has some code to make sure the request has no errors. This can be accomplished by checking the readyState as well as the overall status of the HTTP request. (A readystate of 4 means the XMLHTTP request is complete and 200 means it was a success (as opposed to 404 etc..)
function processXMLResponse()
{    
       if (xmlreq.readyState == 4)  
 {  
       if (xmlreq.status == 200)
        {  
             // Process the XML response…   
       }
    }
}  
Processing the XML response is done using standard Javascript DOM methods.
For example to extract the customer name from the incoming XML stream:  
<customer>      Nupoor   </customer>  
The following code snippet can be used :  
var name = req.responseXML.getElementsByTagName(“customer “)[0];  
Parsing more complex XML involves iterating through the elements using code such as:  
for (i=0 ; i < elements. Length ; i++)
{
  for (j=0 ; j < elements[i].childNodes.length ; j++)  
{
    var ElementData =   elements[i].childNodes[j].firstChild.nodeValue; 
}
} 

MSMQ

In this article I am writing about a technology that is currently being used in my project. “MSMQ (Microsoft message Queuing)”. 

Suppose you are working on an application that needs to communicate to another process that is not currently running but you have to send message to that application then the solution to this problem is MSMQ.It is a technology by Microsoft through which applications running at different times to communicate across heterogeneous networks and systems that may be temporarily offline. MSMQ provides guaranteed message delivery, efficient routing, security, and priority-based messaging. It can be used to implement solutions for both asynchronous and synchronous messaging scenarios. 

Real life Senario: In my current project we have a third party accounting software (i.e. Quickbooks). We are using MSMQ to post transactions to Quickbooks from a windows windows application. We have a QB manager that picksup messages from MSMQ’s message Queue. And as this is totally independent of our window application so it can be running simultaneously with the application but not always. In that case MSMQ stores all the messages in its queue and at aome later time when QB manager runs it picks up all the messages from the queue and post to QB and this is done in the same sequence as posted by window application.

While working on this project I was a bit excited about MSMQ, So I tried to search some details in regard of what it is and how we can use it. I found a number of articles showing what the power of MSMQ is? So here in this article I tried to gether up some links about this technology so that it can be helpful to me and everyone else who is working or wants to work on this technology and have a better understanding of MSMQ.

Ill add up more details as I get into more depth of MSMQ.Here are some useful links. 

For Detailed information about what is exactly MSMQ go to: 

http://msdn2.microsoft.com/en-us/library/ms711472.aspx 

MSMQ is very useful in developing Distributed Applications. There is an article on MSDN which describes how to use recoverable messages, transactions (alone or combined with database transactions), and acknowledgements with MSMQ and the Microsoft .NET Framework. This is really helpful in developing a robust distributed application. Go to 

 http://msdn2.microsoft.com/en-us/library/ms978430.aspx 

There is also a very good sample application available for your reference on how to actually use it in your application.

http://www.codeproject.com/dotnet/mgrmsmq.asp

At Wikipedia: MSMQ is essentially a messaging protocol that allows applications running on disparate servers to communicate in a failsafe manner. A queue is a temporary storage location from which messages can be sent when conditions permit. This enables communication across heterogeneous networks and between computers which may not always be connected. By contrast sockets and other network protocols assume that direct connections always exist.MSMQ has been available to developers on Microsoft platforms since its first version, and has commonly been used in enterprise software built with Visual Studio, both in the unmanaged pre-.NET incarnation (version 5 and 6), and in Visual Studio .NET. Microsoft also has incorporated MSMQ in its messaging technology framework, Windows Communication Foundation. Under WCF, MSMQ can be used to provide secure, reliable transport with a unified programming model compatible with other communications standards.For complete article go to 

 http://en.wikipedia.org/wiki/Microsoft_Message_Queuing  

Conclusion:Talk of enterprise applications, things that come to your mind are transactions, messaging etc. Talk of messaging, what strikes immediately is MSMQ which stands for Microsoft Message Queuing. MSMQ provides a great framework for applications that use messaging infrastructure.