(Also available at Amazon.com or cbooks.com.)
Spotting trends is not only a nice thing to do, it's a career skill. For instance, those who saw the rise of the intranet early on, and obtained the skills they needed to leverage the technology, were the same people who cashed in when the Web took off. Same can be said about three-tier client/server, and now the rise of distributed objects. We may also see the rise of user agents, or point-to-point networking.
In this, the final chapter, I'll discuss the bright future of client/server, including technology that you'll see in the near and distant future. I'll also let you know about some of the trends you can latch onto today, and where to catch the next wave of client/server technology. Then we'll call it a book.
Clearly, the growth of client/server is steady, and as time goes on, the vast majority of applications we build for businesses will employ client/server technology. We still have a ways to go, and many problems to solve, but you can bank on this certainty: The client/server development game will always have room for talented people.
Look around today's "corporate downsized" job market. Those in client/ server development have little reason to worry. There are more job openings than candidates, and that's been a pretty steady trend for several years. For instance, my biggest challenge as a manager of a technology organization is to keep positions staffed with qualified people. That's why recruiters will beat down your door once you have a few years of experience in the business.
What the intranet brings to the table is a new platform, interface, and architectures. The intranet can employ existing client/server applications as true intranet applications, and integrate applications in the Web browser that would not normally work and play well together. The intranet also means that the vast amount of information on the Internet becomes available from the same application environment and the interface. That's the value.
The intranet also puts fat client developers on a diet. Since most intranet applications are driven from the Web server, the application processing is moving off the client and back onto the server. This means that maintenance and application deployment become much easier, and developers don't have to deal with the integration hassles of traditional client/server (such as loading assorted middleware and protocol stacks).
There is a drawback to the intranet movement. The interest in the Web has taken most R&D dollars away from traditional client/server. In many respects, we put the evolution of traditional client/server technology (middleware, databases, and front-end development tools) on hold while the technology vendors moved their products to the Web.
Moving to Proprietary ComplexityWhile the sheer simplicity of the intranet has driven its success, we are now in danger of driving this technology the same way we are driving client servers: to proprietary complexity. The signs are all over. Where HTML and CGI were once commonly held standards, we now have proprietary APIs such as NSAPI and ISAPI that are pushing CGI aside. Java was considered the only way to program dynamic Web applications, but now we have ActiveX hot on its heels. Even Netscape now touts the standard HTTP as "legacy technology."It's difficult at this time to determine if this movement to proprietary technology is a good thing. One thing for sure is that the simple architecture of just a few years ago is gradually disappearing. In many respects, intranet development is becoming as complex as client/server development. The trend is going to continue. We could see even more complexity in the world of Web development than we ever saw with client/server. |
As interest in the Web moves from getting intranet-enabled development tools out the door as quickly as possible to creating successful applications, we'll see more links between the intranet and traditional client/server. Right now, the tool vendors' fear that they will miss a large portion of the market puts them in a reactive rather than a proactive mode.
Using the past as our guide, we can take an educated guess about the future of client/server. I like to break our predictions up into a few categories: networking, development tools, processors and servers, paradigms, and enabling technologies.
Client/server developers must become networking gurus as well. The performance of the network dictates the performance of the client/server system. What's more, with the advent of application-partitioning technology (such as application-partitioning tools and distributed objects), the network not only links the client to the server, but links all the application objects together to form the virtual (partitioned) application. Clearly, the network is the infrastructure of the distributed application.
In addition to upgrading the speed and reliability of enterprise network technology, we are looking for ways to upgrade the speed of WAN technology. Frame relay and other global networking solutions will create high-performance virtual systems, available throughout the world. Let us hope this technology will extend to the Internet. If you haven't noticed, it's creaking under the strain of thousands of additional users who start surfing every day.
In the past, specialized client/server development tools counted on the fact that processors increased in speed every year to mask the inefficiencies of their deployment mechanisms. But users did notice, and they labeled PowerBuilder, Visual Basic, and other specialized development tool applications "dogs" on low-end PCs. Upgrading the hardware in the entire company to run a single application costs millions, and there is something to be said about efficient application development (such as is offered by most C++ development environments).
Today we see a trend in specialized client/server development tools that offers a true compiler. Besides Delphi, PowerBuilder runs close to native, and Visual Basic (version 5) will also provide a true compiler. Other specialized tool vendors are bound to head in that direction. Tool vendors should have done this from the start, and it's about time they got their act together.
Native Links to Distributed Objects and Transaction-Processing Monitors. Despite the fact that distributed objects and TP monitors are key enablers for multi-tier client/server development, few client/server tools exist that can easily use them. For instance, if we want to use a specialized client/server tool with a TP monitor, we have to load and invoke the services of a DLL (in most cases), or limit the selection of tools to those few that support TP monitors (e.g., Prolific, EncinaBuilder). The same can be said about distributed objects.
As mentioned above, the number of multi-tiered client/server applications keeps growing, and so will the need for client/server tools that can access the services of TP monitors and distributed objects. With demand comes innovation, and most tool vendors plan to provide links to distributed objects and TP monitors. With the advent of Transaction Server, for example, TP monitors come as close to a DCOM connection as any COM-enabled client/server development tools.
As IIOP makes intranet development easier, we'll see a rise in the number of tools that support traditional client/server development and integration with distributed objects. Thus, as a byproduct of links to Web technology, we'll see the use of CORBA-compliant distributed objects as a part of most client/server development tools. Already, any Windows-based client/server development tool that does OLE automation can also link to DCOM, and thus, COM-enabled ORBs. The movement toward the use of distributed objects will continue.
Better Component Development Capabilities. The other side of distributed objects is the ability to assemble client/server applications from prebuilt components. While most client/server tools support the integration of components (e.g., ActiveX or Java), they don't support them well. Many components don't work and play well with others, and don't provide developers with enough granularity.
If component development is to work, tool vendors must provide consistent support for components that will allow developers to modify the interfaces, and easily link components together to create an application. What's more, the same tools should create components. We have many examples of tools today (such as Visual Basic and PowerBuilder) that can both create and use components. The future lies in tools that can easily create and share components, as well as mix and match tools to construct an application from a very low level (e.g., middleware) to a very high level.
If current indicators continue to hold true, I believe ActiveX will provide the component standards we need for Windows, while OpenDoc will have limited success on non-Windows platforms. A lot will depend on Microsoft's ability to parlay ActiveX into a legitimate open standard. Right now, developers view ActiveX as a proprietary standard, still bound to Windows. They are right.
Use of Standards. Of course, the use of distributed objects, TP monitors, and components leads to a discussion of standards. While many standards and standards organizations exist today, standards are only as good as the number of developers who use them.
Key client/server standards include CORBA, COM, and SQL92, but many others run with the wolves. A common problem in the industry is our failure to use and enforce standards. The tradeoff is the exclusive advantage that vendors enjoy while they employ proprietary features versus the benefits they could reap if they would provide developers with standards they support in other tools. While many client/server technology vendors give lip service to the idea, standards are not yet a priority.
The movement toward standards really depends on the users/developers. If we demand that tool and technology vendors employ standards, and agree that interoperability is of great value, the vendors will respond. The standards organizations (such as OMG) also need to work harder to bring standards to the technology. It took five years before the OMG had a standard that actually spelled out a way for CORBA-based distributed objects to work together. That's just too long for this business.
Despite the slow movement, I think we'll continue to move toward a standard technology that will let everyone and everything work together. The trick now is to pick the standard(s) you think will win.
Consistent Language Support. Until recently, the mantra of client/server tool vendors was 'build a tool, build a proprietary language.' Fact is, we have more development languages today than ever before, with languages proprietary to particular tools. The reasons are the same as with our previous standards discussion.
To my delight, the most recent trend is for client/server tool vendors to employ nonproprietary languages in their tool, or to use the same language throughout a product line. For example, Delphi is based on Pascal, rather than a proprietary scripting language like PowerBuilder. Optima++ and VisualAge C++ use C++ as their native language. Visual Basic shares VBA with Access, Microsoft Office products, and even third-party tools such as Oracle's PowerObjects. VBA is licensed by Microsoft to over forty vendors. This trend will continue. While developers are happy to learn a new IDE, they aren't nearly as thrilled when they must learn a new programming language.
True Application-Partitioning Capabilities. Along with links to distributed objects, I believe that tools will continue to provide more sophisticated proprietary application-partitioning capabilities. Many traditional two-tier tools, such as PowerBuilder and Unify, are heading in this direction (albeit slowly), while Forte, Dynasty, and IBI's Cactus are learning to do a better job with their existing partitioning tools.
There is also a movement in the application-partitioning world toward the use of open technologies. For instance, distributed objects and TP monitors now work with the proprietary ORBs of application-partitioning tools. Proprietary ORBs are not a long-term solution, and the opening of these environments to nonproprietary technology will only increase their value to developers.
Consistent Approach to the Intranet. The enabling technology of the intranet must settle down to a few consistent approaches. For example, now we have HTML, SGML, VRML, CGI, NSAPI, ISAPI, Java, JavaScript, VBScript, ActiveX, Java, IIOP, and the list goes on. Although this provides developers with an arsenal of technologies and techniques, it's a few too many standards to follow, and confusing for developers.
Over the next year we'll see the list of intranet-enabling technologies shorten, as the market naturally removes the technologies that don't capture the hearts and minds of the developers and that offer redundant technologies. Redundant technologies include Java and ActiveX, JavaScript and VBScript. We'll also see a movement toward ISAPI and NSAPI, or back to CGI. Finally, we need to go with a single HTML standard, and move away from the proprietary extensions of Netscape and Microsoft.
We'll also see the rise of symmetric multi-processing computers and operating systems for use as clients as well as servers. When Windows 95 and Windows NT merge, clients will have a powerful operating system that can make the most of this new hardware. Clients can once again become a location for application processing.
Servers will become more component-based. Architects will be better able to customize servers around particular application server and database server requirements, adjusting the cache, memory, processors, and disk size to the exact specifications of the application. The operating system that will run these servers will have to keep up. Advanced multi-processing operating systems (such as Windows NT and Unix) will provide better load balancing and fault-tolerant capabilities, including, for instance, the ability to better work through memory, disk, and processor failures without service interruptions.
Despite the religious implications of operating systems and an anti-Microsoft sentiment, Windows NT will take more market share away from the traditional server operating system for client/server: Unix. Windows NT is almost as powerful, supports multi-processing, and can run on a number of processors. What really drives the movement toward Windows NT is the ease of use it offers, as well as its ability to support the majority of off-the-shelf software. While Sun servers will run Oracle, they won't run Word for Windows as a native application. Web servers for use on intranets or the Internet will become the domain of NT as well. Microsoft is giving its Web server away with NT, and you can't have things more convenient than that.
The use of components will become more of an issue too. We really can't build an application by mixing and matching today's components. However, as component standards finally take off (see discussion earlier in this chapter), we'll be able to snap in many application components, and even mix and match components with the native objects of the tools.
Distributed Objects. As I already mentioned, the use of distributed objects will increase sharply and soon. Driven by the popularity of intranet development and the need for multi-tier client/server programming, we'll see the rise of CORBA and DCOM ORBs for use in general application programming. Tool support is critical, and that's in our future too.
Transaction-Processing Monitors. As we move headlong into large-scale, mission-critical distributed computing, we need an "ace in the hole." TP monitors are that ace. I had thought the TP monitor market was foundering, but it's now picking up steam as developers understand the benefits, and as other alternatives (such as proprietary application-partitioning tools) prove themselves to be a bit wet behind the ears. With the advent of Microsoft's Transaction Server, we now have a TP monitor that fits easily into commodity Windows environments, built from the ground up for ActiveX and the intranet. With the success of Transaction Server, I see more TP monitors heading into the market.
The Intranet. Due to sheer numbers, the intranet will continue to be the main area of interest for client/server development. As the hype settles down, we'll put the intranet into perspective and leverage its sex appeal and advantages to the bottom line.
Databases. Databases will continue to dazzle us with better performance and new features. I don't see the big three (Oracle, Sybase, and Informix) giving up much market share to other databases, and I don't see the relational database model going away. The concept of the universal server will enlarge the database market by allowing databases to be a "jack of all trades" for developers (object-oriented, relational, Web, binary, etc.). Databases vendors will find, as Oracle is finding now, that working with distributed objects provides a competitive advantage as the rest of the world moves there.
Middleware. Finally, middleware will evolve too. While middleware is powerful and necessary, it's difficult to use and deploy. In the next few years, we'll see a rise of middleware solutions--both message and RPC-based--that provide "snap-in" functionality and consistent interfaces. Microsoft's Falcon message-oriented middleware will once again prove that Microsoft can turn a high-end product into a consumer commodity, and other, more aggressive vendors will have to keep up.
Remember a few things when you work out your tactics. First, it's expensive to be innovative. If you want to lead technology, there should be a good business cause for doing so. Otherwise, you end up with failed project after failed project as new tools and technologies fail to deliver on promises. I always use the 80/20 rule. Vendors usually deliver 80 percent of their promises up front, and the other 20 percent shows up a few years later. For example, while Visual Basic and PowerBuilder offer proprietary application-partitioning mechanisms, they were so difficult to set up and so limited in what they could do that many development organizations abandoned them in their search for a quicker, easier way to move to n-tier. Visual Basic is fixing its limitations with DCOM and integration with Falcon and Transaction Server, but it took a few years.
Your best bang-for-the-buck in technology is to follow the technology curve. While distributed objects were new and unproven a few years ago, they are proven today. DCOM is not yet proven, and proprietary application-partitioning tools such as Forte or Dynasty are almost there.
First, make sure you read a few trade journals that are specific to client/ server developer issues. DBMS Magazine is a great place for information (check out my column), as is Database Programming and Design. For those who want to dig into particular topic areas, you will find publications such as Object Magazine and The C++ Report helpful. There are also publications for particular client/server development tools such as Visual Basic, PowerBuilder, and Delphi. If you live in those environments, their periodicals are must-reads.
Second, try to attend at least two client/server-related conferences each year. Watch out for conferences with a lot of marketing and product managers talking about technology. Make sure you hear from practitioners who are out there solving real problems, and are not trying to sell a product. Conferences with expos are the best alternative since you can visit with tool vendors while you learn about the concepts.
Finally, learn to step out of your comfort zone. Learn concepts and technologies that you may not become exposed to in your day-to-day job. This means becoming a little more innovative, and a bit of a risk taker.
The world of client/server and intranet development remains one of the most exciting. It's in a constant state of change, and typically things change for the better. We have a lot of evolving to do, and we all need to learn to roll with the punches. Clearly, all roads lead to client/server and the intranet, and all journeys begin with a single step.
PROCESSORS AND SERVERS
We can expect processing power to increase; I don't see any slowdown in that area. Today's servers were only a dream a few years ago, and I'm sure we'll say the same a few years from now. It's a safe bet that the power of servers will keep up with the requirements of your application, and we can now run mainframe class systems on commodity hardware.
PARADIGMS
Today we are well into the object-oriented development paradigm, and this will remain true. In fact, as we become better at using object client/server tools, we will dig deeper into their support for the object-oriented development model.
ENABLING TECHNOLOGIES
We must consider the evolution of the enabling technologies of client/server. These technologies include distributed objects, TP monitors, the intranet, databases, and middleware.
Planning for the Future
Planning for the future is simply a matter of establishing the strategy and the tactics of our application development environment. From time to time you need to work with the powers-that-be to:
In most cases, this is a process of looking at new enabling technologies and paradigms that will better serve your needs. For example, if you need access to many applications for a single multi-platform user interface, then you may want to set a course for the intranet. Or, if you need to access a number of legacy resources as a single virtual system, then TP monitors and DCE are worth a look. Of course, you need to work out the tactics as well, including which enabling technology to employ, and then select the tools that support your enabling technology of choice.
Now What?
Now that you reached the end of the book, did you think I'd leave you without a way to get more information about what works with client/server technology? If you want to advance your career in the client/server marketplace, you should be constantly learning. Here are a few places that I go for information.
David S. Linthicum is a widely published author, speaker, and senior manager with AT&T Solutions Systems Integration Practice in Chantilly, Virginia. You can email David at Linthicum@worldnet.att.net..
David writes the Application Architect (formerly C/S Developer) column in DBMS, the Net Developer column in the Internet Systems supplement, and he frequently writes feature articles and reviews for DBMS. The Article Index by Author lists David's articles.