An important principle of business application design is to separate program code into components. Although this may sound obvious, this has not always been done and is such an important topic that we are going to spend some time on it.

Components are not the same things as objects, nor are they simply the divide and conquer aspect of implementing a large project. Components are about managing a complex IT environment, keeping it in step with the needs of the business, and about reuse—the ability to use large amounts of an existing application to build a new one. With good component design, you have the ability to enhance a business application rapidly in response to market needs or to exploit a newly-emerging technology with adherence to business rules assured and without loss of auditability.

There are three aspects that fundamentally differentiate the parts of a modern business application:

There are also some practical differences; that is, the components may be:

These differences cannot be ignored. Instead, they must be taken into account when designing and developing an application. In other words, your application should be structured into components.

The key components of any business application are business logic components and presentation logic components. The business logic component is responsible for business calculations and updating databases. These components are the hardest to develop, the most critical to the operation of the business, and the most valuable to reuse. Get these right and everything falls into place. The presentation logic components and their component interfaces control the presentation of information to end users. The presentation logic components are represented in this book as the 3270 interface using COBOL, as a web interface using servlets and Java Server Pages (JSP), as a Graphical User Interface (GUI) using Visual Basic, and as a Java program using MQSeries to access data in our CICS application. In Figure 2-1 we show the 3270 frontend. Each of the three other frontends have a similar input screen and account display screen.

Business logic components

The individual functions of a business logic component should be designed to operate in a server environment. Business logic functions typically:

• Validate input data

• Search the database

• Cross-validate input data and database data

• Update data (including additions and deletions)

• Log activities

Figure 2-1. Initial outline of a 3270 application

Business logic components should do these things in a way that adheres to business rules and ensures their consistent implementation. For example, they should:

• Update a journal on a particular database containing sensitive material (such as a payroll) for an audit trail.

• Provide the one-and-only approved program that performs complex computations such as interest earned on a deposit account or discount granted on a customer order.

• Obey rules imposed by regulatory bodies.

• Ensure that consistency cannot be compromised. For example, critical updates that are inextricably linked should be done in the same program.

The criteria for grouping business logic functions into business logic components are pragmatic. Business logic components should:

• Encapsulate as much data as possible.

• Have an interface that can be tested independently.

• Be able to move to another server without affecting other components.

• Have a purpose and responsibility that can be discussed in a business context and should not have a purely technical definition such as everything running on a server X.

In a business application, a transaction has the same meaning as it does in everyday English—a single event or item of business between two parties. Business application transactions should have the so-called ACID^[1] (Atomicity, Consistency, Isolation, and Durability) properties, which are described in more detail later on in this section. However, before explaining what ACID transactions are, consider the problems that can occur with transactions.

Imagine a component that operates on bank accounts. The component has three services that could be invoked by end users, one to add to an account, one to delete from an account, and one to move money between accounts.

The most difficult of these is to move money, because it must do everything necessary to ensure that all the accounts are updated and that the operation only proceeds when appropriate. Consider what would happen if things went wrong—if the server failed or if the database contained errors after some, but not all, of the updates had been done. One customer could have his money withdrawn, without the other customer receiving any money (providing an unintended bonus for the bank!). Or, even worse (for the bank at least!), both customers could receive money, resulting in an unintended loss for the bank.

Also, consider what could happen if two bank employees try to move money from the same account at the same time. If the component is designed to read the database to check whether there are sufficient funds and then update the database with the new balance, one of the updates could be lost.

To prevent problems such as these, we need to create ACID transactions:

Trying to implement the ACID properties by unique application code in every business application component would be difficult. It would totally obscure the business logic, making the code difficult to maintain and audit. The problem is that some things are not business issues but technical issues—things the technology should address in order to ensure the code is as easy to write as possible—so as to allow the business logic programmer to focus on the business issues. There is a clear difference between business exceptions, (such as, “the account does not have enough money in it”) and technical exceptions (such as, “the account database has only accepted one of my updates”). Our system software, our middleware, should hide the messy realities of the machinery and present us with services that don’t need us to solve this problem.

Using an application server such as CICS, you can obtain the ACID properties by defining groups of updates that must all be done together. As the transaction proceeds, the updates are done on a provisional basis, and logged. If they all work, you can commit (syncpoint) the changes, that is, make them permanent. But if there are problems you can cancel the changes, that is, back them out. If the system fails—say there is a power outage before you have issued the commit—the system automatically backs out the changes you made. Your program’s responsibility has ended, though the client may need to resubmit the request once power is restored. You can concentrate on ensuring that business exceptions are handled, and you can safely leave the technical exceptions to the system.

It is a well known fact that in computing 80% of programming code deals with handling errors and/or exception conditions, that is, with knowing what is supposed to happen, checking that it has, and doing something about it if it has not!

Suppose a device error occurs on a disk—the data will not be available until the disk is replaced and the data restored. But suppose the application that was trying to read the disk failed to check that the operation succeeded and, as a result, wrote incorrect data to another file. Merely restoring the original data will no longer fix the problem, and finding out why the second file contained garbage could be very difficult.

Suppose a software bug in an infrequently used part of a program caused an undetected overwrite of stored data. Not only could subsequent uses of the program fail because some piece of memory is corrupted, but finding out why the problem occurred could be very difficult.

These examples show why handling errors is vitally important. Errors are a fact of life. In developing applications, it is best to remember these two maxims:

Errors that disrupt business applications can stop a company doing business until the problem is fixed, so it is vital to detect errors early, clean up after the errors to allow operations to continue, and record diagnostic information so that problems can be fixed quickly.

In a CICS application, a transaction is the processing initiated by a request, usually from an end user. A transaction starts, executes, and ends. A single business transaction (such as the enrollment of a new customer) may involve several CICS transactions.

A CICS transaction may contain one or more Units of Work (UOW) where a UOW begins with the first action to alter a protected resource and ends with either an explicit or implicit syncpoint. To summarize, a business transaction involves one or more CICS transactions that, in turn, can involve one or more units of work.

When processing transactions, CICS accumulates performance statistics and monitors the resources used. This provides the information that enables user departments in your organization to be charged accordingly. It also allows you to find out which parts of CICS are being heavily or lightly used. This helps your systems managers to tune the system to improve its performance.

A program is the smallest replaceable unit of an application. Programs are compiled, linked or bound, and turned into a single executable file which is then deployed. They can be written in many languages and run in many different environments. A component of a business application typically consists of multiple programs.

CICS provides a variety of ways for programs using CICS to invoke and be invoked by other programs running inside or outside CICS, for example on web servers or end-user workstations. Program calls can be:

Synchronous calling between programs

There are two main ways in which one program can invoke another program inside CICS. These are discussed in more detail in Commands for Passing Program Control in Chapter 5. For the time being suffice it to say that the CICS API consists of a number of commands that define resources, make calls to other programs and so on. In this book you will meet a wide range of these commands particularly in Part II and Part V. Two of these commands create links from one program to another. Figure 2-2 shows the linking process and relationship of one program to the next. The commands are:

EXEC CICS LINK

Allows one program to transfer control to another in a synchronous manner and continue execution after the called program has returned. This also occurs by means of native programming language facilities such as a COBOL CALL statement.The LINK Command in Chapter 5 gives more detail.

EXEC CICS XCTL

Allows for one program to call another in a synchronous manner but unlike LINK will not receive control back when the called program returns. This has no equivalent high-level language facility. It is particularly useful in error processing when an unexpected error is detected that implies that the program which trapped the error cannot continue. The XCTL Command in Chapter 5 gives more details.

In both cases a COMMAREA (for “communication area”) is used to pass parameters and returned values. For more information about COMMAREAs see Saving Data: Using a Scratchpad Facility in Chapter 5.

The LINK and XCTL commands introduce the idea that different programs involved in the processing for a transaction can be executing at different logical levels. A program invoked directly by CICS is considered to be at the highest logical level of the task (level 1). If it then uses the LINK command to link to another program then the linked-to program is considered to be at a lower logical level (level 2). However, if the program detects an unexpected condition it can use XCTL to call an error handler which will be considered by CICS to be executing at the same logical level as the program issuing the XCTL request. Figure 2-2 illustrates this principle.

Figure 2-2. Transferring control between programs (after an Abend)

For asynchronous processing, you can achieve the greatest flexibility by using IBM’s broad range of MQSeries products. Neither the calling program nor the called program needs to know anything at all about where or when the other program executes because MQSeries provides a common set of facilities for sending and receiving messages, takes responsibility for routing messages to the required location, and holds the message until the receiving program wants it. The sample application uses MQSeries to invoke a CICS program.

Error handling facilities are critical in any application. CICS includes several error handling facilities, including:

These are described in more detail in Handling Errors in Chapter 5.

Security is a complex subject that requires careful planning before it is implemented; as such, it is not dealt with thoroughly here. As we have already mentioned, many people, with many different roles, interact with business applications and the security, auditability, and accuracy of the application depends on these roles being kept separate and identifiable. Therefore it is natural that security of business applications should be role-based.

Once each user’s role has been understood, security can be implemented on the following basis:

CICS works in co-operation with OS/390 security managers (for example, Resource Access Control Facility (RACF), Access Control Facility (CA-ACF2), or TopSecret) to implement this role-based security, with CICS calling the security manager as required to provide the authentication and authorization checks. CICS can request up to three types of authorization check: transaction security, resource security, and command security.

CICS uses operating system services on behalf of components. However, it doesn’t merely duplicate the services but adds value by providing additional services for running transactions. These services include:

The programming facilities CICS provides are:

It’s important to ensure that there is agreement on what each component is required to do. Make sure you document the design of your component thoroughly, and share it with people who are designing other components. Document your component’s interface, if it has one that other components use. Include assumptions about performance and capacity.

If your component has a user interface, test it out on paper first by drawing all of the proposed screens, and asking some of the intended users to check your design by attempting to “use” the screens. Put yourself in the position of the computer, in order to check what happens when it makes a functional request.

Finding problems at the design stage is essential; it is much cheaper and quicker to fix them earlier rather than later.

For each component in our sample application, you will find that there is a chapter describing the design. In these chapters we consider the factors influencing the design of the component, which lead to the decisions made by the component designer.

Read the design document! The main job of the programmer is to implement the design, as documented. At the same time, the programmer should follow:

For each component in our sample application, we show how to convert the design into a working program.

Testing is an integral part of any software development, and must be as carefully prepared and implemented as the development of the product itself. There are many different methods for testing and several standards have been developed. It is outside the scope of this book to describe testing standards in detail; however, here are a few useful guidelines:

Your testing will inevitably uncover errors in the component’s logic or programming. These then need to be removed, a process known as debugging. Chapter 16, describes some of the debug tools available in CICS, and shows some sample debug screens.

Once each component has been designed, programmed, tested, and debugged, it must be deployed correctly. At the same time, the configuration files for the various runtime products must be updated to recognize the components.

Appendix A describes the deployment of our sample application.