Scenarios

Before implementing SOAI, we must understand all the processes, application services, and programs that exist within the enterprise. Confronted with such a monumental task, we must initially ask, How best to proceed?

The first step is to break the processes down to their scenarios, or types. For application integration, these types are rules, logic, data, and objects.

A rule is an agreed-upon set of conditions. For example, a rule may state that employees may not fly first class on flights of less than 5,000 miles or that all transactions over $1 million must be reported to the government. The rules that exist within a given enterprise are built into the applications in order to control the flow of information. Rules can also be placed in enterprises to control the flow of information between enterprises.

Normally, rules exist in stovepipes in a single application and accessible by a single department. The challenge of application integration is to provide the infrastructure that will allow the sharing of these rules between organizations. Thus, these rules will become accessible to many applications, either from their current location, or by moving them to a central location.

Rules need to be understood because they affect every aspect of moving data between enterprises, including identifying, processing, and transforming it. In fact, rules processing at the middleware level through message brokers or process automation tools will become the first generation of application integration.

Logic differs from rules in that it is simply a sequence of instructions in a program. For example, if this button is pushed, then the screen pops up. The real difficulty in dealing with logic is the consequence of a very basic reality any ten programmers, given the same set of specifications, may come up with ten slightly different versions of program logic that all function perfectly well. In many ways, logic is as much an art form as a science.

There are three classes of logic: sequential processing, selection, and iteration.

Sequential processing is the series of steps in the actual data processing. Input, output, calculation, and move (copy) are examples of the instructions used in sequential processing. Selection is the decision-making dynamic within the program. It is performed by comparing two sets of data and, depending on the results, branching to different parts of the program. Iteration is the repetition of a series of steps. It is accomplished with DO loops and FOR loops in high-level languages.

In this context, data is nothing more than information that is shared between applications, computers, or humans. Reporting systems, enterprise accounting systems, and human resource systems all share data. Because application services act on data, you need to understand the way in which information is shared at the application service level in order for SOAI to be successful.

Objects are simply data and business services bound as objects. They are bundles of data encapsulated inside an object and surrounded by application services that act upon that data. Objects are so important to SOAI that we will devote much of this chapter to the discussion of the object model and its use within the application integration problem domain.

Objects in systems generally use object-oriented technology, such as C++ or Java. Despite the fact that most objects are service-oriented objects (that is, objects that do something when an interface is invoked; more on these later in this book), the object "mix" may also include distributed objects.

Identifying objects within the problem domain is more complex than identifying business processes. It requires an understanding of the object models used to construct the applications whether they exist, or, if not, whether they have ever been created. In the absence of the object model, the applications must be re-engineered from the existing code base. (Fortunately, a good set of tools and technologies exist to aid in this re-engineering. Without such tools, the task would demand reading each line of code and creating the object models from scratch.)

Creating object-oriented integration within a B2B problem domain is more than difficult; it may well be impossible. Although its value cannot be disputed, object-oriented integration is a highly invasive process. It demands tight coordination between IT departments within the many different companies that exist in a trading community.