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 Reusability and the Separation of Concerns

5/20/2011 5:39:33 PM
- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
The SOA design patterns catalog establishes a set of foundational service patterns responsible for identifying and defining the scope of functional service contexts and boundaries, as well as service capabilities. As shown in Figure 1, the majority of these patterns pertain and lead to the definition of agnostic logic suitable for reuse and therefore subject to the Service Reusability principle.
Figure 1. These foundational service patterns can be combined to establish a primitive service modeling process that results in the definition of service candidates and service capability candidates.

As explained in the upcoming sections, the combined application of these patterns essentially carries out the separation of concerns in support of the service-orientation paradigm.



Functional Decomposition

The separation of concerns theory is based on an established software engineering principle that promotes the decomposition of a larger problem into smaller problems (called concerns) for which corresponding units of solution logic can be built.

The rationale is that a larger problem (the execution of a business process, for example) can be more easily and effectively solved when separated into smaller parts. Each unit of solution logic that is built exists as a separate body of logic responsible for solving one or more of the identified, smaller concerns (Figure 2). This design approach forms the basis for distributed computing and is essentially embodied by the Functional Decomposition pattern.

Figure 2. On its own, Functional Decomposition  results in the decomposition of the larger problem into smaller problems. The actual definition of solution logic units occurs through the application of subsequent patterns.

Service Encapsulation

When assessing the individual units of solution logic that are required to solve a larger problem (carry out a business process), we may realize that only a subset of the logic is suitable for encapsulation within services. This identification of service logic is accomplished via the application of the Service Encapsulation  pattern (Figure 3).

Figure 3. Some of the decomposed solution logic is identified as being not suitable for service encapsulation. The highlighted blocks represent logic to which this pattern was successfully applied.

Agnostic Context

After the initial decomposition of solution logic we will typically end up with a series of solution logic units that correspond to specific concerns. Some of this logic may be capable of solving other concerns, but by grouping single-purpose and multi-purpose logic together, we are unable to realize any potential reuse.

By identifying what parts of this logic are not specific to known concerns, we are able to separate and reorganize the appropriate logic into a set of agnostic contexts (Figure 4).

Figure 4. Decomposed units of solution logic will naturally be designed to solve concerns specific to a single, larger problem. Units 1, 3, and 6 represent logic that contains multi-purpose functionality trapped within a single-purpose (single concern) context. The application of this pattern results in a subset of the solution logic being further decomposed and then distributed into services with specific agnostic contexts.

Agnostic Capability

Within each agnostic service context, the logic is further organized into a set of agnostic service capabilities. It is, in fact, the service capabilities that address individual concerns. Because they are agnostic, the capabilities shaped by this pattern are multi-purpose and can be reused to solve multiple concerns (Figure 5).

Figure 5. A set of agnostic service capabilities is defined, each capable of solving a common concern.

Utility Abstraction

The application of the Utility Abstraction  pattern results in the separation of common cross-cutting functionality that is neither specific to a business process nor a business entity. This establishes a specialized agnostic functional context limited to utility logic. The resulting type of service is referred to as a utility service and the repeated application of this pattern within a service inventory results in the creation of a logical utility layer (Figure 6).

Figure 6. The application of Utility Abstraction  restricts the agnostic context of the service to utility logic.

Entity Abstraction

Every organization has business entities that represent key artifacts relevant to how operational activities are carried out. The application of Entity Abstraction shapes the functional context of a service so that it is limited to logic that pertains to one or more related business entities. As with Utility Abstraction , the repeated application of this pattern establishes its own logical service layer (Figure 7).

Figure 7. The application of Entity Abstraction  restricts the agnostic context of the service to entity logic.

The Inventory Analysis Cycle

When viewing the preceding set of patterns, one can see there are steps within a service-oriented analysis process. It is important to realize that this process (and its steps) is preferably carried out iteratively, as part of a cycle that identifies, defines, and also refines agnostic service contexts and agnostic capabilities.

This is commonly accomplished by decomposing a set of business processes that belong to a given domain within the IT enterprise. This domain represents the boundary of a planned service inventory. By iterating through a separate analysis and functional decomposition of each business process, agnostic service candidates and their capabilities can be continually refined until they reach a state where their reuse potential has been fully determined before they are physically designed and developed. This takes the guesswork out of applying the Service Reusability  principle in that the reuse of each service is pre-determined based on the current state of the business. Future business change is naturally accommodated by leveraging the inherent characteristics and flexibility established by this and other principles.

Each of these service candidates is added to a collection that eventually results in a blueprint of the service inventory, as illustrated in Figure 8. The depicted analysis cycle is one of several ways to incorporate service-oriented analysis within an SOA methodology. A key consideration here is that the extent to which the cycle needs to be iterated is directly related to the scope of the planned service inventory. When applying Domain Inventory within an IT enterprise, multiple service inventories can co-exist and can be independently planned and defined with different approaches, each iterating through their own cycles within manageable boundaries.

Figure 8. The cycle begins with the definition of business models (such as entity relationship models and business process definitions) and takes practical considerations into account via a step dedicated to the on-going definition of the required technology architecture that corresponds to the scope of the planned service inventory. As service candidates are produced or refined through repeated iterations of the service-oriented analysis (and service modeling) phase, required business models are defined or updated, the technology architecture is accordingly augmented, and the service inventory blueprint is gradually populated.

Additional Design Considerations

While we’ve been primarily focused on the identification, definition, and classification of reusable service logic, it’s important to acknowledge that the Service Reusability principle encompasses several more considerations that shape the service logic and its support architecture, including:

  • robustness of reusable service logic

  • sufficiently generic and flexible service contracts and functionality

  • testing and quality assurance to ensure sufficient “real world” reusability

These types of characteristics, many of which are shaped by design techniques borrowed from the commercial software product development industry, help prepare service logic for a broad range of reuse scenarios.

Other -----------------
- Service-Orientation with .NET : Service Discoverability
- Service-Orientation with .NET : Exception Shielding
- Service-Orientation with .NET : Service Abstraction & Validation Abstraction
- 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
 
 
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
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us
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
 
programming4us
Natural Miscarriage
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Game Trailer