REST is an acronym for Representational State Transfer. REST can be described as an architectural style (not a standard) of networked systems. This architecture is vastly becoming popular with Web services. The underlying protocol which is used with web services is http and the distributed systems are connected through the web (internet). REST is an alternative architectural style to SOAP (Simple Object Access Protocol) which instantly gained popularity with the advent of web services and is the widely used standard for web services data transfer.  In this essay I would highlight on the working of REST, the implementation style, characteristics, and principles and compare the architecture with SOAP and try to conclude which one might be better and under what circumstances. In the end I would explain how to use REST with web services by designing a dummy web service which follows the REST architectural style 

So what does Representational State Transfer mean

 As we all know Internet is a collection of various resources. All the resources on the internet (including the web services with a published wsdl) can be accessed through a uniform resource locator (URL) e.g. http://www.mywebsite.com/mywebservice.With Web 2.0 in action static websites are loosing visitor’s interest and we see more and more dynamic web applications like forums, interactive blogs, websites which are regularly updated by users. Example of these applications are wikipedia where the user can moderate the content instantly , youtube where users can update their videos and they immediately become available to potentially everywhere the web application could be accessed with a browser and EBAY where there is real time bidding by the users of the web applications. With REST as the underlying protocol is Hyper Text Transfer Protocol (HTTP) the application changes or transfers its state after each http request / response for each requested resource. 

 So REST can be considered as an architectural style where a web application changes its state constantly and it is named as Representational State Transfer. 

Roy fielding (A researcher of this architectural style, defined the key characteristics, motivations, benefits and the circumstances where its implementation might be beneficial) explains REST as:  

Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.”

  The motivation for REST was to capture the characteristics of the Web which made the Web successful. Subsequently these characteristics are being used to guide the evolution of the Web.In the beginning of the essay I emphasized on REST being an architectural style and not a standard. REST is a way in which web services can be configured to deliver data streams or we can say that client accesses a resource on the World Wide Web and is certainly not a standard like HTTP or XML. The concept is much similar to what Web 2.0 is, you want see W3C putting out a specification on the working details on REST. Same is true for the vendors of software development technology, the software giants like Microsoft, sun and other platforms manufacturers won’t come out with a REST development toolkit simply because it’s an architectural style. By architectural style I mean a way of implementing things or we can say that defining a framework using the existing technology and using it in a way which is more efficient and effective for us. Although REST is itself not an industry standard but as it works with the Web and the distributed world of internet it works in parallel with many industry renowned standards. These include HTTP, XML, HTML, URLs and various file formats like gif, jpeg, text/xml, text/html and other MIME types. Many of the services especially the web services that we use as out day to day routine for our usage and software development services are based on REST and we are even not aware that we are using it. This is because REST does not work with minor implementation details it has more to do with the overall integration of the components that make a web application or a web service work. 

So what are some of the key characteristics of REST? 

As we know that the model that http follows a Client Server paradigm (as it works on the internet)  where the client is the consumer or requests a resource identified by a URL and located on the World Wide Web and the server is a web server which has the required resource and delivers it using HTTP. The Client Server paradigm is further classified into a pull or push based implementation Style. REST is essentially a pull-based implementation style of http where the consumer (consuming services, applications e.g. browser) or client pulls various representations (resources). Another Key characteristic that rest follows and is due to the http being the underlying protocol is it’s stateless. As we know that http is a stateless protocol so each request from client to the server in this http pull-based implementation style should contain all the information which is necessary for the server to understand the request. In other words the client cannot take advantage of any information that is stored in the server’s context and has to send the client’s info with every representation transfer. An optimization and a key characteristic that REST utilizes to overcome performance limitations and overheads is CACHING. When the web server responds to any of its clients with the requested resource the responses should have the ability to be marked as either cacheable or non-cacheable depending on the capability of client which might be an application or a service. So if the client if Caching enabled the performance can be optimized as the implementation architecture supports caching. What it means essentially is if the same resource is requested by the client again and again or for instance the same parameter or argument is passed to a method exposed by a web service the client should know what the service will return and it should directly get the desired result without going through the whole request/response process. Another key characteristic of REST is all REST implementation should follow a uniform interface .This means that all the resources located on the web server can be accessed by using a generic interface such as HTTP Get, Post, Put or delete. In a REST based implementation, each resource that is requested from a web server can be identified with a unique URL. This is pretty much how internet works, the critical components here are the Client and Server Applications, HTTP as the request/ response based protocol, and the Domain Name System (DNS) which resolves the host names to IP Addresses to exactly know where the requested resources are physically located. So it is essential to use named resources while implementing REST. Another key characteristic of REST is interconnected resource representations. This essentially means that the representations of the resources are interconnected using URLs, thereby enabling a client to progress from one state to another. REST uses Layered components which imply that intermediaries, such as proxy servers, cache servers, gateways, etc, can be inserted between clients and resources to support performance, security, or in other words using intermediary devices between the client and the server does not restrict the client from accessing the server. Etc  Designing web services using REST: 

What are some of the key design principles that we have to keep in mind while designing web services that makes use of REST? Primarily all the conceptual entities that the designers or developers wish to expose as services need to be identified. The design principle is not only limited to REST but it’s a general rule of thumb for good web service design. As we know, one of the characteristics of REST is using named resources. Recall that resources are named as URLs .REST uses a particular naming convention to access resources on the web server. REST proposes to use nouns as resource name instead of verbs.  

E.g. URL such as http://www.bookstore.com/books/getBook?id=11234 should not be used instead the resource should be named as http://www.bookstore.com/books/11234   REST follows the phenomenon of categorization of resources. The resources should be categorized in terms of whether they can only be accessed and not changed by the client. Such resources are called Read Only Resources. With Read only resources clients can just receive a representation of the resource. In addition to this the clients can add new resources or modify existing ones. REST suggests categorizing the resources based on resource types. If they are read only resources which the client can access but not modify, only HTTP Get should be specified as an access method whereas if the clients can update the resources then HTTP POST, PUT, and/or DELETE can be used. In this context all resources accessible via HTTP GET should not have any side effects. That is, the resource should just return a representation of the resource. Invoking/calling or requesting the resource should not result in modifying the resource in any way.   As from the above description it is evident that REST (Representational State Transfer) follows a state based implementation, it supports how we can drill down further into the application. REST supports navigation by supporting navigational links so the state of the request changes and recorded.   For designing a REST style web service some performance optimizations are provided as the design guidelines. REST proposes not to present the whole data in one single response simultaneously to the user (client). Instead present a portion of the data with the ability to drill down information by providing navigational links so the user can drill down by again requesting a resource identified the navigational link and thus the state of the client application changes.   If a web service is to be designed that uses REST as the architectural model, the format of the response data has to be defined using a standardized schema such as the Data Type Definition (DTD) or W3c schema or Schematron e.t.c For those services that require a POST or PUT to it, also provide a schema to specify the format of the response.   The SOAP and REST comparison:   Having discussed the working of REST, characteristics and principles of a typical application that follows a REST based architecture and knowing that it is a design alternative to SOAP (Simple Object Access Protocol) the question that comes to our mind is when to use REST and when to use SOAP , what is the key factor that answers this question ? What are the benefits of REST over SOAP and vice versa? Although there are plenty of overheads which can be immediately noticed with implementing SOAP, writing a wrapper class that puts a SOAP envelope on every request response that goes to and from the web service on the client side and configuring the service itself to parse those request may sound like a lot of work. But primarily we now have tools to do it; I have worked with Microsoft Visual Studio where if a wsdl file hosted on the internet is given as an input all the wrappers required for the web service and initializing SOAP are generated automatically, same is true for many DELPHI environments. The advantage of using SOAP is “sending complex data structures to the web service”.  Development tools like Visual Studio or Delphi can read the WSDL from the web service and that gives you the "INTELLISENSE" auto completion functionality that can save a lot of coding time. The drawback with SOAP is that there is more overhead in the construction of the method request and with the parsing of the request on the web service end.  When you have a web service that is serving thousands of requests a minute or second, that overheard may not be needed. This is in contrast with REST where simple HTTP Get and PUT commands are used to interact with the web service. You compose a URL for your web method request and the service sends back a response.  The response is usually in XML, but that is dependant on the functionality of the web service. For web services that have relatively simple data types, using REST can provide the functionality that is needed.  You also get the advantage of testing individual method requests from a browser as the method request is basic URL. Another big advantage of using REST over SOAP is by sticking to simple semantics (especially if you limit yourself to GET as much as possible); it scales much better as it can take advantage of all levels of caching between you and the server. REST takes advantage of the existing scaling mechanisms the internet has grown on top of HTTP - something SOAP cannot do.
 The complex data types can still be used with REST by including them as payloads - you just have to manage interpreting it yourself instead of relying on a rich library layer to make it feel like some native type in your program. So if we compare the contrasting architectural styles, REST is the way to go if you are looking for better performance and the web service consists of simple data types where as SOAP would be better if the client application has to be developed fairly quickly and Complex data structures are to be used.   A REST example – An Online Library Catalogue exposing library data as a service ( A self created dummy service to demonstrate REST) :   Here I would describe the whole process of how REST works and some of the common practices that are followed by developing a simple Library Catalogue Service which would define a couple methods of displaying a list of books and listing a particular book’s details. The functionality that is exposed by the service is:   Generating a list of books   Generating details of a particular book  

 

Generating a list of books:


The web service presents a URL to a “Book listing” resource. For example, a client would use this URL to get the parts list:

http://www.books-online.com/books

The client does not know anything about how the listing is generated by the service. All the client knows is that if he/she submits the above URL then a document containing the list of books is returned. Since the implementation is transparent to clients, the Book’s catalogue is free to modify the underlying implementation of this resource without impacting clients. This follows two major principles or concepts of Software Design, loose coupling and encapsulation.Here’s the document that the client receives whenever the above URL is accessed:

<?xml version="1.0"?>
 <p: books xmlns:p=http://www.books-online.com xmlns:xlink="http://www.w3.org/1999/xlink">
 <Book id="00001" xlink:href="http://www.books-online.com/books/00001" mce_href="http://www.books-online.com/books/00001"/>
 <Book id="00002" xlink:href="http://www.books-online.com/books/00002" mce_href="http://www.books-online.com/books/00002"/>
 <Book id="00003" xlink:href="http://www.books-online.com/books/00003" mce_href="http://www.books-online.com/books/00003"/>
 <Book id="00004" xlink:href="http://www.books-online.com/books/00004" mce_href="http://www.books-online.com/books/00004"/>
 </p: books>    Note that the parts list has links to get detailed info about each book. This is a key feature of REST. The client transfers from one state to the next by examining and choosing from among the alternative URLs in the response document thus resulting in a change of State which REST is all about.   Generating details for a particular book: Any book’s details can be generated by accessing the URL associated with the book’s detail (as presented by the xml in the response above). Again the client receives and XML document which can be parsed for the book’s details.

The web service makes available a URL to each part resource. Example, here’s how a client requests part 00345:

http://www.books-online.com/books/00001  

Here’s the document that the client receives:  

<? Xml version="1.0"?>
<p: Book xmlns:p="http://www.books-online.com"            xmlns:xlink="http://www.w3.org/1999/xlink">
<BookID>00001</BookID>
 <Title>SOA Concepts, Design and Technology</Title>
 <Description>This book is about Services Oriented Architecture</Description>
 <Author>Thomas Erl</Author>
 <Number of Copies>2</Number of Copies>
<Section>Computer Books</Section>
</p: Book>          

In this tutorial I would be talking about integrating databases in your .Net Applications specifically C# applications. ADO.Net is a .Net framework’s library which is essentially the same for ASP.Net for web development and other desktop applications using C#.Net or VB.Net. In my experience the database that was used most frequently was Ms-SQL Server, off course because both are Microsoft products. .Net seems to integrate with SQL Server very easily and gives better performance.  (ADO.Net provides a Namespace specifically for SQL Server which might result in better performance with SQL Server. It is prescribed to use System.Data.SqlClient when using SQL Server as your back end instead of System.Data.OLEDB)  Having said that .Net can connect to all the major databases systems. The ones I have worked with include Oracle, Sybase SQL Anywhere, MySQL and MS-Access. For the sake of discussion I would be connecting to SQL Server Database here to show how to connect to databases using ADO.Net and do the routine operations.In many books I have seen hard coding of ADO.Net objects and configuring the data sources and some properties of ADO.Net objects which pisses me off. Simply ask yourself the question How are you going to deploy such software? Is it easy to replicate your development environment on the Target client machine? NO !! Not at all!! It’s a nightmare. So setting all the properties in code and all the configurations in a configuration file is the mostly used conventional way of doing things.

Prerequisites for this are some knowledge of C# and I would assume that you have a DBMS available that you wish to use for your practice or running sample code against.

Connecting to Database:
The easiest way to ensure database connection is through a UDL (universal data link) file. Simply create a new text file on your desktop, open it and from the file menu choose the “Save As” Option. In the “Save As” dialogue for file type select “All files” and for file name specify “abc.udl” and save the file. When you close the file you should have a new file called abc.udl. UDL FILES are a Microsoft proprietary file format that is used to configure data sources.

Simply enter your Database info and select the “Test Connection” Button. Once you see the message box that says “Test Connection Succeeded” close the dialogue by clicking “OK” and close the “Data Link File”. Open the file with notepad or any text editor and the third line in the file is the connection string.

 An Alternative approach to connection:

If the above mentioned process sounded too complicated which it is not the following connection strings can be used:

 For SQL Server use: 
Data Source=myServerAddress;Initial Catalog=myDataBase;User Id=myUsername;Password=myPassword;

 For MS-Access use:
Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\myFolder\myAccess2007file.accdb;Persist Security Info=False;

 For Oracle use:
Provider=msdaora;Data Source=MyOracleDB;User Id=myUsername;Password=myPassword; 

 For MySQL use
Provider=MySQLProv;Data Source=mydb;User Id=myUsername;Password=myPassword; 

The first step to talk to databases is to include a reference to ADO.Net library in your code. You don’t need to do it explicitly. Simply use the following statements in the beginning of your code.

 using System.Data;
using System.Data.OleDb; 

Once you have decided what database you want to connect and what connection string you have to use then your C# code starts. I would make a small method that returns an instance of System.Data.Oledb.OLEDBConnection if a successful connection is established else returns a null. 

/// <summary>/// Open the Database Connection/// There should be an entry for “Database” in the app.config
/// </summary>///
<returns></returns>
public System.Data.OleDb.OleDbConnection OpenConnection()
{
    OleDbConnection conn;
    string connectionString = ConfigurationSettings.AppSettings["Database"];
    try
       {
           conn = new OleDbConnection(connectionString);
           conn.Open();
           return conn; 
     
}
    catch (Exception ex)
    {
        return null;
    }           

 }

 Executing an SQL Statement:Whenever you are designing or developing a database centric application, you have to perform database operations ( Select , Insert , Delete , Update) from various places within your application. Here we would discuss about the most common scenarios like there is a dropdown list from where the user selects one or more items. How to populate the Combo box? . We want to show the user search results in a datagrid or a datagridView  in a windows forms or a web form. ? We want to add new records in the database How to do it ? Below you will find answers to all such questions. For the sake of discussion let us consider we have a table in our database called Student and the columns/attributes of the table are Name,ID,Date_Of_Birth,Address,Email , Phone and SSN. I will show you how to manipulate the table from our application using ADO objects and give you some example code to play around. 

Executing a Select Statement for a dropdown list:
 Suppose you have a form where you want to update the students record.You have a dropdown where you will display all the SSN of the existing student. When the user selects the SSN the form gets filled automatically by selected students information. The user can then make changes and click a button and the changes are saved to the database. 

OK, the easiest way to load a combo box or a drop down list is by using an OLEDBDataReader object. The method with the code is shown below:

 public OleDbDataReader ExecuteDataReader(string query)
{
     try 
       
{
 
    
         OleDbDataReader reader;
              OleDbConnection conn = OpenConnection();
              OleDbCommand cmd = new OleDbCommand(query, conn);
              reader = cmd.ExecuteReader();
              return reader;
        } 
      
catch (Exception ex)
 
      
{
              return null;
        }
} 
You can call the method , get the data reader and then loop through all the items this would be something like on the form_load event of your form: // This is how you call the ExecuteDataReader Method
OleDbDataReader dr;
dr = ExecuteDataReader(“Select SSN from student”);
cmbStudents.Items.Clear();        
while (dr.Read())
{
  comboBox1.Items.Add(dr[0].ToString().ToString());
 
Executing a Select Statement to show in a datagrid or DataGridView:
The process of showing some rows of the database on a datagrid or a datagridview is essentially the same process with slightly different objects and the ways you use them.I am really pretty much against hardcoding stuff in the datagrid , the conventions you find in your first C# Book probably.I learned the fact, the hard way and believe me its no good at all. Probably good to make u understand what are the properties and what objects are closely connected or work together in the architecture.Always try to set the properties from your code instead of the designer view when it comes to ADO.Net objects like DataSet,DataReader,DataAdapter,DataGrid,Connection,Command e.t.c. Whenever you want to use Datagrids or DataGridView , the essential property is the “datasource”.This requires an instance of the dataset which has the results of the query passed in. The essential ADO.Net objects here are DataSet,DataAdapter and the DataGridView itself and that is it !!Following is the example of how to use: 
/// <summary>/// Given a query executes a dataset and returns the dataset
/// Ideal when to be shown on a Grid View for searching or display
/// </summary>
/// <param name=”query”>The Select query that returns a dataset when executed</param>
/// <returns></returns>
public DataSet ExecuteDataSet(string query)
{
    DataSet ds = new DataSet();
    try
    {
        OleDbConnection conn = OpenConnection();
        OleDbDataAdapter da = new OleDbDataAdapter(query, conn);
        da.Fill(ds);
        conn.Close();
        return ds;
    }
    catch (Exception ex)
    {
        return null;
    }
} 
This is the calling code from where this method would be called:
 DataSet ds = ExecuteDataSet(“Select * from Student”);
 
dataGridView1.DataSource = ds.Tables[0]; 
Note: You would also have to use dataGridView1.DataBind() if you are programming in ASP.Net 
Executing an SQL statement that updates a table:
Here we are not selecting any rows from the database rather we want to run an insert , delete or update sql statement so we don’t want anything back from the database.So the OLEDBCommand instance is treated in a slightly different way. Below is a sample method which might be used to execute and update a database table: 

/// <summary>
/// executes a given insert query and returns true if query is executed ok/// </summary>
/// <param name=”query”>The insert query which does not return any dataset</param>
/// <returns></returns>
public bool ExecuteInsertUpdateQuery(string query)
{
    bool toReturn = false;
    try
    {
        OleDbConnection conn = OpenConnection();
        OleDbCommand cmd = new OleDbCommand(query, conn);
    
   cmd.ExecuteNonQuery();
        toReturn = true;
        conn.Close();
        return toReturn;
    }
    catch (OleDbException dx)
    {
        throw dx;
 
   }
   catch (Exception ex)
   {
        return false;
   }
}
This method can be used as:  string insertQuery = “insert into student values(‘1’,’2’,’3’);
bool status = ExecuteInsertUpdateQuery(insertQuery); In a similar way delete and update queries can be passed in and the method would return a true or a false indicating whether the statement was executed properly or not. So this was a brief brief introduction and a short tutorial, I would say “ADO.Net Crash Course” and I think there is much more to ADO than what I showed. Keeping in mind these are the essentials which you should know if you want to enter the database applications world with Microsoft.Net.  If you make any additions to this article or simply provide feedback so I can make the required changes, or you want free consultation with your design, leave your comments as feedback.All your feedback is warmly welcomed and I would try my best to address your issues.   

This is an indian movie song from the movie called Om Shanti Om . I haven’t seen the movie but I listened to this song and thought it was really impressive . I experimented a bit with my acoustic and came up with the chords which are I guess pretty much close . I play the barre chords in the E maj shape and the chords sound very much close to the real thing. Here are the tabulature for the chords just in case 

A       = 577655

F       = 133211

F#m  = 244022

G       = 355433

Bm    =  799077

E       =  022100 (Open)

A                A

 Aankhon mein teri ajab si ajab si adaain hain

F                    G                           A

dil ko bana dein ju patang saansein teri ye hawain hain

  A               F#m        F            A

Tere Saath Saath Aisa , koi noor aaya hai 

A               F#m        F               A

Chand teri roshni ka , halka sa ek saaya hai 

 A            Bm                       E     A

Tujhay dekh k dil ka hua ju hashr asar ye hua

Bm                                 E

ab in mein hi doob k ho jaon paar yehi hai dua  

 A                A

Aankhon mein teri ajab si ajab si adaain hain  

F                    G                           A

dil ko bana dein ju patang saansein teri ye hawain hain  

A        F#m         F          A

Ayee aisi raat hai ju buhat khush naseeb hai 

A            F#m            F          A

chahay jissay duur se duniya wo mere kareeb hai

 Bm                                         E         A

Kitna kuch kehna hai phir bhi hai dil mein sawal wohi

Bm                                       E

sapnoon mein ju roz kaha hai wo phir se kahoon ya nahi  

A                A

Aankhon mein teri ajab si ajab si adaain hain  

F                    G                           A

dil ko bana dein ju patang saansein teri ye hawain hain 

If you find any corrections , irregularities or suggestions do make sure to correct me by leaving a comment.Recording coming up soon ;) stay tuned :)

There are many different styles of applications that are written today. But lately we have seen a paradigm shift where the concept of “Software as a Service” is really been taken seriously. If you are an IT professional chances are 9 times out of 10 you must have heard of the term “Services Oriented Architecture”. What the heck? And you are like “Yeah, I know what that is and you go on  You make an application that consumes a web service!! Bingo!! ” No that’s not what SOA means’s is a new software development model or “An architectural style” where the business layer instead of integrated in the code is rather orchestrated :S . Confused already??  What I have realized over a period of time in the Software Market, whenever a new technology comes don’t jump into that technology and just know the couple POWER Words to horrify your bosses. I bet you 10 to 1 that Mr. John Doe or whatever!! Standing by the coffee machine and boosting about that “New technology” knows little about it.The key idea is to write software as a service ( It may be a web service or a windows service , a service within the enterprise accessible to you from your browser or a service that is published on the internet with a valid WSDL).If you notice the companies that have made it really big during the past year e.g. Google , Amazon and EBay I think the primary reason of their success lies with adopting the new software development paradigms and quickly able to deliver business rules with their service orientation.

So ok!! You want to know what exactly a Services oriented Architecture is. It’s a new software development paradigm which is suitable for applications with distributed processing capabilities .How it helps business?

 Information technology is the backbone of nearly all major businesses. Nearly all major businesses today are Information technology driven. Any change in the business rules or business process (ways in which business is conducted) implies a change in the legacy system infrastructure. This change is sometimes difficult to implement as business logic or business rules are implemented as software code. The legacy systems lack the interfaces and are not designed to integrate / interpolate with newer systems, thus the company looses profitable business and a huge factor is the extent to which the legacy systems can be made scalable. We need a new paradigm of Agile Software development where we need to extract the business logic from the actual implementation and expose the data to other applications for quick integration. The idea is to design software architecture around a set of services which are loosely coupled, scalable, reusable and easily integrated. The architecture is called “Services Oriented Architecture” where software can be implemented as a set of loosely coupled and highly cohesive services that may be used by a number of internal / external applications.However, with its advantages there are upfront development costs (time and money) associated with changing the architecture of the software infrastructure and it depends on the nature of the business, the role of IT in the business and the different costs that are required to change the legacy systems whether the company want to adopt the new applications paradigm or not. With that said, it does provide lots of incentives once implemented properly including higher integration options, existence of business process as configurations, higher reusability, a higher degree of compliance with standards ,  increased cohesion within the sub system and decreased dependencies between subsystems Common misunderstandings:Certain level of misinterpretations and misconceptions about Service Oriented Architecture prevail .The primary misconception of this software architecture building methodology is due to a key technology the Web services. The service oriented architecture and the applications that follow SOA are often confused with just the Web services. Some of the common misconceptions are listed below: 

Any application that uses Web services follows a Service Oriented Architecture.

An application that uses a Web service might follow a Service Oriented Architecture or it might not. It depends on the application’s own design, architecture and design considerations that determine its architecture.

 SOA is same a re – branding Web services:Many people think that Services Oriented Architecture is nothing more than a marketing term which might be interchanged with Web services. The important concept they are missing over here is SOA is another Software Architecture that results in the functionality being distributed to many independent Services to better process Business processes.

 Adopting a Services Oriented Architecture Ensures everything can interoperate:It is not necessary that any application that is developed as per the SOA artifacts would be able to interoperate or integrate necessarily with any other component / application or legacy systems. However SOA gives a high emphasis to increase the degree to interoperability by standardizing the Services produced using SOA. 

If you can use a web service with your application you can easily develop applications based on SOA. SOA is the same as distributed computing with Web services. Pitfalls: If there were no potential hazards, problems and everything was ideal with implementing SOA perhaps all the enterprise software today would have been based on Services Oriented Architecture. It depends on the type of functionality, nature of components, exposed interfaces, degree of reusability and working of an application that determines it architecture. Some of the common pitfalls are mentioned below:

 Designing and implementing an application like traditional distributed architectures:SOA is a relatively newer agile application development paradigm. Many of the new Services that implement SOA are designed just like a legacy application that followed a distributed architecture. This would involve Remote Procedure Calls, non standardized definition of services and an improper definition of the function boundary resulting in an increased degree of dependency and lowering the functionality contained in the Service. 

Not making XML the foundation of application architecture:This also has something to do partly with standardization. All applications that follow SOA should conform to certain standards, the foundation of which is XML.Contemporary SOA cannot be achieved if the internal and external interfaces of the Service don’t use XML as a basis. e.g. A key enabling technology in the Services Oriented Architecture are the Web services. Web services are described using a WSDL (Web Services Description Language) which is XML based. Other than that the BPEL (Business Process Execution Language) and some other key components are also XML based. 

 Ignoring the Performance Requirements of a Service:Usually due to the communications overhead performance of applications or Services following contemporary SOA can be below the required level of performance. The message processing time for the service should be reduced by optimizing the code , reducing the number of request / response and it should be made sure that the Service meets the required response times and performance criteria. This can be done by extensive testing (Stress testing) for various input / output conditions. Not making the services secure:

SOA is most likely to be used as architecture for distributed applications. SSL (Secure Socket Layers) is not the security consideration here. The application designers should also consider the WS-Extensions and security frameworks provided by other vendors in order to provide a standardized software design that follows SOA principles.

Now you would ask hey hey hey!! Wait a second: S!! How BPEL, ESB, grid computing and the Business Intelligence do fits in? What the heck are these J I would be happy to explain if you have that in mind.For now just like John Doe who is standing by the coke machine hehehehe understands that BPEL is the Business Process Execution Language, ESB is the Enterprise Service bus and Grid Computing hmmm has many concepts for virtualization? Technically speaking these all are layers of the Architecture we discussed about called SOA and how these are written , mainly in XML yes business rules with xml is BPEL. ESB is where the services are available on one on many services. It can be taken as the medium where the services reside on the www. If you have any questions / suggestions / queries / ideas in your mind do post your comments. Thanks Note: I have taken the concepts of these pitfalls and disadvantages from a book on Services Oriented Architecture(Concept Technology and Design)  by Thomas Erl