Franc Stratton's .NET (TM) Web Application, OOP, and SOA Architecture & Programming Site

A site devoted to ASP.NET (TM), SilverLight (TM) and Browser-Based WPF (TM) Applications, IIS Services, and OOP Architectures

Home     Architecture Overview     WF/WCF/WPF     Data Store     Standards     .NET Security     Resources     jQuery     Silverlight     Developer Tips     Blog     Site Map      
N-Tier Architecture
Service Oriented Architecture
SOA Virtualization
Base Classes
BLL
DAL
Base Page
DALFactory
IDAL
Email
Application

SOA Model-View-Controller (MVC)

 

The MVC pattern adapted to SOA architects and operates similarly to the N-Tier MVC pattern presented previously in "N-Tier Architecture". The only difference is that a much tighter security is required because of the intranet or Internet communications between the HTML browser view and the server-side ASPX code-behind controller. (See "WF/WCF")

 

Shown in the diagram below, an Order Web form code-behind Controller could pass parameters directly to an Order service that would perform the same operation as that depicted in "N-Tier Architecture". The block diagram shows the same process in an SOA framework implemented for an intranet or Internet application:

 

 The MVC pattern begins with an AJAX call to a code-behind control PageMethod that then calls a Windows Communication Foundation (WCF) service which passes parameters to an OrderServiceBLL where business rule validation occurs. When the OrderServiceBLL performs validation, several round trips to the Order Service might be necessary to clear up any exception errors with the Order form data.

SOA Model-View-Controller (MVC) - Continued

 

These business rule error validation corrections might necessitate multiple Order web form partial AJAX postbacks if the page does not contain Microsoft required and regular expression JavaScript validators. These client side validators prompt the user for the correct data input or format before user actions are processed by the page controller.


Another use of the current state of SOA technology can be illustrated by a zip code service that receives an asynchronous call from an Order web form AJAX operation by the ScriptManager through the ASP.NET AJAX PageMethod extensions to the page controller code-behind file. An enterprise zip code service would receive a 5 or 10 character string (e.g.; 37203 or 37203-1548) from the AJAX operation. The zip code service BLL through the DAL would call a stored procedure to search the ZipCode table in a database and return one or more rows in a serialized class object (or one or more JSON zip code objects) that contain city, State, and region data to populate the appropriate textboxes on the Order web form.

 

The MVC SOA Architecture is show in Figure 1 below:

 

Figure 1: An SOA Architecture Pattern That Maintains the MVC Pattern

 

Service orientation is an architectural pattern, and a service is an abstraction within that pattern for developing loosely coupled distributed systems. There should be some basic characteristics of any well-designed service:

 

1. Service boundaries should be explicit: The exposed surface area of services should be well-understood and defined by explicit contracts (interfaces) that clearly identify the communications that flow across the boundary of a service. The Service as a provider can selectively expose the behavior of its members to consumers systems via endpoints.

 

2. Services should be autonomous: A service should be deployed and managed independently of any other services in the service layer of an SOA.

 

3. Services should minimize coupling between themselves and their consumers: The only knowledge that a service provider and a consumer share is the schema of the message passed between them. Consumers should not have or need any knowledge of the implementation or processing of the message in the layered classes that make up a service provider.

 

4. Services should be implemented by standards and best practices for SOA.