CNUG June ‘14 meet-up - slides and demo code

It was a pleasure to present TDD as an evolving methodology and talk about its current state.

I want to thank the group for active participation while discussing application design, benefits & challenges around the methodology.

Also, thanks to Keith Franklin for the opportunity and organizing the event.

The slides and demo code from the meet-up can be downloaded from GitHub here - https://github.com/MayankSri/CNUG-TDD

The YouTube videos on discussion on “Is TDD Dead?” can be found on Martin Fowler’s site here - http://martinfowler.com/articles/is-tdd-dead

The RESTful story – How? (3 of 3)

 

Continuing from the previous post, lets look into what frameworks that are available to implement Web services (REST or SOAP). We will be talking about frameworks available in the Microsoft technology stack only.

Lets take a look at all the options available:

WCF classic

The initial WCF SOAP stack also referred to as WCF classic now, was a unification of all the distributed application technologies including ASMX, Remoting, COM+, MSMQ in a single framework. It was done using SOAP as the messaging protocol.

WCF Data Services

Formerly known as ADO.NET Data Services, WCF data services enables the creation and consumption of OData services for the web.

WCF RIA Services:

A convenient way build the backend for Silverlight applications.

WCF Web Http

At some point the WCF team decided that you should be able to build RESTful/HTTP services using the WCF stack (or brand). This was the attempt to built HTTP/RESTful Services to deal with vanilla HTTP request and response.

ASP.NET MVC

Although ASP.NET MVC is a framework to create web applications, you can return all content types that HTTP supports from an action in your controller. You can build a custom action filter or Result formatter to do content negotiation for you.

As soon as developers identified that you can build RESTful using the ASP.NET MVC framework without messing with WCF Web Http, Microsoft came up with a framework similar to MVC but very specifically for building RESTful services -

ASP.NET Web API

ASP.NET WEB API is the new framework by Microsoft to build HTTP services. Internally it uses the goodies of the ASP.NET MVC framework and caters to all the requirements around building RESTful services. The framework also provides great WCF features like self hosting with programmable configuration.

ASP.NET WEB API OData Services

It is a set of components built on top of ASP.NET WEB API that lets you build OData services. It plays nicely with the WEB API model giving you the flexibility to select a subset of the OData query syntax and/or formats,.

ASP.NET SignalR

This framework allows you to build real time services for the web. It allows you to create a duplex connection between the client and the server. SignalR initially started as an open source effort before it was fully embraced into the ASP.NET stack. The framework uses Web Sockets when available and has fallback options. It supports a variety of clients.

 

What to use?

Lets start with what not to use. It is recommended not to use any of the following in your application:

• .NET Remoting – Encourages tight coupling, does not scale well and does not interoperate.
• ASMX – Limited features around security and session management, for a SOAP based XML web service use WCF.

If you are using one of the above in a new application that you are developing, you really need to catch up with the world. If you have it in an existing application, it might be worthwhile calculating your maintenance for the life of the application with and without the upgrade.

My take on what to use to build services

Consider the following question:

• Is the communication on the same windows machine (locally running service)?
• Is the service going to be consumed within the intranet, in Windows environment?
• Are you dealing with Message Queues?
• Do you need Message based security (and why)?

If you answer to any of the question above is ‘Yes’ you should use WCF classic framework.

For anything else, if your service is going to be consumed over the web, use ASP.NET Web API. Even if you feel your MVC application can handle your minimum requirements, consider looking at Web APIs. It has built in content negotiation, OData support and provides a lot of power for dealing with data result sets.

If you need duplex communication channel where the server should be able to communicate back to the client use ASP.NET SignalR. It is the ideal candidate for real-time application like Stock ticker or chat applications.

So, to conclude in you need to build SOAP services use - WCF classic, if you need to build HTTP service - use ASP.NET Web API.

The RESTful story – Why? (2 of 3)

 

Continuing from the previous post, lets look into what are the big benefits that REST architecture style provides.

 

 

 

Why REST

 

There is a huge push for moving to REST and for good reasons, such as:

Scalability

While soap provided transport neutrality there were doubts and debates about performance & scalability of SOAP based services. REST on the other hand came with all the benefits of HTTP and restful services can scale as easily as Web applications. In addition, since SOAP has it’s own message structure there is a dramatic difference between a SOAP based HTTP request and an HTTP request transporting the same amount of application data. See the messages below:

Example SOAP message over HTTP

Request:

POST http://wcftest.azurewebsites.net/Service1.svc HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8; action="http://tempuri.org/IStockTicker/GetQuote"
Host: wcftest.azurewebsites.net
Content-Length: 168
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
    <s:Body>
        <GetQuote xmlns="http://tempuri.org/">
            <stockTicker>MSFT</stockTicker>
        </GetQuote>
    </s:Body>
</s:Envelope>

Response:

HTTP/1.0 200 OK
Content-Length: 187
Content-Type: application/soap+xml; charset=utf-8
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
    <s:Body>
        <GetQuoteResponse xmlns="http://tempuri.org/">
            <GetQuoteResult>28.33</GetQuoteResult>
        </GetQuoteResponse>
    </s:Body>
</s:Envelope>

Example of RESTful message:

Request:

GET http://webapitest.azurewebsites.net/stocks?symbol=msft HTTP/1.1
Host: webapitest.azurewebsites.net

Response:

HTTP/1.0 200 OK
Content-Length: 5
Content-Type: application/json; charset=utf-8
33.12

Multi platform support

Integration with native application was a drawback for SOAP. All the browsers, phones, tablets, Xbox,  set-top boxes… understand and support the HTTP stack, that means, they can send and receive http requests and know how to manipulate HTTP supported content types. That is a huge benefit with REST, it enable your services to cater to a wide range of clients.

Focus on Resource with a Universal Interface/Contract – SOAP, although arguably was not meant for it, it has been used for RPC based development approach, where as REST approach focuses on resources, and the actions on those resources are defined by http Verbs. In case of REST, the interface or contract of your service is universal and HTTP based. ALL the actions you can take against your resources are :

GET         (Retrieve)

POST       (Create)

PUT         (Update)

DELETE  (<—)

Some sample Request URLs:

GET http://MyOnlineShop.com/Products – Get all products

GET http://MyOnlineShop.com/Products?id=8765 – Get a specific products

POST http://MyOnlineShop.com/Products – Create a product (with the fields data in the request)

REST architecture talks about returning resources and links to navigate to associated resources. This is exactly how the Web works, you go to a web page, it has a content of its own and link to navigate to related content.

Simplicity – Calling an HTTP service is very easy, compared to a SOAP based services like WCF. No WSDL or  Service utility tool is required. The fact that it can be called via JavaScript using just the URL and knowing the HTTP verb says all about the simplicity of RESTful services.

Cloud computing and push from industry leaders – Because of its scalability, multiplatform reach, simplicity etc, it has been adopted by all cloud computing platforms and other SAAS from Microsoft, Amazon, Google, Sales force etc have embraced it. Some companies have dropped SOAP services but most support both. Commonly used social services like Facebook, Twitter, LinkedIn etc. provide both REST and SOAP services. It’s  fair to assume that services created to be consumed at that extent will prefer the consumers using REST.

Disclaimer:

Using REST is not the end of SOAP. By no means this post means that SOAP or SOAP based frameworks are not required anymore.

To decide what you want to do you you need to analyze what you want in your services:

• Do you need to use transport protocols other than HTTP? Remember some channels like TCP or Named pipes are much faster than HTTP if your service will be consumed within same OS environment or on the same machine.
• Do you need message based security?
• Are you dealing with Message Queues?

Among other considerations if the answer to any of the above three question is yes, you are probably better off using SOAP services.

In the next post we will be talking more about the frameworks available to build RESTful services and which ones to use.

The RESTful story – What? (1 of 3)

 

In this 3 part post we will talk about REST, what it is (part 1), why has it gained huge popularity in recent years (part 2) and what are the frameworks that we might or might not want to use, depending upon what we are trying to achieve (part 3).

Where do we begin?

To start with a formal definition - REST is an architectural style for the Web, to build services hosted and consumed over HTTP. To understand that, lets look at something's that you see on most of the webpages you visit:

Each one of these icons have scripts that connects to a target service, like Facebook, Twitter, Google+ to start with. They would handle your authentication and invoke actions that the target service provides.

They are almost like multiple small apps running of the web page. These JavaScript apps are talking to some remote RESTful services. Google was one of the initial companies to completely drop their SOAP APIs.

The REST based service model is becoming rather inevitable with the evolution of cloud computing platforms. whether you choose to develop on Microsoft, Amazon, Google or other platform.

So to understand the shift towards REST, let’s talk a little about SOAP.

What is SOAP?

SOAP is an XML info set based messaging protocol. The big value it brought to the table was transport neutrality or “interoperability”. It is a protocol with a defined XML messages structure, having its own headers and body. These messages are capable of being transported, independent of the underlying transportation protocol.

SOAP was designed to be a remote object access protocol, inherently RPC based.

Understanding REST

REST (aka HTTP services or WEB APIs or RESTful services) is an acronym for Representational State Transfer. It is an architectural style for the Web, to build services hosted and consumed over HTTP. It’s a pattern that focuses more on resources than action. The only actions REST supports are the HTTP verbs – GET, PUT POST and DELETE and supports all the data formats that HTTP supports – HTML, JSON, XAM etc.

Just like the Web, it is stateless, cacheable and scalable.

So to Contract REST against SOAP:

• SOAP is a messaging protocol where as REST is an architectural style.
• SOAP messages can be transported over any transport protocol (HTTP, TCP, MSMQ, Named Pipes) where as REST uses HTTP as the transport layer.
• SOAP has XML based message structure where as REST uses HTTP request structure.

In the next post we will contrast between the two and try to understand why one is better than the other.

What’s new in ASP.NET MVC 4 at Chicago .NET User Group July 18th, 2012

It was a pleasure to present the exciting new features in ASP.NET MVC 4 RC, thanks to Keith Franklin and the great audience and .

The slides and solution can be downloaded from here - http://blogs.mpspartners.com/mayanksrivastava/Lists/Posts/Post.aspx?ID=2

Feel free to reach out in case of any questions.