The IBM McGraw-Hill Series

IBM UK and McGraw-Hill Europe have worked together to publish this series of books about information technology and its use in business, industry and the public sector.

The series provides an up-to-date and authoritative insight into the wide range of products and services available, and offers strategic business advice. Some of the books have a technical bias, others are written from a broader business perspective. What they have in common is that their authors—some from IBM, some independent consultants—are experts in their field.

Apart from assisting where possible with the accuracy of the writing, IBM UK has not sought to inhibit the editorial freedom of the series, and therefore the views expressed in the books are those of the authors, and not necessarily those of IBM.

Where IBM has lent its expertise is in assisting McGraw-Hill to identify potential titles whose publication would help advance knowledge and increase awareness of computing topics. Hopefully these titles will also serve to widen the debate about the important technology issues of today and of the future—such as open systems, networking, and the use of technology to give companies a competitive edge in their market.

IBM UK is pleased to be associated with McGraw-Hill in this series.

Sir Anthony Cleaver

Chairman

IBM United Kingdom Limited

Preface (2004)

Business Objects is now out of print, and the publishers returned the copyright to me a time ago. I thought it might be interesting to make the book available (possibly only to niche IT historians!) in PDF format. It is presented here as submitted to the publisher in 1993, and before copy-editing. Hence there are some trivial differences in wording between this edition and the published 1994 edition.

While the book is in some respects dated, I believe much of it applies today—only the language and terminology has changed somewhat. The main change has been the term ‘component’. In 1993, component had not emerged to mean software artifacts such as COM, EJB, and CORBA Components—it was used indiscriminately for any piece of software or indeed hardware.

However, what I was indeed writing about—quite consciously—was software components, autonomously developed, pluggable (into a component container), and composable. Lacking a generally acceptable term, I coined my own—cooperative business object or CBO. Hence when you read ‘CBO’ or ‘object’, please think today’s ‘component’; and when you read ‘component’ please read it in its older meaning.

For those who may have read Business Component Factory by Peter Herzum and myself (Wiley 2000), the CBO concept maps exactly to a “Distributed Component”.

Preface (1993)

Complex problems have simple solutions, which are wrong.

Client/server systems promise major benefits for businesses, organizations and people. Promises include exceptional ease-of-use, application integration and taking IT off the critical path of business change. The question is, how do we realize these benefits?

This book describes an approach to developing application systems that can play a significant part in turning these promises into achievable goals. It is a book about realizing the dramatic advantages to be gained from the application of object orientation to client/server systems. It describes a new approach to structuring application software. By applying object orientation to the end product of the application development process (rather than to components used within. the process) we provide both ease of programming for distributed systems and a foundation for application integration and rapid development.

Based on experience with industrial-strength systems, this book describes how delivering business-sized objects instead of applications best meets the application design and coding problems otherwise found in distributed and client/server systems. Such business-sized objects are independently developed using either procedural or object-oriented programming languages. They cooperate with each other in providing business function, and hence we call them ‘cooperative business objects’, or CBOs. The term ‘CBO’ is used to distinguish between a business-sized object as an end product, and an object used by a developer as a component of an object-oriented application. Such an application is not itself an object. A CBO is.

Just as transaction programs rather than batch suites were the best ‘shape’ for the on-line systems of the 70s, so CBOs are the best shape for the systems of the 90s. Providing this new shape of deliverable is, perhaps, the real business of objects.

The book is also about ease of programming. CBOs make client/server systems with advanced object-based graphical user interfaces easy for the average application programmer; and, indeed, for the casual programmer. This ease of programming is achieved because of the new application structures introduced.

This book is written for IT managers, AD managers and technical professionals interested in implementing effective client/server systems. Although the concepts developed are widely applicable, the context for the book is medium-to-large IS systems, typically using at least one mainframe (or mini) computer, running core business systems. In particular, it is assumed that ‘client/server systems’ means systems where powerful desk-top PCs are connected to one or more larger systems which manage a company's shared computer-based resources (typically data).

This is not a book about application design methods; nor does it address in any detail the various aspects of connectivity (line protocols, connection APIs, etc). It is not a book about systems management, or the selection of hardware and operating system components; neither does it review existing client/server software, or OOPLs. It is a book which addresses these three questions:

● What does it mean to ‘exploit fully’ the client/server system structure—from the point of view of the users of such a system?

● What ‘shape’ of application-level code should we be aiming at, and what design approaches should we be adopting if we are to meet our ease-of-programming objectives?

● What additional system-level code (or “middleware”[1]) is required to enable application programmers easily to produce code which meets user requirements of these new systems?

Lack of good answers to these three questions has been a prime cause of the difficulties found over the past several years in exploiting fully the new system structures available to us.

This book describes the development of thinking, and the conclusions reached to date, in addressing all of these problems as a whole. From several directions, the concept of the CBO has evolved as a solution. This concept has been proved through the development of production-strength software. The detail of this software is not within the scope of this book; the concepts which that software implements are.

‘Business objects’ as a topic of interest in the industry is growing. Recently, the Object Management Group started a special interest group in business objects. Just as this book was completed, I received a draft of Rob Prins’ book, ‘You Can Bank on Objects’ (as yet unpublished).[2] This presented a particularly exciting application of the business object concept for very large-scale distributed systems (and for smaller-scale systems!). Rob works for IBM in the Netherlands, and is seconded as principal technical consultant to a wholly-owned IBM Netherlands subsidiary, Cyclade Consultants, in Utrecht.

History

At the end of 1986, I took on the technical support role for IBM's Systems Application Architecture (SAA) (announced on 17 March 1987) within IBM United Kingdom. Towards the end of the following year, IBM introduced the concept of ‘cooperative processing’ into SAA.

In essence, this concept pointed towards a vision of systems which blended the best of the PC with the best of the Mainframe. The PC brought user interface capabilities that far surpassed the non-programmable video display terminals typically attached to mainframes; the mainframe brought shared resource management capabilities (large shared databases, for example) that could not be matched on the PC.

Early in 1988, I and a small group of colleagues started to build a demonstration application which would illustrate the benefits of cooperative processing. Using a pre-release version of the IBM OS/2 operating system, we set to work. However, it soon became apparent that most of what we knew about structuring applications (learned through experience with batch, interactive and transaction processing applications) had to be thrown away.

We started saying to each other, “Hey, this is a new world...” And although some of what we had learned with early IBM distributed systems (e.g. the IBM 3790 and 8100 systems) remained applicable, to a large extent we found ourselves in an unexplored and uncharted land. Early in 1989, I wrote an internal IBM discussion paper entitled ‘The New World’. As a result of this and other related papers, the phrase ‘New World’ came to have some small currency among IBM people in the UK and in a few other countries.

One thing about this new world which is very apparent is that we cannot treat the PC merely as a kind of souped-up terminal. The PC is a complex and powerful computer system in its own right. What we have is not a simple hierarchical network with intelligence in the centre controlling a large number of simple devices; we have a peer-to-peer network of large numbers of powerful computers. For the last five years (among other things), I have worked towards understanding how best to exploit this new system structure, focusing on the following goals:

● Ease of application programming (for both the professional and the casual programmer)

● Full exploitation of the PC graphical user interface

● Cooperative application code (cross-system)

● Application integration

Today, we can say that we have had a considerable measure of success in achieving these goals. At the time of writing, achieving all of the goals is within sight. There is a great sense that although the new technology of CBOs is in its early form, it is fundamentally moving in the right direction.

This book is a summary of the concepts proved and lessons learned in addressing these goals through a series of industrial-strength software developments. Throughout, a central theme has been to build an understanding of the appropriate ‘shape’ of application software (CBOs), and to construct a software infrastructure that enables that shape. The infrastructure developed has been used successfully by a small number of UK companies in some major projects.

In August 1993, IBM and Softwright (a UK-based software house) launched a joint venture company called Integrated Object Systems Limited. In May 1994, Integrated Objects announced and shipped a product called Newi (New World Infrastructure). Newi is a CBO-enabling software infrastructure which implements, among other things, the concepts described in this book.

Acknowledgements

Writing this book has been largely a spare time effort. I could not have done it without the unfailing support of my wife, Heather, who gave me the encouragement I needed to develop some of the initial concepts, and pursue their development.

Concepts, however, are only proven through excellent software design and industrial-strength code. Here I owe a great debt to Martin Anderson, Chairman of Softwright Systems Limited (and now Managing Director of Integrated Objects), and Alan Boother, chief software designer at Softwright. Both Martin and Alan shared in the vision. Martin caused it to be realized; Alan, through his technical expertise, transformed it into reality.

Late in 1991, Charles Brett of Spectrum Reports encouraged me to put some of the concepts into writing. His support, and editorial assistance, helped me hone my ideas to a considerable extent. Several sections in this book include extracts from articles written for the February 1992, May 1992 and August 1992 editions of SAA and Open Software Spectrum, and for the November 1992 edition of Open Transaction Management Reports. These extracts are reproduced by kind permission of the Publisher.

In May 1992, IBM in Sweden announced a product called ‘Object-Oriented Infrastructure/2’. This was developed by Softwright under a contract for which I was the technical architect. This development helped immeasurably in moving the concepts of CBOs and the required CBO infrastructure forward. It could not have been done without the enthusiastic support and dedication of Johan Emilsson, Lars Magnusson and Thomas Jonsson, all of IBM Sweden.

I must also thank Martin Anderson (Integrated Objects), Rob Prins, David Hutton-Squire, Dave Schofield, Ray Warburton and Chris Winter (IBM), who read drafts of the book, and whose comments and were always relevant and helpful. In particular I would like to thank Hugh Varilly of IBM, whose detailed reading and checking of the final draft was especially beneficial—in both technical and non-technical areas. Section 1.4 derives largely from an internal IBM paper written by Ray Warburton, and sections 9.2 and 10.3 benefited greatly from discussions with Dave Schofield and from an internal IBM paper written by him. Any errors or omissions, however, I claim as my own.

Finally, I am grateful to the many professional colleagues in IBM, both in the UK and in other countries, who have provided encouragement, constructive comments and support. My thanks to them all.

Structure of the book

The Introduction gives an overview of the major arguments presented in the book.

Part One discusses how the user should perceive the system—how to get the best for the business out of these expensive GUIs. Exploiting the GUI leads to object-based user interfaces, and from there to the concept of cooperative business objects as the thing the programmer should build.

In Part Two we examine what the programmer should see in dealing with distributed systems. Here we define the general ‘shape’ of the application code that we'd like application programmers to write. We discover that cooperative business objects are the right shape for distributed application code as well as for object-based GUIs. Given this shape, we then discuss the kind of enabling ‘middleware’—or infrastructure—needed to implement it.

However, no matter how easy we make it to build application code, there is always the question of how you design application systems for the distributed processing and data inherent in client/server systems. Part Three presents some solutions to the design issues and concerns commonly met by, it seems, everyone who is starting out with client/server.

All of this has implications for IS management, and in Part Four we look briefly at two areas—technical implications and people implications. How to handle these, and how to make a start, are different questions of course, and in the last part of this section we discuss getting started.

In Part Five, we peer into the future a little, to outline some of the areas which initial experience suggests the new technology of CBOs may take us.

Finally, there are a number of appendices, which delve into greater technical detail about some of the areas covered in the body of the book. These are:

● A high-level introduction to object orientation (Appendix 1)

● A technical description of ‘cooperative business objects’ (Appendix 2)

● A short discussion on approaches to handling both synchronous and asynchronous messages (Appendix 3)

● A rationale for having a ‘Model’ object held locally in the PC as well as in the server (Appendix 4)

● A process I've found useful for rapid development of GUI prototypes (Appendix 5)

● Two sample project proposals for getting started (Appendix 6)

Introduction and Management Summary

This book is about a new development in application structuring. It describes a new kind of deliverable from the application development process—the ‘cooperative business object’ or CBO. (A brief introduction to object orientation in provided in Appendix 1.)

It seems that whenever we in information technology (IT) get comfortable with a technology, and consider it mastered in terms of operation, management, methods, software and hardware, then along comes a whole parcel of new things to be handled. The kind of new things that are most difficult are not those that are bigger, or smaller, or faster; it's those that are different. Distributed and client/server systems are different, and have proved difficult. CBOs, however, bring ease of programming to the new environment. A major theme that we develop in the book is that CBOs, rather than more traditional structures, best fit the application programming needs of the 90s.

But what is driving this change? Well, IT change is often driven by changes in business needs, and the move to client/server is no different.

New business needs

Perhaps the most significant of current business needs is the imperative many companies face to enable people to become more effective.

This need is expressed in many forms, and comes not only from competitive pressures (e.g. a need to provide much greater customer service), but also from cost pressures that force a reduction in organizational hierarchy depth. This can lead to a significant enhancement of people's jobs—to empowerment. But empowerment means people addressing more aspects of the business, or addressing the same aspects in greater depth, or both.

Being more effective also means being more flexible as businesses increase the rate at which they change. People need to handle new organizations, new products, new policies, new processes, new customers, new suppliers and new business environments. At the same time, there is a need to reduce training times for new staff.

All of this means that people need much better computer support. In particular, they need to be able to handle many more application areas than hitherto.

Very often, the business turns to their IT organization for the support people need to deliver the greater effectiveness being sought. One of the major IT responses to these demands is to find new ways for users to exploit the investment in data and function present in their computer systems.

Specifically, the search is for approaches that will provide great ease-of-use, reduced training times, application integration for the user, and the ability to react to new requirements fast—ideally faster than other areas of the organization, so that IT can become a facilitator of change. Client/server systems are seen by many to be part of the solution.

New challenges for application development

The whole point of building client/server systems is to combine the usability of graphical user interfaces (GUIs) with the traditional strengths of IT systems—access to and management of shared resources such as data. The promise of such systems is great, boasting exceptional ease of use, application integration and taking IT off the critical path of business change. However, if we are really to benefit from these new systems, we must not only understand how best to exploit the GUI, but also how to do so in a distributed systems environment. One without the other is not particularly useful.

In addition, we need to effect such exploitation using the skills of the average application programmer; and eventually we must harness the capabilities of those many end users who have programming aptitude and are willing and able to apply it. A vital requirement for this new environment is, therefore, ease of programming.

However, the acquisition of many more applications by itself is not enough. These new applications must integrate successfully with others. One of the main promises of the GUI is to allow users to have applications interact effectively with each other on the screen; but there's a problem. Even on a GUI, traditional applications do not deliver the desired levels of integration, no matter how many icons there might be. Object-based GUIs, together with new application programming constructs, offer a way ahead.

In the 1990s, then, we can see four major challenges facing application development:

● Enabling advanced object-based graphical user interfaces

● Building cooperatively processing application function across client/server and distributed systems

● Providing for application functions to be easily integrated with others

● Enabling ease-of-programming for all of the above.

Perhaps the most important thing to understand is that we are facing a radically new technology curve which demands new ways of thinking, and new approaches to design.

A new technology curve

In the 50s and 60s, most systems were batch. We can say that such systems formed a specific technology curve as shown in Figure I1.1. The seventies and eighties saw the evolution of a second technology curve, based on video display terminals such as the IBM 3270 family. This evolution generated a huge change in the way people used systems, in the way we built applications, and in the structure of systems.

Such change does not come easily. Initially, we tend to treat the new technology curve as if it's an extension to what we already know. In the early 70s, I remember working with an IT department who were installing their first video terminals. These were intended to replace a number of cardpunches. Data would be entered directly into the system through terminals, so saving a lot of money on punch cards. The existing batch applications would be unchanged.

The first application placed card images on the screen. Later, a purpose-built data entry system was introduced, which made the screen formats much friendlier; but the core business systems were still batch; there was no on-line access or update.

Figure I1.1. A new technology curve

Looking back, we can see that front-ending the existing batch systems with data-entry screens was not the best way to exploit the new technology (video terminals, teleprocessing and database). To a casual onlooker observing the screens, there would appear to be little difference between data entry and full on-line update with data integrity. However, the user, and the application developer, would certainly know the difference.

Only when on-line access and update via effective transaction processing systems was introduced did the technology start to be fully exploited. The idea of transaction processing introduced a new ‘shape’ of application code—the transaction program; and to enable programmers to build transaction programs easily, a new form of middleware was developed—the transaction processor. Until then, one might say that using the technology for data entry only was little more than just putting punch-card images on screens.

Such under-utilization of a new technology is typical of how a new computer technology curve is often approached. We apply tried and tested methods to the new technology, even though they may not fit. If we really want to exploit the technology fully, we have to understand the software structures best suited to it. Then we can build the middleware and tools required to make it easy. By definition, a new technology does not come equipped with these things.

Today, we are in the same position. Many of the tools being used to address the new client/server environment do little more than the equivalent of putting punch cards on the screen. Some products make GUI-based applications easy to develop; others make it easy to connect a PC to a Server. Few products today enable you to build advanced object-based user interfaces and connect application code across systems and address directly the challenge of application integration and do all of this easily, in the language of your choice. Yet these are the major areas we must conquer if the full promise of client/server technology is to be realized.[3]

Just as twenty years ago, the casual observer saw little difference between data entry and full on-line transaction processing, so today the casual observer often sees icons and windows on a Graphical User Interface as being the full extent of the new technology. However, seeing icons on a screen does not by itself mean that the client/server system behind it is being fully exploited.

So, we are currently at the beginning of the next evolutionary step—moving user interface and application function out from mainframe systems to the PC, and linking system components in cooperative client/server structures across LANs and WANs.

Driven by the business pressures for user flexibility and change, the full exploitation of these systems is taking us into new user interface capabilities, new approaches to application connectivity across distributed systems, new ways to structure application software (the cooperative business objects shown in Figure I1.1), and new software design techniques.

New user interface technology

By providing an increasing range of system resources (function and data) to users, IT delivers an increasing potential benefit. But this by itself is not enough. A user interface is needed which enables users to turn this potential benefit into delivered benefit.

The PC gives us a new level of user interface function—an incredibly high level compared to character-based terminals. Furthermore, this level of function is standard on most if not all PCs today. This point is worth emphasizing. Although it's true that this level of function has been around for some time (Starting perhaps with the Xerox Star in the late 70s), only recently has it become generally available as a base function on all PCs.

However, as users are required to handle an ever-widening range of applications, the very fact of handling more applications makes the additional applications increasingly difficult to use. From a system point of view, this can be seen as a bandwidth constraint—except that the bandwidth in question is a person's ability to handle an increasing number of things. Since we can't change the human brain, the only way to increase the effective bandwidth is to change the way in which computer systems are perceived by their users.

With the technology of character-based terminals, we presented the user with lists of functions that could be used, and constrained business processes to those defined not by the business, but by the application designer's idea of what the business required of a user.

With PC technology on the other hand, we can provide the impression that the computer handles ‘things’, such as invoices, insurance policies, bank accounts, notepads, etc.—thus matching the user's perception of the world outside IT systems. Instead of the computer appearing to the user as a separate and different universe, we can present computer systems as an extension of the user's world. Indeed, in this extension, we can improve on real life (for example, we can have an order form that will tell the user if a mistake has been made—or a shredder which can de-shred). We are talking here of a ‘thing-based’ user interface rather than a function-based one. It's what is called an ‘object-based’ user interface.

This approach can free the user from previous technology-based constraints, hide completely the underlying system complexities, and allow for much greater application integration—all of this while ensuring that the required business rules are enforced.

Object-based user interfaces are a new universe of user interface design. But when you exploit the new PC technology in this way, you find that you need an application software structure that is significantly different from the familiar menu/panel hierarchy structures we use to drive character-based terminals.

It turns out that the easiest way (by far!) to implement the new object-based user interface is to build and deliver CBOs (independent software objects) instead of ‘applications’. Each CBO maps to one of the objects that the user deals with on the screen.

However, new user interface technology by itself is not enough. It is the use of this technology in distributed client/server systems that really make the difference.

New application connectivity

Since corporate data is generally held on a mainframe or mini—a ‘server’—the PC application code must be able to cooperate with server application code in order to handle corporate shared data.

The PC handles the graphical user interface and user interaction, and since much of this is user-driven, we find that the best way to access shared resources (such as corporate shared data) is to build the PC as a client, making requests of separate servers. By ‘servers’ we mean application code which handles independent requests from clients anywhere.

This is a significant change from the more traditional approach; it means that mainframe applications stop driving the business (by driving the user) and become servers, which provide both controlled access to shared resources, and secure enforcement of the business rules.

But, more than just connecting a PC to a server, we are looking at a world where computers of all sizes, whether clients or servers, are being linked together in peer-to-peer networks.

However, connecting one piece of application code to another is not easy—especially when (as in the case of the PC and a server) asynchronous connection is required. The solution to this problem is to use event-loop and message-driven application structures, where some middleware handles the event loop, the messaging and the initiation of the application code.

This is the shape of CBOs, which were so useful for the user interface. So we find that the same new software structure is the right shape for client/server and peer-to-peer systems as well as for the user interface.

New software structures—CBOs

Most OO (object orientation) tools today enable a developer to use objects in the process of building some software deliverable that will be handed to a user to run. But that deliverable is not itself an object. The benefits of OO are seen by the developer at build time, but not by the user at run time. A cooperative business object (CBO) is a deliverable, which is handed to users to run, but which is itself an object. Thus it provides all of the benefits of object orientation to the runtime environment. Since a CBO is a deliverable, it is ‘language neutral’; that is, you can use any one of a number of languages to build it. You could use COBOL—or an OO language.

The cooperative business objects add a new answer to the question posed of application designers: ‘In implementing this business process, what is the thing that you're building—what is the end product?’ Previously, the answer was typically one of:

● A batch program (or suite of batch programs)

● A transaction program (or set of transaction programs)

● An interactive application (such as a PC application)

Now we add the answer ‘a CBO’. The discovery of this as a desired shape of software—as a desired end product of a development process—is a major new element in client/server systems, and we examine this new phenomenon in depth in this book.

With CBOs, we can see new horizons of potential software re-use—even a market in such software objects (we might read in a few years adverts such as ‘Buy XYZ's Invoice CBO—first in Pan-European VAT support...’).

New middleware

To run CBOs, a new form of middleware is required. Why? Well, here's an analogy:

At the end of the 60s and the beginning of the 70s, we found that to exploit fully the then new system potential of terminals connected to computers via telephone wires, several essential system infrastructure components were required:

● Teleprocessing software

● Teleprocessing hardware at the mainframe

● Database management software

However, even with this infrastructure in place, it was soon discovered that the ‘shape’ of the application software—transaction programs—required a further underlying piece of software infrastructure—a transaction processor—if programming was to be made easy.

Systems of the 90s comprise PCs with powerful GUI capabilities providing secure access to extensive, distributed and high-value corporate resources. These systems also need a new ‘shape’ of application software—the CBO, and a new layer of software ‘middleware’—a CBO-enabling layer—upon which to run.[4]

Know-how

New system and application structures raise many questions. For example, how do we manage the multiple update problem? Do we need to design and build this ‘middleware’ code to support this new client/server structure? How are business rules enforced on an object-based user interface? What design methods will deliver the new software structures required?

Although today the understanding of how to answer these and other related questions is not yet widespread, the answers do exist, and the know-how is available.

Clearly many new skills will be required. There is an old saw which says, ‘Hear and forget; see and remember; do and understand.’ In this area, as in others, experience shows that these new skills come only from doing—from actually building systems.

Does this all mean a revolution in application development? Do we have to re-train everyone in some ‘big bang’ conversion to the new technology curve? The answer to this is no. Techniques have been developed which provide an evolutionary path to the new system structures. The necessary know-how and skills can be developed by a small core of people, and then spread more widely in a controlled way. New client/server systems can be grown alongside more traditional systems in such a way that they co-exist.

Summary

Today we face a major challenge—understanding how to climb the new technology curve, building systems that exploit:

● Cooperative processing in a client/server environment

● Object-based graphical user interfaces on the PC

● Application integration

and that are:

● Easy for the average application programmer to build.

A major theme of this book is that the CBO is the right ‘shape’ of application-level code to meet these challenges. The CBO structure, together with its enabling middleware, provides us with a way forward into this new world.

1 Usability—the new system bottleneck

As people are required to handle an ever-widening range of applications, so systems are becoming increasingly difficult to use. From a system point of view, this can be seen as a bandwidth constraint—except that the constraint in question is an inherent human limitation. Since we can't change the physiology of the human brain, the only way to increase the effective bandwidth is to change the way in which computer systems are perceived by their users. This chapter discusses the nature of that change.

1.1 The usability challenge

Many companies have invested huge amounts over the past twenty years in data, systems infrastructure and systems management—managed and controlled on behalf of the business by the IT organization. As pressures on businesses to re-organize, re-structure, diversify, consolidate and slim down increase, they look to their IS functions to provide flexible and changing access to that investment.

Thus there is increasing pressure on IS departments to provide computing services which will exploit existing investments for both:

● A wider range of users and processes

● New processes in new business areas

Often the response by the IS department is to embark on large projects aimed at integrating applications, often in conjunction with a change to a more distributed (client/server) system structure.

Yet there is little point in spending huge sums on integrating applications, and data, if this investment fails to exploit systems because they prove too difficult to use. As someone said (in the context of on-line systems):

Computer systems themselves deliver no business benefit. All they deliver is potential benefit to the screen. It is users who realize that potential, and so deliver benefit to the organization.

This seems self-evident; but it does mean that the benefit that can be realized from computer systems is dependent to a large extent on the user interface.

But is there a problem? The answer is yes—because the demands on users—and on user interfaces—are changing and increasing. To explore this problem, and to identify the solution, we must firstly understand the business need that is behind those demands.

1.2 A vital business need

Among the several imperatives many companies face today is the need to make much better use of the inherent abilities of their people. This derives from various pressures, such as slimming down staffing and bureaucracies, re-structuring towards flatter organizations and winning competitive edge through significantly improved customer service.

Typical comments heard from executives across a variety of enterprises in recent years have one common thread—the need to obtain greater staff effectiveness—and such comments include:

● ‘We need whole job people…’

● ‘…move them out to the front office.’

● ‘Competitive edge through better service…’

● ‘If we could integrate our applications, our people could…’

● ‘People need to be (made) more effective…’

● ‘We need to cut the learning time…’

● ‘We must enable people to do more…’

Effectiveness does not mean only productivity. It means people addressing a wider range of activities than previously:

● Bank tellers moving from behind the counter to become customer service and sales people

● Insurance claims clerks handling agent's commissions and customer queries as well as processing claims

● Order entry clerks becoming account administrators, so enabling business transformation by providing full single-call customer service, with an eye to additional marketing opportunities as well

It also means providing for depth—extending jobs so that a person can do the next step in a process. For example, an insurance clerk may be enabled to handle some of the more complex queries, instead of having to pass them all along to their technical support.

IT implications

In IT terms, this demand for increased effectiveness also has a common thread: the need to enable people to access a much wider range of business processes than they did before.

Clearly one way to address this need is through the use of IT systems. Other options—such as increased training time or more staff—are today no longer viable.

If supported by appropriate systems, the normal human capabilities of most people should be adequate for this extended role. The 64,000-dollar question is, can we build these ‘appropriate systems’

Today, PCs and client/server systems can give the user multiple applications concurrently. This means that the technical constraints imposed by character-based terminals on dialogues (including limited or no dialogue concurrency) can be overcome. Will this provide an answer? Initial experience suggests that the longer-term answer is no. Why not?

1.3 The application problem

Consider an order processing system user. The column towards the left hand side of Figure 1.1 shows how the AD department might traditionally deliver this function. It would:

● Analyze the process (the leftmost of the three ‘clouds’ at the top of the figure).

● Identify that this process involved key corporate entities—such as the customer

● Design and build an application, to appear as one of several windows on the user's PC.

Figure 1.1. Application orientation.

Such an application encapsulates the function required to perform the process. Conventionally that's what is meant by the word ‘application’. Probably, within the application, the code accesses the common corporate customer database.

Suppose, however, that the users, in addition to taking and entering customer orders, are now required to handle:

● General customer enquiries

● Product returns from customers, and

● Journal entries for customer account adjustments

In principal, this is no problem—two additional applications which may even already exist are provided (see Figure 1.1). But consider the consequences.

We find that, although all three applications may use the common customer Database to access customer details, each application presents a list of customers (the same customers) in a different way. So what? Well, assume that in responding to a customer on the phone, the user needs to look at the customer's balance outstanding, and at the date of the last order. This data may well be in two different customer lists. The user therefore has to choose the correct two customer lists—by accessing the appropriate two applications—to get at the needed information.

The practical consequence is that the application developers have unwittingly given the user a new problem—by expecting him to be an expert in:

● Understanding situations where one list rather than another must be used

● Knowing which application provides the relevant list

● Knowing how to start (get into) that application

● Understanding how to navigate through the application in order to produce the required list

● Understanding, that in some situations two lists will be required concurrently on the screen, and knowing how to produce that effect

Indeed, where a specific ‘customer query’ application (yet another application!) has not been provided, the user may well have to create an Order, do a search for the customer, then delete the Order—merely to look at a list of customers (the result of the search)!

Exporting problems to users

Now the IS department did not plan to give the user a problem. It's just that the very design technology we've used so successfully over the past 30 years—choosing ‘applications’ as the vehicle for delivering business function—is now becoming a serious constraint—on IS's ability to deliver the level of integration and ease-of-use required, on users' ability to get the most out of the IT investment, and hence on the ability of the company to realize the return on investment expected.

In fact the problem may be worse than this. Many companies today are planning staff empowerment that envisages users accessing (not all at once!) up to thirty applications. Yet one such company already estimates that after around twelve applications there is a diminishing return, at an increasing rate, for every application added. The increasing user load makes each additional application effectively less usable than the last. This applies despite improved ease of use of any given application—including those with a GUI.

Thus we face a major problem: Although our technology now allows the user to access many applications concurrently, their very nature makes them difficult to use together. But use them together is precisely what the user expects when he sees them on the screen concurrently!

Furthermore, the problem exists even when a set of consistent ‘look and feel’ user interface standards are applied across applications.

This problem derives from the very nature of today's typical application, which is:

● A software encapsulation of a single business process.

● Essentially stand-alone with respect to other applications

Consider: the one thing that a typical application is seldom if ever designed to do is to talk as a matter of course with other applications.

Encapsulation on conventional process boundaries makes it infeasible for the user to use something from one application in another application (other than trivially through a cut-and-paste function)—even though he may be viewing them side by side, each with an attractive graphical user interface, on the same screen. Clearly, since our systems can deliver the required business function to the screen of a user's PC, then there must be something wrong with the way it's delivered at the screen.

So how do we overcome this? To answer this, we firstly consider briefly the nature of the general problem of usability.

1.4 Usability

The conventional way to address usability is through intensive training. But the time required is prohibitive. Already reducing training time is a key business need...

There is another way: Instead of trying to teach the user about how the computer system works, we can exploit knowledge already in the user's head.

But how do we do that? Let's start by considering how people deal with technology in general, and then apply it to computers.

In discussing how people use technology (such as a video player, a swing door, a cooker, or a computer), Donald Norman [Norman 1990] identifies three conceptual, or mental models that are important in the operation of such devices. These are:

● The user's model (the user's concept of how the device works)

● The designer's model (how the device actually works)

● The system image (what the user sees).

In practical terms, the system image is the user's only access to the designer's model of the system. Thus, for a person to formulate a good user's model, the designer must make his (the designer's) model obvious through the system image.

The difficulty is understanding how the user builds a conceptual model. Norman describes the psychology of the user's conceptual model as being built from everyday experience. The user will attempt to transfer existing knowledge to new systems:

● If the new system fails to match his conceptual model he will find it difficult to learn (leading potentially to frustration and rejection)

● If it does match, he will rapidly gain confidence in its relevance and applicability

The ‘usability iceberg’

Mapping this to computer user interfaces indicates that users' conceptual models are of crucial importance to computer usability. This is illustrated by the ‘iceberg’ concept,[5] which shows (see Figure 1.2), system usability as being dependent on three factors:

● First, usability is dependent on the presentation of the system to the user. This includes factors such as layout, color, and the aesthetic appearance of the system. However, these factors account for only 10% of the usability of the system. For example, in a car the layout of the instruments does not significantly affect driving the car.

● Second, we derive usability from the effectiveness of user interaction with the system—how he makes it do things. This includes editing techniques, scrolling, mouse use, pop-up panels, keyboard use, etc. Consistency of interaction is a very important factor in achieving usability; but the contribution of these factors is only 30% of the total.

● Third, the remaining 60% of the look and feel iceberg—the bit under the water—comes from how well the system maps to the user's view of the world. In other words, how easily can the user build a mental picture (a conceptual model) of the way the system works, so that he can accurately predict how the system will behave?

Figure 1.2. The usability iceberg (source: D.F. Liddle, Metaphor Computer Systems).

This last point suggests that IS should put onto the user the responsibility for building the correct conceptual model. However, a better way must surely be for IS to provide a system image which naturally maps to the user's model of his world.

What is the user's world?

But what is the user's world? Looking at a typical office, it is a world of things, of tools (used to perform tasks), such as:

● Forms

● Ledgers

● Files

● Notepads

● Manuals

● Phones

In fact, on looking round an office, you will never see an ‘application’. Of course, there are procedure manuals, and instructions on forms which represent the actions required, etc. But what you see are manuals, forms, etc; not the ‘procedures’ themselves.

Considered in this way, it becomes apparent that the notion of an ‘application’ is an artifice of the IS world. Until recently, the only way to deliver business function through IT systems was by building code around this artifice.

1.5 New user interfaces

To explore how these considerations can help us find a solution, let's return to our example of the order processing system user. His ‘extended job’ would be made much easier if the customer list could be presented:

● As a single thing (a list—of customers)

● As being usable in whatever business process it is required.

This would not only mean that experienced users could do their job more efficiently, but also that new users would benefit. A manual order entry clerk would be familiar with a ‘customer list’ to which he could refer whenever necessary. Thus the system would work in the way he would expect.

This, of course, is the prime consideration. Users will find a system much easier to use if, as we indicated above, it maps well to their own view of the world. Remember that 60 per cent of the usability of a system depends on how easily a user can build a conceptual model of how the system works; and he can do this most easily if IS provides a system which naturally maps to that user's world of everyday things.

With these concepts understood it should be possible to build a user interface which keys into the well-evolved world of the office or work place. What is needed is provision of a ‘thing-based’ rather than a ‘function-based’ user interface.

This is quite possible, but only via the local power of the PC. The PC can present on the screen sets of ‘things’ or ‘objects’—reference material, ledgers, forms, files, notepads, etc. Instead of the computer presenting to the user some list of functions that can be done, it should present the set of things the user needs to do his job.

For example, referring back to the multiple application problem, a user will probably find it difficult to build a mental model of the behavior of a ‘customer list’ when it:

● Appears in several different forms,

● With different underlying behavior, and

● Accessible in different ways

But if the customer list is presented as a single thing, usable wherever needed (following our previous discussion), then it should be much easier to use. (For data analysts, such commonality of data is not something new. But for application developers, and for end users, common presentation of such data entities across business processes—or ‘applications’—is new.)

With this approach, separate education for each application should not have to be given. ‘Thing-based’ (or ‘object-based’) user interfaces make use of knowledge which already exists in the user's head—knowledge about ‘how the world is’. Providing user interfaces that exploit this knowledge is the key.

Suppose we adopt such an approach—what would it look like to the user? To examine this question, the next chapter shows the train of design thinking, starting from a typical character-based terminal application, and ending with an ‘object-based’ user interface of the kind described.

2 Making computers familiar:
object-based user interfaces

Starting with an old-style menu-panel character-based terminal application, this chapter traces the development towards an object-based user interface. In particular, two underlying principles of object-based user interfaces are introduced:

● The user should be able to use a given object in all processes (‘applications’) where that object is required

● The user should be able to re-group objects in folders or containers (themselves other ‘container’ objects) to suit their way of working

It is in the implementation of these two principles that we will see the necessity for new software structures.

To illustrate the solution, and why the underlying technical implications are non-trivial, we use a sample application—order entry.

Firstly, we look at how this application might be done with character-based terminals, and then examine some of the ways we can exploit the PC technology. Then we assess this PC solution in the light of the key usability factors discussed in the last section. Finally we show how our example application develops beyond application boundaries into a true object-based user interface.

2.1 The character-based terminal approach

Figure 2.1 shows a sample initial panel of an order entry application, running on a non-programmable character-based terminal such as an IBM 3192 or 3278.

The implications of this technology are as follows (and we take this list from what we observe about real applications):

● The user selects what to do from a list (a ‘menu’) which has been defined by IS.

● The user can do only one thing at a time.

● The interface is typically ‘modal’—that is, once the user has chosen one function, then in order to go to another function he has first to complete the current function. A good example of this is where the user has to handle an enquiry in the middle of an entry transaction (such as entering a customer order). Before answering the enquiry, he first either has to cancel out of the order, or complete it. In other words, the user is bound by the ‘mode’ he's in (in our example, he's in ‘order entry mode’).

Figure 2.1. Character-based terminal—menu/panel user interface

● Two or more functions typically cannot be handled concurrently. For example, we are not able to allow the user to process both a customer enquiry and an order panel concurrently.[6]

In summary, we might say that the current character-based terminal interface is single-function modal. By ‘modal’ we mean that the dialogue with the user is placed in a certain mode, and while in that mode, the user cannot do other things.

However, the menu-panel hierarchy design approach for character-based terminals has two great advantages:

● The design technique maps well to the technology (where each box in the function hierarchy typically maps to a menu or panel)

● It enforces business rules by encapsulating them in one or more ‘transactions’, and so guides the user through the required business process

With PC technology, we can throw away the first of these; but we must retain enforcement of required business rules.

2.2 A PC-based approach

Here we see how we might start to exploit the PC technology.

Figure 2.2. PC—graphical user interface.

Figure 2.2 shows a PC (bottom left) with four application windows. (The PC screens illustrated in this document are stylized for presentation purposes—they do not accurately show all the detail.) The order entry window is shown enlarged (top left), and this shows a PC alternative to the initial menu panel on a character-based terminal. Instead of a list, the user sees four icons:

● The Customer List (bottom right)

● The Product Catalogue (bottom left—this company specializes in gear wheels and sprockets)

● A pad of Order Forms (top left)

● The Order History File (top right)

To enter an order, the user would ‘tear off’ a new order form by dragging one (with a mouse) from the Order Forms icon. The result might look like the window on the right of Figure 2.2, where the new order form is shown.

Note that the order history file is now hidden (under the order form). This is not a problem, as the user (not the application) controls the positioning of windows, and so can easily slide the Order Form to one side to reveal the Order History File icon if that's what's wanted. (The application can, if desired, take over control of window positioning; however, except in very special circumstances, experience has shown this to be user-hostile behavior for this style of user interface).

Figure 2.3. Application concurrency.

GUI principles

With this application, we can now go on to illustrate four important principles of a GUI. Without all of these principles, the user productivity potential is severely constrained.

Note also that while these principles are relatively easy to implement on a PC, they are difficult or impossible with the typical character-based terminal.

1. Multiplicity What if the user wanted to work on two orders concurrently? With a PC, this is very easy—you can have as many order forms up as you like. This ability to display multiple instances of the same class of thing we call multiplicity.

2. Concurrency How does the user fill in the order? Well, the customer list icon is clicked to bring up a list of customers (see Figure 2.3). The user would search through this list until the customer record is found.[7] Note that the user now has two things up on the screen. Showing several different things on the screen concurrently we call concurrency.

3. Amodality Further, the user should be able to switch between the two things at will. If he or she had to complete work with the customer list before continuing with completing the order, then that would be a ‘modal’ way of operating. In general, modal operation is undesirable, and a non-modal or amodal interface is almost always highly preferable.

4. Direct Manipulation To fill in the details on the Order Form, the user just clicks on the customer record, holds the mouse button down, moves the mouse over to the Order Form, and releases the button. The system then fills in customer number, name and address details. Note that this is more than cut and paste. The name for this type of operation is direct manipulation.

In this example we've seen how the user is ‘in control’—even in a structured clerical process like an order entry application. We've also seen how the four GUI principles greatly help with achieving the usability aims set out in the last chapter—of enabling the user to deal with ‘things’, just as in the real world, rather than with functions.

However, we are still dealing with an application—the order entry application in our example—and we have not yet dealt with the ‘application problem’ (discussed in Section 1.3). To recap, the application problem is the inability of a user to use effectively information from one application in another. This is fundamental, and we now go on to address it.

2.3 Presenting objects on the screen

Our problem really lies in our overall mind-set. For all we have done is to look at how the new technology could be used for a standard application such as Order Entry. What we have effectively done so far has been little more than transferring our unconscious knowledge of what an application is, to the new technology.

In the early days of the character-based terminal, some IS departments saw it as a kind of superior cardpunch, which would save money on cardboard (punch cards). They actually put card images on the screen. What we have done in our example is the 1990s equivalent of putting card images on a screen.

What we have not done has been really to ask, ‘How can we use this new technology to further our business objectives?’ We didn't ask this because we know that the answer has always been ‘through building applications…’, and we assumed unconsciously that this is still the right answer. And of course, in the sense that we still need to address business processes, it still is. However, in answering the question, we have also dragged along all our notions about what an application is. This is a fundamental design error.

2.3.1 A ‘workbench’

Now let's come back to our question (which was, ‘How can we use this new technology to further our business objectives?’), and at the same time look at an alternative to our traditional notions of application structure and presentation. We build on the concepts introduced in Section 1.5. (These concepts are reflected in such modern user interface guidelines as the IBM CUA-91 Manual (IBM 1991a,b).) Thus we present an interface where the user manipulates and uses every-day real things (or objects) directly on the screen. Let's develop this idea.

Figure 2.4 shows what one might call a ‘workbench’—a window containing the things or objects required by the user to do sales support tasks. Objects are shown by the small pictures—or ‘icons’. The user manipulates these with a pointing device. For example, an object can be looked at by ‘opening’ it (through a double click with mouse button 1).

Figure 2.4. Object-based user interface.

Again, an object such as Product X567 may be printed by dragging it to the printer icon and dropping it (mouse pointer over Product X567 icon, press and hold Button 2, drag pointer over to the Printer icon, release Button 2).

Some things remain the same as our previous design—we still see the pad of order forms, the customer list, etc. However, we've added some of the other things a user might use from day to day, such as an in and out tray, a bin, a notebook, etc. Two questions arise:

● Figure 2.4 shows only a fraction of the objects a real end user would normally deal with, and the screen still looks messy. We need a way to let the user tidy it up.

● Much more importantly, where have the business processes gone? For example, how does the user enter a customer order? Or query the status of a part? Or update a customer record? We need to ensure that such business processes are retained in our move to an object-based user interface.

Tidying the messy desk

Firstly, let's look at the problem of keeping things tidy. The major solution to this is to put things in ‘containers’. (The IBM CUA 91 Manuals describe this approach in detail, and identify it as a key user model concept. They also introduce other useful techniques for keeping things tidy.) In Figure 2.5 we see two container objects called ‘Store Room’ (the icon is meant to represent a cupboard), and ‘Stationery’. The user has tidied most of the objects into one of these two. Figure 2.5 shows how the user has double-clicked on the Store Room icon (bottom left), and has ‘opened’ it, resulting in a window showing the contents of the Store Room.

Figure 2.5. ‘Container’ objects.

The user has pulled out (by direct manipulation) several objects (Customer list, Product Catalogue, the Stationery container, and the Department Printer) from the Store-Room. Note that the ‘Stationery’ object is also a container object, and will contain the various pads of forms required.

The business process

The second question—how to tell the user about the clerical or administrative procedures the Company requires him to follow—is not as difficult as it might first appear. Two approaches to this are:

● First, we might make use of the ‘procedures’ manual that exists in most companies, even though it sometimes gathers dust in a forgotten cupboard. This manual defines clerical and administrative procedures. The idea is to put this manual on-line as another object on the screen. This is shown in Figure 2.6, which shows the workbench as it might look halfway through the day, while the user in the midst of taking a customer order.[8]

The procedures manual is open at the ‘Take Order’ page (top right in Figure 2.6). The individual ‘Take Order’ procedure is itself an object, and the procedures manual

Figure 2.6. Retaining the business process.

(not shown in Figure 2.6) is a ‘container’ object containing many different administrative or clerical procedures.

As the user completes the order, appropriate boxes in the procedure are automatically checked off by the system. If a job is incomplete (say at end of day) then it can be filed away to be opened and worked on the next day.

Notice also that in the example shown in Figure 2.6, there were initially four steps in the procedure. In the course of filling the order, an exception condition was triggered (above credit limit). The system can automatically insert an additional step into the procedure (in this case, ‘Contact Manager’). Indeed, a major application of expert systems to business processes will probably be in the area of guiding people through complex administrative and clerical procedures.

● Secondly, we could use the Help function, along with an ‘intelligent’ form. The user would first look up Order Entry (for example) in Help. This would tell him to open an Order Form (and guide him on how to do it). The Order Form in turn would have behind it the business logic to guide the user through the Form, warn of errors and insist on business-determined sequences and completion criteria.

In general, the second approach is to be preferred. Although on first sight the first approach might look better, experience has shown that for single-form processes, the user can easily see the state of the process merely by looking at the form. Showing a ‘procedures’ page merely uses up the screen unnecessarily.

Where a process uses more than one form, or where it goes past more than one user (or both), then we can encapsulate that process in a ‘folder’. This folder will hold all the objects (things) required for the various users to do their part of the process. An essential attribute of this folder would be a list of the steps to be taken. This list would be ‘intelligent’, and would behave rather like the ‘Procedures Object’ in the example above. It might be implemented as a separate object within the folder, or as data ‘belonging’ to the folder.

‘Tool’ Objects

This approach can provide an extremely effective environment for ‘tools’ which, although individually trivial, can add substantially to user effectiveness. Figure 2.6 shows two such tools:

● A notebook (bottom left, next to the out tray). The idea here is that the user can make free-form notes on anything relevant (such as the information that a customer buys a product from another company) and then mail that note through the electronic mail system simply by picking up the note with the mouse and dropping it on the out-tray.

● A ‘customer contacts’ tool (shown by a little organization chart). The user can keep here specific contact details by customer. For example, he might record that for Company X, his normal contact is Joe, Joe's manager is Mary, and Fred stands in for Joe when Joe is away. If our user belongs to a company that sends Christmas presents to customers, then Joe and Mary's gift preferences might be kept. Then, when our user takes a vacation, this object can be mailed to his stand-in, so that small personal contact details are not lost.

Other Objects

Finally, at the top left are two windows that the user might have been using before starting the order entry procedure. The first is some simple analysis (prompted by another administrative procedure) of a customer's order history; the second shows a high-level index to the customer file, illustrating one possible approach to handling large amounts of data at the user interface.

Advantages

This sort of approach—the building of what we might call a ‘sales support environment’ for clerical staff—is clearly achievable with PC and cooperative processing technology. It is not particularly obvious that we could do it with character-based terminal technology.

So, it appears that the advantages, and design implications, with PC technology are:

● The user has a choice of several things he can do.

● Once the user has chosen to do one thing, then he can at any time switch to another—as easily as taking out a new file from his desk drawer and laying it on top of the old one—in fact, probably even more easily than that. Things that are suspended are not in a different state than when they're active; it’s just that mouse and keyboard input do not go to the ‘suspended’ things, they go to the ‘active’ thing.

● The user can have multiple objects concurrently on the screen, such as an administrative procedure, an order form, a customer list, a mailbox or out tray, etc. Users quickly adjust to their own comfort level of concurrency and multiplicity. Indeed, this is a major advantage of the PC technology: if properly exploited it can (as it were) automatically adjust to an individual’s needs.

● We do not really have ‘applications’; rather a business process is built from a set of ‘application objects’, where a single given object may be used by more than one business process. For example, a ‘customer object’ could be used in the following processes:.

▪ Customer Enquiry

▪ Order Entry

▪ Billing

▪ Customer Locate

▪ Customer Record Maintenance

Now compare Figure 2.6 with where we started—Figure 2.2. To the extent that business benefit is delivered at the glass (at the user interface), it is arguable that the sort of capability illustrated through Figure 2.6 can potentially deliver a far greater and more effective range of business function and hence benefit than that shown by Figure 2.2.

2.3.2 Summary

To summarize, we can say that—in addition to graphics and image—a PC can exploit the following functions which are typically not available on character-based terminals:

● Multiplicity

● Concurrency

● Amodality

● Direct manipulation

● Presentation of objects

● Presentation of container objects (which hold other objects)

These functions allow us to build a workbench within which application objects reside. With such capability, we can design imaginative and innovative application solutions that can contribute substantially to the effectiveness of the enterprise, and hence to the business case for high-function PCs.

However, the design we have built up so far has one important flaw. We have presented everything in a single window. This approach, when implemented, allows one all too easily to slip back into the old application-oriented way of thinking. If this happens, then we can be in danger of throwing away much of what we've built.

2.4 The ‘workbench problem’

The approach required in designing an object-based user interface is to ask not what function does the user need, but rather, ‘What are the things the user needs to perform the required tasks?’ Given this, the trap one can fall into is to deliver this set of objects wrapped up in an application—which appears to the user as a ‘workbench’.

What can happen is that different development groups, each addressing a different business process, each builds their own ‘workbench’. The problem arises when the designer's model of this workbench is that of an application that contains all the things required for the given set of business processes.

This is the flip-side—the developer's side—of the ‘application problem’, and in this section we further explore the problem.

As a vehicle for discussion, we'll look at what actually happened in one company that took this approach (although the details have been changed to fit our example—and to protect the innocent!).

The company decided that new developments would have an object-based user interface on PCs (and that data would be held on a mainframe). Shortly after this decision was made, the AD department was asked to implement two different business processes—order entry and contracting. Thus they initiated two projects, each with their own development team.

The first project started work on an ‘order processing workbench’ for a set of people in the marketing division. The project team’s initial analysis suggested that this type of end user needed seven objects:

● Customer list

● Customer

● Order history file

● Pad of order forms

● Order form

● Parts catalogue (a list of products)

● Part (a product object)

Figure 2.7 shows the Order Processing workbench as the top left window, with an Order Form opened to the right (the icon for this is not shown).

A few weeks later, the second project began development of a ‘contracting workbench’ (all the things needed to handle contracts with customers) for people in both the manufacturing and marketing divisions. Analysis suggested that users needed seven objects with which to handle this business area:

● Customer list

● Customer

Figure 2.7. The workbench problem.

● Product list (a catalogue of parts)

● Product (a part object—not shown in Figure 2.7)

● Contracts folder

● Pad of contract forms

● Contract

This workbench is shown at the bottom of Figure 2.7.

As it happened, many of the users in Marketing needed to handle both customer orders and contracts. When (luckily at a prototype stage) these two workbenches were put together on a single user's PC, it immediately became apparent that the system—as a whole—would be very difficult to use, because:

● There were two customer lists (each with the same name—suggesting they were the same, but each with a different icon—suggesting they were different).

● There were two different ‘customer’ objects, each containing much the same information. But worse than that, the users found that they could use the customer object from the Order Processing workbench only with the Order Form, not with the Contract Form. In addition, the Contracting customer object could only be used with the Contract Form object. These limitations are shown by the ‘X’s in Figure 2.7.

● There were two different product lists—one of them being called a ‘parts catalogue’. At least both the names and icons were different. The only problem was that they both contained the same information.

● There were two different ‘product’ objects, with the same difficulties as the product/parts lists.

Instead of an easy-to-use natural real-world user interface, the user found confusion and inconsistency. In fact, by presenting objects within application boundaries, the AD department had inadvertently given the user the worst of both worlds:

● An interface which suggested the user was using things rather than functions, without showing the user the boundaries of where those things could be used

● Application boundaries which relied on the user recognizing ‘modes’ of use—without giving the user any indication at all about where those boundaries were, or how to switch into one of the modes

In essence, the AD department was producing what I call ‘iconic applications’. In the two workbenches, there are 14 objects (12 shown in Figure 2.7, two not shown)— which, by all the conventions of object-based user interfaces, states quite categorically to the user that there are 14 objects (things) needed for order processing and contracting. However, the user knows quite well that only ten are needed (customer, customer list, product, product list, order history file, pad of order forms, order form, pad of contract forms, contract form, contracts folder).

To summarize; the essence of the workbench problem is this:

● In building code, we duplicate items across our applications. Over the past twenty years, we have learned not to do this when it comes to data; we try to design databases so that data is not duplicated. Yet we still duplicate the application function that accesses that data.

If we adopt object-oriented programming techniques, we may avoid actually re-writing the various duplicated items. But that is typically at the source code level, and when the applications are delivered, we still have the situation where the executable code consists of much duplicated function—which leads to a greater maintenance load.

● Great difficulty in ‘integrating’ applications. This does not mean running them concurrently; on today’s PCs that is trivial. What it means is enabling both the developers and the users to re-use parts of one application in another business process.

● If each application presents an object-based user interface, then the user may see several of the same object—each of which behaves differently, and none of which can be used outside their own ‘application’ environment. Experience has shown this to have very poor usability.

A good principle for object-based user interface design is the principle of ‘least astonishment’, which goes something like this, and where ‘correct’ means correct in human factors terms:

For any given user action, the result which least astonishes the user is most likely to be the correct result.

In our example, four business objects were represented to the user as eight objects. Each of these looked different, behaved differently, and interacted with other things in different ways than their duplicates. That astonished the users.

The result was an unusable interface. The company in question had to go back and do a fundamental re-think, and re-design.

The lesson here is simple: an iconic user interface which does not present objects as the user understands them is not an object-based user interface.

Thus in spite of consciously setting out to do so, the AD department failed to provide an object-based user interface for the users; what they provided was an application-oriented interface which used icons to represent application objects. Instead of an object-based interface, AD actually produced two iconic applications. If the objective is to produce an object-oriented user interface, then building iconic applications is a fundamental error. The objects on an object-based user interface are user objects, not application objects.

Let's now complete the picture of the solution to the business need by deriving some important lessons from the ‘workbench’ problem.

2.5 The object-based user interface

Given that there is a consistent standard for presentation and interaction (the ‘usability iceberg’ above the water), then two principles of an object-based user interface from ‘below the line’ are of crucial importance—both for usability and for implementation). These two principles are:

● Object re-use: Any given object must be re-usable across business processes where appropriate

● User-defined grouping: A user can put any object in any container he chooses (subject to business rules). A container is an object.

Object re-use

The principle here is that a single given object can be used across multiple business processes. Figure 2.8 shows a simple example of this, where the customer object is used in both order processing (the user can ‘drop’ it on to the order form to enter the customer details), and also in the contracting process (where the user can similarly use the same customer object to complete a contract form).

Again, this same customer object can, of course, be used for customer enquiries, and to update the customer record. To look at (and perhaps update) the customer details, the user merely has to get a ‘view’ of the object. (The CUA practice for this is to do a double-click on the Customer icon with button 1 of the mouse.)

Figure 2.8. Object re-use by the user.

User-defined object ‘grouping’.

The second principle is that a user can ‘group’ or locate objects to suit their own needs. Suppose, as shown in Figure 2.9, that AD delivered to the user an ‘order processing’ object (a container or ‘work area’ containing the things needed to process customer orders).

Figure 2.9. Business object independence.

What the ‘user grouping’ principle means is that the user can, if he wishes (and assuming the business rules allow it), re-group the contained objects in other container objects. Figure 2.9 shows an example of this, where the user:

● Creates two new containers—‘Customer A123’ (perhaps because there is some significant piece of work to be done with this customer); and ‘My Daily Work’ (to hold the things needed for the user's normal daily tasks);

● Moves objects from the ‘Order Processing’ container to the two newly-created containers.

● Then deletes the original ‘Order Processing’ container, since he does not intend to use it. Deleting this container does not necessarily mean removing it from the system—it generally means removing it from the user's PC only.)

● Finally gets the ‘Customer A123’ object out of the Customer List object—which is also a container—and moves it to the ‘Customer A123 Work’ container.

The re-grouping would be permanent as far as that particular user is concerned—positions of objects on the screen are normally only changed by the user, and are maintained by the system over power-off.

Now let's consider these two principles from the point of view of the developer. The key question here is: if this behavior is available to the user, then what was it that development developed? If ‘applications’ were developed, then how did the user re-group them? What sort of application is it when the user can interactively—and extremely easily—tear it into pieces and re-assemble the pieces to suit him or her self?

We answer this question in the next chapter, in which we find that implementing this behavior has enormous implications on the software structures required.

2.6 Summary [9]

We have argued that, in a cooperative processing system, the best approach to exploiting the investment in system resources is by providing the users with an object-based user interface. But in doing that, there are several major implementation issues, including:

● Enabling the object-based user interface

● Design of a cooperative processing infrastructure which will make it easy for application programmers to write cooperative business systems

● Ensuring a cohesive system-wide design which embraces a potentially large number of heterogeneous `server' systems as well as large numbers of PCs

● Handling resource sharing and resource distribution

We now go on to look at the implementation of an object-based user interface, leaving the other issues for later chapters.

3 Cooperative business objects

In the previous chapters, we have seen how an object-based user interface can let people use IT resources without stumbling across artificial ‘application’ barriers. Building this style of user interface, however, is typically not easy. In particular, implementing the two important principles of object-based GUIs—object re-use and object re-grouping—has proven elusive when attacked with commonly-available programming tools.

This problem we call the ‘integration problem’, as it revolves around how to build independent and (possibly) separately-developed units of software which map to the objects on the user interface in such a way that integrating them—at run-time—is easy-to-program. It is the flip side of the workbench problem (see Section 2.4, which was how to avoid building ‘workbenches’ which are really applications, with application boundaries. From now on, we refer to this problem under the single name, ‘integration problem’.

The problem can be overcome by adopting a new kind of software structure that has proved to have great ease-of-programming attributes for object-based GUIs. We call this new structure a ‘cooperative business object’ (CBO) – because:

● What we deliver as the end product of the development process is an object. in the true object orientation sense of the word

● The size of the object maps to ‘business’ things (such as a customer, an invoice, a claims form, etc.)—so it's a business object

● It cooperates with other business objects to perform some desired task—hence it's a cooperative business object—or ‘CBO’.

This chapter introduces the concept of CBOs as applied to the GUI. Later on, we will see how the same structure also brings ease of programming to cross-system communication.

3.1 The ‘integration’ problem

The traditional approach to structuring business function for delivery through computer systems is to build ‘applications’. Figure 3.1 shows how each overall business process (the ‘clouds’ at the top of the figure) is encapsulated into a software structure called an ‘application’. On the left of the figure, we show two old character-based terminal applications being front-ended on the PC to form a single GUI application. (While this approach can bring major benefits in specific circumstances, it is not generally seen as a viable long-term structure for the majority of mission-critical systems.) We also show several departmental processes which people build and run for themselves in order to help them fulfill their corporate mission. Our traditional application approach does little or nothing for these.

Figure 3.1. Application orientation.

Now, the problem with application-oriented software structures is that they cannot avoid the integration problem. Although they may enable us to deliver iconic applications, they cannot deliver object-based user interfaces. Let's look at two ways that have been tried in the past to address the problem using application-oriented software structures:

● Build one large application, within which the various components can communicate. All objects appearing on the user interface will be controlled by this one application

● Build a number of small applications where each application can talk to each other application.

The problem with the first approach is that it takes us right back to building large monolithic lumps of code which become a nightmare to maintain—especially if different parts are produced by different development teams. While acceptable for trivial developments, this approach just does not scale up.

The second approach runs straight into the ease-of-programming problem. It is certainly the case that expert programmers, using languages such as C or C++, can write system-level code to access the various low-level system mechanisms for inter-application connection (such low-level mechanisms include, for example, DDE, OLE, Pipes, and Shared Memory, etc.). However, it is not obvious how the average application programmer using (say) COBOL—or the ‘ambitious end user’ using (say) Visual Basic or REXX—can do so. Even the expert programmers must first agree the mechanism, then the data formats to be used, not to mention agreeing on the general architecture of their necessarily single solution.

As Figure 3.2 shows, the developer of an application can use either procedural languages or object-oriented languages to build the thing that is delivered. That is not the point. The point is that what is delivered is an application; and the heart of the integration problem is how to make those applications interact—as interact they must do. This problem is shown in Figure 3.3.

Not only must they interact with each other, they must also interact with the GUI, and with other applications across the network. They must also interact with new applications introduced if application integration is to be achieved (more on this later). The question marks in Figure 3.3 indicate that, in creating an application that will interact effectively with other applications (both local an remote), the average programmer—or someone in his organization—has to contend with much more than just the application code. He or she has a major integration problem at the system level. In general, one or more (sometimes all) of the following problems need to be resolved:

1. GUI APIs The need to understand and code the system-level APIs needed for modern GUIs. Examples are OS/2 Presentation Manager, Windows, X-Windows. All of these require a high skill level on the part of the programmer. It can take up to six months for a good C programmer to become proficient. This explains the popularity of GUI tools, which allow one to ‘paint’ the window, and which hide the underlying complexities.

2. Multi-Tasking While not required for stand-alone applications, multi-tasking (that is, multi-threading) is often required when the PC communicates with other systems. Otherwise the window(s) can ‘freeze’ while interaction with a remote system is going on. This is sometimes called the ‘hourglass problem’ (due to the appearance on the screen of an hourglass symbol, telling the user he has to wait). Handling this assumes, of course, that the programming language supports multi-tasking, which some high-level languages do not do. But there is more to multi-tasking than just starting the task. The programmer also has to handle task synchronization, inter-task communication, ending the task tidily, memory allocation for cross-task data, etc.

Figure 3.2. ‘Application’ isolation.

Figure 3.3. The ‘integration’ problem.

3. Communications APIs In connecting to another system, the application programmer often has to deal with system-level API calls to the communication subsystem. The programmer's real problem here is not the complexity of the APIs, but understanding what's going on.

4. Application Structuring The application programmer has to determine how the application should be structured so that it copes with all the various external influences on the program.

5. Asynchronous Processing If multiple threads are used to handle long-running events, the programmer has to understand how to handle asynchronous events within his or her own code.

6. System APIs If one program has to talk with another, there are mechanisms provided by the operating system that he can use. However, the system APIs to these are often extremely complex. In addition, someone has to ensure that the writers of the other programs use the same mechanism.

7. Cross-Language If a program talks to another program, then not only does some inter-application communication mechanism have to be built from generally low-level system functions, but if the languages used to write the applications are different, then some form of software ‘Esperanto’ must be built, since many languages do not talk easily to others. One form of cross-language and cross-program communication is an intermediate file. This will often not perform nearly well enough—aside from the problem of managing the file, synchronizing writes with reads, etc.

8. Other This includes things like how code is initiated, and how data is understood when exported from one program to another.

Although various software tools address some number of these, there are very few (if any) which address them all. This makes any effective solution to the ‘workbench problem’ (discussed in the previous chapter) very difficult for the average programmer building applications.

3.2 Objects and Messages

It appears, then, that applications, whether large or small, will not provide us with the interaction we need without involving the programmer in layers of complexity. So we need to look at the question from another angle.

Now, real life is a continuous spectrum of complexity. In capturing some aspect of that complexity in software, the designer must focus on one aspect rather than another. He must ‘encapsulate’ software based on that aspect. Such encapsulation is essential in any software design process. ‘Applications’ are the result of designers choosing a business process or procedure—some set of closely-related functions—as the focal point.

Intuitively, since the objects on the user interface must be independent, then it seems reasonable to base our encapsulation strategy on those objects. Experience has shown that this is an excellent design strategy. Thus instead of focusing on processes and functions, we should focus on the things needed by the user. This means encapsulating on the basis of things rather than functions.

And this brings us to object orientation. (A brief introduction to object orientation is provided in Appendix 1.) A fundamental principle of OO is encapsulation on the basis of data—or ‘things’. Consider a ‘customer’. A customer has data (or attributes)—a number, a name, an address, a balance, etc. A customer also has behavior associated with it. It can be deleted, changed, created; it can be printed or displayed. It can be queried (e.g. ‘What's your balance?’).

OO encapsulates customer by wrapping into one software unit firstly a definition of the data for any given instance of the class ‘customer’, and secondly the functions required to give the customer some behavior. These functions operate on the data (the attributes of customer).

Now, object-oriented programming languages apply object orientation to the components being used in the build process. They seldom (if ever) focus directly on the thing being built—and which will be delivered to the end user.

We, on the other hand, need to deliver objects as independent executables. Thus we must apply OO to the unit of delivery. We call such a deliverable a ‘cooperative business object’—a CBO. (To be absolutely precise, I mean, of course, deliver classes not objects.[10] See Appendix 1 for an explanation of the difference.) Whether we use procedural or OO languages to build a CBO is beside the point, as ether can be used, as illustrated in Figure 3.4.

Now these objects need to talk to one another. For this, they use messages. Since the objects are produced as independent executables, the messaging mechanisms must be external to the objects, and this in turn points to the need for some form of run-time layer of middleware infrastructure software. This message externalization is a major difference between these objects and the sort found in OOPLs.

Of course, the infrastructure is the 64,000 dollar question. But if there were such an infrastructure, then the difficulties referred to above could be handled by that infrastructure. The result would be as shown in Figure 3.5, where CBOs as deliverables can communicate happily with each other at run-time. Figure 3.5 shows a collection of CBOs, some written using an OOPL, others using procedural languages, and where one of the CBOs is remote. The figure indicates that the developer does not have to worry about system level complexities. Multi-tasking (multi-threading), communications APIs, GUI APIs, cross-language considerations, etc., are all handled for him by the same middleware layer that handles messages.

This same middleware also converts all external events into the same messaging API, as well as providing all of the system-level GUI function required. But what does CBO application code look like? Figure 3.6 shows (at a high level of abstraction) what a CBO programmer might write.[11]

Figure 3.4. CBO cooperation.

Figure 3.5. CBO integration.

First, a CBO is event-driven. It is invoked by the infrastructure when a message needs to be handled by it. Secondly, the CBO handles the message (shown by testing for the message within a ‘case’ statement). If the message is not handled, then it is passed to the CBO's superclass.[12] Note that a CBO may send a message to another CBO in order to complete the handling of the incoming message. The CBOs can each be written in different languages.

A CBO is not a kind of mini application, running in its own address space. While that may on occasion be required, in general, several CBOs should be able to run in the same

address space—perhaps in the same thread (or task). From the operating system point of view, this makes CBOs quite fine-grained units of execution. The underlying CBO Infrastructure must enable this level of granularity as well as larger levels.

Finally, we need to consider the data carried on messages between CBOs. Here we need some form of type-independent data stream, which carries information about the data itself. It must carry data labels, in other words. Performance is a prime concern here, so building and parsing this data stream must be exceedingly efficient. This aspect of required CBO infrastructure is discussed in greater detail in Section 8.4.2.

Figure 3.6. A cooperative business object.

3.3 A re-statement

That a CBO is the end-product of a development process, rather than a component used within it, is so important that in this section, we re-state what we've said already, but in a different form. If what we've said so far needs no re-statement, please skip this section. If not, please read on.

Let's take the example of a financial institution, where a user is required to handle account transfer, customer enquiries, and account maintenance (or update).

The question we now want to address is, how should we structure the application software in order to present this function—money transfers, customer enquiries and account update—to the user?

We might have done an entity analysis of this and related business areas, and we might have identified three base entities (using the term fairly loosely)—account, transfer (a relationship between accounts) and customer. Further, we might have done some process analysis which showed, among other things, that we needed to display four things to the user: customer, a list of customers, an account and a transfer slip. Treating the base entities as servers, and the others as clients (which might reside on the PC), we arrive at the conclusion that our application software must handle the things shown in Figure 3.7.

Traditionally, when we build code to deliver business function through computer systems, what we do is to encapsulate a given process into what we call ‘an application’.

Figure 3.7. Example—items to be handled by application software.

This is shown in Figure 3.8, where we have wrapped the seven items we identified above into our three applications. Tidying up this picture gives us the situation shown in Figure 3.9.

Here we see the major aspects of the application problem. How can we address this problem? The answer is not to encapsulate business function and processes in applications. Rather, it is to build CBOs—individual software executables which are compiled and link-edited separately.

The key here is to encapsulate on the basis of the data, not on the basis of the process or function. This, of course, is the idea behind object orientation. What's new here is the idea of developing and producing independently-executable objects rather than producing applications whose source code is organized on the basis of objects.

Figure 3.8. Example—applications by functional encapsulation.

Figure 3.9. Example—duplication in applications.

In building an independent software object of this sort, the developer knows that it is of limited use all by itself, and that its real use is to be used with other independently-developed objects at execution time, connecting to each other through messages. This is quite unlike applications, which are generally built without any idea of communicating with other applications.

Figure 3.10 illustrates a set of such independent objects. Note that account maintenance required us to implement a customer object. Because the customer object was an independently-developed object, then at run-time we also gain (free and gratis!) three more capabilities—without development having built any applications:

● Customer service (elements of)

● Customer locate

● Customer enquiries

Figure 3.10. Example—independent objects.

The design point for independently-developed objects is at the level of a business entity—such as a ‘customer’, an ‘invoice’, an ‘account’, an ‘order form’, a ‘transfer slip’, etc. This is why we call them business objects. To reflect the key point of their being independently-developed, and hence their need (generally) to cooperate with each other to perform many business-related processes, we call them ‘cooperative business objects’—or CBOs for short.

So far, we have seen how borrowing the OO idea of encapsulation on the basis of data is very useful. Is there anything more we can usefully borrow from object orientation? Well, consider again our transfer slip object. Its behavior is as follows:

● It knows about two accounts

● It knows about an amount

● It understands that the amount is to be transferred between two accounts.

● It has data (and probably an identifying number)

● It can send a message to a Register Log object to effect the transfer

Now consider that we want to add another function for the user—a ‘sweep’, where an amount is transferred from account A to account B on a periodic basis (say once per month)—if the balance in A is greater than some pre-set value. Would we have to write a new money transfer object?

Here we can draw on the OO technique of ‘inheritance’ (discussed in Appendix 1). What we could do is to build a subclass on our transfer slip CBO (remember that a subclass, in OO terms, typically provides a superset of behavior—the behavior of the subclass plus the behavior of its superclass—the object from which it is subclassed). Thus we might build a subclass which had this behavior:

● It knows about how often the sweep is to be done

The rest of its behavior would be inherited from the Transfer CBO. Thus just by adding a subclass of Transfer, we get an object that:[13]

● Knows about two accounts—one to be debited, the other credited

● Knows about an amount (below which the transfer should not occur)

● Understands that the amount is to be transferred between two accounts.

● Has a data (and probably an identifying number)

● Can send a message to a register log object to effect the transfer

● Knows about how often the sweep is to be done.

And since the subclass may be in a different language than the superclass, we see a level of software re-use which has long been wished for, but never—until now—delivered.

The key to enabling this is to enable inheritance mechanisms across independently-developed CBOs—which also means across languages. Thus we see another requirement on our infrastructure.

3.4 Summary

The cause of the integration problem is the very structure of code we have been building for the last 30 years or so. An ‘application’ is an island of function, devoted to a specific task. It hides the things in it—things which are needed to perform the function. The solution is to build CBOs instead of applications.

If we build CBOs, then the picture would look like Figure 3.11, where IT would firstly have done an object analysis of a given business process, and would then have built the CBOs needed by the user to perform that process.

Note, however, that if a CBO has already been built for another process, it is not re-built. It is not even included in other code (as would be the case with many object-oriented programming languages). The user would just re-use it (on the object-based user interface). This illustrates the principle of object re-use—by the user, and also by other CBOs.

Again, the use of CBOs rather than applications makes it feasible to do something about the departmental processes which are seldom addressed by AD departments. For instead of building trivial applications, the AD function could develop re-usable ‘tools’—such as a pad of Post-It notes, or a specialized Container (some form of folder, perhaps). These would then be able to work with other CBOs.

Figure 3.11. Business objects.

Cooperation between CBOs is all-important to addressing the user needs, and is achieved by CBOs sending messages to each other. Thus systems are built of independent CBOs, acting on messages sent to them, and in turn sending messages to other CBOs.

For these objects to live on today's operating environments, some form of ‘middleware’, or software infrastructure needs to be built. But, just as, if you want to build transactions, then a batch spooling system is the wrong software infrastructure, so current infrastructures are wrong for CBOs. A new infrastructure is needed (as shown in Figure 3.12).

We will discuss some of the characteristics of such an infrastructure later (Chapter 8), but first let us concentrate on the other great impediment to ease-of-programming—the client/server connection.

Figure 3.12. Business process integration.

4 Structural overview

In this chapter, starting from the viewpoint of traditionally-structure application code, we develop the argument in favour of CBOs as the foundation for a general model. We do this by addressing three main questions:

● What are the base requirements for application structuring in a client/server system?

● What shape of application code should be written if ease-of-programming is to be achieved?

● What is the end-to-end structure of a client/server system?

Making programming easy is the crux of the matter. But unless there is a consensus about the general ‘structure’ of the application code—and what should be distributed where, then we cannot design a general-purpose application enabling layer which will make it easy.

Given that CBOs are the right shape for application code, we further develop a structure based on the separation of ‘user logic’ from ‘business logic’. We develop not only technical reasons for this separation, but also sound design reasons.

4.1 Base requirements

To begin the discussion, we propose the following four maxims:

1. There will be application code on the PC which handles the GUI, and thus serves the user. For the moment, we will call this code ‘user logic‘.

2. In general, the user logic must be able to respond to keyboard or mouse ‘events’ within a tenth of a second or less (otherwise the GUI becomes well nigh unusable).

For example, suppose the user has requested some data, and then changes his mind and presses the ‘cancel’ button. The user logic code should (must?) respond to this straight away (if only to say ‘please wait’). Again, for direct manipulation (drag/drop by the user), it is sometimes necessary to refer to the user logic code to see if one object is allowed to be dropped on another. This requires GUI response times within the application code (i.e. the user logic). (Clearly this is not always the case. My point is that we must allow in our thinking and in our design for such response times.)

Although not always required, such fast response time within the application code must be provided for by our model—otherwise it would not be general-purpose.

3. There will be application code which accesses the shared resources needed by the PC user. We could call this code the ‘shared resource logic’; but since the shared resource is mostly data, for the time being, and for ease of reference, we'll just talk about data. Hence we'll call this application code the data access logic.

4. The delay in accessing shared resources is generally (much) more than a tenth of a second. In addition, such shared resources will not typically be located on the PC.

From these four givens, we can see a key design consideration: there is a significant difference in response time between the application code which handles the GUI—the user logic—and the code that handles the shared resource—the data access logic.

The user logic code must return to the underlying system-level presentation layer within around 1/10th of a second. The data access logic, on the other hand, cannot be expected to respond reliably within this time. Indeed, we may be talking of tens of seconds (two orders of magnitude greater) rather than milliseconds!

The only effective way to handle this difference is to separate the two pieces of code, such that they run at least in different threads of control (tasks), or in different processes (address spaces), or maybe on different machines.

Running the two pieces of code in different threads of control means that the connection between the two must be asynchronous. That is, code initiating a request from the user logic (managing the GUI) to the data access logic must not be held up waiting for the response. Here we have a key distinguishing characteristic of cooperative processing in a client/server environment:

Cooperative processing applications require asynchronous requests and responses between user logic and data access logic.

The top part of Figure 4.1 shows this—the separation between the user logic and the data access logic by an asynchronous connection. This in turn means that we need a simple way for the programmer to handle asynchronous requests.

Notice that this model is insensitive to the placement of the data access logic. As shown at the bottom of Figure 4.1, whether or not we have distributed database makes no difference to the model. Placing structured query language (SQL) calls on the PC does not remove the disparity in response times between the user logic and the data access logic. It merely means that we have to do asynchronous connection within the PC. However, for ease of exposition, we will assume that the data access code will not be on the PC. This assumption makes no difference to the overall model—it merely serves as a useful vehicle for discussion.

The key point here is that user logic must not be blocked while the data access logic is executing; otherwise the user interface will block.

Figure 4.2. Client/server separation.

Our model, then, must recognise that:

● There will be application code (user logic) which handles the GUI and which is separate from:

● Different application code which handles the shared resource (data access logic); and that

● User logic and data access logic must run in different threads of control, but in such a way that

● There is a simple mechanism provided for the application programmer to connect these two pieces of code.

These considerations give us the model shown in part 1 of Figure 4.2(a) (for clarity, the operating system components and their APIs are not shown). The thread boundary is shown as a vertical dotted line.

So far, we have talked only of the user logic (GUI) and data access logic. But what about the business logic? And what do we mean by ‘business logic’?

Business logic

What people normally think of as ‘business logic’ is that application code that enforces business rules. For example, code which ensures that a customer order is either completely recorded on the database, or completely rejected, is business Logic. ‘Complete recording’ of an order will often entail the update of several different database tables (e.g. order header, order detail, product, and maybe customer). In other words, ‘business logic’ is often associated intimately with the commit scope processing.

Figure 4.2. Cooperative processing model (1).

We can distinguish this sort of logic from that required to access a single table or file (data access logic), or to do cross-field validation on data entry (user logic), and we call it ‘business logic’.

Thus we introduce business logic as a separate thing from data access logic. But since it is normally dedicated to ensuring the integrity of data (and shared resources generally), and will typically not return with a ‘yes’ or ‘no’ until the data has been properly accessed, then it is placed with data Access on the other side of the thread boundary from user logic.

An example which serves to show the difference is as follows. Code that checks whether a customer is over credit limit is business logic. On the other hand, code that displays a warning to the user that the customer is over credit limit is user logic. Again, code that reads a record from a file is really data access logic; while code that checks that if an order header record is recorded, then at least one order detail line must also be written, is business logic.

Consider an order entry process. Figure 4.3 illustrates the main actions within such a process (for simplicity we exclude back-ordering, stock allocation and error conditions). Notice how many of the things which need to be done are primarily to do with accessing data, or supporting the user. However, the kernel of the process—the part which must be done (even if it's a batch process, where the ‘user’ parts would have been done via data entry and edit runs) is business logic.

But where should this logic be?

Figure 4.3. User logic, data logic, and business logic.

We have said that business logic should be on the same side of the thread boundary as the data access logic. In general, the thread boundary defines the boundary between ‘client’ and ‘server’. Often this boundary will be much more than just a thread boundary—it will be a communication link. Business logic is frequently associated with commit scope processing (that is, code effecting business rules which must be followed between receipt of a request by the server and its response to the client). In that case, the ‘server’ will normally be a shared resource system which is physically separate from the PC. On the other hand, where the data access logic is handled by a distributed database facility on the PC, then the business logic and the data access logic may be on the PC—but still on the other side of the thread boundary from the user logic. User logic (which will often include simple data validation) should be in the PC unless it is obvious from the nature of the logic that it should be done elsewhere. In building real systems, this is almost always a trivial and obvious decision.

In this categorisation, we are not attempting to define rigorously the differences between the three types of application logic, nor to build a model with precise theoretical boundaries. What we've done here is to focus on the major differences between the necessary bits of code in the client/server system. Later, we shall give each part more precise responsibilities. For the time being, the important thing is the separation of business and data logic on the one hand as the preserve of the server, and user (presentation and interaction) logic as the preserve of the client.

Thus we can enrich our model by adding business logic, as shown in Figure 4.2(b). (For clarity, in Figure 4.2(b) we omit the PC screen and the actual data (the disk storage). From now on, we will not show these.)

GUI code

But why have we also added another block called ‘GUI Code’ in this figure? And why is the task boundary shown as being between user logic and business logic, rather than between GUI Code and user logic?

Consider the GUI API provided by the system. Handling this API is generally complex and requires a very high level of C programming skills. We need to isolate the application programmer from this complexity if we are to achieve our ease-of-programming objectives. This is often done by providing a window layout tool, which generates the required low-level GUI code. We re-draw the model to show this in Figure 4.2(c), where we label the GUI code as just ‘GUI’, being produced by some appropriate window layout tool.

But what about the thread boundary? Well, and this is an important point, often not fully appreciated, the thread boundary is as shown because, in the general case:

The user logic on the PC must sometimes respond at GUI speeds to user events.

This does not mean, of course, that there cannot be a thread boundary between the GUI code and the user logic; indeed, such a thread—or process—boundary may be very useful depending on specific PC operating system implementations. What is being said here is that there does have to be such a boundary between the user logic and the business logic.

Thus there is a technical reason in addition to a design reason for separating user logic from business and data logic.

Before examining this separation in more detail, we now take a necessary detour to answer the question, how are the separate pieces of cooperative code connected? How does the programmer access one from the other? This is perhaps the key question in enabling us to design easy-to-build code, and hence define the underlying ‘enabling’ infrastructure required.

4.2 Application code structure

In this section, we address three areas of difficulty:

● What kind of connection—between two separate pieces of application code—should we provide for the programmer?

● What API model best implements the kind of connection chosen?

● Is there a specific structure for application code which delivers ease-of-programming more than any other?

4.2.1 Kinds of connection

Our focus here is a single interaction between two pieces of application software across a communications link. There are, in general, three different design approaches for such an interaction:

1. Master-slave This is where one end (the master) owns and drives the other (the slave), and usually implies a great deal of knowledge at the master end about the state of the slave end. The master controls and directs the whole process. An example of this is where code on one system drives a non-programmable terminal through the code on a screen controller. In this case, the ‘single’ interaction is probably very long-running—from login to logout.

2. Peer-to-Peer This is where each end of the link is of equal importance. Either end can initiate an interaction. Usually, peer-to-peer requires each end to know detail about the state of the other, and protocols are defined to communicate these states.

An example of this might be a distributed database system, where to ensure coordinated recovery, each database must discuss recovery, sync point and rollback matters with the other. Any of the databases can initiate this with any of the others. The single interaction here may be short or long duration, and is characterised by each end both sending and receiving within that interaction.

3. Client/server Here, a ‘requester’ piece of code (the client) initiates a request to a ‘responder’ piece of code (the server). Note that here we are using the phrase ‘client/server’ in its ‘connection design’ sense; see the Glossary for the other two meanings. Essentially the server is there to provide a service of some sort for any client that requires it. The server knows nothing about the state of the client. The server is (typically) passive.

An example of this might be a credit check agency, which provides a ‘server’ interface to other company's computers requesting a credit check. This design is based on the following principles:

(a) The client makes a request of a server; the server responds back to the client

(b) In each completed interaction between client and server, the client sends one and only one request. This request starts the interaction. The server responds with one response (which may be in several parts). This response ends the interaction.

(c) No state information is retained in the client or the server about the state of the interaction. That is, each interaction between client and server is independent of other interactions. Of course, both the client and server may retain information about their own state across multiple interactions. What we're saying here is that for any given interaction, there is no dependence on either previous or future interactions for that interaction to complete successfully.

This design is sometimes called a ‘one-shot transaction‘, to imply that there is no continued conversation or dialogue between the client and the server. Note that servers can also be clients. The processing logic within a server could make requests of other servers. In that case, the requesting server would be a client to those other servers.

From these three, we choose the client/server design as the basis for connection between the separate pieces of cooperative code. The reason a client/server design is preferable are:

● It is simpler than the others, due to the lack of state information that needs to be held about the interaction

● You get much looser ‘binding’ between each end of the interaction than otherwise. The looser the binding between two pieces of code, then the greater the potential for re-use. Thus several clients may use the same server. Servers can be re-used across application boundaries. Several servers may be accessed by a single client.

While this form of connection may not suit all occasions (for example, if the thing you're building is a distributed relational database, then it may be insufficient), it seems to suit most, if not all, of the situations met in commercial data processing—the ‘core’ or ‘mission-critical’ business systems. It also seems to suit many other situations.

4.2.2 Programming models

But what does a programmer actually have to write to effect the connection between two separate pieces of application code? Well, when a programmer writes code, he is actually doing two things:

● Implementing a concept—a model—of what he wants to do

● Obeying some syntactical rules about how to implement that model

The second of these is of much lesser importance. If the syntax is particularly tortuous then it merely makes the thing the programmer wants to do more laborious. The first is much more important. If a programmer cannot easily conceptualise the effect that each line of code has, then his task is made extremely difficult.

In Figure 4.4 we show on the left a number of different tasks that a programmer might want to perform. In each case, the programmer is easily able to visualise the effect of the code he needs to write. This code is shown in the centre of the figure. Depending on the language, the programmer will either do a call to make something happen (as with the C language for example), or there will be some built-in language syntax (as with COBOL), or there will be some statement which is pre-compiled into a call (as is often the case with EXEC SQL …). Figure 4.4 shows examples of all three. Finally, down the right of the figure are the underlying system mechanisms which implement the code he writes. Note that the implementers of such mechanisms are usually also the designers of the APIs which access them.

In the first example, the programmer is reading a record from a file. He is protected from all the underlying complexities of the file system by the design of the API to that file system. This allows him to write the simple statement ‘READ FILE INTO RCD_A’ to implement his image of the process. Thus the designer of this API ensured that the API corresponded to the programmer's model of what he (the programmer) was actually doing.

Figure 4.4. Models, APIs, and implementations.

Thus:

Implementers of APIs for cooperative processing must first design the application programmer's ‘model’

Designers either do this explicitly or they do it unconsciously (because they cannot avoid it!).Note also that the examples of code in the centre of Figure 4.4. include a ‘call’ form (such as might be written in the C language). Self-evidently, although the syntax of each of these calls is similar, the programmer is doing quite different things, and has a different model of what's happening in each case. We will come back to this later.

In providing an API model for the programmer, we must above all else keep it simple. It must be easy-to-use. This means that:

● ‘System-level’ complexities must be invisible to the programmer. Such complexities include:

▪ Getting across a task/process boundary to handle the asynchronous nature of the connection

▪ Synchronising application code with code running in the other task/process

▪ The physical location of the other piece of business logic

▪ Driving the underlying communications API

▪ Initiating or loading the other piece of business logic

▪ Routing the response back to the requestor

● The API itself must be simple (a few lines of code at the most)

It is for these reasons that many currently-available APIs are not suitable (e.g. pipes, sockets, re-directed file I/O). For example, none of these will get the programmer transparently over the task boundary.

There are probably four different choices for an API model:

● Remote Procedure Call

● Conversation

● Make the interaction look identical to some existing external facility (for example, like file Input/Output)

● Messaging

As we shall see, none of these is entirely satisfactory by itself. We will need to add a further factor—the shape of the code which deals with the API. Before discussing that, however, let's look at each of the four models.

Remote procedure call

The idea behind RPC is that the programmer merely calls a procedure (a subroutine) as usual—but the procedure is actually outside the program—in another process or address space, either on the same or a different system.

Figure 4.5 shows this. The programmer calls a procedure. The ‘system’ intercepts the call, routes it to the remote procedure, which then executes. Meanwhile, the calling program waits—just as it would do if the procedure was local. When the remote procedure has executed, it returns control (together with any data and maybe a return code) to the ‘system’, which then returns control (with the data and return code) to the next sequential instruction in the calling program. If any code translation needs to be done (e.g. ASCII to EBCDIC, or one form of floating point to another), then the ‘system’ will do it automatically. A different form of RPC from that shown in Figure 4.5 is where the programmer passes a handle that identifies the routine to be invoked by the response. In this case, the programmer has to work out what to do if, before his program can continue, the response is needed. Perhaps wait (if that’s an option)—synchronously.

Figure 4.5. Client/server models—RPC.

Figure 4.6. Client/server models—conversation.

Conversation

The principal behind a conversation is that each end does explicit sends and receives. This implies that each end must be aware of the state of the other (at least whether it's expecting to send or receive). Figure 4.6 shows such an interface.

Note that if both ends send at the same time, there must be a way to handle and recover from the resulting collision. Protocols such as CPI-C provide for such events.

Using an existing model

This means creating an API based on some existing and well-known mechanism. For example, one could construct a cooperative processing API to look like file I/O, thus building on concepts already familiar to the programmer.

Messaging

Here, the programmer thinks in terms of sending a message to something (another piece of software), and of receiving messages from somewhere (other pieces of software—either his own, or someone else's). In procedural code, a messaging scheme might look like the one shown in Figure 4.7. Notice that the programmer must be aware that a message will be returned.

Sending a message is inherently an asynchronous operation. Control is returned to the calling program before the message is delivered. Notice, however, that the receive is synchronous; the program issues a ‘receive message’, and waits until there is a message to be received. Thus messaging is synchronous at the receive.

Figure 4.1 Client/server models—Messaging

4.2.3 Choosing a programming model

Before choosing between these four, remember that there are three different aspects of an API:

● What the programmer thinks he or she is doing.

● The language statements (and their syntax) which the programmer needs to write to make it happen.

● The underlying mechanism that implements those statements.

It is the second of these three that people normally mean when they talk about an ‘API’. But it is the first of these three which is the most important to the programmer.

Let us consider the four types of connection in relation to our objectives—asynchronous messaging and ease of programming.