Introduction to Windows Server AppFabric. Hosting Services with BizTalk and Service Bus

This is the third and final part of the articles on Windows Server AppFabric services. You can find two other articles at the following links:

• Introduction to Windows Server AppFabric. Caching Services
• Introduction to Windows Server AppFabric. Hosting Services, hosting and scaling services

Scenario: Connecting a workflow-based service to an existing application using BizTalk Server

Many applications, perhaps most, have the need to communicate with other applications. For example, imagine the service that was created for the store site again. Suppose a service has to send a completed order to an ERP application for processing, or it may be necessary for it to obtain information from another application to verify a credit card. One way or another, services often need to communicate with each other.

In the Microsoft world, this type of integration is usually handled by the BizTalk Server. Figure 1 shows how a workflow-based service, AppFabric Hosting Services and BizTalk Server can work with each other.


Fig.1. BizTalk Service and Server Integration
')
As shown in the figure, activity in the service can create a request to the BizTalk server. This can be done using a web service or something else, for this purpose BizTalk offers a mechanism of adapters for different types of communications. After the start of the request, it can be processed by the business logic running on the BizTalk server. This logic is implemented as a conductor, it knows exactly how to support the next step in this process. Here, for example, the conductor uses another BizTalk adapter to interact with the ERP application directly. Any reply can be sent back through the same components.

From a purely technical point of view, a workflow-based service running on AppFabric Hosting Services may look just like a conductor running on a BizTalk server. Both of them are workflows, both can be created in graphic editors, Microsoft even offers WCF adapters that can be used by both the service and the conductor. Nevertheless, you should not be deceived, these two technologies solve different problems.

A workflow-based service launched on AppFabric Hosting Services designed to implement business logic is an application. Conductor running on BizTalk, in contrast, focuses only on integration. Integration is a special problem that requires special tools and technologies, and BizTalk is just such a tool. In most cases, the choice between the two technologies is simple: use AppFabric Hosting Services to build applications and BizTalk to solve integration problems.

Although it is technically possible to implement BizTalk functionality using AppFabric Hosting Services and WF, it does not make sense for financial reasons. The total cost of building and maintaining your own integration server is likely to exceed the cost of a license to BizTalk Server. In reality, it would be better to consider AppFabric Hosting Services and BizTalk partners than competitors. Each of the mechanisms plays a role in the creation and connection of applications.

Scenario: Connecting to a remote service via the Service Bus

Another problem that may arise when working with services is providing access to them from the Internet. Imagine that a WCF service running inside an organization needs to be provided to clients outside the organization, via the Internet channels. Regardless of whether or not you are using WF, in this case there are some obstacles. For example, how can a client interact with a service through a firewall? And, knowing that most organizations use dynamic addresses and NAT, how can our service offer a fixed IP for its clients?

Service Bus is part of the Windows Azure platform, was created to solve this problem. Figure 2 shows the scheme of work:


Fig.2. Work Service Bus

To begin with, the WCF service registers its endpoint with the Service Bus, providing a unique name for this (step 1). After that, the Service Bus itself provides this endpoint with the same interface (step 2). Using a unique name, the client can access the Service Bus endpoint (step 3). Since the client is familiar with the interface, he can operate with the end point in the Service Bus (step 4). For each operation that the client calls, the Service Bus calls the corresponding operation in the service on the enterprise infrastructure side (step 5).

To understand why this works, it is important to understand that in step 1, when the service registers its end point with the Service Bus, a TCP connection is established with the cloud mediator. After that, the connection remains open, allowing the Service Bus to invoke service operations without blocking the enterprise firewall. Since the firewall treats such traffic as responses in a connection from a client outside the enterprise, it ignores such packets. Keeping the connection open allows the WCF service to have a fixed IP address independent of NAT, allowing the Service Bus to flexibly invoke service operations. Well, since the Service Bus always has certain IP addresses, customers can easily find it.

Scenario: Creating a composite application with a service based on workflows

With the growth of applications that provide their functionality through services, developers have more opportunities to build various applications that these services consume. Composite applications of this type can be very useful in different situations. For example, instead of directly changing an existing ERP application, it will be easier and cheaper to create a composite application that uses ERP services and other services from third-party applications to create new functionality. Figure 3 shows how a workflow-based service launched using AppFabric Hosting Services can offer a way to create this type of application.


Fig.3. Composite Application Scheme

In this example, a workflow-based service interacts with other applications using several approaches:

• Using Service Bus to invoke operations in an Internet partner application
• Creating direct requests to a CRM application using SOAP services
• Relying on BizTalk to interact with an ERP application

In a growing service-oriented world, simplicity in creating logic for working with these services plays a major role. AppFabric Hosting Services supports this movement by offering a service architecture for running your applications.

Combining parts into a whole

The two parts of Windows Server AppFabric — AppFabric Caching Services and AppFabric Hosting Services can be used separately from each other. But it often makes sense to use them together. For example, imagine that an organization is going to create an application that will be able to handle a very large number of simultaneous requests from users. Figure 4 shows how the two components of the Windows Server AppFabric can be combined to achieve this goal.


Fig.4. Using AppFabric Services Together

As usual, a request from a user can be processed by a load balancer for distribution among multiple web servers with a copy of business logic — as an ASP.NET page — on each. If this logic often uses the same information, for example, a catalog of data describing exactly what an organization sells, then such information can be accessed through a cache cluster implemented using AppFabric Caching Services. And due to the fact that the application shopping cart is implemented using a workflow-based service that is running in AppFabric Hosting Services, requests from the web server can be distributed among several intermediate servers. By the way, although this is not shown in the figure, workflows can also access cache data to get the necessary information. In scenarios like this, combining both parts of the Windows Server AppFabric is a great benefit, making life easier for developers who need to build highly scalable systems.

Conclusion

Slow applications can not be called good. Also really good applications should be managed. By offering an infrastructure to improve the performance, scalability, and manageability of Windows applications, Windows Server AppFabric services can help developers make their applications better.

Like all software infrastructures, these technologies are tools. But tools are the basis for a comfortable life. Similarly, the goal of Windows Server AppFabric is to offer a framework for building more efficient Windows applications. It will be better for everyone if developers spend more time on business logic and less on building infrastructure.