An Overview of the Simplified Application Framework - The Configuration Service
(Page 3 of 7 )
SAF.Configuration provides a consolidated service for providing application-specific configuration information at runtime. A business application is often composed of several separate applications and is perhaps developed by multiple teams. Establishing a standard configuration storage and retrieval mechanism helps reduce the management overhead and make the code easier to read, since patterns of retrieving configuration information are the same across different part of the application.
SAF.Configuration is built on top of the .NET configuration and provides an easy way for developers to define application-specific configurations. SAF.Configuration enables developers to consolidate and centralize their configuration settings. SAF.Configuration also introduces the concept of strongly typed configuration objects, which should simplify reading configurations within an application’s code.
Some of the major .NET technologies used in SAF.Configuration are .NET configuration file/concepts. We will learn more about this configuration component as well as strongly typed configuration objects in Chapter 6.
The EventNotification Service The EventNotification service provides an event-notification model for business applications. It is very common that one part of application’s actions are based on events fired from another part of the application, usually from a separate process or remote system. Without predefined event-notification architecture, each team of developers would create its own event-notification system. This would result in a difficult integration process among the different event-notification implementations from separate teams. SAF.EventNotification solves this problem by providing an event-notification service as a component at the framework level. It reduces the need for each development team to create its own event-notification implementation. Because each development team can now use the same standard in sending and receiving the fired events, extra integration effort will not be required during development.
SAF.EventNotification is built on top of two .NET technologies: delegates and .NET remoting. There are two major goals for SAF.EventNotification. First, it should provide developers a standard way to send and receive events across process boundaries. Second, it should eliminate integration effort when multiple applications are involved in event notification. SAF.EventNotification’s architecture is based on the “observer” and “mediator” design patterns, which we will learn in depth in Chapter 7.
The WindowService Service One of the most common ways to start and continue running an application on a Windows platform is through a window service. For example, you can create a window service to host a listener object that constantly watches incoming data at a message queue, network port, etc. Window services integrate very nicely with the service console under the administrative tools and can be configured to automatically start when the operating system is launched. However, for each window service, there is a service installation project that has to be created and deployed. If your application requires multiple window services, the result will be additional overhead to the development and deployment effort. SAF.WindowService solves this problem by creating a consolidated window service that allows the developer to add additional background processes through a simple change to a configuration file. With SAF.WindowService, developers are no longer required to create and deploy multiple window service projects and its installation projects. Instead, they can simply create multiple business classes and modify the settings in the configuration file. These business classes will be loaded and will run continuously in the background after system startup.
The key .NET technologies used in SAF.WindowService are .NET window services, .NET reflection, and .NET threading. The template method design pattern is also used to create the hot spots where developers can plug in their own business logics for the running services. We will cover them in depth in Chapter 8.
 This chapter is from Developing Application Frameworks in .NET by Xin Chen (Apress, 2004, ISBN: 1590592883). Check it out at your favorite bookstore today. Buy this book now.
|
Next: The MessageQueue Service >>
More .NET Articles
More By Apress Publishing
/ 6 
