Now the BizTalk is recognized and advertized mostly as an Integration server.
There is an architectural pattern for using BizTalk. It is used:
* as an integration engine, as an integration layer between applications (usuallyand as a data transformation layer);
* for the workflow applications (including the long-running workflows);
* as a host for Business Rule Engine applications.
I think the BizTalk Server is more then that.

Let’s think of BizTalk Server as a genericApplication Server.
Now we have the Windows Server OS as an Application Server. We have the IIS as the Application Server.
Windows can host the standalone applications and Windows service applications. We can start the applications by hand, schedule its start by the Scheduled Task utility, setup the special developed applications as the Windows Services.
IIS hosts the Web applications.

Let’s look at the BizTalk Server as a genericApplication Server. Application Server for our usual standalone applications.

The .NET applications can easily start from the Expression shape of the simple Orchestration. There is little redundancy in development.

What the advantages we have using the BizTalk as an Application Server for standalone applications?

Data-driven applications:
Somewhere in the system the data appears. It can be a new file copied in a folder, new file received by FTP, new data in SQL database, new messages in the message queue, new data in the SAP/R3 application, new e-mail. Those data triggered the BizTalk application.
Data is appeared and this starts the appropriate application.
Say a hundred new files appears in the folder (or a hundred rows appeared in the SQL database). And this starts a hundred appropriated applications to concurrently process this data.
This is not easy to implement this data-driven application managementin the usual standalone application.
BizTalk implements many transport and application adapters to transfer data to/from BizTalk applications, like File, FTP, MSMQ, SAP/R3, JD Edwards, etc.

Long-running applications; data correlations:
Say our application sent data to the remote partner then after several minutes or days the partner modified data and sent it back. How can we facilitate the application to wait this response? How can the application survive the server restarts? How can we facilitate the situation when thousand applications are waiting the responses and flooding the server memory? How can we correlate the response data with appropriate application?
BizTalk by design works all these cases.

Scaling up and scaling out:
Having BizTalk as an Application Server the developers can redesign the architecture from big, monolithic application to the small, isolated business-unit application set. BizTalk helps to transfer data between those small applications, helps to correlate data. This ways to high scalable application. Moreover the BizTalk has the intrinsic functionality to manage the high availability and high performance requirements by the special host mechanism.

Yes, it’s true that the data-driven applications get the well-organized data which definitely is the output from other applications. Is that mean we’ve returned to the point where we have gone because it means the old paradigm, the integration level where the BizTalk always was positioned?
The integration tool is the intermediate level tool. It is not the self-independent tool.
But seems the BizTalk is the self-independent Application Serverfor our usual standalone applications.

Any ideas?
Best regards,