Saturday, December 5, 2009

What I Learned from PDC - Service Oriented Architecture

Mapping Functionality into Abstract Software Components

Each of the presentations at PDC are designed to discuss some aspect of Microsoft’s packaged technology: ASP.NET, SQL Server, Silverlight, Entity Framework, LINQ & PLINQ, MVC, WPF, WCF Data service, Azure, … Windows 7. In every case, the presentations show code samples on how to use that technology, and in the process they casually introduce some abstract software architecture concept (View Models, Data Proxies, Domain Models…) to help illustrate the technology.

Application Depth

I have extracted the software concepts from all those talks and constructed an application depth stack that maps these functional requirements to software layers. These layers combine the “best practices” in software design from ASP.NET MVC, WPF & Silverlight applications and also include technologies that are common to all solutions like WCF Data Services, SQL Server and Entity Framework. The software component names are not official and the code boundaries between them in many cases are not precise, but they are useful in categorizing the Microsoft technologies that are used to construct and execute each layer.

Client, Domain and Server Models

I broke the sections up into Client, Domain, and Server. The Domain section can execute on the client or the server. When deployed as a thin client, the Domain logic is executed on the Server, but when deployed as a rich client the Domain executes on the Client and helps manage State. Server components are traditional data access services. Using data services is now Microsoft’s preferred way of connecting to data. Data services use simple web protocols to request and transport data even if you are consuming data on the same machine as the client. The service can be accessed just by passing a URL. Data access is provided using proxy service “wrappers” that provide an API by ingesting the META data about the service. These are the building blocks of a Service Oriented Architecture (SOA).

Best Practices? For My Purposes They Are!

I am not saying that each of these abstract software components need to physically exist in order for you to have a well designed or valid .NET application. Most CRUDS database solutions (Create, Read, Update, Delete, Search) are put together in a forms-over-data software architecture and do not implement all of these components. I am saying that during the design/development phase of a solution, I believe that the most developers should at least think about these functional areas, even if it is just to dismiss them as unnecessary.

No comments: