Chapter 5: Building the Business Logic with WebSphere Studio

 Download CD Content

Overview

Chapter 2 advanced the argument for a componentized approach in creating the elements that compose an application. Dividing these elements into the essential categories of presentation, business, and data logic promotes a modularity that can increase the flexibility of the distribution of the application elements; can facilitate independent development of different element categories by different people, departments, or organizations; and can additionally provide new opportunities for logic reuse.

Business logic, generally speaking, is the set of procedures or methods used to perform a specific business function. Applying an object-oriented approach enables the developer to decompose a business function into a set of logical elements or components called business objects . Like other objects, business objects have both state and behavior. For example, a customer object has data such as a customer ID, name , address, telephone number, and so on. It has methods for changing the address, or updating lifetime purchases in dollars. To manage a business problem you must be able to represent how such business objects function and interact to provide the desired functionality. The set of methods, business-specific rules, and pre- and post-conditions that must be met as an object exposes its function to the other objects in the system, are known collectively as business logic .

The J2EE architecture specifies a component model for each of the major tiers in the application landscape. In the previous chapter, we took a close look at the use of the web component model in building the presentation logic. In this chapter we will use the Enterprise JavaBean (EJB) component model to build up the business logic for our sample application, Plants-By-WebSphere.

The EJB component model is a good choice for building business logic for several reasons:

• It includes stateless, stateful, and persistent models.
  This means we have flexibility in choosing the component type that best fits our needs. Stateless EJBs are excellent for organizing into reusable packages business logic that maintains no state of its own. Stateful EJBs satisfy the need for business logic to hold state that is more or less temporary, valid for only minutes, hours, or days. Persistent EJBs are well-suited to model artifacts in the business domain that have state, are long-lived, and have associated business logic.

• It is insulated from the presentation and logic tiers.
  EJBs do not imply your choice for the other tiers in the computing models, increasing their flexibility. EJBs can be driven by presentation tiers on the same system as the EJBs themselves or on a different system. The stateful and persistent EJB models take many of the database programming issues out of the hands of the business logic developers, freeing them to focus on solving problems from their business domain.

• It offers powerful declarative transaction and security policy.
  These and other services are provided by the EJB container, further simplifying the task of creating reusable business components by removing the need for business logic developers to spend time building these capabilities into their components. Moreover, since these services are declarative, they can be adjusted for use in different applications without necessarily changing the component implementation. This further increases component flexibility and reusability.

In the remainder of this chapter, we will focus on using WebSphere Studio Application Developer to build and test the business logic for our Plants-By-WebSphere application. The task ahead of us is to understand the design requirements for the business logic of our application, implement that design using EJBs, and then integrate our EJBs with the web presentation logic that we created in Chapter 4.