Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Azure

Service-Orientation with .NET : Service Abstraction & Validation Abstraction

5/17/2011 4:34:01 PM
- Windows 10 Product Activation Keys Free 2019 (All Versions)
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire

Service Abstraction

The Service Abstraction principle in essence advocates regulated information sharing when it comes to information about a service’s behavior, architecture, and implementation. The objective of this principle is to turn services into black boxes so that their implementations can be modified or evolved independently from service consumers that may already be using the service’s capabilities.

When applying this principle, we classify the common types of information available about a service into four categories referred to as meta abstraction types (Figure 1):

1.
functional information

2.
technology information

3.
programmatic information

4.
quality-of-service information

Figure 1. The four meta abstraction types used when working with Service Abstraction .


Of these four types of meta information, usually technology and quality-of-service details make their way into actual published contracts. It is generally considered unnecessary for service consumer designers to need access to the rest of the information. Steps are therefore taken to intentionally hide or limit access to this information so as to avoid consumer-to-implementation coupling and the temptation for service consumers to further optimize their programs in relation to how the service architecture currently exists.

Service Abstraction is also applied at a more detailed level to the actual service contract itself, as explained in the upcoming Validation Abstraction pattern description.


 Validation Abstraction

Regardless of whether you are building services as Web services or REST services, you can define message schemas with data types and validation logic that establish specific constraints and a specific level of validation granularity.

Strongly typed service contracts and data models have the benefit of sparing services from having to process messages that do not comply to certain types of baseline data standards. On the other hand, there can be long-term consequences to publishing this type of granular validation logic in public service contracts used by service consumers. Namely, if the logic needs to change (due to changes in overarching business requirements or otherwise), then there may be the need to introduce new versions of the service contract and assume the governance responsibilities that come along with that circumstance.

The Service Abstraction  principle asks us to consider how much detail we absolutely need to publish in service contracts and encourages us to trim away any unnecessary constraints in support of optimizing the service contract for increased longevity and reduced governance burden (Figure 2).

Figure 2. Optimizing the service contract will reduce the overall quantity of contract content.


The flipside of this approach is that the validation logic may need to be deferred to an intermediary or inside the service logic itself.

The primary objective of Validation Abstraction is to further protect services and their consumers from the impacts of change. When you have reason to believe that some parts of a message structure may be volatile, there is good reason to consider not hard coding those parts into a message schema.

For example, let’s say that you have a type called ApplicationClassType containing an enumeration of different classes that an application pertains to:

Example 1.
<xsd:simpleType name="ApplicationClassType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="CDA"/>
<xsd:enumeration value="TRU"/>
<xsd:enumeration value="CMI"/>
<xsd:enumeration value="TER"/>
<xsd:enumeration value="LBR"/>
<xsd:enumeration value="LBA"/>
<xsd:enumeration value="MAG"/>
<xsd:enumeration value="IST"/>
</xsd:restriction>
</xsd:simpleType>

If you need to add an enumeration value to this list, you will need to create a new version of the schema, as follows:

Example 2.
<xsd:simpleType name="ApplicationClassType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="CDA"/>
<xsd:enumeration value="TRU"/>
<xsd:enumeration value="CMI"/>
<xsd:enumeration value="TER"/>
<xsd:enumeration value="LBR"/>
<xsd:enumeration value="LBA"/>
<xsd:enumeration value="MAG"/>
<xsd:enumeration value="IST"/>
<xsd:enumeration value="GER"/>
</xsd:restriction>
</xsd:simpleType>

This is considered a backwards-compatible change (as per Compatible Change ), meaning you may not need to force consumers to be updated after the change is made. However, if a consumer wants to use the new value (“GER”) it may need to update in order to be made aware of its existence. A non-backwards-compatible change, such as if MAG were no longer a valid ApplicationClassType, will require that existing consumers be updated.

A means of loosening this constraint when applying Validation Abstraction could be to specify the ApplicationClassType as follows:

Example 3.
<xsd:simpleType name="ApplicationClassType">
<xsd:restriction base="xsd:string">
<xsd:length value="3"/>
</xsd:restriction>
</xsd:simpleType>

This way, when you add GER to the list of accepted values you will not need to change the structure of any messages. The downside of this approach is that you have to solve two things, namely validating the ApplicationClassType field inside the service logic and informing service consumers of when the range of acceptable values changes.

One way of informing consumers without having to rely on human communication is to expose a separate service capability that returns the most current list of values for the ApplicationClassType. This list can then be retrieved and cached inside consumers to avoid repeated communication overhead.

The validation of the field can be performed by creating a class that produces a list of ApplicationClass values and then creating an extension method that takes a string and checks if it is part of the list of values:

Example 4.
public static class Validators
{
private static List<string> listOfApplicationClass;
static Validators()
{
listOfApplicationClass = GetListOfApplicationClass();
}
private static List<string> GetListOfApplicationClass()
{
var list = new List<string>();
list.Add("CDA");
list.Add("TRU");
list.Add("CMI");
list.Add("TER");
list.Add("LBR");
list.Add("LBA");
list.Add("MAG");
list.Add("IST");
list.Add("GER");
return list;
}
static List<string> ListOfApplicationClass
{
get { return listOfApplicationClass; }
}
static bool ApplicationClassIsValid
(this string applicationClass)
{
return ListOfApplicationClass.Contains(applicationClass);
}
}


Inside your service implementation you could then validate the incoming string for the application class as shown here:

Example 5.
if (!applicationClass.ApplicationClassIsValid())
{
... return error message to consumer ...
}

If the validation code inside your service implementation finds that the ApplicationClassType field is not valid, an exception is raised, responding to the consumer with an error message (and the consumer would need to be prepared to handle this kind of error).

As demonstrated here, applying Validation Abstraction can actually result in extra development effort and more complex service and consumer logic. This can be justified when the long-term savings in governance effort and expense are considered worthwhile.

Other -----------------
- Service-Orientation with .NET : Service Loose Coupling and Service Capability Granularity
- Service-Orientation with .NET : Service Façade
- Service-Orientation with .NET : Decoupled Contract
- Service-Orientation with .NET : Service Loose Coupling
- Service-Orientation with .NET : Service Contracts and Interoperability - Canonical Protocol
- Service-Orientation with .NET : Service Contracts and Interoperability - Data Model Transformation
- Service-Orientation with .NET : Service Contracts and Interoperability - Canonical Schema
- Service-Orientation with .NET : Standardized Service Contract
- Cloud Services with Windows Azure : Windows Azure Storage
- A REST Service in Windows Azure
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
Popular tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 windows Phone 7 windows Phone 8
programming4us programming4us
Celebrity Style, Fashion Trends, Beauty and Makeup Tips.
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server