Columns Banner

The Renaissance Programmer: Resolving Technology Tensions

By Bruce Whitenack, Object People

oftware development involves a constant effort to resolve the tensions of new and old technologies, combining the best attributes of each technology to produce a solution better then either one alone provides. When a new technology, such as visual programming, is adopted by a software development organization, it merges with the old technology (in this case - textual programming). Thus, a development environment such as VisualAge has two editors for defining programs, a Composition Editor for visual programming, and a Script Editor for programming in text. A visual programming tool is usually sufficient for straightforward applications. However, it often lacks all the parts and connections required for complex processing. In projects with complex requirements, developers must use both tools to build successful applications. They must learn how to fuse the two technologies: visual programming and textual programming. This is just one example of a number of "technology tensions" that must be resolved by "Renaissance" developers, those who are experts in multiple technologies. This column briefly enumerates these tensions, discusses VisualAge for Smalltalk Server as an example of a toolset that merges technologies, and defines how " Renaissance" development with programmers, teams and toolsets must be used to resolve these tensions to build large, complex systems.

In addition to visual versus textual programming, there are numerous other pairs of technology tensions that currently are being addressed in software development. These include:

Workstations versus mainframes
Objects versus transactions
Object models versus relational databases
OO Languages versus procedural languages
Reusable parts and frameworks versus create your own
Fat client versus thin client
Asynchronous versus synchronous communication
Centralized versus distributed architectures
Methodologies versus patterns
Data-centric versus behavior-centric design
Performance versus maintainability.

Each of these is a major topic in itself. In-depth discussions on the resolution of these technology tensions will be the subjects of future columns.

A new technology does not completely replace an old one. Visual Programming has not replaced textual programming. Objects have not replaced functions. Workstations have not replaced mainframes. Smalltalk has not replaced COBOL. Java will not replace Smalltalk. Instead, there is usually a joining of the old technology with the new one.

Systems are built by developers who can master the software tools of the diverse technologies and define and use design strategies to combine the technologies together. This breed of software developers has been called "Renaissance Programmers". They have mastered a diverse set of tools, languages and construction paradigms to build working systems. A team that pools their knowledge and skills to build systems is a "Renaissance Team". A software development environment that enables the building of a system combing a number of technologies could be termed a "Renaissance Toolset". The VisualAge family of software components has at its core the promise of being an excellent Renaissance Toolset.

Never has the ideal of a Renaissance programmer, team and toolset been made more clear to me then in the opportunity I currently have to develop and teach a course entitled VisualAge for Smalltalk Server: Transaction Managed Objects. This course covers the tools, languages and techniques required to build client-server, multi-tiered applications using this new VisualAge product. To appreciate the importance of Renaissance programming and toolsets, let us take a brief look at some if its features.

VisualAge for Smalltalk Server provides cross-platform development where Smalltalk applications to be run on a host mainframe are developed and first tested on the workstation. Figure 1 shows the general flow of cross-platform development. One of the most surprising things to notice, especially for a Smalltalk developer, is that there are multiple Smalltalk images in the workstation development environment. There is one development image and there can be multiple passive images. Each passive image is created for one type of target environment, either CICS, IMS or Batch (on either OS/2 or MVS). All the images on the workstation share a common repository where applications and classes are stored. Different images can contain different applications. Regardless of which image the developer is working on, when the current image is saved, all the images are saved.

With VisualAge for Smalltalk Server, development is done on the workstation. Look at figure 1 again to see the cross-platform development path. A passive image for a selected target environment (CICS, IMS or MVS Batch) is created and applications developed in the development image are loaded into a passive image. The Packager tool is then used to create a file called a packaged image from the classes loaded in the target's passive image. The packaged image can be small (typically 200K - 500K) and contains only those classes and methods required to run the program on the target environment (who says you can't have small images in Smalltalk?). To run on the host, a load module must be created from the packaged image file. This is accomplished when the packaged image is uploaded to a data set on the host and is converted to an executable load module via a batch job. In the CICS environment, this load module is registered and run as a transaction program.

Figure 1. Cross-Platform Development © The Object People, 1997

The target environments include CICS or IMS. These are both Transaction Processing (TP) Monitors that are used for handling transactions in mission-critical applications for businesses such as banking, airline reservations and insurance. Clients invoke remote transactions managed by the TP Monitors on the host server. Each transaction either succeeds or fails as a unit. The point of control is centralized in the TP Monitor so updates can be made at once to the database(s) and clients do not have to be trusted to make updates. This ensures tight security and the integrity of the databases.

In figure 2 we see that Smalltalk applications can be both on the client and on the host. The Smalltalk applications on the host are part of a transaction. Clients communicate with a Host Transaction Monitor and send requests to the host via communication software such as APPC, ECI and MQSeries. Transactions written in Smalltalk can communicate with transactions written in other languages, such as COBOL, PL/I or C. The transaction servers can access databases via SQL, DL/I or some other primitives. A TP Monitor like CICS knows only about transactions, transaction programs, queues and storage areas. It has no direct knowledge of object models or message sends.

Figure 2. Client-Server Transaction Processing © The Object People, 1997

Applications in these environments are run as part of a transaction task. Usually the programs are written in languages such as COBOL, C or PL/I. In VisualAge for Smalltalk Server, these programs can be written in Smalltalk, and can both call and be called, by programs written in traditional, procedural languages. In a Smalltalk application, the image is alive in memory only when the task in running. When the task completes, the image and all the objects that have been instantiated during the task, are gone.

With the current state of technology, using an object-oriented language like Smalltalk as a transaction programming language makes sense. It also highlights one of the technology tensions listed earlier: objects versus transactions. TP Monitors allow the scaling up of applications to handle multiple, concurrent users, on diverse platforms running transactions requiring high performance. Transactions ensure data integrity and robustness. Object models allow better communication between analysts and the development team for maintainability and productivity. They provide a rich set of reusable components and business objects that make it easier to use and integrate components The tension arises in how best to combine transactions and objects so as to derive the benefits of both technologies. This will be the subject of a future column.

VisualAge for Smalltalk Server solves a number of problems involving productive Smalltalk development for mainframe applications. These are listed in the first column of Table 1. Smalltalk was originally designed as a single-user, single image workstation development environment. It is a pure OO language used for modeling complex domains and contains facilities for windowing and graphical user interfaces. What traditional Smalltalk provides is listed in the second column of Table 1. For Smalltalk to be used in mission-critical business applications, it must retain its complex modeling capabilities as well as be used in applications involving thousands of users, sometimes triggering hundreds of transactions per second and involving millions of records on transaction-processing hosts. How VisualAge for Smalltalk Server addresses these problems is in the third column. The "technology tensions" that must still be addressed by developers using VisualAge for Smalltalk Server are in the last column.

Problem addressed by VisualAge for Smalltalk Server	Traditional Smalltalk on the Workstation	How VisualAge for Smalltalk Server addresses the problem	Technology Tensions that must be addressed by developers using VisualAge for Smalltalk Server
How can you get the development productivity of the Smalltalk environment in developing mainframe applications?	Provides mechanism for interfacing with Communications Manager, Presentation Manager, CICS, OS/2, DB2/2.	Provides cross- system development which uses all the software products on the workstation in development and testing and then can run the applications on the host using CICS, IMS, TSO, ISPF, VSAM, DB2, APPC, MQSeries, JCL.	Workstation tools versus Mainframe tools How do you handle the differences in environments? How do you acquire the expertise and knowledge to use the tools effectively?
How do you scale up your Smalltalk applications so they can be used simultaneously by many users?	Single user on a single workstation machine	Multiple users accessing objects on a server machine	Fat client versus thin client Data-centric versus responsibility-centric design
How do you create images that will run on host server platforms?	During development, uses a single image on a workstation. Images contain GUI Code	During development there are many images. Images can be packaged for different target environments (most of which contain no GUI code).	Managing images on both the mainframe and the workstation Designing applications that can run on both clients and servers
How do you model business objects in your applications but also provide a robust environment which ensures the integrity of the data and handles business processing needs?	The applications involve long-lived Object Models which model the business objects, events and processes.	The applications are industrial-strength transactions which usually run as short-lived Units of Work. The Smalltalk classes model business objects, events and processes. Huge amounts of data are processed and Smalltalk applications may also be part of batch jobs.	Objects versus Transactions Long-lived versus short-lived transactions Objects versus RDBMS Performance versus maintainability Workstation versus mainframe environments
How do you get the creative and productive skills of Smalltalk developers and apply it to the mainframe world. How do you get the discipline of the mainframe world in Smalltalk development?	Independent developers	Uses a Smalltalk environment which is very flexible and allows experimentation, but programmers are expected to be cooperative citizens. They must work closely with database and network managers and follow department rules.	Workstation versus Mainframe mentalities Methodologies versus patterns

Table 1. Problems Solved by VisualAge for Smalltalk Server and subsequent Technology Tensions to be addressed © The Object People, 1997

To build better systems by combining old and new technologies and to use a toolset like VisualAge for Smalltalk Server most effectively, members of a development team must have the qualities of a Renaissance programmer. What are these qualities?

A Renaissance programmer is a designer. In the case of using VisualAge for Smalltalk Server, he designs solutions that allow transactions to manage objects and objects to support transactions. This may entail the design of objects that support business units of work and those that model transactions on the host.

A Renaissance Programmer is a builder who is a tool expert. There is a saying in the construction business, "The tool is the trade". Master the tools, and you master the trade. This is applicable to the software "construction" business. A Renaissance Programmer knows the tools (both conceptual and software) and knows how to build software using those tools. You can see in the first row of table 1 that the tools and products required for cross-system development are extensive. In fact, they are too much for any one person. A team of tool experts is required. The better the development team's combined knowledge, the better the opportunities to devise successful strategies that incorporate the tools to build robust systems.

A Renaissance programmer is multi-lingual. Using MVS Smalltalk Server as an example, it helps if you also know SQL, JCL, the CICS EXEC Commands and DL/I for IMS programs. In addition, some knowledge of the language used in the legacy transactions you may call ( e.g. PL/I, COBOL or C) would be helpful.

A Renaissance programmer is a scholar. In the world of object-oriented software development, we are all learning. Indeed, some of us are probably studying harder, and reading and learning more now, than when we attended school.

The Renaissance programmer is a communicator. Either through papers, discussions, teaching, usenet groups, self-documenting code or in well-articulated documents and discussions of designs, he explains the ideas that he applied. In other words, he defines the patterns that support his approach.

All good developers are to some degree Renaissance programmers. All good teams are Renaissance teams. They have a well-equipped set of tools at their access, facility in several languages, strategies that merge multiple paradigms, the ability to apply design solutions to the problems inherent in the system and good communication skills. All good development environments include a Renaissance toolset. The career of a software developer is a journey and those of us involved in it must be capable of learning new tools and techniques, communicating problems and solutions, integrating different development paradigms and tools to apply to solutions. In short, we must seek to be Renaissance programmers on teams working with Renaissance toolsets. So let's get started and learn together.

Enjoy the article? Subscribe to Eye on Objects!

Bruce Whitenack is a Software Writer in Residence with The Object People, U.S. in Raleigh, North Carolina. He is the author of RAPPeL (Requirements Analysis Process Pattern Language) and co-author of Crossing Chasms as well as the course developer for VisualAge for Smalltalk Server: Transaction Managed Objects and TOPLink, a relational database to objects framework . He welcomes your comments..

Home Page