AppFabric Applications: Episode II–Service, Service Groups and Containers

It is about five years ago as we started a small talk in Redmond about composing of modules and related things. We have been thinking about connecting everything with everything. Of course this was in more or less early but serious days of WCF. The idea was basically elaborated by exposing of devices as services. Imaging, we would have in WCF a binding which incorporates so called in-memory-channel. This channel would not talk via network to other services, but it would talk to other components thought memory. This is a hard topic which requires advance knowledge of WCF stack. It is important in this context, that there is a platform capable to treat components as services.

So if we know that we can start to compose systems as services, because we now, it will always be some way to connect them.In this world we think about components as it would be services. Basically, this idea will work for every component you can imagine. All one application/component needs to have is some endpoint.

By using of that endpoint other applications can talk to this application. Depending on type of application we can have different types of endpoints. For example the queue provides endpoints like https://abc.servicebus.appfabriclabs.com/. The SQL service provides also TCP endpoint at port 1430. Web applications would typically provide TCP port 80. Behind all endpoints there is some specific protocol and some high level application or component which we will simply call service.
As already mentioned in Episode I. In AppFabric Application model, services can be grouped in Service Groups or containers. Because services can behave differently there is a physical constraint when choosing the service group (container). In the current version of AppFabric following containers are supported:

• Web
  Used for: WCF-Service, ASP NET application
• Stateless (AppFabric Container)
  Used for: WCF-, WF- and Code-Services
• Statefull
  Used for: State full services
• Referenced
  Used for: Externally referenced endpoints like SQL, Cache, Queue etc.

Web Container

Stateful Service Group

AppFabric Container (Stateless group)

Referenced Services

There are four containers and each service type can be applied to one container. The only exception is WCF which can be placed in WebContainer and AppFabric Container. Container (Service Group) is in fact the place where services will be deployed. Because of that container provides a set of properties related to deployment. Following picture shows which properties can be currently used.

ScaleoutCount defines how many physical machines will be used to host services in the container. For example, if you set here 100, it means 100 instances of each service in the group will be span across 100 machines in the cloud.

TraceSourceLevel defines the logging level.

After the application is started each service depending of its group will be attached to appropriate container. Following picture shows how all this looks in the In the local environment (emulator).

This is the set of containers which is running all the time locally. If your application has a WebContainer one additional deployment for that container will be performed. Each green bullet represents one machine which host your services which belong to that container. In local environment the maximal number of instances (machines) is 2. While debugging your service it is useful to setup ScaleoutCount to 1. Otherwise it will be difficult to debug two instances in the same time.