BizTalk - Data-driven application host server (?)

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

But the BizTalk Server is more then that.
The BizTalk Server is a generic Application 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 standalone application by hand, schedule its start by the Scheduled Task utility, setup the special developed application as the Windows Service.
IIS hosts the Web applications.
Let's look at the BizTalk Server as a generic Application Server. Application Server for 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 message in the message queue, new data in the SAP/R3 application, new e-mail. The data triggers the BizTalk application.
Data appeares and starts the appropriate application.
Say a hundred new files appears in the folder (or a hundred rows appeare in the SQL database). This starts a hundred appropriated applications to concurrently process each file or each row.
This is not easy to implement this data-driven application management in the cusom-made 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 sends data to the remote partner then after several minutes or days the partner modifies data and sends 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 services 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 helps to create the high scalable applications. Moreover the BizTalk has the intrinsic functionality to manage the high availability and high performance requirements by the special host mechanisms.
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 Application Server for our usual standalone applications.
Any ideas?

Best regards,
Print | posted on Tuesday, November 13, 2007 9:06 AM


No comments posted yet.
Post A Comment