The .NET Platform
Development Tools
COM & COM+
Data Access
Web Development
XML Technologies
Windows Servers
Wireless & Mobile
Security issues
Design & Process
Career Development
Analysis & Comment
Disposable Objects
We found this book useful!
You are not logged in: login here to access all areas.
Handling the traffic with COM+
Microsoft has a mature and comprehensive set of middleware services in COM+. Matt Nicholson finds out how they can help you build large-scale applications.
Author: Matt Nicholson
Last updated: Jul 2000
The history of modern computing can be seen as the slow reconciliation of two very different worlds. On one side are the desktop PCs, offering ever increasing power and ever more sophisticated user interfaces. On the other are the mainframe and mini-computers, running applications that have become critical to the operation of the enterprise, but less and less able to adapt to the needs of the modern world - so much so that they are frequently referred to as 'legacy' applications. The middle tier Balancing the load
The first overture came with the widespread enthusiasm for client/server architectures in the early 1990s. Increased use of local area networks made it feasible to link Windows-based applications to legacy systems using custom drivers. Techniques such as 'screen-scraping' kept IT managers happy because, as far as they were concerned, their precious mainframe was still talking to a conventional green-screen terminal just as it always had. End-users were happy because they could carry out their day-to-day business through stylish new point-and-click user interfaces.
However, once the honeymoon was over, the inadequacies inherent in the client/server paradigm began to show through. IT managers were increasingly reluctant to tamper with badly documented mainframe applications that were becoming more out-dated with each passing year. By contrast, clients were becoming top-heavy as a new breed of developers, assisted by tools such as Visual Basic, turned to the increasing power on the desktop to cope with the ever-changing needs of the modern business.
As the number of clients in a client/server system grows, version control and software maintenance become increasingly problematic. Furthermore, each client demands a unique connection to the server, which inevitably limits scalability.
The solution was found in component-based software. Using software components you can encapsulate the various business functions implemented by an application into stand-alone objects, independent of the way in which they are presented to end users, or the way in which the data they manipulate is actually stored.
As a result, business functionality can be separated from the client layer, which then becomes solely concerned with end-user interaction; and from the data layer, which becomes solely concerned with data storage. A three-tier architecture is born, with a new middle tier that implements the business logic inherent in the application (see diagram on next page).
A software component encapsulates a business function, such as the validation of credit cards, the transfer of money between bank accounts, or (in an e-commerce application) the management of a shopping basket. Although some business functions are very specialist, most are likely to be relevant to more than one application. This means that a single middle-tier component can service the needs of more than one application, which makes for more efficient employment of developer resources.
Instead of a hodgepodge of relatively isolated applications, each designed to satisfy a particular business need, organisations can concentrate on encapsulating business rules as middle-tier services, implemented as software components. New client applications can call upon these services as needed, without having to re-invent the wheel. This is the idea behind Windows DNA, and Microsoft's concept of the 'digital nervous system'. (For a full exploration of component-based software, see
'Understanding Software Components')
So how do we implement this middle tier? Obviously, each software component is unique in that it has to satisfy a unique business need. However, there are a number of services that all middle-tier components are going to require such as load-balancing, transaction management, security services and message queuing. Such services are inherently difficult to implement, and it makes little sense for each organisation to implement their own from scratch. Far better to buy these middleware services ready made.
So it should come as no surprise to find that component-oriented middleware is one of the most fiercely contested areas in the market. Those companies traditionally associated with the server side of the equation argue that business services need the stability offered by operating systems such as UNIX, and the capacity offered by modern mini-computers. The main contenders here are the Common Object Request Broker Architecture (CORBA), from a loose alliance of companies represented by the Object Management Group (OMG), and Enterprise JavaBeans (EJB), from Sun Microsystems.
On the other hand, Microsoft argues that Windows 2000, combined with Intel-based PCs, provides a stable platform that is both cheaper and - thanks to the ubiquity of Windows on the desktop - ideally suited to interfacing with client applications. Microsoft's middleware is an extension of its Component Object Model (COM) services called COM+ which comes as part of the Windows 2000 operating system.
COM was originally conceived in 1992 to provide an infrastructure that would allow software components to communicate regardless of what operating system they're running on, and regardless of what language they're written in, although it didn't achieve its full potential until 1996 (see panel). It provides mechanisms that allow clients to locate server components, find out about the interface they expose, and make calls to these interface across process and machine boundaries. It supports reference counting, so components can be cleared from memory when no longer needed; and it provides a security model, checking that the client has the right to access the component. However one service COM did not offer was transaction processing monitoring
(TPM).
As demand on the middle tier grows, there comes a point when it makes sense to distribute middle tier processing across more than one machine - particularly as the 'Wintel' platform (Intel-based PCs running Windows) is relatively cheap these days.
COM+ was originally slated to include component load balancing as standard, which meant that COM+ itself would automatically distribute object instances across the network to make best use of available processing power. However, Microsoft has now decided to make component load balancing part of AppCenter Server, which should be released later this year. AppCenter Server will bring together a number of services and utilities for the deployment of applications across multiple Windows 2000 servers.
Click here for our Privacy Statement. Copyright © Matt Publishing. All rights reserved. No part of this site may be reproduced without the prior consent of the copyright holder.
