Introduction to Windows Server AppFabric. Hosting Services, hosting and scaling WCF and WF services

Getting data into the application through services is becoming increasingly popular. On Windows, this most often means the implementation of such services based on the Windows Communication Foundation (WCF). And due to the fact that the logic of such services can often be represented as workflows, it is possible to implement WCF services using Windows Workflow Foundation (WF).

But the question arises, where should all these services be launched? Neither WCF nor WF require a specific host process, so developers can use them as they see fit. However, creating an efficient and manageable host is not such an easy task. It would be much easier if Windows Server offered more support for hosting and managing these services.

And this is exactly what AppFabric Hosting Services offers. In order to better understand this part of the Windows Server AppFabric, it would be useful to first quickly run through the underlying technologies of WCF and WF.

Technology Basics

WCF offers a common way to create and consume services. WF offers support for creating business logic in the form of workflows. Since WF workflows typically use services to interact with the outside world, we will start with WCF to describe these two technologies.
')

Creating Services: Windows Communication Foundation

WCF allows a developer to create and use different types of services — SOAP, RESTful, and others — through a common programming model. Figure 1 shows the basics:


Fig.1. WCF Services Schema

Using Visual Studio (or another tool) a developer can implement a service that can offer any functionality. Such a service becomes available to customers through one or more endpoints, each of which provides a specific interface (also known as a contract).

The service usually divides its functions into a number of operations, each of which is responsible for one or another aspect of business logic. For example, a service that implements an e-commerce application may have operations to create a basket, add an item to the basket, delete an item, pay for a purchase, and so on. The client of this service causes each of the operations as needed.

Creating Workflows: Windows Workflow Foundation

How should developers implement the service? In some cases, service operations may be independent of each other, for example, in a service that offers access to different types of data sets. In other cases, service operations may follow each other in the form of a process, which means that they must be called in a certain order within a certain period of time.

For example, think about how a developer can implement a web store cart service with all the necessary operations: create a cart, add a product, delete, pay. The first challenge that the client will perform is the creation of the basket - it is completely unacceptable to do something else with the goods before that. Further, the client usually triggers the operation of adding a product to the cart - there is no point in calling the deletion in the empty cart - and then it can call the delete function if necessary. When the payment function is called, it is already unacceptable to call the operation of adding or deleting goods.

Potentially, all this can take a large amount of time. Imagine, for example, that a user created a shopping cart, added a couple of goods, and then suspended work with the service for a while. He may return in a few hours or days and will expect his basket and goods to be still waiting for him.

How should this kind of logic be implemented? In fact, this is a series of steps with rules defining the order in which these steps should be executed. The implementation must also maintain the state — the cart — throughout the entire process, which may take hours, days, or even more. Especially in those cases when the goal is to build a scalable application, the implementation of such logic in the form of workflows built on the basis of WF would be the most preferable. WF workflows are designed to simplify the creation of processes and they can be a good choice when developing certain types of services.

WF consists of simple basic parts: a designer for building business logic blocks and a runtime environment for implementing logic based on workflows. Figure 2 illustrates the operation of WF:


Fig.2. WF - the basis for creating process-oriented business logic

Each WF workflow is created based on activities, each of which implements a part of the business logic of the process. WF offers the standard Base Activity Library (BAL) with a set of activities that implement basic functions such as if or while. Developers are free to create their own activities to meet the needs of their business logic. In order to create a workflow, a developer can use the WF Workflow Designer, which is part of Visual Studio, to distribute activities. Regardless of what activities will be used, they are all executed using the WF runtime.

A workflow offers a set of useful things to a developer who implements the process. For example, when a workflow is waiting for input, such as a request to add or delete a basket item, the WF runtime can automatically save the state of the workflow and unload it from memory. When a new request is received, the environment reloads the state and starts the worker thread to process the request. This allows you to simplify the development of scalable applications, since the worker threads do not consume memory, system threads, or other resources when they are not executed. The runtime can save a record of each workflow execution, known as tracking, allowing the developer to see various useful things, such as when each activity is turned on and off in the workflow.

Creating a service based on the workflow

WF workflows can be used to implement a fairly large number of diverse types of business processes — they are not limited to creating services only. However, a WCF service whose logic was created based on WF deserves its own name — a service based on a workflow. Figure 3 demonstrates this approach:


Fig.3. Workflow based service

Imagine a developer who creates a service based on workflows or a simple WCF service that does not use WF. Neither WCF nor WF explicitly defines the host of the process in which the service should be running. The good thing about this is that the developer is free to choose which process he will use - WCF and WF do not limit him in this. This is especially important for industrial development, when the main goal is to create business logic, and building a host process for the service is unnecessary work. After all, this process is part of the infrastructure, and infrastructure issues are the responsibility of Windows Server. The solution to all requests for hosting services in the infrastructure is what AppFabric Hosting Services helps.

Introduction to AppFabric Hosting Services

AppFabric Hosting Services (codename "Dublin") is not designed to create some kind of completely new infrastructure. On the contrary, it is built on what is already offered by the IIS server and the Windows Process Activation Service (WAS) mechanism. Based on this foundation, AppFabric Hosting Services adds new capabilities to run and manage WCF services, including workflow-based services. Figure 4 illustrates this:


Fig.4. AppFabric Hosting Services makes it easy to start and manage services

As shown in the figure, WCF and workflow-based services are launched in workflows serviced by IIS - this means that AppFabric Hosting Services does not create any proprietary processes. This technology also uses the capabilities of WAS, which allow you to start the service at the time of receiving a message via HTTP or another protocol. AppFabric Hosting Services is built on existing infrastructure, adding the ability to run certain services immediately after deployment, without waiting for messages to be received. This allows the service to be more responsive to customers who are the first to contact it, since they do not have to wait for the service to start.

As shown in Figure 4, AppFabric Hosting Services also extends IIS Manager with new service management tools. Using these extensions, the administrator can manage the WCF configuration, start or stop services, explore service endpoints, suspend, resume or terminate certain instances of services based on workflows. At the same time, AppFabric Hosting Services offers a set of PowerShell cmdlets for managing services, allowing administrators to create their own scripts.

In order to simplify the lives of developers, Visual Studio offers built-in project templates for creating both WCF and WF services. Services created on the basis of these templates can be immediately placed in AppFabric Hosting Services - developers do not need to do anything extra. And after the service is deployed, it can be available for consumption in many different ways. Consider them on the scripts.

Scenario: hosting service based on workflows

Although AppFabric Hosting Services can be used to work with any WCF service, it offers additional support for running and managing workflow-based services. Figure 5 shows some of the most important such features:


Fig.5. AppFabric Hosting Services contains additional tools.

As mentioned earlier, the WF runtime automatically saves the state of the workflow, which waits for data input, and then restores it when data arrives. But where is the condition preserved? If you use WF as a separate mechanism, the developer has to independently create and configure the database to save the state. However, as shown in Figure 5, AppFabric Hosting Services offers a pre-configured state store. WF also allows you to track the workflow execution, automatically allowing the developer to obtain detailed performance information. And again, WF itself does not determine where exactly the tracking information is stored. As shown in Figure 5, AppFabric Hosting Services offer built-in database for monitoring. It is necessary to clarify that the state storage and monitoring database are separated from any of the application databases that can be used by the workflow.

As with any other WCF service, there are monitoring and control mechanisms for workflows. Along with the previously described service control elements, AppFabric extends IIS Manager with additional features that apply only to workflow-based services. For an example, take a look at one of the extensions called AppFabric Dashboard shown in Figure 6.


Fig.6. AppFabric Dashboard Control Panel

As shown in the figure, AppFabric Dashboard offers the AppFabric Hosting Services control panel. From above, you can see the status of current WF services, which displays the number of services in different states. A little lower in the window shows the history of recent calls, exceptions, and so on. Microsoft also offers the optional Management pack for System Center Operations Manager, which allows you to monitor AppFabric Hosting Services events using standard Windows management tools. The purpose of these tools is to provide clear information about what is happening in the environment of hosting services at the current time.

Scenario: make workflow services more scalable

The ability of WF to automatically save and restore the state of workflows allows developers to create scalable business logic. AppFabric Hosting Services allows developers to create workflow-based services even more scalable. Figure 7 demonstrates this:


Fig.7. Scalable workflow-based services architecture

In this scenario, three web servers launch copies of the same ASP.NET load-balanced application. ASP.NET is used only to generate a user interface. The business logic of the application, maybe a shopping cart, is implemented as a service based on workflows (and so there is no confusion: although this is not shown in the figure, as a rule, each service based on the workflow is launched as an IIS workflow) .

The first user request is sent to the top web server (step 1). The ASP.NET page that received this request causes the first operation in the service based on the workflow, for example, the creation of a basket. This request is sent to the service instance running on a separate server (step 2). Once the operation is completed and the result is returned, the WF runtime automatically writes the state of the service to the storage supplied by AppFabric Hosting Services (step 3).

The following user request is sent by the load balancer to another web server (step 4). This time the ASP.NET page that processes the request, for example, adding an item to the cart, sends a request to a service that is running on a different server from the first (step 5). Although this second request is executed by a service on another server, the WF runtime allows you to load the state of the workflow instance from the repository and process the request (Figure 6).

As shown in the example, AppFabric Hosting Services allows the same services based on worker threads to run at different times on different physical servers. This makes services more scalable, since now we can host many intermediate servers to handle any number of requests. Just as an ASP.NET application can be scaled by simply adding web servers, so business logic implemented as workflows can be scaled with additional servers.

See the beginning at this address , continued, ending should.