Application Architecture for Applications Built on BEA WebLogic Platform 8.1
Pages: 1, 2, 3

Business Process Layer

The Business Process layer depicted in Figure 1 is responsible for providing Business Process Management (BPM). Business processes are created as a process definition or a combination of process definitions. The business process may be a completely automated process, or it may be a process that includes human interaction with the system. When humans are involved in the business process the worklist control is used to provide the interface points into the process definition.

The Business Process layer is not concerned with the presentation or the interface to either systems or humans. Instead, the Presentation & Interface layer is responsible for presenting the user interface for all business processes whether automated (and the interface is a programmatic one) or interacting with humans. The code developed in the Business Process layer should be devoid of any presentation or interface logic.

The following sections describe each of the components shown in the Business Process layer, the component's interaction with the rest of the application, and any design considerations associated with the component.

Process Definition

The process definition component is used to capture business processes and as such is the heart of the Business Process layer. Process definitions should encapsulate a particular process and should not be used as a substitute for writing business logic in Java. Essentially, the idea is that process definitions tie together and orchestrate the interaction between individual business logic components.

In many applications there are lower-level processes that are common to several higher-level processes. Similarly, a process definition component can model the higher-level process, in turn invoking other process definitions that model lower-level processes. When doing the use case analysis for an application, the use cases that are included in other use cases are prime candidates for these types of reusable process definitions.

Process definitions can be started either via a client request (that is, synchronously) or via a message arriving from the message broker (that is, asynchronously). Process definitions started by a client request should respond back to the client in minimal time since the client is blocked waiting for a response. If the request will take a long or unknown amount of time, the process definition should respond back to the client with a "processing" message and handle the request asynchronously. This is where callbacks can be especially useful.

Process definitions are described in Java Process Definition (JPD) files. WebLogic Workshop provides a graphical view of a JPD file. Developers can optionally add Java code to the .jpd file that is used within the process definition. This code should be kept to a minimum since the code is not reusable, as it is only available to that process definition. Code that is valuable to a wider audience than one process definition should be put in a separate Java class, an EJB, or a custom Java control.

Process Control

The process control is used to access a process definition. This control might be used within a variety of other components including a page flow, a web service, another process definition, or a custom control. A process control is a JCX file and can be autogenerated from a process definition (JPD) file in WebLogic Workshop.

Worklist Control

The Worklist control allows process definitions to be used in business processes that include human actions. The Worklist control allows the process definition to assign tasks to users and have the user notify the process definition when a task has been completed. The two types of Worklist controls are the task control and the task worker control.

Publish Control

The publish control allows a process definition to publish a message to a channel on the message broker. This allows a process definition to send a message to another process definition, which could either start the latter process definition or cause it to resume processing at the point that it stopped to wait for this message. This is the primary mechanism that applications use to initiate asynchronous processing for business processes.

Subscribe Control

The subscribe control allows a process definition to wait for a message from the message broker delivered on a particular channel. This is the primary mechanism by which asynchronous processing is initiated or continued.

Business Logic Layer

All business logic is implemented in the Business Logic layer shown in Figure 1. When processing a request a component in this layer validates the information in the request according to unique business rules, performs the requested business logic, and possibly makes calls to the Data Access & Integration layer to create, read, update, or delete the appropriate external entity. The most common external entity is a relational database.

The components within the Business Logic layer are called from either the Business Process layer or the Presentation & Interface layer. If called from the Business Process layer the component is being used as part of a process definition. This is how common business logic can be used across multiple business processes.

If the Business Logic layer component is called from the Presentation & Interface layer then the component is servicing a user request. This is the design pattern most commonly used within J2EE applications. However, frequently in J2EE applications the business process is hard coded in servlets or session beans. Extracting the business process into a process definition or page flow increases the flexibility and maintainability of the application.

The following sections describes each of the components shown in the Business Logic layer, the component's interaction with the rest of the application, and any design considerations associated with the component.

Custom Control

The custom control is a Java control that encapsulates reusable functionality. Custom controls are created by a Java control source (JCS) file and an associated Java file. A custom control can be used within an application or packaged so that it can be used in multiple applications. Therefore, a custom control is similar to an EJB. However, custom controls have several advantages over EJBs including:

  • Custom controls can use other Java controls
  • Custom controls can be extensible
  • Custom controls support asynchrony via callbacks

BEA has open sourced the custom control framework at the Apache Software Foundation, making it available for all Java development, not just for WebLogic-based development.

EJB Control

The EJB control is used to make calls to a session or entity bean. It takes care of all the initial context lookup, accessing the home interface, and so on, and lets the developer just call the methods on the EJB that performs the desired functionality.

Message Driven Bean

The Message Driven Bean (MDB) is used to process messages from a JMS topic or queue. MDBs can be readily developed and deployed using WebLogic Workshop. MDBs should not contain business logic but rather should accept messages from JMS, perform data validation and transformation as appropriate, and then call a Stateless Session Bean or other component that contains the reusable business logic.

Stateful Session Bean

The stateful session bean (SFSB) is used to provide stateful interactions with a client. SFSBs can be readily developed and deployed using WebLogic Workshop. In most cases, stateless session beans should be preferred over SFSBs whose use is limited to a few special situations.

Stateless Session Bean

The stateless session bean (SLSB) is used to encapsulate business logic. Unlike stateful session beans, SLFSs provide excellent scalability and performance. SLSBs can be readily developed and deployed using WebLogic Workshop.

Timer Control

The Timer control notifies an application when a specified period of time has elapsed or when a specified absolute time has been reached. The Timer control can be used to start business processes or to wait a particular amount of time for an event (for example, receipt of a response message) to occur.

Data Access & Integration Layer

The components in the Data Access & Integration layer send data to or receive data from Enterprise Information Systems (EIS) external to the application. The most common EIS are database management systems. This layer exists to encapsulate the complexity of communicating with the various EIS.

In today's enterprises, applications integrate to far more diverse EIS than just databases. Any number of external systems, from mainframes to proprietary legacy systems, can be targeted to send data to or receive data from the application. Web services, which leverage the Simple Object Access Protocol (SOAP), various messaging services supporting the Java Messaging Service (JMS), and the various implementations of the J2EE Connector Architecture (J2EE CA) specification are examples of integration transport components that can form the Data Access & Integration layer. Each of these components invokes APIs in the EIS to send or retrieve information.

The following list describes each of the components shown in the Data Access & Integration layer, the component's interaction with the rest of the application, and any design considerations associated with the component:

  • Application View - The application view component encapsulates a J2EE CA adapter and provides a level of abstraction between the application and the underlying EIS. The application view allows the developer to program to an interface appropriate for the application being developed and hides the complexity of the underlying EIS. It also allows the J2EE CA adapter to be changed without effecting any of the application code.

    J2EE CA adapters come in several varieties. Type 1 adapters are products available from BEA and support the most common EIS. Type 2 adapters (aka field-based adapters) support less common EIS and are available from the BEA field-based adapter group. Type 3 adapters are available from BEA partners. Custom J2EE adapters can always be constructed as part of an application development effort; however, it is recommended that type 1, 2, and 3 adapters be used unless there is a compelling reason to build a custom adapter.

  • Database Control - The database control is used to access data residing in a relational database. A database control can return data as a RowSet, XML, or Java objects. The database control provides an easier mechanism to access relational databases than coding JDBC code or using entity beans.

    BEA has open sourced the database control framework at the Apache Software Foundation, making it available for all Java development, not just for WebLogic-based development.

  • Email Control - The Email control is used to send an email. The Email control allows the usual email fields (for example, to, cc, bcc, subject) including attachments.

  • Entity Bean - Entity beans provide the object-to-relational mapping necessary to bridge the object-oriented world of J2EE with the relational world of databases. Entity beans also provide a powerful caching mechanism for read mostly or read only data. Entity beans can be readily developed and deployed using WebLogic Workshop.

    In general, Container Managed Persistence (CMP) entity beans should be preferred over Bean Managed Persistence entity beans whenever possible, as using CMP entity beans removes the burden of developing JDBC code from the developer.

  • File Control - The file control is used to read, write, or append to a file residing in a file system. Files can be one of the following types: XmlObject, Binary (raw data), or String. In addition, the file control supports file operations such as copy, rename, and delete. The file control can also be used to list the files stored in the specified directory.

  • JMS Control - The JMS control is used to send messages to or retrieve messages from a JMS destination. Messaging systems (for example, MQSeries, Tibco) are frequently used to access legacy systems. This control provides an easy mechanism to interface with these messaging systems and hence the legacy system.

  • Liquid Data Control - The liquid data control is used to access data supplied by Liquid Data for WebLogic. This control provides an easy mechanism to incorporate the data from a variety of EIS that is fetched and aggregated by Liquid Data for WebLogic.

    Liquid Data is a simple-to-use yet powerful tool for creating EIS spanning data queries and data aggregation. Custom code should not be written to aggregate data from multiple backend data sources. Liquid Data can do that easily and additionally provides configurable caching of the resulting aggregated data.

  • TPM Control - The Trading Partner Management (TPM) control provides query (read-only) access to trading partner and service information stored in the TPM repository. This would be used, for example, as part of an ebXML B2B Process Definition.

  • Transformation Control - The Transformation control is used to perform data transformations. The transformations can be binary-to-XML, XML-to-binary, or XML-to-XML. Therefore, transformations to and from virtually any format are readily defined and used within Workshop. The XML-to-XML transformations use the power of XQuery for transformations, which is more flexible and dramatically faster than using XSLT.

  • Web service Control - The Web service control is used to access Web services. Any Web service for which a Web service Description Language (WSDL) file is available can be accessed via this control.

    BEA has open sourced the custom control framework at the Apache Software Foundation, making it available for all Java development, not just for WebLogic-based development.

  • XMLBeans - XMLBeans provides a developer-friendly interface to XML. XMLBeans are created by importing an XML schema into the schema directory of a Workshop application. Workshop automatically generates the appropriate Java classes that can then be used within the Workshop development environment.

    XMLBeans is far easier to use than JAXB, DOM, or SAX. XMLBeans is based on an efficient XML token stream that provides easy navigation of XML data using cursors. XMLBeans preserves the structure and richness of the original, native XML. BEA has open sourced XMLBeans at the Apache Software Foundation, making it available for all Java development, not just for WebLogic-based development.

Database Access Options

J2EE provides several mechanisms to access relational databases including JDBC, entity beans, and Java Data Objects (JDO). In addition to these mechanisms, the BEA WebLogic Platform adds database controls and Liquid Data.

Many J2EE applications have been written using the Data Access Object design pattern. In this pattern the developers are required to write all the database access code using JDBC. The Data Access Object design pattern can be constructed much more easily and rapidly using the database control. Database controls allow the developer to specify the SQL yet removes the burden of writing all the tedious JDBC code.

In many cases the Data Access Object design pattern was used instead of entity beans due to the shortcomings of the EJB 1.1 specification. The EJB 2.0 specification has removed the major problems associated with EJB 1.1 entity beans by providing local interfaces and robust CMP. Therefore, if there is a need (or desire) to provide an object oriented persistence layer that hides the underlying relational schema, then entity beans with CMP should be used. This moves the object-to-relational mapping out of the Java code and into the deployment descriptor.

In many applications there is no compelling need to construct an object model that hides the underlying relational schema. These types of applications generally used straight JDBC in many cases directly from a servlet. For the WebLogic Platform, database controls are the recommended approach for these types of applications. Database controls can return the results from a SQL select as a result set, Java object(s), or as XML. Database controls combined with the page flow and data binding JSP tags makes Rapid Application Development (RAD) a reality.

Liquid Data is radically different from the other database access options. Liquid Data does not provide write access to the data sources. It is specifically designed to aggregate data from a variety of data sources (database, file, J2EE CA, Web service, and so on) and return the aggregate data as an XML document. If the desire is to aggregate data from a single database, use a database control (with SQL joins) and return the result as XML. However, if the data to be aggregated exists in two or more data sources, then Liquid Data is the appropriate technology to use.

This concludes the discussion of the various layers discerned in the Development View. The next section will discuss the Physical View of the 4+1 View Model.

Pages: 1, 2, 3

Next Page ยป