We can obtain the vertical and horizontal slices by a right-click on an artifact in the Classification pane, followed by the selection of the Show vertical slice or Show horizontal slice menus. Now, let us look at certain examples.

As a CICS transaction appears in the highest layer of the architecture, it is not itself "used" by any another artifact. In the above figure, we can see that transaction RWCD is started by program RWCP1198, which calls RWCP1200, RWCP116, and RWCP1202. In turn, the last two programs access certain files (shown at the very bottom of the diagram) in read mode (R), Read/Update (RU), or Read/Update/Insert mode.

The preceding figure shows a vertical slice of the screen RWCS80A, which is sent and received by the program RWCP110, and sent only by program RWCP1132. These programs then call programs RWCP1138 and RWCP1156 to read data sets.

The above figure shows a vertical slice of program RWCP1136. We can immediately notice that this happens to be a 'frontier' program, according to the classification that we have described earlier, as it does not access screens and is called directly by programs that access screens. This special position in the architecture would make it a good candidate for exposure as a Web service.

From the preceding figure, we can discover a fact that is relevant in the effort to extract services — all operations against the selected file (seen at the bottom, in a white box) are performed via a single program, RWCP1120. This makes the program ideal as a service, as it certainly contains all the logic needed to access the file from outside.

While vertical slices through the application's architecture show usage scenarios, horizontal slices show the processes or workflow performed by the operator. Horizontal slices do not make sense for files or tables of other persistent data artifacts, as they do not represent processes or actions triggered by the user. For programs, horizontal slices show the exclusive change of control from one program to another, as for example via XCTL operations in CICS. For screens, they show the possibilities for the operator to move from one screen to another.

We can look at some examples of horizontal slices.

The preceding figure shows a horizontal slice for the screen RWCSA8. The block on the left shows all the screens from which the operator can potentially move to this screen, while the block on the right shows all the screens to which the operator can potentially move from this screen.

I have intentionally used the word "potentially", because not all these transitions may happen at runtime. The simple reason is that the static analysis cannot always discover the exact transitions, due to the fact that they may be controlled deep in a program or even in a file or table. In some legacy applications, the traffic between screens is recorded in a table which a traffic cop program reads in order to figure out how to process a user request. The preceding figure should be interpreted as "from screen RWCSA8 one can possibly move to screens RWCSA3, RWCSA5 and RWCSA8." In reality, the program that controls RWCSA8 may contain additional restrictions, which prevents, for example, a move to screen RWCSA8.

The preceding figure shows a horizontal slice of programs. Every edge in the graph indicates an exclusive change of control from one program to another program.

Together, horizontal slices and vertical slices offer a good picture of the role of a particular artifact in the application architecture.

In a perfect architecture, all programs that belong to the client layer should only deal with screen logic and navigation. Data access should be accomplished through the programs belonging to the frontier and sub-frontier layers, which in turn should be called by the client programs. This is the case in a well-layered application. But in real life, this restriction is not always enforced. In some cases, where no strict architectural discipline is enforced, programmers may take shortcuts and combine the screen access and data access in the same programs, as it is shown in the following vertical slice for program CUSTINQ1:

As I have already stated, although a program like CUSTINQ1 may function very well, it may present some limitations when it comes to the mining of services. Let us suppose that this program contains some very special logic that interprets the data read from the Customer Master file. It is possible, for example, that the program reads the date of birth of a customer and calculates the age, which is then displayed on the screen. Many such derivations are possible. We would like to have a service that does not just read a record from the Customer Master file, but also interprets and derives new data items. Unfortunately, while CUSTINQ1 does the interpretation and the derivation, it cannot be simply made into a service, as it is also conversing a screen (by definition, a service cannot do that). We will discuss later what can be done in such a case.

It is tempting to look at all programs that are called as potential services. In principle, a call is a request to the called program to perform a task, and that is also the nature of a service. However, in real life applications, we will, encounter situations where a called program cannot be made into a service for a simple reason that it also converses a screen, as can be seen in the following figure, with program SYSTEM.PCITN100:

There can be many reasons why the original application included this anomaly. Perhaps the most common reason is that when a "service" program is written the programmer finds it convenient to report an exception immediately to the operator by sending a screen with a message. By writing the program in this style, the programmer simplifies the code, but renders it unfit to become a Web service (which by definition cannot converse with a user interface).

If the program in question is desired as a service, it should be modified such that instead of sending a screen in case of an exception, it should return to its caller with a special return code signaling the same exception.

This anomaly is mostly theoretical, as transitional programs are not usually candidates for services. However, it signals a strange situation, in the sense that usually transitional programs (as defined above) are mostly dedicated to directing the screen navigation, and not to the fulfillment of a task (typical for called programs).

This is a generalization of the "Client programs called" anomaly. It happens when a client program calls a "service" program, which in turn calls another client program. Although the one in the middle seems to be a perfect service (because it is called, and does not converse a screen), it is impossible to turn it into a service, as during the execution one of its called programs converses a screen.

In the figure under the heading Calling Client Programs, this is the case with the program CRMODL.GRQUN900, which is "almost" a service. This program is called by CRMODL.GRQUN600, but in turn calls SYSTEM.CRTXN06, which calls SYSTEM.PCITN100, which is actually a client program conversing the screen SYSTEM.PCITM100.

A perfect CICS service program may not become a perfect Web service due to the fact that it fails to perform data validations. That may not be a problem in its original environment as it relies on its caller program to perform such validations. Let's have a look at the following figure:

Next to the ORDERR1 program, you can see a label with the text, "7 validations". This label appeared automatically after:

The "7 validations" label indicates that as ORDERR1 converses the screen ORDMAP1, it performs 7 validations against the data entered by the operator on this screen. Such validations check if the data is numeric, properly formatted, or entered in the mandatory fields. When program GETINV is invoked to perform an operation against the INV.CONTROL file, it assumes that all data is already valid (otherwise ORDERR1 would have issued a warning message to the operator). GETINV can now fulfill the requested tasks without the danger of running into some data that does not make sense.

Although GETINV is otherwise a good candidate for a service, here is the caveat! If this service is invoked from another environment other than its original one, there is no guarantee that the data it receives is valid. What worked perfectly in CICS may not work properly in SOA architecture.

There are various remedies we can apply to resolve this issue. One of them could be that the application server or even the client facing programs in the new architecture perform the validations and ensure that GETINV does not receive anything else other than correct data. Another remedy is to repeat the same validations in GETINV as they exist in its caller, ORDERR1, and have GETINV return with a special return code, should these validations fail.

One would usually expect the caller and called programs in a CICS environment to communicate through the CICS COMMAREA. This is the most common way, but not the only way, in which CICS programs pass data. It is also possible that the called program writes the data into a temporary storage queue that the caller reads. As most CICS adapters are equipped to deal only with data passing through COMMAREA, this creates a major difficulty.

We need to discover if such situations exist. It is in fact quite simple. After we display a vertical slice through the architecture (see the description of vertical slices above), we press on the Tools | Intersect Queues menu. This will add labels next to the programs that operate with queues, as shown in the following figure:

This diagram tells us that GETINV writes to a queue and ORDENT1 reads from a queue. It is just a red flag at this point, enough to determine us to investigate. If we really find that the data passes from GETINV to its caller via the queue, then we know that normal service adaptors would not be able to create a good service out of GETINV. When the program is called as a Web service in SOA architecture, the service consumer will expect to collect all the data from the service interface that describes the COMMAREA, while the data actually resides in a queue.

The remedy is to either modify GETINV to pass the data exclusively through the COMMAREA, or to create a special 'service' program that reads the queue and passes it through the COMMAREA. Finally, it is possible that some vendors offer service adapters that are capable of getting the data from CICS queues.

One such method is to start with the screens that suggest the functionality that we are after. By inspecting the screens, for instance, we may discover that one of them helps the operator perform an Order Entry function. Screens may be viewed in the SOA Analyzer by selecting the View Source menu visible when we right-click on a screen mode. Our Order Entry function will display as follows:

Once we discover the screen that deals with the service function, we can look at its "vertical slice" through the application. The vertical slice, as displayed by the SOA Analyzer, shows a cut through the layers, which includes the screen as well as all the programs that service it, as shown in the following figure:

In this diagram, we can see that the screen ORDMAP1 (which appears on the top) is accessed by the program ORDENT1, which in turn calls other programs to fulfill a request. All these called programs are candidates for services. Together, they could become operational in a Web service that would be consumed when one makes a request to create a customer order in the new SOA architecture.

As we look for potential service programs, we should give special attention to the frontier programs. Indeed, they encapsulate the most complete functionality. They not only know which data to access, but also know how to assemble it in a manner consistent with business requirements. If lower-layer programs are selected, then some of the data assembly must be performed on the application server, opening the possibility of erroneous implementations that differ in functionality from the original application. Choosing frontier programs for exposure makes the task simpler and eliminates the possibility for further errors.

Another method to find the services with a particular functionality is to look for special patterns in the code. This can be accomplished from the Relativity's Application Analyzer with the aid of the so-called clipper queries.

To run a clipper query, we'll go through the following steps:

This entire search points to GETINV as a good candidate for the desired service. It performs some operations with the Invoice, and it is a service type program that does not converse any screen.