Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article



In recent years, Web portals have risen in popularity as a way of aggregating, organizing, and presenting content in a highly uniform, customizable, and personalized way.

As the technologies that enable the creation and management of these Web portals have evolved, it is not only information content that is being offered, but application functionality as well. With application functionality making its way to the Web portal, a whole new dilemma arises as developers attempt to adapt their application functionality to the characteristics and behavior of the Web portal.

Portal Concepts
In the simplest terms, a portal is a Web site that provides content and application functionality in a way that is both useful and meaningful to the end user. It also serves some purpose from the portal provider's perspective, whether it is a public portal trying to attract Web traffic to a site or an enterprise desiring to provide a central location for employees to obtain company information. Portals have evolved to enable the ability not only to provide a unified look and feel to the entire site, but to apply personalization and customization to the content. In this way, a person who accesses a portal and logs in with a predefined user name and password can customize not only what portal content is displayed for them, but how that content is displayed.

Most portals and portal frameworks contain the concept of a "portlet" as a window to a specific set of content within the overall context of the portal page. Portlets generally support the ability to customize the information displayed within this window. From the perspective of the portal framework, portlets tend to look and behave much the same as individual windows running in any windows-based operating system. They can be minimized, maximized, and rearranged to suit the individual portal user. From the developer perspective, a portlet is really a piece of code that plugs into a generalized framework. Different portal frameworks implement the concept of a portlet differently. In some cases, the portlet is a collection of JSP pages. In other cases, a special type of class may implement certain interfaces. Regardless of how it is implemented, the portlet is generally responsible for presenting a specific set of content that may be tailored to a user's preferences. The portal framework handles the infrastructure services, such as providing the overall presentation of the selected portlets, user management, security, and personalization.

A Developer's Approach
When you think about adapting an existing application, it's important to understand that typical Web applications don't necessarily map easily to a portal paradigm. This is especially true for Web applications with multipage interactions, and is due to the fundamental difference in navigation behavior inside a portlet as compared to a traditional Web application or Web page. In a traditional Web page, a user would typically select a link on the page presented in the browser, which would lead to another HTTP request returning a completely new page of content. By contrast, the goal of a portlet within a portal is more to present to the user the impression that the contents of only that one portlet are changing. This presents a distinct challenge to developers who typically have designed their Web application navigation as a set of URL links that invoke JSPs, Java servlets, or even static HTML pages. Now they must think about how to specify navigation, not in the context of the Web application, but from the perspective of the overall portal.

In order to present to the user the appearance that only the portlet they are interacting with is changing, it is necessary to use functionality that allows the portal framework to intercept the result of URL invocations and redirect them to the portlet making the invocation. In BEA WebLogic Portal, a mechanism called Webflow can be used to define the flow of events that take place between components of the Web application. These Webflows effectively take the place of actual URLs in the execution of the various actions within the application. What follows is an example of how we adapted a Web application called "QuizGame" into an existing portal domain running on BEA WebLogic Portal.

The QuizGame application is a demo Web application built using a combination of a single controller servlet, a number of Enterprise JavaBeans, and a single JavaServer Page for handling the generation of the presentation. Figure 1 represents the architecture of this application.

In order to adapt the QuizGame Web application to WebLogic Portal, three key steps need to take place.

1.   The Web application components must be added to the portal Web application.
This includes the EJBs and WAR file containing the controller servlet and other helper classes used by the Web application. In WebLogic Portal, the portal itself is implemented as a sophisticated Web application. Within the portal Web application, a subdirectory is defined where the different portlets are stored. The portlets are typically JSPs connected together through the definition of Webflow events. Any servlets and helper classes should be stored in the typical Java Webapp structure with exploded individual classes stored under the "classes" directory and classes packaged in JAR files stored under the "lib" directory. In addition, servlets and the components they reference must be registered with the Web application by adding them to the Web.xml file. Once the portlet is created in the next step, the JSP files should be stored in the portlet-specific directory. These files will be adapted in the final step.

2.   A new portlet must be created and added to the existing portal domain E-Business Control Center (EBCC).
This portlet will contain the pages representing the view for the Web application being added. Once the portlet itself is created, a Webflow needs to be defined to represent the interactions between the various components of the presentation. The events defined within this Webflow will replace the actual URLs previously defined in the QuizGame application. Figure 2 shows an example of the Webflow created in the EBCC.

Figure 2 shows two kinds of elements. Presentation nodes represent various kinds of presentation components, such as static HTML pages, Java servlets, or JSPs. These presentation nodes can have a user-friendly name, but must reference the actual component or page. The Webflow events are shown as arrows and represent invocations between the various presentation components. These events can be given user-defined names.

3.   The URLs defined in the original Web application must be replaced with a special URL built from the Webflow events defined in the EBCC.
Due to how the QuizGame application was built, the URLs were largely contained in the output JSP. Changing these URLs in the JSP files is an easy task due to the availability of a helper TagLib. Listings 1 and 2 show how to replace a URL invocation to the DemoControllerServlet with the equivalent Webflow invocation to the same servlet. Listing 1 shows a traditional form with a URL invocation to the DemoControllerServlet as the action. Listing 2 shows the use of the event "QGControllerServlet.event" to represent the same request using a Webflow event. This was one of the events defined between the Index_html presentation node and the DemoControllerServlet presentation node in the EBCC Webflow designer tool.

These three steps will enable the application to run within the overall portal and behave correctly throughout the execution of the application. This is accomplished without significantly changing the look or actual behavior of the application. The main difference is that now the QuizGame application is simply one portlet window within the greater portal presentation.

Once the application has been successfully portalized, additional enhancements can be made, such as adding the ability to customize properties of the game through an edit page. This shouldn't be considered the end of the process, but simply the first step in integrating an application into the portal. BEA WebLogic Portal provides more sophisticated mechanisms for controlling the flow and behavior of the application through the use of pipeline components and processor components.

The use of these types of components can replace the need for the servlet and JSPs and enable better flow control and access to other portal features, such as security and personalization. At the same time, they still allow the ability to reuse the existing business logic components, such as EJBs.

Developing Portal-Ready Applications
Up to this point, this article has discussed portalization from the perspective of moving existing application functionality to a portal framework. If you are creating a new Web application, a number of techniques can be used to make the application more portal ready.

Tip 1: Use a Model-View-Control Architecture
The Model-View-Control (MVC) architecture is a way of grouping application functionality into three distinct categories, each serving a specific role in the overall application. The objective of using an architecture such as MVC is to allow the ability to isolate each of these functions so that it is possible to make changes to one component without significantly impacting the others. For example, a change may be made to the view aspect of an application without requiring any changes to either the model or the control modules.

This architecture provides a distinct advantage in portalization. MVC-based applications can be more easily adapted to a portal by simply making changes to the view and possibly the control code. Even if there is a certain business logic associated with the application, this can often be left untouched if it is not tightly woven into the view and control components. More specifically, an application can be adapted to the portal by first only changing the view. These changes are often superficial in order to adapt to a different form factor than may have been used for a browser. Then the control module can be modified or even replaced to suit the needs of navigation within the context of the portal.

Tip 2: Use XML to Represent Content
In Web applications, XML is often used as a client-neutral way of describing what will be presented. XML coupled with transformation technologies such as XSLT allows the ability to delay the decision of how to present the content until the last stages of processing. Delaying this decision allows you to tailor the presentation of the content in very client-specific ways.

In the context of adapting functionality to portals, this allows the ability to contain the definition of how the content is presented to a single mechanism, such as XSLT and the corresponding stylesheets. Doing this makes it easier to change the presentation and navigation parts of the application without significantly impacting other parts of the application. In order to use XML in this way, the code responsible for controlling the behavior and interaction should be made to return XML rather than presentation-specific content such as HTML.

The focus in defining the presentation should be defining the basic presentation constructs, such as tables, forms, fields, etc. The explicit definition of things like fonts and background and foreground colors can defeat the ability to personalize the portlet to the overall portal color schemes and font styles.

Tip 3: Prepare to Leverage the Portal Security Mechanisms
Portal security is a fairly complex topic and not within the scope of this article except as it may affect the individual applications being adapted to the portal. One key benefit of a portal is the ability to sign on once to enable access to the applications offered within that portal - often referred to as "single sign-on." For applications that will be hosted in the same middleware infrastructure as the portal framework, it is much easier to leverage the same security mechanisms. Many portals use a standard HTTP cookie to store session information. In order to enable the ability to have single sign-on, it is important that all applications share the same session information within the portal. The WebLogic Portal TagLib provides a number of helpful utility methods for assisting the portlet in obtaining and sharing session information from the portal Web application perspective.

Be careful in building a Web application not to define a unique security scheme. Rather, the Web application should leverage the existing infrastructure mechanisms as much as possible. For example, most J2EE-based application servers support a number of security mechanisms for propagating user authentication and authorization information to the various components. Typically, portals that are built on top of a J2EE application server will leverage these same mechanisms. For applications that aren't colocated with the portal framework, it's often necessary to build bridging interfaces that can map the portal-specific security mechanisms to those of the application being adapted to the portal.

This article discussed an approach for enabling an existing application to be adapted to a Web portal. In doing so, the goal has been to provide the necessary concepts and developer tips to enable a developer to plan for and ultimately perform the portalization. You should note that moving an existing Web application to a portal doesn't have to take place all at once. It can be a multiphase process. The first phase is to present the existing content or functionality from within the portal. Once this is accomplished, the application will need to be better integrated with the portal so that it can leverage the portal navigation, personalization, and security mechanisms. The final phase is to enhance the personalization capabilities of the application by providing an edit page for allowing users to predefine values, such as their player ID and whether they prefer to have their top scores show.

More Stories By Mark Secrist

Mark is a senior constultant for the HP Developer Resource Organization with 10+ years experience involving distributed object technologies and building n-tier, web-based applications. He currently consults with enterprise customers on J2EE & web services development. Mark also has published technical white
papers on J2EE, mobile and web services development.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

IoT & Smart Cities Stories
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-c...
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
The explosion of new web/cloud/IoT-based applications and the data they generate are transforming our world right before our eyes. In this rush to adopt these new technologies, organizations are often ignoring fundamental questions concerning who owns the data and failing to ask for permission to conduct invasive surveillance of their customers. Organizations that are not transparent about how their systems gather data telemetry without offering shared data ownership risk product rejection, regu...
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
Predicting the future has never been more challenging - not because of the lack of data but because of the flood of ungoverned and risk laden information. Microsoft states that 2.5 exabytes of data are created every day. Expectations and reliance on data are being pushed to the limits, as demands around hybrid options continue to grow.
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
Enterprises have taken advantage of IoT to achieve important revenue and cost advantages. What is less apparent is how incumbent enterprises operating at scale have, following success with IoT, built analytic, operations management and software development capabilities - ranging from autonomous vehicles to manageable robotics installations. They have embraced these capabilities as if they were Silicon Valley startups.
As IoT continues to increase momentum, so does the associated risk. Secure Device Lifecycle Management (DLM) is ranked as one of the most important technology areas of IoT. Driving this trend is the realization that secure support for IoT devices provides companies the ability to deliver high-quality, reliable, secure offerings faster, create new revenue streams, and reduce support costs, all while building a competitive advantage in their markets. In this session, we will use customer use cases...