Processes, Enterprise Objects, and Services

The architecture of applications, no matter how complex they may be, continually presents software designers with new challenges. With each new step in the direction of more advanced technology and with each new challenge brought in from the application areas of business and information technology, the design aspect must grow in a new dimension. Enterprise JavaBeans spares the software developer some of the design decisions through the component model. For problems such as distribution, scaling, and persistence there are answers to be found in the specification, and a closer look will reveal many known design patterns (for example, the EJBObject represents a combination of proxy and decorator patterns, and the home interface corresponds to the factory pattern [5]). Frequently, however, the developer will be searching for answers to questions such as these:

• For what tasks should I use entity beans?

• For what tasks should I use session beans?

• For what tasks should I use message-driven beans?

• Should the client communicate with all components or only with particular components?

• How should components cooperate and communicate?

The goal of this section is to give some suggestions for the use of entity, session, and message-driven beans.

One models business processes on computer-supported systems in order to learn how to handle them better and more efficiently. As a rule, one attempts to relate these models to actual conditions. The reality of everyday business meets us in the form of processes, business objects, and services. The following implementations should help to clarify what we understand by processes, business objects, and services and how they are mapped to Enterprise JavaBeans.

Business Objects

By a business object we mean an actual object or item of a concrete application area. For example, in the area of marketing, a business object might be a customer, a supplier, or an invoice; in manufacturing, such an object might be a machine, a parts list, or a production list. The immediate connection of these objects to the business world is underscored through the name business object. Business objects are are represented and identified by their data. Thus a customer has a name, a shipping address, a billing address, and so on. In a data-processing system the customer will be assigned a unique customer number as means of identification. The same holds for suppliers. Product parts, say, are represented by the data that describe their technical properties and are identified by a unique part number. All of these properties lead to the decision to model such business objects as entity beans (see Chapter 5). Entity beans are persistent objects, and they can be identified and located by a unique key. Business objects are not to be viewed each in isolation, but in relationships among one another. A production list refers generally to an order (vertical relation), while a parts list consists of several modules, which themselves are divided into individual segments (horizontal relation). Thus business objects reflect the structural aspects of an organization.

Processes

Processes represent the dynamic aspects of an organization. By a process we understand a defined sequence of individual operations. At a given time, a process is in one of a number of states, which makes it possible to guide and control the execution of the process. Furthermore, state transitions are defined. The individual operations of a process are carried out on the data of business objects (that is, they are used and/or altered). Table 9-3 shows the process of executing an incoming order.

Table 9-3: Steps in processing an order.

Process Step	State
Receipt of order documentation	Process is started
Checking of order data	Data being checked
Transmittal to the group of unprocessed orders	Order being processed
Completing order data	Order being processed
Release of order	Released

In this process one can include (according to the type of business) the business objects Customer (who places the order), Endproduct (the object being ordered), Rawmaterial (inventory control for meeting a promise of delivery), and Order.

Processes are ideally suited for modeling as session beans (see Chapter 4). Since processes have states, one should use stateful session beans. Stateful session beans are transient, and are available to a client exclusively for one session.

Services

By services we mean all operations that do not belong to a single business object or process. Such operations play a supporting role. They can be grouped into those that support objects and those that support processes. Services can be modeled as stateless session beans or message-driven beans. Stateless session beans model synchronous services, while message-driven beans model asynchronous services.

Synchronous services are used when further processing depends on the result of the deployment of the service. If the result plays no role or does not influence the further execution of a process (that is, the result can be accessed at a later time), then the service can be asynchronous. The use of asynchronous services can improve performance if the processing of the service can take place on another computer or processor while the original process continues running in parallel. Asynchronous services can also be used to launch processes asynchronously or to execute processes in parallel. In such a case a message-driven bean, as opposed to a (stateful) session bean, takes the role of the EJB client. The message-driven bean is provided all the relevant information, via a message, that is needed for the launching and execution of the process.

The following two examples should serve to clarify the mapping of business processes onto objects, processes, and services.

Example: Bookkeeping System

The (stateful) session bean Booking shown in Figure 9-3 contains the logic for implementing double-entry bookkeeping.

Figure 9-3: Example— accounting system.

It can force the order of execution of the individual steps (for example, by triggering an exception in the case of a violation of the preset order) and thus ensure an orderly execution of the process. The method setDebitAccount() initializes a new accounting entry process and checks with a findByPrimaryKey call whether an account exists for the given account number. At the same time, the session bean obtains a reference to an entity bean to be able later to make the entry in this account. The same holds for setCreditAccount(). With a call to setAmount() the session bean can check various conditions, for example, whether an account has been overdrawn. A call to book() will open a transaction context, which includes the participating accounts, and will execute the entry using setBalance(). An account will be represented by an entity bean according to the above implementations, since an account is an object with a persistent state. The components offer an interface by which the state of the account can be modified.

The process for a double entry can be used by every client via a (stateful) session bean. The logic is available in a central location for the entire system. Furthermore, the client communicates exclusively via the session bean. To make the entry it is not necessary to communicate directly with entity beans. In this case the session bean would support the remote client view, while the entity bean supports the local client view.

A minimal requirement of such a primitive bookkeeping system is the keeping of an accounts journal, in which all entries are recorded and with whose help all accounting processes can be checked and reconstructed. The recording of the individual entries is of particular importance if entries must be able to be canceled at a later time. The accounting journal consists of individual entries. An entry consists at least of a unique entry number, the debit and credit accounts, the entry amount, entry date, time of the entry, and the user that made the entry. The addition of a journal entry and querying of information from the journal is not a process, but a stateless concatenation of individual operations. The accounting journal is not classifiable as a typical business object. Since the accounting journal can grow very large, the modeling as an entity is critical from the standpoint of performance. The accounting journal is in our sense to be seen as a classical example of a service, which offers the logging of accounting procedures and inquiry into the state of the data arising from such logging.

The message-driven bean JournalEntry and the (stateless) session bean JournalService (see Figure 9-4) represent the interface to the accounting journal. In our example the accounting journal is stored in a database. It would also be possible to store it in an archive system. Writing a journal entry is an asynchronous service that can be executed by sending a message to the JournalEntry bean. An asynchronous service has the advantage that the bean Booking does not have to wait until the data have been stored. During the writing of a journal entry the call returns to the client. The bean Booking does not expect a result from this procedure. The Java message service takes care of the requisite data security. To locate data in the accounting journal an asynchronous service is employed in the form of a JournalService bean. For locating data a limited number of methods with fixed functionality can be specified (as shown in Figure 9-4), although one might also consider developing a primitive query language. For extensive and lengthy data searches an asynchronous service could also be employed. After the client has started the search, it could continue with other actions. The result of the search would then be delivered later, for example, by the Java message service or by e-mail.

Figure 9-4: Example— accounting procedure with extensions.

Example: Production Monitor

The (stateful) session bean Productionmonitor depicted in Figure 9-5 contains the logic for monitoring a production process of a product that is produced by a single machine.

Figure 9-5: Example— production monitor.

In this example the client is an existing machine that can produce the product and that is directly linked into the system (for example, via a Java or CORBA interface). Into the process are brought the business objects Machine (the logical representation of the machine in the system), Product (which is produced by the machine, also in the form of a logical representation), and Productionorder (which relates to the product and specifies in detail the number of items to be produced, in what time period, and on what machine).

For example, through a service a (real) machine obtains all production orders, which were assigned by an optimization process. Thus the machine knows what product is to be produced and in what quantity. Each production order is processed by the (real) machine using the session bean Productionmonitor. The session bean can then check by calling the method start() whether in its production order the (real) machine corresponds to the associated (logical) machine. In the course of the production process checkpoints are set by the (real) machine via setCheckpoint (for example, a checkpoint can be set after each process step, after the completion of a piece, or after the completion of a particular job lot). The session bean compares the set checkpoint with the list of checkpoints required by the procuct P₁ (Product.giveCheckpoints()). The prescribed checkpoints arise from the technical specification of the product and are built into the system or the machine configuration by technicians. For the case in which the checkpoints fail to correspond or other irregularities arise (which can be reported by the real machine via reportError()), the session bean can set corresponding reporting mechanisms in motion (for example, a technician can be summoned by a pager). After the requisite number of pieces have been processed, the production order is reported as complete. Thus the progress of the entire production process can be monitored.

Not every situation of a given business domain can define processes (which can be modeled by stateful session beans), business objects (modeled by entity beans), or services (modeled by stateless session beans or message-driven beans). Nor is every entity bean automatically a business object, a stateful session bean a process, or a stateless session bean or message-driven bean a service. The mapping of a problem to the domain of Enterprise JavaBeans is nonetheless easier if in the analysis of the problem one always keeps in mind the semantics of these three entities.