AbstractThis article provides architecture and application best practices for software applications built using the BEA WebLogic Platform 8.1. The technologies discussed include WebLogic Server, WebLogic Portal, WebLogic Integration, WebLogic Workshop, and Liquid Data for WebLogic. This article is intended for enterprise architects and application architects and uses the 4+1 View Model to describe the architecture of an application built with the WebLogic Platform 8.1. IntroductionA common way to describe software application architecture is by using the 4+1 View Model. The five views of this model are:
The 4+1 View Model is typically used to describe a particular software application. In this document the 4+1 View Model is used to describe the sound software architecture of any application built on the BEA WebLogic Platform. Specifically, the model outlines typical WebLogic Platform components as well as best practices associated with each view. Because of the breadth of the products and capabilities covered here, no individual product will be covered in much depth. Rather, the goal is to illustrate how the whole platform is used to construct a maintainable, architecturally sound software application. This article does not describe a particular software application, so no use cases are specified. For this reason the Use Case View has been omitted. Similarly, since there are no use case realizations to be detailed in the Logical View, the Logical View has been omitted. The views are presented in an order intended to facilitate the reader‘s understanding of how to build a system using the BEA WebLogic Platform. Therefore, the order differs from what is generally done when specifying the architecture for a particular application. However, each view is presented in a self-contained fashion, allowing the reader to read the views in any order desired. This article is not an introduction to the products, a tutorial for the products, or a description of the features, functionality, or internal workings of the products. Additional articles are suggested at the end of this article. The reader should be familiar with the 4+1 View Model, object-oriented analysis and design, and J2EE, and have a working knowledge of the Unified Modeling Language (UML). Development ViewThe following diagram presents the Development View (aka Implementation View) of an application built on the WebLogic Platform:
In the Development View, the application architecture is divided into four layers:
Each of these layers provides a specific set of functionality to the overall application architecture. Dividing and modularizing the components of the application according to these layers results in a more maintainable system. For large applications it also allows development teams to be divided and assigned to particular layers with well-defined interactions between the layers. Not all the layers will necessarily exist in an application. At one end of the application spectrum, a simple CRUD (create, read, update, delete) application might only have the Presentationand Interface and Data Access and Integration layers. This simple application would not contain any business logic or provide interfaces to other systems. It is essentially a two-tier Web application. The other end of the application spectrum is a process portal, which includes a personalized interface, enforcement of business processes, complex business logic, and access to a variety of backend systems (for example, CRM, SCM, and ERP). Inter-layer communicationAn application should be constructed so that any component only accesses components within its layer or any lower layer. Exceptions to this constraint should be very rare and well justified. Components are allowed to access lower layers that are not adjacent. For example, a component in the Presentation and Interface layer may access a component in the Business Logic layer directly without using any component in the Business Process layer. However, it is important to remember that the layers exist for a reason and should not be bypassed arbitrarily. The WebLogic Platform includes a callback mechanism that at first sight may seem to violate the restriction of lower layers accessing higher layers. For example, a web service, a component of the Presentation layer, can receive a callback from a custom Java control, a component of the lower Business Logic layer. However, callbacks are a response channel set up by a higher level component for a lower layer component it invokes. The higher layer component "invites" callbacks and explicitly provides handlers for the callbacks it receives. Therefore, callbacks adhere to the inter-layer communication rules and, in fact, provide a simple mechanism for asynchronous communication between components. Layering and SOAComponents of the Business Processes and Business Logic layers can be exposed in the Presentation and Integration layer through programmatic interfaces. Exposing a programmatic interface allows the application to participate as a supplier in a Services Oriented Architecture (SOA). The Data Access and Integration layer allows this application to consume services provided by other systems in an SOA. In other words, this application architecture facilitates a true SOA where business logic and business processes can be shared between applications, thereby facilitating composite application construction via Service Oriented Development of Applications (SODA). The following sections will discuss the various layers in the Development View and provide a short overview of the components in each layer. Presentation and Interface LayerThe Presentation and Interface layer is responsible for providing the interface to the application. This might be in the form of a browser interface for a web or portal application or a programmatic interface for a rich client or another system. The browser interface runs remotely and accesses the application via HTTP or secure HTTP, while the programmatic interface may use HTTP, SOAP, RMI, RMI/IIOP, ebXML, or RossettaNet. A web interface provides the simplest user interface into the application. The web browser client application is the platform that hosts the user interface for all web applications. Content displayed in the browser is mostly static, except for client-side processing driven by JavaScript. Client-side processing is usually leveraged to do light initial data validation or to visually enhance the user interface. A portal interface gives users a single point of access to applications and information in a unified interface. A portal interface can provide customized content and applications to multiple audiences with reusable portal resources. A portal interface also allows large amounts of data to be organized and accessed easily. This makes a portal interface ideal for business-to-consumer (B2C) and business-to-employee (B2E) applications. A programmatic interface allows other applications to access data, business processes, and business logic of this application. Careful thought should be given when designing a programmatic interface because the interface is a public contract between this application and the client application(s). Any change to the interface will most likely have significant impact on the client applications. Therefore, the interface should be designed to abstract the underlying implementation and thereby allow this application to change without requiring the client applications to change. The WebLogic Platform supports HTTP(S), SOAP (that is, web services), RMI, RMI/IIOP, ebXML, and RossetaNet. For business-to-business (B2B) applications ebXML and RossetaNet are natural choices and will generally be dictated by the requirements of the application being built. The choice of SOAP versus RMI/IIOP is not as clear cut. In general, a SOAP interface is preferred over RMI or RMI/IIOP. The advantages of a SOAP interface are:
The one advantage that RMI or RMI/IIOP has is in raw performance. The parsing of SOAP messages creates extra computational overhead not present for the binary protocols. Therefore, if performance is the primary requirement then RMI or RMI/IIOP is the better choice. The following list describes each of the components shown in the Presentation and Interface layer, the component‘s interaction with the rest of the application, and any design considerations associated with the component:
|
|
|
