Everywhere the talk is about client/server. Have you gone to client/server yet? How many applications are you running? What kind of applications are they? How did you do it?
The talk reflects the recognized significance of this computing paradigm. Client/server is a worldwide phenomenon, powered by the architecture's ability to change the way organizations use information, and thereby confer competitive advantage.
The twin capabilities client/server enables are enterprise-wide end-user data access, and business process change. The two are closely allied. Indeed, many projects that begin as data access end up facilitating business process change. This is due to the fact that heavy user participation is required in end-user data access projects to get the user interface, application navigation, and workflow right. This participation usually results in moving decision-making processes closer to the customer.
And, although studies show that organizations add more features to client/server applications as they gain experience, the most important features are implemented first. These features include multiple operating environments, windowed interfaces, integration with production applications, and desktop application integration. Although some of the features, such as multiple operating environments, are more difficult to implement, they are added first because they are crucial for information access and business process change -- the raison d'etre of client/server.
Lastly, timeliness and accuracy in addressing customer needs is a continual effort. Competitive advantage is not a static quality. It must be constantly maintained -- re-earned, in a proactive manner -- or it will be lost. Therefore, client/server applications must be easily changeable and evolvable.
The environment in which client/server applications are developed and maintained is critical. Initial creation and deployment is only the beginning. The ability to adapt, modify, and manage applications is the acid test.
The development environment must deliver the power and functionality necessary to solve today's technological problems, as well as offer the flexibility to adapt to tomorrow's. Just as client/server applications are changing the way organizations use information, they are also changing the way applications are developed. The challenges posed by the applications themselves are driving the evolution of development.
Industry analysts encourage organizations to think their client/server development plans through from the beginning, and to be long-sighted in their approach.
"If successful, things will only get more serious," points out IDC. That seriousness happens fairly soon, given the business goals of client/server. The need to increase the number of users, number of applications, and complexity of applications grows quickly.
Investing in the appropriate development infrastructure -- architecture, middleware, tools, services -- from the beginning saves pain and added expense later.
First-generation client/server applications have tended to be departmental in scope, performing non-mission-critical functions, with an average of 15-20 users. Typically, these applications have been created with a GUI builder that places presentation and application logic on a Windows(R) PC. Data is handled by a relational DBMS.
This two-tier architecture is appropriate for simple, routine, relatively homogeneous applications that are not expected to grow. Two-tier applications are simpler, faster, and less expensive to build than their three-tier counterparts. Their need for middleware is minimal, if present at all.
The two-tier architecture has difficulty, however, supporting the inevitable scale-up that initial success usually encourages. As adopters seek to expand the number of users, developers, and complexity of applications to fulfill the promise of client/server, the limitations of the two-tier approach become apparent.
Consider, for example, a two-tier database application that grows to encompass many desktop systems. Most of the business logic resides in the desktop tier. Whenever it is necessary to make a change in the business logic of the original application, developers must seek out and change the application code on each and every individual PC that now runs this application.
The Gartner Group counsels that every application be evaluated on a case-by-case basis to determine if two-tier or three-tier architecture is warranted. It advises that a three-tier architecture be applied if any ONE of the following conditions are present, including:
Gartner is not alone. Across the industry, analysts recommend a three-tier client/server architecture for large, heterogeneous, complex, and/or long-lived client/server applications.
Why? Because three-tier client/server architecture solves the scalability problems inherent in two-tier computing. In a three-tier application architecture, presentation, business logic, and data are all logically separated. Each element is an independent component that can be changed or replaced without requiring any of the other components to be rewritten.
Three-tier applications can also be physically deployed in a way that mirrors the logical application architecture, i.e., a desktop PC handles the presentation component, an intermediate server runs the application logic, and a back-end server is responsible for the data processing component. Running client/server applications in a distributed environment expands and complements the flexibility inherent in the client/server architecture.
Three-tier client/server's architectural advantage in addressing scalability lies in its middle tier. The middle tier insulates the application from heterogeneous environment issues and provides for economies of scale -- developer productivity, application consistency -- across the enterprise by enabling key services to be shared by multiple applications.
Since the middle tier/intermediate server will hold business logic and services to be accessed by multiple clients, the application server must be sufficiently powerful to process multiple requests simultaneously to speed throughput and ensure adequate performance.
The need increases as the number of users increases. At the level of enterprise applications, concurrency, serialization, and distributed lock manager needs are high.
For example, currency conversions in a three-tier enterprise application need to be performed in the middle tier -- not at the top tier where the data must be kept pristine, nor in realtime at bottom-tier trader workstations where performance would be degraded and where changes would have to be input to each and every station. Instead, the intermediate server must have sufficient capabilities to handle mission-critical application functions for numerous clients who are all demanding the same information.
Accordingly, it may be advantageous to anticipate demands on intermediate as well as back-end servers when selecting deployment platforms for the move to client/server.
Middleware provides resource location transparency, migration transparency, and reusability for three-tier applications. It alleviates the need to write all the interfaces between components oneself, and recode as often as changes occur in the target environment. Coding the interfaces oneself requires an intimate knowledge of all the underlying platforms, databases, protocols, etc. involved in each target environment. As applications stretch across the enterprise, with a broad diversity of dynamic elements, the difficulty of such a task becomes enormous.
Selection of middleware prior to development tool selection fosters the establishment of a single corporate architecture with a consistent infrastructure for all applications. Developers then need focus only on the business requirements of the application at hand. In this case, middleware selection should be based on the scalable needs of a wide array of existing and anticipated applications.
Distributed computing middleware handles such infrastructure issues as directory, security, platform translations of differing data constructs, and time designations in a heterogeneous distributed environment.
Database gateways and database integrators provide transparent access to and integration of diverse multivendor databases located throughout the network. They access the remote data source and handle the underlying communications. Data middleware alleviates the need to know where data is physically located or the type of database in which it resides.
Transaction processing middleware provides a DBMS-independent method for implementing two-phase commit capabilities. This ensures that updates across multiple databases do not jeopardize application data integrity.
Middleware to link logically separated components into complete applications embraces remote procedure call, message-oriented, and object-oriented approaches.
Remote procedure calls implement an appropriate API for use in synchronous communications links. RPC interfaces between all application components may be overkill for some client/server applications. However, for organizations with strong in-house IS staffs who are developing for an enterprise environment in which many clients need access to many distributed services, use of RPC pays off handsomely.
Message-oriented application linking enables messages to be sent from one program to another, across diverse platforms, through a message queue that acts as a buffer. Asynchronous messaging middleware is ideal for applications requiring "fire and forget" communications or for queuing requests for deferred processing (e.g., with mobile clients). It provides guaranteed communication between distributed applications and requires minimal investment in learning new software.
Application components can also be connected via object request brokers. Object request brokers are middleware that deal with objects rather than communications modes. Object-oriented technology enables finer granularity in decomposability of application elements. Objects encapsulate their implementation behind a generic interface, so it is easier to move them from one platform to another, or to change the underlying program that executes the object's behavior. For this reason, developers sometimes choose to move legacy applications into the client/server world by encapsulating them as objects.
Companies likely to select object request brokers for application integration are those who have already begun work using object technology or plan to do so, and who have existing applications that they want to integrate.
It is possible to build three-tier client/server applications in a traditional 3GL such as C, FORTRAN, or COBOL by separating the logical tiers into callable procedures. Handling procedural complexity in this handcrafted approach can be difficult, however, as one moves beyond one data source and a homogeneous environment. And strict discipline must be maintained, so that later modifications do not negate the decomposability of the application.
Another development approach is to write the application in an object-oriented language like C++. Object-oriented languages and tools promote re-use, make it easier to control the development process, and make application modification easier. Application data and process are tightly integrated in object-oriented technology, which facilitates the integration of business data and process in the application. Many analysts predict that object-oriented, peer-to-peer distributed computing will be the next step in the client/server evolution.
However, an important consideration in evaluating a move to object-oriented development at this time is the skillset of the programming staff. Experience has shown that the transition from COBOL to C++ programming is not easy, and that not all programmers can make the shift.
For those who feel that they are not ready for object-oriented programming, use of high-level 4GLs might be an appropriate course to follow. While 4GLs offer less direct developer control than either traditional 3GL or object-oriented C++ programming, they write at a high level and include powerful built-in middleware that can generate an application for multiple environments. In addition, the more graphical the application specification, the easier it is to maintain the application.
Next-generation client/server development environments currently available include tools that enable developers to create logical three-tier applications, then automatically generate partitioned applications. The applications can also be automatically repartitioned later as deployment needs change.
When a specific line of business application needs to be quickly developed, a 4GL or 5GL development tool may be most appropriate.
Four qualities are usually cited as necessary in good client/server tools: high functionality, integration, scalability, and extensibility. Scalability makes it possible to provide complete functionality to increasing numbers of developers, users, and operating environments. Extensibility allows functionality to be extended within the existing architecture, providing additional functionality and transparent integration with other tools with little or no impact on the performance of current tools and applications.
Obviously, the tools must deliver a great deal of functionality -- three-tier client/server applications are complex. And, although use of loose, ad hoc assemblages of tactical tools are helpful, they are also giving way to more tightly integrated, specification-driven tools, with a central (conventional or object-oriented) repository to track application parts and facilitate re-use within or between applications.
Tools needed in conventional development -- application design, code generation, debugging, testing, version control, configuration management, and project management -- are also needed in client/server development. With the added need for cross-platform accommodation and operating environment independence. Formal 4GLs and CASE tool configurations can be most helpful here.
In some quarters it is believed that all CASE tools are still oriented toward mainframe, host-based development. Analysts point out that perception is no longer true. CASE tools can now generate native GUI code and provide transparent cross-environment targeting.
Application management tools are also important elements in an efficient client/server application environment. After development, application roll-out in a distributed environment can be made faster and easier through the use of software distribution tools.
And after installation, powerful runtime application management tools can help assess and monitor the soundness of a client/server application. These tools transcend the traditional barriers between development tools, system management tools, and middleware to create a logical view of all the components within the context of a given running application (platform, executable files, data, distributed code, networking software, etc.) This enables the administrator to determine if all the parts of the application are correctly configured.
And distributed inventory tools can help to keep track of servers and clients across a dynamic environment. Automatic registration of systems and upgrades helps administrators identify for developers if and where hardware and software needed to implement later application changes resides.
IDC points out that distributed client/server application development is "more difficult by an order of magnitude than host-based development, simply because of the greater number of systems and environments."
Use of consultants and service providers can help ease the process of transitioning from conventional to three-tier client/server computing. Assistance can range from systems integration consultancy, to education and training services, to ongoing support.
A complete set of service offerings should provide assistance opportunities at all four stages of an application environment lifecycle -- alignment of the business and IT strategies, building the client/server infrastructure, integration and migration to the new environment, and its management and operation.
A broad portfolio of service offerings enables a development staff to supplement in-house talent where needed, and to avoid purchasing unnecessary services.
The client/server paradigm is sweeping through the computing world, changing both the way organizations use information and the way applications are developed. Its three-tier architecture provides the scalability necessary to successfully sustain client/server applications at any level, including the enterprise.
Guided by principles of functionality, integration, scalability, and extensibility, organizations can begin today to assemble the infrastructure, middleware, tools, and services that will stand them in good stead in both creating and modifying client/server applications.
Judicious selection in the software development environment, coupled with solid training and education of the development staff, can result in the development productivity that makes the promise of client/server computing a reality.
For more information on issues to consider when selecting a client/server development environment, see:
Aberdeen Group, Inc. "Object-Oriented Three-Tier Plus Computing: Client/Server for Adults". Boston: Aberdeen Group, Inc., February, 1996.
Eckerson, Wayne W. "Three-Tier Client/Server Architecture: Achieving Scalability, Performance, and Efficiency in Client/Server Applications," Open Information Systems. Boston: Patricia Seybold Group, January, 1995.
Hendrick, Stephen D. and Anthony C. Picardi. "Application Development Tools: Scalable Client/Server Computing". Framingham, Massachusetts: International Data Corporation, February, 1994.
Melling, W. "Three-Tier Software Architecture -- Hardware Deployment". Stamford, Connecticut: Gartner Group, January 18, 1995.
Picardi, Anthony C. "Application Development Tools: Client/Server Tools -- Keys to Competitive Advantage". Framingham, Massachusetts: International Data Corporation, February, 1994.
Picardi, Anthony C. "Application Development Tools: Coresident Tools for Client/Server". Framingham, Massachusetts: International Data Corporation, August, 1994.
Picardi, Anthony C. "Application Development Tools: Tools for Enterprise Application Development". Framingham, Massachusetts: International Data Corporation, June, 1995.
Schulte, R. "Three-Tier Software Architecture in Perspective". Stamford, Connecticut: Gartner Group, January 18, 1995.
Schulte, R. "Two-Tier vs. Three-Tier Trade-Offs". Stamford, Connecticut: Gartner Group, January 18, 1995.
Digital believes the information in this publication is accurate as of its publication date; such information is subject to change without notice. Digital is not responsible for any inadvertent errors.
Digital conducts its business in a manner that conserves the environment and protects the safety and health of its employees, customers, and the community.
Windows is a registered trademark of Microsoft Corporation.