Pro ADO.NET Data Services (eBook)

John Shaw has worked in business processing and integration for over 10 years and has architected some of the largest Microsoft integration projects in the U.S., U.K., and Australia. His technical expertise includes implementing Microsoft BizTalk and messaging standards for a variety of clients in finance, supply chain, and other sectors. Most recently, he founded SphereGen, a niche company that provides a blended model of low-cost onshore and offshore solutions for its clients. Prior to that, John worked as the U.S. BizTalk Practice Lead for Conchango, where he obtained BizTalk Virtual Technical Specialist (VTS) status within Microsoft.

A table of contents is not available for this title.

CHAPTER 4 (S. 121-122)

Exposing Existing WCF SOAP Services and .NET APIs Through ADO.NET Data Services

The reality many enterprises will face when considering adopting ADO.NET Data Services is how to implement this new technology alongside their existing services and components. Unless important reasons exist to start from scratch, many will need to make use of their current investments in the .NET technology stack and the SOAP- based services they have built over the last few years.

There can be little business justification in tearing down a working set of existing services just to create RESTful APIs. Indeed, many enterprises will have external clients who consume their SOAP services and cannot be forced to change to a RESTful world. Alternatively, such enterprises may need to expose some or all of their existing services to some clients through SOAP because they rely on WS- * policies for measures such as security.

This chapter will cover one such scenario and discuss the measures that architects could take in order to preserve existing investments while benefiting from adding RESTful services to their enterprises. The current architecture in any enterprise is unique and is unlikely to match this example exactly, but some of the patterns used here are commonplace, and the chapter provides commentary throughout to describe some alternative scenarios.

The Legacy Customer Service

The example service used throughout the rest of this chapter is a customer service. This service has been prebuilt to represent a legacy SOAP service that will then be adapted through exercises to add an ADO.NET data service endpoint to the service offering. The legacy customer service would be used in a typical enterprise to manage customer information. This chapter will describe some example drivers for adding a REST endpoint to the existing service using ADO.NET Data Services.

Note
In reality, a customer service would be quite a complex undertaking, possibly incorporating integration into a CRM. This example service has been extremely simplified to include only four service operations with a simple customer entity. However, this example shows many common patterns associated with a request-reply- based SOAP service. The customer service was built on top of the customer application. When the customer application was designed, the architect chose to store the customer data using SQL Server 2005.

He built a strongly typed data access layer (DAL) using ADO.NET, executing stored procedures against the object for all methods (using parameters that match those of the stored procedures) and additionally using the object for methods that needed to read multiple rows from a SQL result set. The architect chose to encapsulate all the business logic (such as validation) of the application in a business logic layer. He used a Data Transfer Object (DTO) pattern to pass strongly typed entity objects from the presentation layer, through the business layer, and into the data access layer and vice versa.

Note
The Data Transfer Object pattern separates out entities from business logic. Entity objects provide an object- oriented representation of the information with no business logic encapsulated. Entity objects are therefore the common currency in the application between the data access layer, business layer, and presentation layer.