Application Evolution with App Server – “Dublin”

Dublin – upcoming Application Server should fundamentally address two issues by leveraging of existing applications: Scaling and Process visibility.
However, Dublin could slightly change architecture and implementation details of a typical .NET application.
To understand the idea behind this let’s take a look on typical sales scenario.

The salesman (second form left) enters the customer data in a web app CRM and web app Biling application.
Nothing special. To make this a bit better you will have to implement by yourself web services which will talk to
existing apps as they would be back end. Additionally you will implement some king of fancy front end, which will consume these services.
This is shown on the next picture.

In fact such application would have a service( or just an API) which simply call three services as shown below:

This is much, much better architecture, because it can be endless tuned. For example, if one call fails in this scenario
the user in front end will be possibly frustrated. To avoid this, you will build now the durable workflow service.
This service will receive the message and notify the user that the request has been received.
Then the service (I mean workflow) will behind the scene perform the task shown at the next picture:

The big picture of the final solution looks like:

Now it is obvious that durable workflow services visualize big picture and business relevant process steps.
Considering Scale of the processes we could now implement application which would replace the salesman.

 
Last, but not least, here is the probably final architecture picture of Application Server Dublin:

Material used in this post has been provided by Dan Eshner, who is Product Unit Manager at App Server team.