How important is IBM to your life as a Web developer? I wish this column could be an instant survey because real answers to this question are, unfortunately, hard to come by. (I looked.) Some of you work in companies where IBM is deeply involved with all aspects of computing and, of course, you probably have been using some IBM tools for the Web. The same would apply to companies using Lotus products, especially Notes. However, I suspect the majority of Web developers havenıt used any IBM Web products, and IBM may actually register like a UFO on the products and trends radar.
As a public confession, I must admit Iıve been working in and around Web applications for more than two years and have never given IBM more than a momentıs thought. I say "confession" because I feel guilty about it. IBM was, is, and probably will be the largest computer company in the world for some time to come. It has been active in all things Internet for a long time. It feels uncomfortable to say that I havenıt paid attention.
This is especially true because I go way back with IBM: all the way to the first IBM PC. I even heard what may have been the first utterance of the question "Is it IBM PC compatible?" The year was 1981 in a stock room of a retail computer store chain. We were viewing a demo of a new PC from Texas Instruments (TI). It was extremely well engineered and milked the last bit of capability from the Intel 8088 and 64K of RAM. They wanted us to buy several thousand units. The president of our company asked, "Is it IBM PC compatible?" The TI representatives were literally insulted. Not only hadnıt it occurred to them that being IBM compatible was desirable, but they considered it beneath their integrity as an engineering company.
We didnıt buy any TI computers, and TI didnıt last very long as a mainstream supplier to the PC industry. I learned that good technology isnıt everything, and sometimes it isnıt anything. IBM had set a standard that, while not the best possible, worked and was surprisingly open. That was more than enough.
Itıs been a while since IBM set standards, much less determined the course of the industry. Some would say that its failure to make the Microchannel Architecture (MCA) an open standard during the late ı80s contributed to IBMıs "near fatal" corporate convulsions by 1990. Thatıs a stretch, but the MCA bus design and how IBM handled it is a classic case of singing the siren song of openness while hiding the proprietary reefs. It might have worked, but the song was off-key, and low water exposed the rocks. I apologize for the metaphors, but IBM was just that clumsy and never convinced the industry to adopt the MCA.
There are some parallels and ironies in the current situation with Java. IBM and Sun (namely JavaSoft) are dancing around the standardization of the Java language in some odd ways that remind me of the MCA problems. Now Sun is the standard setter, and IBM is the settee. But Iıll speak more on this in a bit; there is some additional background that will help explain the situation.
If youıre building applications for the Internet, chances are very good that they are part of something involving electronic commerce. E-commerce is an omnibus term that is already overloaded, but I think we all understand that it means doing business on the Web. It also seems to be generally accepted that e-commerce will soon dominate Internet usage. Iıve heard estimates that e-commerce will create from $300 billion to $1 trillion in business by the year 2010. No matter what the number is, e-commerce is going to be big. Obviously, this kind of potential attracts attention. Most companies have joined the Internet bandwagon, but the two that have arguably done the most (especially for starting from behind) are Microsoft and IBM. Microsoftıs supposed about-face on the Internet is already the stuff of business school lore. From where I watched, it seemed less a turnaround than a change of force along a predetermined vector. Microsoft only needed to accelerate pieces of code that were already in development. IBM needed whole classes of products and a way to incorporate its vast hardware operation. If Microsoft turned around its battleship, IBM was, and is, dealing with a fleet.
Thatıs where e-commerce comes in. Big as it is, IBM probably needs as much verbiage to marshal its own forces as it does to present itself to clients. E-commerce provides a focusing concept that can be explained to the salesperson, technician, and line manager alike. In the past couple of years, under chairman Lou Gerstnerıs regime, IBM has committed billions of dollars and tens of thousands of employees to infusing the entire IBM inventory of products and services with e-commerce.
Excuse me, I mean e-business. Thatıs IBMıs term that, in a logo youıve probably seen in a thousand ads and commercials, includes the "e" inside the @ symbol. Because it couldnıt copyright e-commerce, IBM defines e-business as "any application on the Web that enhances productivity, facilitates access to business data, or expands business reach, such as electronic data interchange and communications among employees, customers, and suppliers." That about covers the whole tortilla. Within this lingo, e-commerce refers specifically to business transactions. The first time I saw the IBMıs e-business logo was in connection with the 1998 Winter Olympic Games. IBM spent a ton of money in Nagano (reportedly one of the causes of a bad quarter for the company). I also remember the debacle of the 1996 Summer Olympic Games in Atlanta, where IBM was trashed for messing up the results sent to the press. Nagano was a completely different experience, both on television and at the various Web sites. It was exactly what IBM hoped it would be: a splendid demonstration of its Internet technology and proof that when it comes to the enterprise, nobody can pull off big like IBM.
Watching the Nagano IBM commercials raised my consciousness. I realized that no other company offered hardware, software, and services for the Internet like IBM. It also indicated how far down the line IBM has gone in coercing its hydra-headed product lines to sing a consistent tune. Most of the time, I make a living belittling the likes of IBM. When I say, "raised my consciousness," I certainly donıt mean I ran out and replaced every computer I own with an IBM model. It means that for the first time in a long while, I was curious about what IBM was doing ı and thinking perhaps it mattered.
What I found when I surveyed IBMıs involvement with the Web, Java, and intranets went beyond the soup-to-nuts approach all the big computer companies have adopted. Sure, IBM and Lotus have Web servers, commerce servers, transaction monitors, application development systems, and so forth. But IBM as a hardware supplier has also worked extensively in making these various Web-oriented programs operate across its platforms. While this in itself was not surprising (IBMıs motherlode has always been legacy systems), I was surprised at how far IBM had already gone in implementing Java as the common language. I was also surprised by some of the initiatives IBM had taken on its own to enhance the effectiveness of the Java language, in particular with its San Francisco project.
To put the San Francisco project into perspective, letıs start with the idea that Java is constructed with classes. As an object-oriented (OO) programming language, Java uses the most basic classes to create subclasses that inherit methods and properties from the basic classes and then add new methods and properties. This construction leads to a class hierarchy that, in a fully developed OO language, provides the necessary tools to create complete programs. In Java there are the basic classes of the java.lang and the java.awt, which package the most necessary elements such as control structures and user interface controls.
However, the Java basic classes arenıt enough to create much more than modest programs. Full-scale applications need more sophisticated classes, preferably packaged in such a way as to avoid the need to program much (or anything) from scratch. Thatıs where foundation classes such as the Java Foundation Classes (JFC) or Microsoftıs Application Foundation Classes (AFC) are important. The term foundation is misleading because these are not the most basic classes, but they are often the most frequently used in building real applications.
Even at this so-called foundation level, building applications requires programming to connect many parts. When you add beans to the application, you still need a way to integrate all the components. Integration usually requires a considerable amount of ad hoc programming as well. When you get to the elements of an application that are truly domain specific (elements required by the type of application, such as business rules and screen forms), even more custom programming is necessary.
For anyone developing more than one application, it quickly becomes apparent that cobbling these pieces together for each application is a waste of time. After all, shouldnıt encapsulation and class inheritance make it possible to prepare all the elements needed for rapidly constructing most of an application? Yes, and itıs called an application framework.
Iıve always considered application frameworks the most convenient way to bundle code and documentation for all the major elements of an application, including data access, menus, user interface controls, help systems, and error trapping. Having built two moderately ambitious application frameworks myself (one in Visual FoxPro and the other in Java), I have something of a feel for the work involved. Let me put it this way: Youıre seldom paid enough for doing it. The trick is to make a framework generic enough to handle a relatively broad category of applications so you can reuse it many times while minimizing the amount of new (domain-specific) programming.
Reusable application frameworks are exactly what IBMıs San Francisco project is all about. Developers build applications by modifying and extending the default business objects and logic of the framework rather than starting an application from the raw requirements and application analysis. A specific example is the Purchase Order Management framework that contains code, logic, and default properties for managing sales orders, quotes, and supply contracts throughout their life cycles.
Perhaps a question has popped into your head about the name, "San Francisco project." What is this, a product or product line? Why "project"? Itıs a project because itıs a collaborative effort. The impetus for the application frameworks came from some of IBMıs software partners, primarily application builders in and around large corporations. They wanted to leverage object-oriented technology but were hindered by the high cost of developing components, the need to retrain programmers, and the potential risks of investing in a new technology.
A few years ago, IBM was beginning its commitment to Java and decided that Java components in some kind of application framework could provide what the software partners were demanding. IBM decided to provide all or part of three layers of reusable code: the Base or Foundation layer, the Common Business Objects layer, and the Core Business Processes layer.
The Base or Foundation layer provides the infrastructure and services needed for industrial-strength applications in a distributed, multiuser, multiplatform environment. In other words, the Base has all the routines necessary to manage objects, connect to data, monitor transactions, and handle errors common to Web applications.
The second layer, the Common Business Objects (CBO), defines frequently used objects and services among a number of application types, for example, access to customer data. This might be a specialized grid that displays a customer name, address, and phone number and is complete with search routine and selective sorting. The CBO provides consistency and integration among applications, and you can use it many ways.
The top layer, Core Business Processes, contains the business logic and objects used in specific domains (vertical applications). IBM sees this layer as providing forms, transaction structures, and other elements specific to an application domain (although these are still relatively generic). The list of the first available Core Business Processes should give you the idea of what this layer is about: Accounts Receivable and Accounts Payable Ledger framework, General Ledger framework, Sales Order Management framework, Purchase Order Management framework, Order Management framework, and Warehouse Management framework.
Each of these frameworks lets the programmer work in any of the three layers, picking and choosing components, services, or methods as needed by an application. In most cases, IBM expects you to customize the user interface, country and industry-specific requirements, details of business rules, and special features added for competitive reasons.
You can approach building an application from a San Francisco project framework three ways. The easiest is to use the objects and classes in the framework as is. You would define properties and draw upon what is called the factory object from the Base layer to manage access to the framework business objects. I doubt if this approach will be practical in all but the most undemanding of applications.
The other two approaches involve modifying classes in the framework. In one, you can add new domain classes from the Base objects, for example, adding a business object that uses data access. To make this kind of modification, the programmer must know a great deal about the Base layer and proceed very carefully in order not to interfere with other classes. The third approach is to extend the supplied domain classes or methods. Other than requiring a knowledge of the domain classesı methods and properties, this type of modification is probably the easiest and least fraught with peril.
From the frameworks Iıve tested (many are available at the IBM Web site, www.ibm.com/java/Sanfrancisco), most applications will involve a considerable amount of customization at the domain level, as well as configuration or incorporation of external services for the Base layer. This is particularly true if youıre developing a distributed application for the Internet.
Considering theyıre hardly more than a specification, Enterprise JavaBeans (EJB) have been accepted with a vengeance. (Vengeance is possibly the right word because so much of Java is guided by a punitive animus toward Microsoft, in this case about its COM technology.) There are lots of reasons for this, but the most important is that Enterprise JavaBeans (EJB) play well to the distributed nature of the Internet and to the needs of large corporations to build enterprise scale applications quickly and inexpensively. No surprise that IBM has embraced Enterprise JavaBeans. Plans have been made to incorporate EJB components throughout the IBM lineup of products, and, given the business orientation of the EJB specification, Iıd expect the beans to show up in the CBO layer of San Francisco project frameworks. In fact, I expect IBM to push Enterprise JavaBeans and enterprise applications much harder than JavaSoft ı and probably more successfully. This will be a major source of problems for JavaSoft, which has been given the mandate to make money with Java. I can also see this becoming a bone of contention in much the same way HP became disgruntled with Sun (JavaSoft) over the use of Java in embedded systems.
As I was writing this, a push message arrived via email. JavaSoft is going to reorganize, largely in response to complaints from the Java business partners (IBM being primus inter pares). No details were given, but apparently there will be a division between the area of JavaSoft responsible for shepherding the Java language as a standard and the area producing competitive Java applications. If so, and depending on the details, this could present an interesting example for other large, standard-setting software companies (nudge, nudge).
I donıt know if this means anything for IBM except a longer period of time to develop its Java independence. I believe that IBM, not Sun, is the barometer for the success of Java. IBM has wagered that Java will be the common language that binds and integrates its many pieces. This role is even more important than Cobol, which was the soul of IBM applications, but not the heart of its systems operation. Java has the potential to be both. Java must succeed because there is so much at stake for IBM (and by extension, Lotus). If Sun canıt do it, then IBM will pick up the reins. This news is good and bad. The good news is that Java has an ensured future. The bad news is that Java could, potentially, suffer the same fate as Unix ı infertility through fragmentation. In any case, Iıve made a resolution to keep my eye on IBM and its Web activity; e-business seems well on its way to replace e-commerce as the word for making money on the Web.
Nelson King is a professional software developer specializing in Internet database management applications. He has published eight books on database subjects for MIS:Press and frequently wears a journalistıs hat. You can email Nelson at nhking@winternet.com.
What did you think of this article? Send a letter to the editor.