While itıs difficult to call the next trend in this industry, there seems to be something going on among the traditional client/server tool vendors. Most of the vendors, such as Microsoft, Borland, Powersoft, and so on, are creating new strategies to provide tools to produce applications not only at the front end, but at the middle tier as well. In other words, the traditional front-end tool vendors are getting into the application server business ı once the domain of the high-end middleware vendors only.
This is actually nothing new. Most of the vendors were moving toward servers slowly around 1995, but then the Web hit, and R&D dollars went elsewhere. For example, PowerBuilder 5.0 had its own proprietary application partitioning subsystem as well as a mechanism to communicate with CORBA ORBs. However, now that the Web has found its place in the enterprise, traditional front-end tool vendors are looking once again to build applications within a middle tier or on their own application server technology. I call this "moving to the middle," or the shift in focus from the front end of the client/server architecture to the middle tier.
To understand why we are moving to the middle here, we need to understand where we came from. The basic concept of client/server is to split the processing load between, naturally, a client and a server. By sharing the processing load and processing requests in parallel, a client/server architecture provides better performance and decouples the application processing from the data, not only logically but physically.
Things arenıt always that simple, however. Today we are looking past the traditional client/server concepts, moving client/server away from the two-tier world to a complex world where applications are split across multiple processors and databases. Whatıs more, these systems must maintain mission-critical characteristics such as providing fault tolerance and failover features. We are not there yet with traditional front-end tools such as Visual Basic and Delphi, but weıre moving quickly in that direction.
Application partitioning, or placing logic at the client and the application server (sometimes the database), is an architectural concept. A fundamental decision when building a client/server system is which base architecture to use (for example, two-tier, three-tier, or n-tier). Once architects select an architecture, they must decide where to place the application processes to optimize available resources and meet application requirements. Some things to consider are user load, processing load, application type, cost of development, maintenance, and performance expectations.
Two-tier client/server systems are typically specialized client/server development tools (for example, Visual Basic, Delphi, PowerBuilder, and so on) building an application at the front end and a database server in the rear. Traditionally, two-tier client/server applications were fat-client applications. However, the trend has been to place some of the application processing on the database server in the form of stored procedures and triggers.
The advent of three-tier and n-tier client/server architectures has revolutionized what we can do with client/server. Traditional two-tier client/server canıt scale to a large user and processing load; three-tier and n-tier client/server solves this problem. For example, a middle tier provides not only another location for application processing but a mechanism to multiplex the database server as well. Thus, 1,000 users may only appear as a few hundred to the database server.
Multitier and three-tier client/server architectures have other advantages as well, such as the ability to place application logic in a single shared layer. This architecture provides better maintenance and "change without pain." I see different approaches to providing the middle layer: transaction processing (TP) monitors, distributed objects, and proprietary mechanisms.
TP monitors sit between the client and a resource and can process transactions on behalf of one or many clients. A resource can be a queue or an API, but in most cases it is a database server.
The basic idea is that a developer builds services within the TP monitor environment. Services are small programs that can interface with the TP monitor through an API. Examples of TP monitors include Transarcıs Encina, BEAıs Tuxedo, Microsoft Transaction Server (MTS), and IBMıs CICS.
TP monitors can reduce an application to a transaction level, breaking it down to many transactions or events that are bound together by a front end. Developers create most application functions as transactions with a beginning, a middle, and an end. These are usually granular functions such as updating a customer database with new customer information or deleting rows from several heterogeneous databases at the same time.
Using this transaction model, TP monitors can recover from problems that may occur while processing a transaction and bring the system back to the state it was prior to invoking the transaction. This rollback means that network and database problems wonıt leave your system or data in an undesirable condition. Either the transaction works, or it doesnıt.
TP monitors can also perform load balancing, which means that the TP monitor can move processing around to maximize available resources. TP monitors can also restart servers and report trouble to a central console. Of course, each TP monitor does these things in its own proprietary way.
Distributed objects are tool- and language-independent binary objects that can run on a variety of platforms. Distributed objects can communicate with one another using a common communications mechanism, where they can invoke each otherıs services.
Two flavors of distributed objects exist: those built using the Object Management Groupıs (OMG) Common Object Request Broker Architecture (CORBA) specification and those built using Microsoftıs Distributed Component Object Model (DCOM). CORBA is the oldest and most widely used distributed object standard. CORBA isnıt a product, but a specification. Several commercial object request brokers (ORBs) are based on CORBA, including Expersoft, Iona, and now Borland (more on Borland later).
The idea is that a client/server developer can build application services using any one of these commercial ORBs and distribute them to any server. Because they all use the same CORBA standard, they should be able to communicate with each other, finding and invoking object services. This interoperability lets the developer mix and match ORBs to create a flexible distributed system independent of a tool, language, or vendor.
While CORBA-based ORBs could be the future of client/server, they have a few problems. First, performance is not what it should be, and ORBs sold by different vendors canıt work together yet. The OMG and the ORB vendors are both addressing these problems. For now, they are very much niche players, and the market seems to be shrinking. Moreover, ORBs lack the tool support they need to become successful in the near future.
DCOM takes a different approach. Instead of creating and having everyone agree upon a specification, Microsoft has built the ORB infrastructure into the operating systems it sells. For example, if you purchase a copy of Windows NT 4.0 or Windows 98, DCOM is available to you.
The idea behind DCOM is that any tool that can create automation servers can share those servers with other COM-enabled applications. This strategy means that most of todayıs existing client/server development tools, including PowerBuilder, Visual C++, Visual Basic, and Delphi, can create ORBs for use over DCOM.
So how is Borland moving to the middle? It went out and purchased a few middleware products, including Visigenic. As I was writing this column, Borland disclosed a new product road map, explaining how the company will hook together the distributed object technology from the Visigenic acquisition and its core set of tools.
Calling itself the "New Borland," the company plans to leverage the use of objects strategically from the client to the enterprise. In other words, itıs integrating Visigenicıs CORBA-compliant ORB technology with its popular tools such as Delphi and JBuilder. This is a good move for Borland, which wants to move into the traditional enterprise-scale application development market.
At IT Forum (held the end of April after this column went to press) Borland will reveal an integrated tool strategy surrounding the use of the Visigenic ORB. At the same time it announces the Borland middleware strategy, it will also announce a new version of its Entera middleware for tying to legacy applications using the Distributed Computing Environment RPCs. Entera will now support CORBA using the Visigenic technology.
While the Borland approach is moving closer to the middle, it lacks the transaction support many developers are looking for today that will send them into the waiting arms of Microsoft. This hole in the strategy needs to be filled.
Microsoft has already moved to the middle with its MTS and DCOM offerings. Visual Basic is the tool of choice for most client/
server development shops out there, and if you know how to use Visual Basic, then youıll know how to link your Visual Basic applications to an application server driven by MTS. MTS lets ActiveX controls become transactional in nature, letting clients invoke those transactions using the existing DCOM infrastructure.
The advantage of the Microsoft solution is price and ease of use. MTS, like everything else from Microsoft, will be built into the base operating system of Windows NT ı so you can get it for a song. Other TP monitors cost $50,000 or more, depending on the platform and user configuration. Whatıs more, where traditional TP monitors were difficult to program, Microsoftıs is going to let developers program MTS using any number of traditional Microsoft tools, such as Visual Basic or Visual C++. So far, Microsoft is well ahead of the direct competition and is the one to beat, in my opinion.
Powersoft, a division of Sybase, is taking a similar approach to Microsoft, providing a robust transactional application server ı called Jaguar Component Transaction Server ı that can use components. Powersoft, however, goes beyond the MTS features by providing the ability to run JavaBeans and C++ components as well as ActiveX.
The idea with Jaguar, like MTS, is to let the developer place application logic on a remote application server and create the application server logic using traditional tools such as PowerBuilder. The value of this type of architecture is scalability, as well as the ability to share application logic using many different types of enabling technologies or languages. The disadvantages are apparent. Jaguar will have to compete with Microsoft head to head, and thatıs always a losing situation in this day and age.
While the move to the Web was mostly a good thing, the movement to the middle tier and the application server is a great thing. We simply must be able to create applications that both are scalable and offer the ability to share logic at a centralized server.
Whatıs more, and unlike the traditional application server technology (for example, TP monitors) that have been around for years, we need the ability to create those applications with little or no additional pain. In the past, you could count on complex three-tier client/server applications taking almost three times as long to create as the same application created using traditional two-tier applications. The front-end tool vendors promote ease of use as the value proposition, and they are carrying that forward to middle-tier development. In other words, itıs a good trend this time.