Pro ADO.NET Data Services
Working with RESTful Data
Published on 29. January 2009
336 pages
978-1-4302-1615-5 (ISBN)
Description
Pro ADO.NET Data Services: Working with RESTful Data
is aimed at developers interested in taking advantage of the REST-style data services that ADO.NET Data Services (formerly code-named Astoria) provides. The book shows how to incorporate ADO.NET Data Services into a wide range of common environments, including BizTalk, Ajax and Silverlight client applications. The material is intended for professional developers who are comfortable with the .NET 3.5 Framework but are coming to ADO.NET Data Services for the first time and want to understand how to integrate it into their own applications and enterprise solutions. The book is packed full with extensive real-world solutions and exercises, ensuring you walk away with a deep understanding of how to use ADO.NET Data Services to your best advantage.
More details
Other editions
Additional editions
Book
12/2008
APress
€46.00
Shipment within 15-20 days
Persons
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.
Content
ADO.NET Data Service Fundamentals.- The Foundations of ADO.NET Data Services.- Addressing RESTful ADO.NET Data Services.- ADO.NET Data Services Development.- ADO.NET Data Services in the Real World.- Exposing Existing WCF SOAP Services and .NET APIs Through ADO.NET Data Services.- ADO.NET Data Services from the Outside.- ASP.NET and AJAX Solutions.- Mashing Up Data Services.- Silverlight 2.0 Solutions.- Using ADO.NET Data Services with BizTalk.- The Future of ADO.NET Data Services.- Conclusion.
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.
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.
