Examples of COM-Based Application Architecture

"An example of a high-level application architecture that you might use in COM+ is a prototypical, simple application with a FAT client and a Win32, or native, client. This application will communicate with a business service layer and an application data service layer running COM+ on Windows 2000. This application also has a number of components operating in the COM+ environment. These two layers communicate using DCOM, enabling the Win32 application to request a particular type of object and create it. An interface pointer will be passed, and the user service layer and business logic will communicate directly. These business objects can, in turn, use other objects. In many cases, the business objects will use data objects that encapsulate access to particular data stores. For example, ADO might be used to share SQL Server and also the data object communicating with SQL Server. There are several different options and types of stores that you can use for this type of data access. However, ADO is the easiest, most flexible option, from a programming perspective. It's a high-level and easy to understand model that can be accessed from scripts and components in almost any programming language. Later in this presentation, we'll talk about some alternatives to ADO and their varying degrees of flexibility.

"Another type of application that has recently become common is Web-based applications. In Web-based applications, IIS, probably in conjunction with ASP pages, acts as the part of the business layer that directly communicates with the user services, or the program that the user can access. In many cases, this user service layer is written using HTML, or perhaps dynamic HTML, or DHTML, and perhaps using some client-side components to aid in constructing logic that you might want to run in your user service layer. Instead of using DCOM to communicate between the Web-based application and IIS, you would use HTTP. In this case, you'd get a typical HTTP response request used to communicate between the user service layer and the ASP pages. The ASP pages then call business objects to do some of the work. ASP pages are interpreted today, so if you have lengthy work that you might want to reuse in multiple environments, it's really important that you take it out of script code and encapsulate it within a component. As I mentioned, these business objects can communicate with the data objects, which in turn will communicate with the data tier.

"Another aspect of applications that you might want to consider is having two independently developed applications that don't really have any explicit dependencies on each other, but sometimes need to collaborate and share information. A common example used in this context is order entry and shipping. When an order is placed, it will eventually need to be shipped. But you don't need to tie up the order entry process, waiting for confirmation that the order will be shipped, when it will be shipped, who will do the boxing, and so on. What you could do to prevent order tie-ups is use messaging to pass information from one application to another. In this scenario, you would have a front end that communicates to an application and does some work. That application, in turn, sends a message to a message queue; MSMQ would then be responsible for sending it to other applications that may use the message. Each application can communicate with its data store, and in some instances, may also communicate with the same data store.