Application Architecture for Applications Built on BEA WebLogic Platform? 8.1

Application Architecture for Applications Built on BEA WebLogic Platform™ 8.1
byBob Hensle
02/14/2005
Abstract
This 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.
Introduction
A common way to describe software application architecture is by using the 4+1 View Model. The five views of this model are:
Development View (aka "Implementation View") Physical View (aka "Deployment View") Process View (aka "Concurrency View") Logical View (aka "Design View") Use Case View (aka "Requirements View," which is the "+1" of the "4+1")
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 View
The following diagram presents the Development View (aka Implementation View) of an application built on the WebLogic Platform:

Figure 1. Development View of a generic WebLogic Platform application
In the Development View, the application architecture is divided into four layers:
Presentation and Interface Business Process Business Logic Data Access and Integration
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 communication
An 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 SOA
Components 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 Layer
The 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:
Platform and language independence Interoperability with other web service architectures Callback support Easy-to-use asynchronous and conversation semantics Support for SOA Less rigid interface due to an XML (not binary) interface More easily supports a document-centric interface
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:
Display - The display component in Figure 1 is actually a catch-all for a variety of constructs within WebLogic Portal that controls how the browser displays the portal. These constructs include look and feel, skins, themes, layouts, shells, and so on. These are generally not architecturally significant but can have a dramatic effect on the user experience. These constructs of WebLogic Portal provide an easily modifiable yet extremely flexible mechanism to create the desired user experience for a portal application.
ebXML - The ebXML component implements the Message Service Handler (MSH) from the ebXML specification. This provides the interface for B2B interaction with partner companies that wish to communicate using the ebXML protocols. The actual partner interaction is driven by process definitions in the Business Process layer.
HTML - HTML pages are used within the architecture to provide static content. HTML pages can be standalone or can be part of a page flow. It is recommended that any page navigation be abstracted out of the HTML pages and put into the JPF (Controller) file of the page flow that includes the HTML page. HTML pages may be used in a portal interface or a web interface.
Image - Images provide static content within a page. Large images or too many images on a page can degrade performance. Images may be part of a portal interface or part of a web interface.
Java Server Page - Java server pages (JSPs) are used within the architecture to provide dynamic content on a page. There should be little or no Java code within a JSP; tag libraries (for example, netui, content, es) should be used instead. Any Java code in the JSP should be used for data access and data display. At no time should Java code in the JSP provide business logic. Page navigation should also not be in the JSP; rather, it should be abstracted out into the JPF (Controller) file of the page flow that includes JSP. JSPs may be used in a portal interface or a web interface.
Page Flow - A page flow typically consists of a JPF (or Controller) file and a collection of JSPs. The JPF file provides page navigation within a portal interface or a web interface. It typically also contains the Java code that ties the user interface to the rest of the architecture. Java controls are generally the mechanism used within a JPF file to access other layers of the architecture. For large web applications it is desirable to create multiple page flows instead of trying to develop and maintain one large page flow. In this situation a page flow would represent a functional area within a larger application.
BEA has open sourced page flows at the Apache Software Foundation, making it available for all Java development, not just for WebLogic-based development.
Portal - The portal component is a powerful framework that allows the creation of portal interfaces independently of the application logic or web pages. A portal lets users view each application or web page in its own window, called a portlet, and a single browser window can contain multiple portlets. For a large portal it may be desirable to divide the portal into smaller pieces that can be developed in parallel. This is supported by using .pinc and .portion files.
Portlet - A portlet is a portion of a portal. A portlet may contain HTML, JSP, web flow, page flows, Struts, .pinc, JSR 168 portlet, or WSRP proxy portlet. The portlet is effectively where the application work gets done inside a portal. Each portlet within a portal loads its information by default sequentially or, optionally, in parallel. However, the portal page cannot display until all portlets have finished loading. Therefore, it may be necessary for some portlets to provide an asynchronous loading mechanism so that one portlet does not cause the whole portal to display too slowly.
RosettaNet - The RosettaNet component provides the interface for B2B interactions with partner companies that wish to communicate using the RosettaNet protocol. The RosettaNet PIPs are implemented as process definitions in the Business Process layer.
Servlet - Historically servlets have been used as the Controller in the Model-View-Controller pattern for web applications (seeUnderstanding JavaServer Pages Model 2 architecture). Page flows, in particular the JPF files, provide this capability within the WebLogic Platform; therefore, servlets should be rarely used.
Style Sheet - Cascading style sheets are used to create a consistent style for a web application. For a portal application the display component includes style sheets. However, style sheets are applicable to non-portal interfaces as well and are therefore separate from the display component.
Web service - A Web service exposes a programmatic interface into the application. The interface is defined in a Java Web service (JWS) file and is exposed to clients via WSDL. The JWS file should only contain data validation and translation logic. All business logic should be delegated to the lower layers in the architecture. For a conversational Web service, the JWS file can contain state information in local variables. The variables need to be serializable so that the conversation state can be stored.
BEA has open sourced the Web service framework at the Apache Software Foundation, making it available for all Java development, not just for WebLogic-based development.
Pages: 1,2,3
Next Page »
_xyz