Understanding the Structure of Business Objects

Designing business objects in Java, you rely heavily on the JavaBean patterns to represent interfaces relating to data. The JavaBean patterns encompass several standards, including method signature patterns and patterns for observing state changes within a bean. Typically, as is the case in this chapter, relying on JavaBean patterns refers to the method signature patterns inherent in JavaBeans. The method signature patterns, in short, include the concept of a property that is simply a piece of data or calculated data. A property contains accessor methods, get methods, and set methods ( otherwise known as mutators ). Properties of type boolean can use an is prefix for the accessor methods.

Listing 6-1 shows an example of the JavaBean patterns in practice. In the listing you see two attributes, test and debug , each with their associated method accessors. The debug property is a read-only property; thus there is an accessor with no mutator. If debug was a read/write property, you would add a setDebug(boolean inDebug) method to the class.

Listing 6-1: JavaBean Example Class
start example
 public class JavaBeanExample {    private String test = null;    private boolean debug = true;    public String getTest() {       return this.test;    }    public void setText(String inTest) {       this.test = inTest;    }    public boolean isDebug() {       return this.debug;    } } 
end example

The choice of JavaBeans heavily influences the structure and representation of a Web Service that represents a business object. There are two primary reasons for relying on JavaBeans in business objects:

  • Using the predictable JavaBean patterns simplifies the generation of architecture adapters for tools that enable Web Services.

  • Java object/relational mechanisms often rely on the JavaBean patterns ” again, for their predictability ”when generating the persistence mappings.

Using the JavaBean patterns applies to the service implementation interface itself and the complex properties that the service implementation surfaces. Figure 6-1 illustrates a simple, generic pattern for designing business objects implemented in Java.

click to expand
Figure 6-1: Generic pattern for business objects

Using JavaBeans, it is possible to build a rich business object domain by nesting the complex data types. Interestingly, this is in direct conflict with the flat nature of Web Services. Because the Web Service architecture derives many of its attributes from a component-oriented architecture, the focus is on loose coupling of components , not on the ability to create a versatile and flexible object paradigm. Often, loose coupling goes against the nature of rich object-oriented structures. The pattern in Figure 6-1 is purely generic in nature, but you should understand the potential richness of the structure. Not pictured in Figure 6-1 is the potential for inheritance in an object-oriented paradigm. Because inheritance does not translate at all to many programming platforms, it makes sense to leave inheritance out of the generic pattern. On the other hand, rich data structures, such as the one portrayed in Figure 6-1, do typically translate to other programming platforms, thus its inclusion in the diagram.

Understanding the Business Object Structure

There are two primary components of a business object structure: the BusinessObject and the ComplexData structure:

BusinessObject: This is a representation of a top-level business concept, such as a sales order, customer, or product. The business object surfaces only properties or, in more complex business objects, operations against multiple properties. Properties can represent primitive data, such as a string, integer, or boolean value. You also treat complex data, described next , as a property on the business object.

ComplexData: You can think of complex data as a subcomponent of a top-level business concept that is more complex than a primitive type of data. For example, a primitive type may be the last name of a person represented as a string, whereas the address a person resides at is a complex data type. In this case, the complex data type gets built from multiple primitive data types and is a separate concept from the primary business object of a person. Complex data can contain additional complex data types, such as the case of a company containing employees who, themselves , have addresses.

This chapter does not cover the components that act on the business object. Occasionally the actors are part of a pattern, but in this case, the actors are irrelevant.

The structure of the business object is relatively straightforward. The number of properties and complex data types that a business object contains can vary greatly. The important part of the design of business objects is not the number of properties but that the properties on a business object all belong together. In other words, the business object must be highly cohesive.

Understanding Collaborations with a Business Object

Clients of a business object expect to be able to retrieve and change data residing in the business object. The business object also, typically, gates access to the complex data contained within it. Figure 6-2 illustrates a scenario where an application first retrieves some complex data and then changes a property on the complex data. In most business object scenarios, the client changed a local copy of the complex data, not the real instance of the complex data. The application must submit the change back to the business object to change the business object's copy of the data.

click to expand
Figure 6-2: Retrieving and changing complex data in a business object

The key interaction between the business object and application, the call to the getComplexData() method, returns a copy of the complex data to the client application. This allows the business object to retain ownership of the data but, in turn , forces a second interaction with the business object to change the data owned by the business object.

Web Service Patterns
Web Services Patterns: Java Edition
ISBN: 1590590848
EAN: 2147483647
Year: 2003
Pages: 190

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net