Archive for June, 2010

Benefits of using RESTful WCF Services

Monday, June 7th, 2010

Overview

WCF Restful service is a simple yet very useful concept of WCF Services. Either in .Net 2.0 or .Net 3.5 the web services whether by ASMX or WCF have been implemented using SOAP and WS-* standards. WS-* Standards are extensions of the SOAP specification which defines the Advance level functionalities such as Transactions, Reliable Messaging and much more. There is no doubt that if you create the web service using SOAP protocol with HTTP carrier, you can create viable solution for big Enterprise Problems. Due that SOAP is a very heavy weight and complex protocol; it cannot be easily readable by human. It also contains lot of extra xml markups which are protocol oriented or sometimes really not required by the solution. Those xml markups increase the size of the messages resulting into higher data transfer rate on the wire.

In the release of .Net 3.5 Framework WCF offers support for both the programming model Web & SOAP. So the Restful web services are nothing but a web programming model to expose WCF Service.  REST can have more impact on data transfer reduction in combination with JSON or other serialization techniques.

What is REST?

REST stands for REpresentation State Transfer. Representation State Transfer term is invented by one of the original author of the HTTP protocol, Roy Fielding in his 2000 doctoral dissertation.  Visit the wiki for more about REST.

Key concepts of REST

  • Resources: Resources are nothing but entities in a business domain for ex.  Items, Vendors, Customer etc…
  • URIs: All resources are referenced using URIs (Universal Resource Identifiers)
  • Representations: It consist of 2 things Data that reflects current or desired state, meta data that provides description of data values. For ex. HTML, XML, JSON, Text files, zip, Images, Mpegs etc…

Limited Set of Methods

There are uniform interfaces like methods, operations, verbs

Verbs are actually HTTP verbs

GET

  • Retrieves a resource
  • Guaranteed not to cause side-effect (SAFE)
  • Cacheable

POST

  • Creates a new resource
  • Unsafe, effect of this verb isn’t defined by HTTP

PUT

  • Updates an existing resource
  • Used for resource creation when client knows URI
  • Can call N times, same thing will always happen

DELETE

  • Remove a resource
  • Can call N times, same thing will always happen

IMPLICIT INTERFACE DESIGN

  • REST does not call meta-languages to describe Structure of representations, Data Types used in representations, What operations are supported at a given URI, How input data must be sent for a given URI/Operation combination.

Why to Prefer REST?

  • REST is powerful, intuitive, and relatively easy to implement.
  • Light weight – not lot of extra xml markup as in SOAP.
  • Unlike SOAP it provides much simpler result that can be human readable.
  • It is very easy to build no extra toolkits are required.
  • Improve scalability of the application through caching and session state.
  • Custom URIs using URI templates
  • Consistency with design of the World Wide Web

Examples

Below examples are taken from one of our existing project & describes how the message size on the wire has been reduced to optimize the performance and reduce the cost overhead when the Bandwidth is concerned as per business need.

SOAP vs. REST

Above example clearly indicates that WCF REST services better takes care of Data usage size than the WCF SOAP services. Hence, whenever data usage size is a matter of concern, WCF REST is the way to go.

Few Smart Database Indexing Tips To Boost Application Performance

Wednesday, June 2nd, 2010

Indexes play key role in performance and scalability of any database intensive applications. Here are few tips to smartly use indexes to get the best out of it.

  1. Decide Best Candidates for Index. The column(s) which are most frequently used to filter records (WHERE clause and JOIN clause), group records (GROUP BY clause) and/or sort records (ORDER BY) are best candidates for index creating. Analyze your queries very attentively and avoid creating indexes which are seldom used.
    You should also minimize the number of indexes for the tables which has data being frequently updated/deleted/inserted to reduce index maintenance cost during each such operation.
  2. If you create a composite (multi-column) index, try to order the columns in the key as to enhance selectivity
    1. With the most selective columns to the left most of the key.
    2. The WHERE clauses of the frequently used queries match the column(s) that are leftmost in the index.

    The order of the columns in a multi column index plays a key role during query execution. The composite index used only when the left most column is included in WHERE clause of the query otherwise the index will not be hit and instead an expensive full table scan will be performed.
    For example, if you create composite index such as “Branch, Department”, then the query with the WHERE clause such as “WHERE Branch = ‘New York’” will use the index, but the query with the WHERE clause such as “WHERE Department = ‘Finance’” will not use the index.

  3. Every table should have a clustered index. Cluster index ensures that data rows stored in particular order only. If you do not create a cluster index for a table, the data rows will not be stored in any particular order, and ‘Heap’ will be used. Every time data is inserted into this table, the row will be added to the last block of the table. When many rows will be added concurrently, a “hot spot” can occur in absence of proper locking. To avoid “hot spot” and improve concurrency, you should create a clustered index for each table.
  4. Carefully create clustered index instead of non clustered to increase performance of the queries that return a range of values and for the queries that contain the GROUP BY or ORDER BY clauses and return the sort results. However, make sure to NOT create clustered index on column(s) that is updated very frequently. Because clustered index ensures that data is stored in order of key to the index, updating of key data will cause lot of index maintenance which is not desirable for performance centric application.You should choose column(s) for clustered index very very carefully because every table can have only one clustered index. First you analyze all your queries and select optimum candidate which is best suitable for the above mentioned criteria to create the clustered index.

By smartly placing indexes you can achieve great response times to your database applications and offer better user experience.

Happy Indexing!