EDITORIAL NOTE: Web Services have become very popular. They come in a variety of flavors and styles, a fact that can be proven pretty confusing. Microsoft ecosystem currently provides two core technologies for the implementation of web services: Windows Communication Foundation, introduced with .NET 3.0 and the ASP.NET Web API, included in ASP.NET MVC. The current article presents a Decision Framework for the implementation of these web services and is the first one of a series of posts that aim at helping technical professions like solution architects and application developers design effective solutions based on Service Oriented Architecture (SOA).

1. Introduction to Web Services

A Web service is a method of communication between two electronic devices over a network. It is a software function provided at a network address over the Web with the service always on as in the concept of utility computing. The W3C defines a Web service generally as:

A software system designed to support interoperable machine-to-machine interaction over a network

One of the most common requirement for the majority of composite software solutions nowadays is considered to be that of targeting multiple devices. This process starts on the back end. Applications need to expose services that can be consumed on any device and scaled for the Internet.
Internet services are meant to have high availability and continuity with the back-end services that allow modern applications to work. They must also be agile and have a continuous, smooth evolution, adhering to the velocity of business change.

1.1 Web Service styles

1.1.1 SOAP

SOAP – Simple Object Access Protocol – is a communications protocol for XML based web services callable over a variety of transports, the most common being HTTP, and also including TCP, MSMQ, etc. SOAP is actually agnostic of the underlying transport protocol and can be sent over almost any protocol such as HTTP, SMTP, TCP, or JMS. It is published and governed by the W3C and is currently in version 1.2.

SOAP together with schemas, defines a very strongly typed messaging framework. Every operation the service provides is explicitly defined, along with the XML structure of the request and response for that operation. Each input parameter is similarly defined and bound to a type: for example an integer, a string, or some other complex object.

It is fundamentally a stateless, one-way message exchange paradigm, but applications can create more complex interaction patterns (e.g., request/response, request/multiple responses, etc.) by combining such one-way exchanges with features provided by an underlying protocol and/or application-specific information. SOAP is silent on the semantics of any application-specific data it conveys, as it is on issues such as the routing of SOAP messages, reliable data transfer, firewall traversal, etc. However, SOAP provides the framework by which application-specific information may be conveyed in an extensible manner. Also, SOAP provides a full description of the required actions taken by a SOAP node on receiving a SOAP message.

The SOAP architecture consists of several layers of specifications: for message format, Message Exchange Patterns (MEP), underlying transport protocol bindings, message processing models, and protocol extensibility. SOAP is the successor of XML-RPC.

All of this is codified in the WSDL – Web Service Description (or Definition, in later versions) Language. The WSDL is often explained as a contract between the provider and the consumer of the service. In programming terms the WSDL can be thought of as a method signature for the web service.

As was already mentioned, the SOAP message itself must be XML-formatted. Thus as for any normal XML document, there must be one root element: the Envelope in this case. This contains two required elements: the Header and the Body. The rest of the elements in the message are described by the WSDL.

1.1.2 REST

REST (Representation State Transfer) is an architectural style for structured communications over the World Wide Web introduced by Roy Fielding in his 2000 doctoral dissertation. This style, which emphasizes on using HTTP as an application and not merely a transport protocol, has gained traction during the last years due to its simplicity, compatibility with a large number of Web and other clients, and its consistent URI semantics.

The basic principles as described by Fielding are:
• Starting with the null style
• Adding the client-server architectural style
• Constraining the interaction to be stateless
• Providing with explicit caching semantics
• Exposing information through a uniform interface
• Building layered systems
• Enabling code on demand

One of the key characteristics of a RESTful Web service is the explicit use of HTTP methods in a way that follows the protocol as defined by RFC 2616. Also, instead of focusing around XML data representations, as SOAP does, it allows the use also of the JSON data format that is easily usable from Web clients.

1.1.3 CRUD

A common style that applies to web services, especially data intensive ones, and is orthogonal to the communication style used (SOAP or REST), is CRUD, short for Create/Read/Update/Delete, a pattern used to manage information in persistent storage.

In CRUD styled web services, each operation refers to a specific data entity in the domain model and either Creates a new entity, Reads one or more entities, Updates or Deletes a single entity.

A typical example of modern web services that follow the CRUD pattern are those that follow the Open Data Protocol (OData). OData provides a standard for communicating with data services over the web. Many enterprises today use OData to exchange data between systems and partners, in addition to providing access into their data stores. Because OData is a standard protocol, other client applications on almost any platform or device can access the data that you expose as OData. For example, users can connect to OData service directly from Microsoft Excel:

CRUD is a style commonly applied because it corresponds directly to typical data management patterns used by a variety of software solutions and can be easily mapped to relational data stores (note the direct mapping of CRUD actions to SQL queries and commands – insert, select, update, delete).
On the other hand, it is a style that exposes the internal data model of a solution to external consumers directly, without providing enough (or many times, any) transformation that is more applicable to the application domain and the business scenarios supported by the solution.

1.1.4 CQRS

CQRS, standing for Command Query Responsibility Segregation, is an architectural pattern based on the concept that that you can use a different model to update information than the model you use to read information.
CQRS splits the CRUD conceptual model into separate models for update and display, which it refers to as Command and Query respectively. The rationale is that for many problems, particularly in more complicated domains, having the same conceptual model for commands and queries leads to a more complex model that does neither well.
In a typical web service scenario using the CQRS style, there is one web service managing queries against data, and a separate one handing commands that modify the data. The major difference against a CRUD styled service is that commands do not directly correspond to simple Create/Update/Delete semantics, but expose domain specific actions that can affect multiple data entities in different ways.

The main benefit of the CQRS pattern is handling complexity in a complex business domain. The other main benefit is in handling high performance applications. CQRS allows separating the load from reads and writes making possible to scale each independently.

2. Core Microsoft technologies

Microsoft currently provides two core technologies for the implementation of web services: Windows Communication Foundation, introduced with .NET 3.0 and the ASP.NET Web API, included in ASP.NET MVC. There are some other alternative technologies listed in this as well.

2.1 ASP.NET Web API

The term Web API generally refers to both sides of computer systems communicating over a network: the API services offered by a server, as well as the API offered by the client such as a web browser. The server-side portion of the web API is a programmatic interface to a defined request-response message system, and is typically referred to as the Web Service.
ASP.NET Web API is a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework. It is included in the latest version of ASP.NET MVC.

Services implemented with the ASP.NET Web API are very easily consumable from Web clients, and are particularly fitting in rich Web applications.

2.1.1 REST services with Web API

In ASP.NET Web API, a web service is implemented as a controller that handles actions, which correspond to service operations. Mapping a REST service URI to a controller and a specific action is performed through the same routing mechanism in ASP.NET MVC using routing tables.
The basic features in REST service programming with the ASP.NET Web API are:

• Support for XML, JSON and form encoded data
• Capability for batching with the MIME multipart format
• Easy extensibility to support the Open Data protocol
• Hosting within IIS or in a separate process
• Model binding and validation for data contracts as in ASP.NET MVC
• Extensive configurability

Why using Web API

1. If you need a Web Service and don’t need SOAP, then ASP.NET Web API is best choice.
2. It is used to build simple, non-SOAP-based HTTP Services on top of existing WCF message pipeline if required.
3. It doesn’t have tedious and extensive configuration like WCF REST service.
4. Simple service creation with Web API. With WCF REST Services, service creation is difficult.
5. It is only based on HTTP and easy to define, expose and consume in a REST-ful way.
6. It is light weight architecture and good for devices which have limited bandwidth like smart phones.

2.2 Windows Communication Foundation (WCF)

Windows Communication Foundation (WCF) is a framework for building service-oriented applications. Using WCF, you can send data as asynchronous messages from one service endpoint to another. A service endpoint can be part of a continuously available service hosted by IIS, or it can be a service hosted in an application. An endpoint can be a client of a service that requests data from a service endpoint. The messages can be as simple as a single character or word sent as XML, or as complex as a stream of binary data.

The basic features provided by WCF are:

• Service orientation
• Interoperability and full support of the standard WS-* stack
• Multiple message patterns
• Service metadata
• Representation of information as data contracts
• Security primitives
• Multiple transports and encodings
• Reliable and queued messages
• Durable messaging
• Transactions
• AJAX and REST support
• A broad extensibility model

The process of designing and implementing a web service with WCF follows these steps:
1. Defining the service contract. A service contract specifies the signature of a service, the data it exchanges, and other contractually required data
2. Implementing the contract. To implement a service contract, we create a class that implements the contract and specify custom behaviors that the runtime should have
3. Configuring the service by specifying endpoints and other behavior information
4. Hosting the service

2.2.1 SOAP services with WCF

WCF can be used to implement SOAP web services using any of the available WS-* protocols, over a variety of communication transports.

Delivery of services through SOAP is the default in WCF and supports the following features:

• Using different message serialization options to control the body or the entire SOAP envelope
• Complete control of XML data serialization
• Support for addressing and routing with the standard WS-* protocols
• Support for transactions
• Capabilities for session management, queued and reliable message delivery
• Standards compliant implementation of fault reporting
• Request-response, one way and duplex operations
• Security primitives compliant with (but not restricted to) WS-Security and WS-Federation
• Extensibility throughout the message processing pipeline

2.2.2 REST services with WCF

WCF supports the implementation of REST-style web services using the same steps and programming model as with SOAP services. Actually, a service can be designed once and exposed simultaneously through SOAP and REST endpoints.
Delivery of REST services with WCF supports the following features:

• Control of the URI schema used to address the service
• Support for all HTTP verbs
• Multiple data formats (XML, JSON, binary) with automatic format selection
• Automatic help page generation to make up for the absence of structured service metadata in REST services
• Support for arbitrary input data through streams
• Extensibility throughout the message processing pipeline

The REST programming model poses certain restrictions on implemented services, especially around available security options, which are mitigated by the simplicity of the model and its seamless integration with a variety of clients.

2.2.3 Data Services

WCF Data Services (formerly known as “ADO.NET Data Services”) is a component of the .NET Framework that enables you to create services that use the Open Data Protocol (OData) to expose and consume data over the Web or intranet by using the semantics of representational state transfer (REST).

2.3 LightSwitch OData Services

In addition to using LightSwitch to create applications, you can also use it as the middle tier to provide data to other applications. When you publish application data from LightSwitch to a web server, that data is exposed as an Open Data Protocol (OData) service.
When you deploy a LightSwitch application in a three-tier configuration (hosting the middle tier in Internet Information Services), the service endpoints are exposed. You can control access for a LightSwitch application – it supports three authentication settings: None, Forms, and Windows.
Any application that supports OData on any platform can consume OData feeds from LightSwitch.

2.4 Workflow services

As applications become increasingly distributed, individual services become responsible for calling other services to offload some of the work. Implementing these calls as asynchronous operations introduces some complexity into the code. Error handling adds additional complexity in the form of handling exceptions and providing detailed tracking information. Some services are often long running and can take up valuable system resources while waiting for input. Because of these issues, distributed applications are often very complex and difficult to write and maintain.

Workflows are a natural way to express the coordination of asynchronous work, especially calls to external services. Workflows are also effective at representing long-running business processes. It is these qualities that make the workflow a great asset to building services in a distributed environment.

Workflow services are WCF-based services that are implemented using workflows. Workflow services are workflows that use the messaging activities to send and receive Windows Communication Foundation (WCF) messages. .NET Framework 4.5 introduces a number of messaging activities that allow you send and receive messages from within a workflow.

Like WCF services, workflow services must be hosted. Workflow services can be hosted in a variety of ways, for example:

• In a managed .NET Framework application
• In Internet Information Services (IIS)
• In Windows Process Activation Service (WAS)
• In a managed Windows Service

2.5 SignalR

ASP.NET SignalR makes it incredibly simple to add real-time web functionality to your applications – ability to have your server-side code push content to the connected clients as it happens, in real-time.
SignalR also provides a very simple, high-level API for doing server to client RPC (call JavaScript functions in your clients’ browsers from server-side .NET code) in your ASP.NET application, as well as adding useful hooks for connection management, e.g. connect/disconnect events, grouping connections, authorization.

SignalR can be used to add any sort of “real-time” web functionality to your ASP.NET application. Any time a user refreshes a web page to see new data, or the page implements Ajax long polling to retrieve new data, is a candidate for using SignalR.
SignalR enables applications that require high frequency updates from the server.

3. Decision framework

Based on the preceding discussion, the table below recommends technologies for the implementation of web services, depending on the context of your application and its priorities.

Table1: Decision Framework for the implementation of web services, depending on the context of your application and its priorities.

The following table summarizes the support provided by WCF and the ASP.NET Web API for various service creation technical requirements:

Table2: Support provided by WCF and the ASP.NET Web API for various service creation technical requirements

4. References

1. ASP.NET Web API
2. WCF
3. WCF Data Services Tools for Windows Store Apps
4. Creating and Consuming LightSwitch OData Services
5. ASP.NET SignalR
6. Web API