Service base design

sfkwan

SOA Framework???
小弟最近在研究着Dynamic Web Services, 你文章里有些概念和我的想法有些相似,但你的比较清晰.基本上,我要的就解决每个module之间coupling 和scalability 的问题
目前还在Concept 的阶段,迟点才做POC

mokth

这是小第最近写的一片关于FRAMEWORK 的简单文章. 拿出来现丑. 希望大家来讨论,把它搞的更好.

Framework

The Service base framework is built up by several modules (services which provide specific functionality) and manage by a façade class (we named it controller class). The façade class is responsible for the instantiation of the modules and injects all the services to each individual module during start-up; provide the main interface for client (UI) to request functionality and perform specific task. The design is to enable each individual module to have to full access to other modules without direct linking to the modules; each module is design to be behaved independently from each other (only those related assemblies are allowed to direct link to the module for the mean implementation purpose).

The main Façade tasks are listed below.

• Instantiate service modules.
• Inject the services to each individual module.
• Provide the interface for client to deal with services.
• Main Listener class, capture the events fired by the various services in the framework and delegate to the appropriate module to act on it.

Client here means Web Form/Win Form/Console/Window service/Web Service application. The client is only allowed to deal with Façade to utilize the services provided by the framework; it only manipulates instances through their abstract interfaces return by the Façade. The client is not allow or unable to direct call the service modules’ methods. This design makes the client de-couple from the framework, any changes on the framework will not affect the client coding. The client is only focusing on the Implementation of the client requirement.







Services

Services are built up using module design patterns and most of the modules are implemented using an abstract Factory pattern. As show in the picture below, each module consist of a manager (Façade/Factory) class which is responsible for the module instantiation and delegates client (Framework façade class) requests to appropriate subsystem object (component). The client communicates with the module’s components by sending requests to the manager class, which forwards them to the appropriate component. Although the component performs the actual work, the manager class may have to do work of its own to translate its interface to component interfaces. Client that used the manager class don't have to access its subsystem objects directly (de-couple the client from the implementation module).

Module
The manager class is design to “accept” the framework services during initialization. The main framework façade class wills instantiate modules in sequence store the modules’ instant in a list and “inject” the list into each module’s manager class. The manager class is responsible to inject the service list to the sub classes. The class with the services list can inherit the global service helper class, so that the framework services can be fully access without knowing the actual implementation. This design is to make the modules self independent, reducing coupling between modules. Then when one module changes, the change does not propagate to other modules. The communication between modules is through the interface of the global service helper class. This abstract coupling keeps modules from knowing which implementation of a module’s is used.






The component (implementor) can easily extend to subclass (subimplementor). The main component can “detect” any subclasses available using .Net reflection method. This de-couples the sub component from the main component, any change on the sub component is propagating to the change of the main component, and the deployment of the sub component can apply the xcopy method as well.






Module Layout

A general module is consist of several components as shown in the picture below.

• Common

• This is module contains the common tool, constants, enum and structure for use in this service only. This module is not public to outside.

• Component

• This module contains the actual implementation code of the service. The module can direct link to the service common module. It’s strictly prohibited to direct link to other services assemblies. In order to use other services, it will go through the Service Helper (found in the public common module – AbstractServicesHelper class) to request the services which injected in by the service manager.

• Sub Component

• The Similar concept to the component module, the difference is; the component is design for not to direct call by the service manager module, in fact, this sub component is called by service manager using reflection method. The idea behind this is to build a sub component easily without having to rebuild the service manager or other component modules.

• Service Manager

• The manager provides all the necessary simplified methods of the actual implementation hide in the component modules. The component modules are directly link to this module. It's responsible for initialization and injecting the services into the components/sub components.

[ 本帖最后由 mokth 于 9-12-2008 02:24 PM 编辑 ]