Architecture

Retired Content

The Web Service Software Factory is now maintained by the community and can be found on the Service Factory site. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. Retired: November 2011

This subtopic describes the overall architecture of services built using the Service Factory. The architecture is an aggregation of the three layers described later in this topic.

The service architecture is comprised of the following elements:

• Service interface layer. This layer defines the operations provided by the service, the messages required to interact with each operation, and the patterns by which these messages interact—these patterns are referred to as message exchange patterns. The service interface layer is described by a service contract, which specifies the service behavior and the messages required as the basis for interaction. The service interface layer contains service adapters, which implement the service contract and expose its functionality to endpoints. It also implements the translation between data outside the service and data within the service.
• Business layer. This layer incorporates components that implement the business logic of the service. Some services often require only a simple business action, but services with more complex requirements may implement a Controller pattern or business rules for implementing service behavior. The business layer also includes business entities that represent objects specific to a business domain. These entities represent both state and behavior. This layer can also include business workflows. These define and coordinate long-running, multi-step business processes, and they can be implemented using business process management tools, such as Windows Workflow Foundation in the .NET Framework 3.5.
• Resource access layer. This layer contains the logic necessary to access data. The layer also contains service agents, which isolate the idiosyncrasies of calling diverse services from your application and can provide additional services, such as basic mapping between the format of the data exposed by the service and the format your application requires.
• Components to address cross-cutting concerns. These components address functionality common to multiple layers of the architecture. Exception management and instrumentation are examples of this common functionality.

Figure 1 illustrates these layers of the service and shows the interaction between the service and the client applications and the interaction between the service and other services. Services built using the Web Service Software Factory help you create the service interface layer.

Figure 1
The high level architecture of a service

Logical View

Figure 2
Logical view of a service

Figure 2 illustrates the following elements:

• Data types. These are used to define the data structures that form the basis for content within a message. These types are often reused by different operations of a service and even by different services.
• Message types. These are used to compose complex messages from existing data types and primitive types.
• Service contracts. These specify the operations that services support and the messages required for interacting with each operation.
• Service implementations. These are .NET Framework classes that implement service contracts.
• Adapters. These invoke business actions after they use the EntityTranslator to translate between message types or data types and types required by the business actions.
• Entity translators. These transform between message types or data types and business entities. The entity translator is an object that is tightly coupled to both the service interface and business layers, but at the same time provides loose coupling between them. This loose coupling prevents changes in one layer from forcing changes in the other layer.
• Business actions. These organize business logic by procedures where each procedure handles a single request from the presentation layer.
• BusinessEntity. This is a class used to represent a domain model entity within the business layer of the application.
• Repository. This is an intermediate object used to support interactions between business logic and the data access logic.
• IDomainObjectFactory and DomainObjectFactory. These are used by the repository to invoke procedures on the database.

Implementation View

Figure 3 illustrates the resulting structure of a Visual Studio solution when the Service Factory is used to build a service-oriented application.

Figure 3
WCF implementation projects created using the Service Factory

This Visual Studio solution structure conforms to the logical view while also supporting the requirements of the deployment view.

Deployment View

Figure 4 illustrates the relationships between the .NET Framework assemblies in a service-oriented application built using the Service Factory.

Figure 4
Relationships between .NET Framework assemblies

Figure 5 illustrates a common deployment pattern for a solution deployed on an intranet that has rich client applications consuming Web services. This is the main scenario targeted in this release. The pattern consists of one server farm that hosts services, data access logic, and business logic, with all user process and user interface components deployed on the client application.

Figure 5
Rich client accessing a Web service

Figure 6 illustrates the deployment of services and service agents (components that may call Web services or that may connect with other systems) with local business logic.

Figure 6
A service with local business logic

For more information about deployment, see Chapter 4, "Physical Deployment and Operational Requirements" in Application Architecture for .NET: Designing Applications and Services on MSDN.