IBM announced the acquisition of Bowstreet. Bowstreet provides portlet factory to jumpstart the portal development for IBM WPS and Oracle Portal server. It claimed productivity improvements to the tune of 40% for standard applications.

Bowstreet will help further IBM's strategy around service oriented architectures (SOA), a standards-based framework that enables enterprises to more effectively integrate data and applications with customers, partners and suppliers.

Bowstreet will enable customers to more easily combine a wide variety of pre-existing data and enterprise applications seamlessly with their WebSphere Portal environments and leverage the benefits of an SOA architecture.

Ever ran into problems of multiple portal servers installations and rapid deployment and not able to do so. Well, IBM has released series of scripts that allow you to create images of WAS and WPS installations and deploy on the same on other machines in a snap. Check out more details here.

WebSphere Portal expert Stefan Hepper answers questions on portal programming, JSR 168 portlet specification, and Java™ portlet development: why things are the way they are today, how to solve a specific problem, why feature XYZ is missing, or more general architectural and strategic questions.

Stefan answers to some of the commonly faced problems while designing solutions around WPS. Things like Portal Popups, accessing user information attributes, inter-portlet communication in JSR 168 portlets have been touched upon. Check the out the article here.

Filed in: WPS

Latest buzzword is Ajax. There has been a lot of talk going on the use of Ajax by Google Earth and GMail and how it improves the web site performance. I got started to look for some good articles on the same. I have found a good here.

Filed in: J2EE

Another article on designing and construct Portlets visually in UML using Rational Software Architect. The article talks about using newly released "State Oriented Portlet Patterns" while construction for WPS 5.1.

Filed in: WPS

IBM has released a lightweight J2EE application server built on Apache Geronimo open source technology is designed to help you accelerate your development and deployment efforts. It harnesses the latest innovation from the open source community to provide a readily accessible and flexible foundation for building Java applications.

The application server can be downloaded from here.

XPath is not traditionally considered a data binding API. It doesn't even get much attention in the XML world, except in passing as part of other specifications. But once you fully understand what XPath is and how to use it -- particularly in a Java™ programming environment -- it becomes a powerful data binding tool that's often preferable to traditional data binding APIs such as JAXB or JaxMe. Brett McLaughlin's Practical data binding column returns with the first in a two-article series that examines XPath as a data binding tool.
Part 1

This article gives an introduction to Global Business Object (GBO), an IBM alphaWorks technology that offers a set of Java™ libraries of culturally sensitive GUI elements for global applications. The article walks you through GBO's architecture and globalization features. The article also describes one GBO component in detail, illustrating how GBO can integrate with your Web-based apps.

When you develop a J2EE application, you often need to run some custom code during the application server startup to initialize the application. This custom code might load static data into memory, initialize data, or start another process. How do you achieve these tasks in WebSphere Application Server (WAS)? Check out my article published on WebSphere Advisor on the same here.

Learn how to create a Web service provider, including the deployment descriptors and the Java classes, and see a demonstration of the Java compiler, Java2WSDL, and WSDL2Java command-line tools.

Security consists of more than just some firewalls at the edge of your network protecting you from the outside. It is a difficult and complex set of actions and procedures that strive to strengthen your systems as much as is appropriate. These articles covers many aspects of security in general, details the IBM® WebSphere® Application Server security architecture, and discusses hardening a WebSphere Application Server environment. The article talks about the four squares that represent the type of attacks, the techniques presented in the article helps to prevent:

* N = Network-based
* M = Machine-based
* E = External application-based
* I = Internal application-based.

Part 1
Part 2

This guide steps through a detailed procedure for installing, configuring, and building an IBM® WebSphere® Portal V5.1.0.1 cluster using IBM WebSphere Application Server 6.0.0.2, Windows® 2000 Server, Oracle 9.2.0.4 Server and client, IBM Directory Server 5.1, and IBM HTTP Server 1.3.26.1. The approach described is applicable for any WebSphere Portal V5.1.x and any WebSphere Application Server 6.0.x release.

Filed in: WPS WAS

This article describes some best practices when using WebSphere MQ shared queues to provide continuous availability of messages. Topics include Coupling Facility list structure and queue size, queue depth, and data serialization.

Performance Harness for Java Message Service is a flexible and modular Java package for performance testing of JMS scenarios and providers. It provides a complete set of JMS functionality as well as many other features such as throttled operation (a fixed rate and/or number of messages), multiple destinations, live performance reporting, JNDI, and multiple vendor plug-ins. It is one of the many tools used by performance teams for WebSphere MQ, WebSphere Business Integration Message Broker, and WebSphere Business Integration Event Broker in order to conduct tests ranging from a single client to more than 10,000 clients.

Download the tool from here.

This article describes the approach taken on a recent WebSphere Portal deployment project to secure specific pages on the portal that collect and display personal information about the user. Portal administrators and developers might be able to use this technique for your WebSphere Portal deployment.

This article describes Java™ API for XML-Based RPC (JAX-RPC) handlers and demonstrates how to easily generate, implement and add a JAX-RPC handler to an existing WebSphere Web service imported from the IBM® Rational® Application Developer Samples Gallery. Handlers are pluggable applications for handling XML messages and can be registered to run before or after the Web service or Web service client is invoked. They are frequently used in common functions such as processing message headers, logging activity, and measuring performance. This article shows you how to implement and deploy a message logging handler.

The article shows how to set up a portal project infrastructure in IBM® Rational® Application Developer that can be used to perform daily builds using Apache Maven. You walk through a complete example which covers the primary aspects of the build and deployment process. You see how to extract source from a version control system, build the source, deploy the resulting artifacts on IBM WebSphere® Portal Server V5.1, and generate reports about the process.

Filed in: WPS IBM

Each year JAVAPro magazine turns to its readership and asks it to select the best tool it uses to get the job done — whether the task is on an individual or a team basis. This year, IBM WebSphere Portal won the Best Java™ Enterprise Portal Technology category competing against BEA, Oracle and Sun Microsystems.

Check out the article here.

Filed in: WPS IBM

Service-oriented architecture (SOA) is hot. And as today's primary entry point for SOA, the emerging enterprise service bus (ESB) market is heating up, too. For example, within the last few months two major application platform vendors, BEA Systems and IBM, formally entered the ESB market, legitimizing the concept for many potential buyers. To assess the state of the ESB market and see how the vendors stack up against each other, Forrester evaluated the strengths and weaknesses of top ESB vendors using 100 criteria. The result: The market has two segments, with different leaders in each. The ESB suites segment is led by Cape Clear Software, Fiorano Software, BEA Systems, and Sonic Software, whereas the comprehensive ESB suites segment is led by Oracle, TIBCO, and Sun Microsystems.

The analysis that led to this view of market segmentation was based on customer interviews, which led us to group ESB buyers in two groups:

* The "keep it simple" group wants simple and low-cost integration, support for service orchestration, and the core of future support for managing services through their full life cycle.

* The "I want it all now" group wants ESB capabilities in the context of their leading application or integration platform, combined with richer service life-cycle support, and BPM capabilities needed to support business transformation.

Both groups want full support for SOA and a wholehearted embrace of open industry standards.

Tune in to the insight and outlook of IBM visionaries and leading technical practitioners as they comment on issues facing IT architects today and in the future. This month they respond to the question, Why should you care about SOA, and when is it the right choice and when is it the wrong choice?

Check out the article here.

Web services have become a standard way of implementing Service Oriented Architectures. Developers have used many patterns of developing these Web services, but these patterns have not been well-defined or discussed.

The article identifies and describes three development patterns:

* Bottom-up pattern: Start with Java to produce WSDL.
* Top-down pattern: Start with WSDL to produce Java.
* Round-trip pattern: Start with WSDL to produce Java, which is then used to produce WSDL, which is then used to produce Java.

The article then goes on to explain the each pattern, its advantages and disadvantages. Pretty basic but good to read.

Check out the article here.

The article shows you how to use IBM WebSphere Process Server to take control of the connectivity and persistence logic for container-managed persistence (CMP) beans, enabling them to be stored to non-relational datastores. You learn about the various data access patterns that are supported and step through basic usage scenarios that include demonstrated examples ranging from very simple to somewhat complex. This article covers some best practices, such as using Service Component Architecture (SCA) from within the special Java class, UserDefinedPushDownMethodsImpl, enabling reuse of services that expose legacy systems via a service-oriented architecture (SOA), and insulating you from needing to know all of the details involved in communicating with the non-relational datastore.

A number of new tutorials have been published on the IBM Developerworks Site, on creating JSR 168 Portlets, which allow you to implement inter-portlet communication, portlet service and WSRP portlets. Check out all these tuturials here.

Creating a JSR 168 portlet for use by diverse portals using Web Services for Remote Portlets

Creating and deploying a portlet service for IBM and JSR168 portlets

Implementing JSR 168 inter-portlet communication using Rational Application Developer V6.0 and WebSphere Portal V5.1

With the release of IBM® WebSphere® Integration Developer and IBM WebSphere Process Server, comes a new programming paradigm for building service-oriented architectures (SOA) called the Service Component Architecture, a new programming model designed specifically for building and assembling business solutions in an SOA, and targeted for integrating and composing services. Check out the same here.

Link

I had talked about ESB Myths some time back. Today, I thought let me take one step backward and find out

What is ESB?

One defination goes as
"An Enterprise Service Bus (ESB) is a flexible connectivity infrastructure for integrating applications and services. An ESB can power your service-oriented architecture (SOA) by reducing the number, size, and complexity of interfaces between those applications and services."

Another says
"The Enterprise Service Bus (ESB) provides a new way to build and deploy enterprise service-oriented architectures (SOA). ESB is a concept that is increasingly gaining the attention of architects and developers, as it provides an effective approach to solving common problems such as service orchestration, application data synchronization, and business activity monitoring."

Another says
"An enterprise service bus (ESB) is a pattern of middleware that unifies and connects services, applications and resources within a business. Put another way, it is the framework within which the capabilities of a business' applications are made available for reuse by other applications throughout the organization and beyond."

Another says
"An ESB is software infrastructure that simplifies the integration and flexible reuse of business components using a service-oriented architecture. An ESB makes it easy to dynamically connect, mediate and control services and their interactions."

Another one says
"An enterprise service bus refers to a category of middleware infrastructure products or technologies, based on Web services standards, that enable a service-oriented architecture via an event-driven and XML-based¹ messaging engine (the bus). An enterprise service bus generally provides an abstraction layer on top of an Enterprise Messaging System which allows integration architects to exploit the value of messaging without writing code."

I feel the last defination describes the ESB better. ESB is an abstract layer sitting on top of a messaging system, which makes use of Web Services to achieve connectivity.

Although the exact definition of an ESB varies, most agree that the following are characteristics of an ESB::

* it requires the clear separation of message headers and message body
* it is usually operating system and language independent; it should work between Java and .Net applications, for example
* it (often) uses XML and Web services to transport messages
* it includes adapter standards (such as J2C) for incorporating existing applications into the bus
* it includes support for asynchronous processing
* it includes intelligent, content-based routing
* it includes a standardized security model to authorize, authenticate, and audit use of the ESB
* it includes transformation services (such as XSLT) between the format of the sending application and the receiving application, including the transformation of data/message formats
* it includes validation against schemas for sending and receiving messages
* it can uniformly apply business rules, enrichment of the message from other sources, splitting and combining of multiple messages, and the handling of exceptions
* it can conditionally route or transform messages based on a central policy
* it is monitored for message latency and other characteristics described in a Service Level Agreement
* it (often) facilitates "service classes," responding appropriately to higher and lower priority users
* it supports queuing, holding messages if applications are temporarily unavailable
* it handles a "publish and subscribe" messaging model, including event handling
* it handles business events from disparate sources

Any J2EE application needs some type of caching. Whether, the application needs to cache some meta data or some global objects , caching has always been used. Caching can dramatically improve performance of your application. The idea behind caching is to store locally any data that changes infrequently but which may be nonetheless expensive to obtain from the data source—such as data obtained from a database.

Most of applications I have come across or even developed myself, make use of some type of Singleton pattern making use of a hash table. Here we create a singleton object which gets the data from the database and caches.

public class GlobalCache
{
private static GlobalCache
instance = null;
private List classes;

public static GlobalCache getInstance() {
If (instance == null) {
instance = new GlobalCache ();
}
return instance;

}

// Prevent instantiation

private GlobalCache () {
classes = loadDataFromDB();
}

public List getClasses() {
return classes;
}
...
}

This approach works fine for standalone applications, but for a distributed environment, this approach won't work because the caches on individual nodes must get synchronized within the cluster.
Now, what are the options available to us?

One way is use caching solutions available in the market. Products like

SwarmCache
OSCache
EHCache

This is just a sample, market is flooded with caching solutions.

But, in case we do not want to use any of these caching solutions and want to develop something in-house that supports caching across clustering.. (Typical mindset of controlling what's happening in the application ?)

In a clustered environment each server runs in its own JVM, which poses an interesting problem: What happens when the repository changes on one node in the cluster? The caches residing in the other application server nodes quickly become out of date, and users connected to other servers in the cluster will get stale data.

The option is to make use of JMS. JMS is a natural fit for this problem, and it has the following advantages:

• JMS provides a simple yet flexible messaging API
  
• JMS is standard in any J2EE compliant application server
  
• MS is the basis of EJB 2.0's Message Driven Beans (MDB), which greatly simplify writing asynchronous J2EE applications

I am currently working in developing a caching solution on the same lines. Once finished, I will share my findings.

During my experience in handling J2EE projects, the LDAP has always proved to be a mystery for many a team members. Faces tend to go blank and they just don't know how to use.configure or write code to work with LDAP. I found a very nice article which takes your through the journey of LDAP - right from basics to the Advanced level where you configure LDAP with IBM WebSphere.
The article is in a 5 part series. Check out the same here.
Part 1
Part 2
Part 3
Part 4
Part 5

IBM has released a tool that allows organizations to calculate ROI for their Portal Projects. IBM says that ROI calculator that will help the organizations to select and frame the benefit areas and sample costs of an IBM solution. The ROI calculator allows the organizations to easily adjust cost and benefit drivers for the company's business portal project. Very useful to craft a business case for specific integrated business portal projects.

Check out the WPS ROI Link, for more details.

Another ROI Link...

I subscribe to the J2EEPatterns mailing list. One of the questions I recently came across was on the Singleton Pattern. The pattern seems to little hard to understand specially when it comes to multi threading. One IBM Article that really explains the Singleton Pattern implementation. I went through the same and I must say the article is Must Read.

I came across another article that talks about the challenges and pitfalls of J2EE.
1. It talks about the architectural approaches when selecting Application server.
2. What needs to be considered when designing and developing production ready applications?
3. How Operational requirements impact the application?

For full article, click here

You can also refer to my earlier article on the same subject

This article discusses the highlights of service-oriented modeling and architecture; the key activities that you need for the analysis and design required to build a Service-Oriented Architecture (SOA). The author stresses the importance of addressing the techniques required for the identification, specification and realization of services, their flows and composition, as well as the enterprise-scale components needed to realize and ensure the quality of services required of a SOA.

Advanced Web sites typically consist of both static content (served by a traditional Web server) and dynamic applications (using a portal product) surfaced in a common end user experience. With the new adaptive page caching, portlet caching, and object caching functions, IBM® WebSphere® Portal V5.1 can efficiently serve the dynamic parts of a Web site while projecting the static parts into caching proxies or browser caches. This paper explains how and why to run an entire Web site -- including the static parts -- on WebSphere Portal with unified deployment, administration, and content management.

After years of providing highend messaging solutions, IBM announced that it would begin to ride the bus. A host of new additions to its WebSphere product line, including a lightweight WebSphere Enterprise Service Bus and an Eclipse based service-oriented architecture development tool known as WebSphere Integration Developer, marks the company’s expanded SOA platform.

IBM also announced a wider partnership program for its SOA offerings, a new WebSphere Process Server, the WebSphere Business Modeler and the WebSphere Business Monitor. In addition, the company said it will release an updated version of its WebSphere Message Broker. The announcements reflect an array of new solutions that IBM is offering for start to-finish SOA implementation within enterprises.

Recently, I migrated from WSAD to RAD 6.0. I have started working on creating JSF portlets (JSR 168 compliant). While, surfing the net for any good article, came across this 2 part tutorial.

Developing JSF Portlets with Rational Application Developer 6.0 and WebSphere Portal Server 5.1, Part 1

Developing JSF Portlets with Rational Application Developer 6.0 and WebSphere Portal Server 5.1, Part 2

I found it pretty useful although the instruction are little cryptic. So you need to go through the article pretty closely to get the sample running.

Another 5 series article on creating plain vanilla JSF applications.

Developing JSF Applications using WebSphere Studio V5.1.1


This I found easy to follow and give clear instructions to go about creating the application. The same logic can be followed for creating portlets also.

Filed in: WPS

Message-Driven Beans in WebSphere
— With WebSphere Application server 5.0+ you can now add Message-Driven Beans (MDBs) to your WebSphere arsenal. These beans are handy for many processes. I recently had to write a MDB using MQ Series. WebSphere Application Server (WAS) 5.0 had the same functionality built-in, but I had a hard time learning how to use it. I also encountered some issues while configuring it to run in a load-balanced environment.

During my last couple of years as architecting J2EE applications, I have come across certain do's and don'ts, during the design of a Enterprise Application.

1. Use of EJB's
Many projects use EJB's because that is the "in thing" or because this is an enterprise application, using EJB's is a must. My experience says use EJb's where it makes sense. Places where you need to utilise the EJB Container services - like transaction, security. In case, the application does not require all this, then the application should look at POJO's as a viable alternative.

2. Validations
Another issue is the deciding which validation need to be done at client side and what all need to be done at server side. We tend to segregate the validations between client and server. It works fine, as long we are the only clients for our server objects. The movement, another client(Rich Client Application, Mobile Applications) wants to utilise the services of our server objects, our server objects start bombing, because the new client is not conforming to the client side validations expected from him. The best practice is to make sure that our server objects does all kinds of validations so as to avoid any bombs later on.

People might question, on why do we do perform simple checks like field length validations twice. I say, you are not doing twice. Look from the Responsibility angle, the serve object needs to be self sufficient to perform all validations for the data the object deals with. The server object should not fail because the client did not gave correct data or all the data. Validation on the client side are more from Presentation layer perspective, where the client can restrict the user from entry garbage data or insufficient data.

3. Application Security
When starting the design of the enterprise application, the application security is the most ignored aspect. It is usually added as an add-on the application during the fag end of the application development. But it might be too late by this time. Security needs to be thought through and implemented as a vertical layer in your application.

Once, I worked on an application, where the application had almost 10 different types of security requirements. Privileges needed to be captured at multiple layers. Presentation layer had different set of security privileges. Business layer had different, Data Layer different. Even the data going into database needed to be encrypted, even the DBA was not supposed to see that data.
There is a nice book Core Security Patterns: Best Practices and Strategies for J2EE™, Web Services, and Identity Management on the same subject.

4 Internationalization and Resource Bundles
Another pitfall is the non-use of resource bundles. The common excuse is, our application is a extranet application or meant for one particular customer target or country, where the requirement is English only. Internationalization is the underlying theme today for all applications. The application should from day one take internationalization into account. Here,just moving the text for labels, or messages does not make the job complete. Things like menu items text, application header and footer and also how does the language effects lay out of the page need to be accounted for.
In the old client-server days, I remember we were working on a MFC based windows applications where we needed to support 2 languages - English and German. So the mandate was the length of each field label needs to be 25% extra as what we had for English label.
Check out J2EE Internationalization and Localization

5 Improper Use of MVC model
MVC is a presentation layer model. Adding business logic to the model class leads to wrong usage of the MVC model. The model class should call a business delegate class and that business delagate class should invoke the business objects. The Business Delegate acts as a client-side business abstraction; provides an abstraction for, and thus hides, the implementation of the business services. Using a Business Delegate reduces the coupling between presentation-tier clients and the system's business services.



These are some of the big ticket guidelines. I will try to blog down another set soon. Watch out for the same.

Filed in: J2EE

Recent, I came across an article that talked about the 10 top myths when it comes to Enterprise Service Bus(ESB). I am mentioning the heading's here.

1. ESB is just a new name for EAI.
2. ESBs compete with J2EE application servers.
3. I don't need an ESB if I'm using Web services.
4. An ESB is simply an abstract concept or design pattern.
5. ESBs are simply message-oriented middleware with a new marketing spin.
6. ESBs will be obsolete once BPEL and the WS-* standards are complete.
7. Microsoft is building an ESB with its Indigo project.
8. An ESB container can be implemented using an EJB container.
9. ESBs offer yet another proprietary middleware stack.
10. ESBs are useful only for departmental applications.

Read details about each of these here

Filed in: SOA

Disparate Service Invocation Challenges and Solution Alternatives for SOA in J2EE by Sushil Shukla and Sudhir Bhojwani -- This presentation discusses the challenges in heterogeneous service invocation and solution alternatives in the form of Apache WSIF, Apache Beehive and other custom frameworks.

You can cache data in JSR 168 portlets in order to avoid unnecessary backend requests. First, you see how to leverage the IBM WebSphere Application Server dynacache infrastructure to store cached data. Next, you see how to generate cache keys for data which is shared across all components in the Web application and which has a session scope. Then, you look at a second cache key generation technique to address the need for caching data that is private to a portlet window. An example bookmark portlet illustrates both caching techniques.
Check out Caching data in JSR 168 portlets with WebSphere Portal V5.1

Filed in: WPS

Forrester reported that Web mail usage among North American online households is changing: Compared with last year, users access Web mail more regularly and are 33% more likely to say that Google, MSN Hotmail, or Yahoo! provides the email address they use most frequently. Web mail providers are upgrading the experience too, making Web mail look and feel more like a snappy desktop application than the slow, refresh-laden experience of several years ago. But these innovations aren't aimed at customer acquisition — instead, portals will exploit a better Web mail experience to entice users to spend more time on search and other services that drive revenue.

Learn how to get major security benefits by developing code that lets your J2EE™ applications transparently send identity information to your database. Get the benefits of J2EE, including CMP beans, and still leverage the power of your database security.

Performance considerations for custom portal code
— Stumbled on this while trying to performance tune the portal application. A very useful article specially if you are using custom portal code

Filed in: WAS

Develop high performance Web sites with both static and dynamic content using WebSphere Portal V5.1
— Stumbled on this while trying to performance tune the portal application. A very useful article.

IBM's New WebSphere Process Server Gets Its First Business Rule Software
— ILOG today announced it is the first Business Rule Management Systems (BRMS) software vendor to offer integration with the new IBM WebSphere Process Server version 6.0, announced yesterday by IBM.

New to SOA and Web Services
— If you are new to SOA and WebServices, then this article is a very place to start with. The article talks about What is SOA? What can do you do with SOA? What are the different component technologies in SOA? How can you build a SOA system ?

How to access user information in JSR portlets
Several API calls are available in WebSphere Portal Server to access user information from JSR portlets. This technote explains which API should be used for which purpose. It also provides troubleshooting information for some common problems with the APIs.

Filed in: WPS

IBM's Steve Mills "We're Not Feeling Boxed In By Oracle"
— IBM is embracing SOA...in a bear hug. In a teleconference today fronted by Steve Mills, Senior Vice President and Group Executive, IBM Software Group and the General Manager of WebSphere, Robert LeBlanc, it was manifestly apparent that the company - which considers itself the world's leading provider of technologies that support Business Integration and Business Process Integration - is not looking over its shoulder, not at Oracle nor anyone else. And IBM Global Services turns out to be the secret ingredient of Blue's software portfolio 'realignment.'

Figure 1 WebSphere Application Server Dynamic Cache overview

The Dynamic Cache is part of the IBM solution for improving performance of Java 2 Platform, Enterprise Edition (J2EE) applications running within WebSphere Application Server. It supports caching of Java servlets, JavaServer Pages (JSP), WebSphere command objects, Web services objects, and Java objects.

Figure 1 presents an overview of the Dynamic Cache engine. The Dynamic Cache stores its content in a memory-based Java object store. These objects can be accessed and manipulated by APIs that are provided with the service. The WebSphere Application Server also offers a Web application called Cache Monitor, which plugs into the cache to provide a view of its contents and statistics.

The Dynamic Cache uses a replacement policy like the least recently used (LRU) algorithm to create space for incoming entries when the assigned space is full by deleting contents based on the replacement policy. It can also be con- figured to push data to a disk cache from which it can reclaim the data if needed in the future. Removal of entries from a cache can also occur due to data invalidations, based on cache policies defined by the administrator.

Dynamic caching requires cache policies to be con-figured for an application, or for the application to explicitly use the available caching APIs. The Dynamic Cache (in the cachespec.xml file) stores a caching policy for each cacheable object. This policy defines a set of rules specifying when and how to cache an object (i.e., based on certain parameters and arguments), and how to set up dependency relationships for individual or group removal of entries in the cache.

Web Page/Fragment Caching

WAS Dynamic Cache provides caching for static and dynamic content of servlet and JavaServer Pages (JSP) pages and fragments making up Web pages. You cache servlets and JSPs in WAS declaratively and configure the caching by using a cache policy defined as an XML deployment descriptor included in your Web application. The cache policy file — named Cachespec.XML — is located in your Web module's WEB-INF directory along with the standard Web.XML file. When configuring the cache policy for Dynamic Cache, you must consider which servlets or JSPs to cache, what makes an invocation of that servlet or JSP unique, and when to remove content from the cache.

Identifying Servlets or JSPs to Cache

WAS Dynamic Cache parses the Cachespec.XML deployment descriptor on application startup and extracts from each . . . element a set of configuration parameters. Then, every time a new servlet or JSP is initialized (e.g., when the servlet is first accessed), the cache attempts to match that servlet/JSP to each cache-entry element to find the configuration information for that servlet.

Whenever a servlet of the specified class is initialized, WAS Dynamic Cache will match that servlet with the configuration for this element. The tag identifies the type of object being specified in the tag. For servlets and JSPs, the tag always has a value of servlet. Other types of cacheable entities (e.g., commands) use different values for the tag.

You can also identify a servlet or JSP using its Web URL path. For example, the following specification defines a cache policy for a servlet with a mapping in Web.XML of /action/view:

<cache-entry>
<name>/action/view</name>
<class>servlet</class>
</ cache-entry>

The specification of the Web path is relative to the Web application's context root; therefore, the context root isn't included in the servlet's name.

Identifying What Makes a Cache Entry Unique

Most servlets and JSPs make use of a variety of inputs to generate unique dynamic content (otherwise, static HTML is used). This variable input usually comes in the form of request parameters, browser cookies, request headers, session attributes, path information, and request attributes from parent or peer servlets. To correctly cache a servlet or JSP, the cache policy author must identify the minimum set of input variables that makes a servlet's or JSP's output unique. Dynamic Cache supports declaring these inputs through the use of <cache-id> and <component> tags.

<cache-entry>
<name>/viewQuote </name>
<class>servlet </class>


<cache-id>
<component id="ticker" type="parameter" />
<component id="style" type="session" />
</cache-id>
</cache-entry>

Figure 2: Displaying the View Quote servlet's dependencies

For example, Figure 2 shows that the View Quote servlet's output is dependent on a request parameter named "ticker" and on a style attribute that was previously stored in the user's HTTP session. When a request is made to the URL http:/myhost/quoteapp/viewQuote?ticker=IBM by a user with an HTTP session attribute of style=frames, the following cache ID is generated:

/quoteapp/viewQuote:ticker=IBM:style=frames

Each request to the View Quote servlet with unique ticker and style attribute values will produce a unique cache entry instance. WAS supports many different input variable types that you can use to uniquely identify requests. Figure 3 (below) displays a list of valid types supported for use in generating cache IDs.

Removing Entries from the Cache

After populating the cache with servlet and JSP content, the next important consideration is how to remove the content. Dynamic Cache removes content based on an explicit timeout, an explicit invalidation based on cache ID or dependency ID, and replacement due to being selected for eviction by the cache's replacement algorithm. Dynamic Cache manages the replacement algorithm, which uses a cache entry's priority and frequency of access to determine which entry to evict when the cache has exceeded its capacity. The cache policy in Figure 4 sets each cache entry to have a timeout value of five minutes (300 seconds).

There are three ways to explicitly remove entries from the cache: programmatically by cache ID, programmatically by dependency ID, and declaratively by dependency ID.

Enabling and Analyzing Runtime Dynamic Caching

After you've created Dynamic Cache policies to cache and control appropriate page fragments in a cachespec.xml, next step as the WAS administrator is to enable servlet caching for the application. The WAS Web container configuration in the Administration Console provides a check box property for this. You'll find specific details for enabling caching by searching "Dynamic Cache" in the WAS Info Center at http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp.

Once you've enabled the Dynamic Cache, your next step is to monitor and optimize application caching at runtime. WAS 5.0 provides two methods for runtime analysis: the Dynamic Cache runtime monitor application and the Tivoli Performance Viewer (formerly the WAS Resource Analyzer). Both methods detail runtime cache behavior by showing cached servlets, JSPs, and objects, as well as cache invalidations, Least Recently Used (LRU) evictions, and other key runtime data.

The Dynamic Cache monitor is an installable Web application provided as part of WAS 5.0. To install the cache monitor application, follow these steps:

1. Install the cachemonitor.ear application from the was_home>/installableApps directory.
2. Access the cache monitor via a Web browser using the URL http://:/cachemonitor. For example, http://localhost:9080/cachemonitor would work for a WAS instance installed on the localhost node using the default HTTP port 9080.

Optimizing Dynamic Cache Runtime

You optimize caching performance by managing the WAS Dynamic Cache cached entries and memory usage. The number of distinct cached entries in a Web-based application can quickly grow. Each cache entry instance takes up memory in the WAS instance JVM. The amount of memory used varies based on the size of the object in the cache. A large JSP page or deeply nested Java object can require significant memory for each cache entry. You must consider memory constraints when setting the cache entry size. Setting it too large can result in system paging (drastically reducing performance) or even the dreaded Java out of memory error.

Memory limitations often restrict the Dynamic Cache from keeping all cache entries active, so you must take the following actions to keep performance high:

• Adjust cache entry size for optimal cache size and memory requirements. The Dynamic Cache removes entries when the number of cached objects exceeds the WAS setting for cache entries. The default cache entry size in WAS 5.0 is 1,000 entries. If the number of cached objects exceeds the cache entry size, objects are evicted and must be re-created when they're accessed again, which reduces the performance efficiency of caching. The cache monitor application details the runtime statistics for cache entry size and number of active entries. If the number of active entries frequently reaches the cache entry size, you should increase the size setting on the Dynamic Cache configuration page to reduce overflow evictions.
• Set cache entry priorities to "LRU out." When all cacheable objects can't be cached due to memory constraints, the Dynamic Cache offers a "priority" mechanism to better control which objects to evict. The cache uses an LRU algorithm when selecting candidates for eviction. This ensures that those cache entries hit often will remain in the cache. You can further tune this behavior by increasing the priority of cache entries that are expensive to compute. Priorities range from 1 to 10 and determine a cache entry's relative importance. For example, in the above scenario, you could raise the priority for user account cache entries. This would lead to stock quotes that are rarely accessed and less expensive to compute being evicted from the cache first. You set a cache entry priority in the cachespec.xml file, as Figure 3 shows.

<cache-entry>
<name>/viewQuote</name>
<class>servlet</class>
<cache-id>
<component id="ticker" type="parameter" />
<component id="style" type="session" />
<priority>3</priority>


</cache-id>
</cache-entry>

Figure 3: Setting cache entry priority

• Monitor for entries that have excessive invalidations and stop caching them. The Dynamic Cache also removes cached entries based on explicit timeouts and invalidations as defined by the caching policies in the application's cachespec.xml. Invalidating cache entries, such as objects in the Dynamic Cache, is expensive and can reduce performance. You can monitor for cache invalidations using the Tivoli Performance Viewer. You should disable caching for dynamic cache entries that have a low cache-hit ratio and/or high invalidation rate.

Distributed Caching

The WAS 5.0 Dynamic Cache can improve performance even more by providing caching in a cluster. A cluster is a cooperating group of WAS servers that are all running the same application code. WebSphere can provide dynamic replication to share cache data across a WAS cluster. You can replicate both application cache entries and invalidations.

There are three primary modes of operation for data replication:

• None — Data is not replicated in the cluster.
• Push — Data is immediately pushed to other cluster members as it's updated on one node.
• Push Pull — the cache ID is immediately pushed to other cluster members so they know that an updated copy of the data is available. If a cluster member receives a request for that set of data in the future, it will retrieve the data then.

Disk Offload

When a memory-based cache is insufficient to hold the cached items required by your application as previously described, you can enable the Dynamic Cache to overflow the LRU cache items onto a disk. WebSphere has implemented this overflow-to-disk capability using a technology called Hashtable On Disk (HTOD).

HTOD manages a virtual hash table on the disk in 1 GB file chunks. Individual cache entries are then hashed and placed inside the virtual storage in a manner similar to a memory-based heap. This methodology provides high performance and low latency for disk storage and retrieval. To enable the overflow-to-disk capability, simply select the "Enable disk offload" option on the Dynamic Cache configuration page and specify a directory path for the cache in the "Offload location" field.

For more information, refer http://www.alphaworks.ibm.com/tech/cachepolicyeditor/faq

References

1. WebSphere Dynamic Cache: Improving J2EE application performance by R. Bakalova,A. Chow, C. Fricano, P. Jain, N. Kodali, D. Poirier, S. Sankaran, D. Shupp

2. IBM WebSphere Portal for Multiplatforms V5 Handbook – RED Book

3. WebSphere Information Center

4. Exploiting Dynamic Caching in WAS 5.0, by Stan Cox , Brian K. Martin

5. Dynamic Cache Policy Editor for WebSphere Application Server

WebSphere Application Server Java Dumps
— This article is meant to bring you up to speed on Java dumps and their debugging purposes quickly. It assumes that you?re familiar with basic Java, the Java Virtual Machine (JVM), and threading concepts. Some information about Java dumps and their contents is intentionally omitted from the discussion to simplify things since it?s not relevant to the type of problem determination discussed here.

IBM has just signed an agreement to acquire PureEdge Solutions, a pure-play e-forms vendor known for its focus on secure, XML-based e-forms. IBM's acquisition underscores e-forms' role as a core technology for automating business processes and allows IBM Workplace customers to seamlessly integrate e-forms into back-office systems like ERP and CRM. This acquisition strengthens IBM Workplace and puts IBM in direct competition with Microsoft InfoPath and Adobe LiveCycle. It also gives current Lotus Domino e-forms customers a migration path from proprietary e-forms to XML-based forms. IBM now has a strong e-forms solution that can be leveraged across IBM's collaboration, enterprise content management (ECM), and business process management (BPM) offerings, and is primed to be a strong contender in the growing e-forms market.

Jinwoo Hwang, an IBM software engineer who is a member of WebSphere Application Server Technical Support Team, based in Research Triangle Park, has released HeapAnalyzer 1.3.5 – allowing the finding of a possible Java heap leak area through its heuristic search engine and analysis of the Java heap dump in Java applications.

HeapAnalyzer analyzes Java heap dumps by parsing the Java heap dump, creating directional graphs, transforming them into directional trees, and executing the heuristic search engine.

Java heap areas define objects, arrays, and classes. When the Garbage Collector allocates areas of storage in the heap, an object continues to be live while a reference to it exists somewhere in the active state of the JVM; therefore the object is reachable. When an object ceases to be referenced from the active state, it becomes garbage and can be reclaimed for reuse. When this reclamation occurs, the Garbage Collector must process a possible finalizer and also ensure that any internal JVM resources that are associated with the object are returned to the pool of such resources. Java heap dumps are snap shots of Java heaps at specific times.

The HeapAnalyzer tool can be donloaded here.

If you plan to build a scalable and highly available Website, you need to understand clustering. In this article, Abraham Kang introduces J2EE clustering, shows how to implement clusters, and examines how Bluestone Total-e-server, Sybase Enterprise Application Server, SilverStream Application Server, and WebLogic Application Server differ in their approaches. With this knowledge you will be able to design and implement effective and efficient J2EE applications.

Putting WAS on Unix
— In the last part of this three part series, we're going to look at some advanced topics and further considerations for running WebSphere effectively under UNIX, including monitoring, security and resilience.

Inter-Portlet Communications
— This article demonstrates the steps performed to implement JSR 168 compliant cooperative portlets using IBM Rational Application Developer V6.0 and WebSphere Portal Server V5.1. The article illustrates passing multiple values from source portlet to target portlet without defining complex data type inside WSDL file.

Filed in: WPS

Your Guide to Portal Clustering in WebSphere Portal Server 5.1
— Some things in WebSphere PortalServer work well and are well documented. Other things are well documented and work well in theory. Still other things have okay documentation and will work well when all of the WebSphere stars are aligned. Depending on your implementation, Portal Clustering can fit into all three categories.

Filed in: WPS

The Portal Scripting Interface
— One of the great advantages of the WebSphere software platform is that it's been built with a great deal of flexibility. A product simply wouldn't bear the WebSphere name if there weren't several different ways to do things. WebSphere Portal Server is no exception. With the release of version 5.1 IBM has added another way to administer the configuration of the Portal. This is sure to delight the poor, overworked Portal administrator who doesn't want to learn the art of XMLAccess and wants to avoid the use of a Web-based administration interface all costs.

Filed in: WPS

Authentication in WebSphere Portal
— Enterprise application integration (EAI) is a prime objective driving the decision to implement a portal. Portals are often used to integrate data and applications from remote systems and present them in a unified manner to users through a Web-based workspace. Because these back-end systems can contain sensitive business information and functionality (for example, a company's order control system) or private data (e-mail or employee records), access should be well controlled.

Filed in: WPS

What's New in WebSphere Portal V5.1.0.1?
— The first thing that you said to yourself when you saw the title of this article is, Why am I reading an article about a point release? A fixpack update point release usually provides just technical fixes. Who cares?
Surprise! IBM® WebSphere® Portal V5.1.0.1 provides new and updated capabilities, as well as the typical set of adjustments and fixes to some components of the product. It also contains some long anticipated enhancements that did not quite make it into WebSphere V5.1.

Filed in: WPS

This section gives a high level comparison between the new JSR 168 Portlet API and the IBM Portlet API. First, it covers the concepts that are similar; then, it explains some of the differences between the two.

Similarities

The following features are very similar in JSR 168 and the IBM Portlet API.

Feature	Similarities	Differences
Portlet modes	Both support the basic portlet modes: Edit, Help, and View.	The config mode is optional in the JSR 168. The other optional JSR 168 modes (About, Edit_defaults, Preview, Print) are not supported by the IBM Portlet API.
Window states	These window states are supported: Maximized, Normal, and Minimized.	The Solo window state is only supported by the IBM Portlet API.
Portlet lifecycle	The lifecycle life cycle is the same: init, process requests, destroy.	none
Request processing	Request processing is divided into an action phase for processing user actions and a render phase for producing the markup.	none
URL encoding	Both support creating URLs pointing to the portlet or to a resource.	none
Include servlets/JSPs	Servlets and JSPs can be included in the portlet.	none
Portlet session	Portlets can store transient information that should span requests in a session.	none
Portlet application packaging	Both package portlet applications as WAR files with an additional deployment descriptor called portlet.xml.	The portlet.xml format differs.
Expiration-based caching	The portlet can support expiration based caching.	The APIs use different mechanisms to implement this functionality. The IBM Portlet API uses a polling mechanism where the portal queries the portlet for how long the markup will be valid, whereas in the JSR 168 the portlet can attach an expiration time to each created markup. Sharing the cache entry across users is only possible in the IBM Portlet API.

Differences

JSR 168 and the IBM Portlet API differ in the following ways.

Feature	IBM Portlet API	JSR 168
Portlet application entities	Lets you define an abstract portlet application and different instance of this portlet application as concrete portlet applications via the deployment descriptor. This allows reusing settings of the abstract portlet application and only overwriting the parts that are unique for each concrete portlet application.	The deployment descriptor follows the web.xml deploymentdescriptor and defines one portlet application and the portlet definitions for this application.
Portlet entity	There is one portlet object instance per portlet configuration in the Web deployment descriptor. There may be many PortletSettings objects parameterizing the same portlet object according to the Flyweight pattern, provided on a per-request basis. Changes in the PortletSettings apply to all portlet instances of this concrete portlet. The user can also have personal views of concrete portlets that are rendered using the PortletData for customization of the output.	PortletSettings and PortletData are merged into one object called PortletPreferences.
Request/Response objects	The request/response object that the portlet receives in the render call is the same as the one received in the action call.	In the JSR 168 these are two different objects.

Exclusive to JSR 168

These items are only available in the JSR 168.

Feature	Description
Render parameters	Render parameters allow the portlet to store its navigational state. Render parameters stay the same for subsequent render requests and only change when the portlet receives a new action. This enables bookmarkability and solves the browser back button problem.
Global HttpSession scope	Portlets can store data not only with the visibility of the portlet, but also with the visibility of the whole Web application.
Redirect	Portlets can redirect to other Web resources in the action phase.

Exclusive to the IBM Portlet API/p>

The following concepts are only available in the IBM Portlet API.

Feature	Description
Eventing	Events can be sent between portlets.
Additional lifecycle listeners	Lifecycle listeners besides action and render, (such as begin page) are not available in the first version of the JSR 168.
Portlet menus	Lets the portlet contribute content to a menu bar to facilitate navigation through portal pages.
Invalidation based caching	Lets the portlet explicitly invalidate cached content.

References

1. Comparing the JSR 168 Java Portlet Specification with the IBM Portlet API by
Stefan Hepper

Filed in: WPS

Portlet Packaging
By default, portlets do not share the Portlet Session object. So, if a page has 4-5 portlets, each portlet will have its own portlet session object. This can lead to a lot of overhead when rendering the page. To avoid this problem, portlets with common functionality should be packaged in one WAR file. Further the portlets packaged in the same WAR, share the same Portlet Session object, hence saving on the memory requirements, all leading to faster rendering of the page.

Summary

• Architecting, designing, building and management of Enterprise Business applications using COTS (Commercial Off The Shelf) packages as well as Custom Application development
• Wide experience in Requirements Gathering and Analysis, System Design, Use Case Modeling, Defining functional/technical specifications and creating Architectural views for applications
• Expert in estimation methodologies ( Function Point, WBS, Use Case Analysis), project planning ( RUP, Agile methodology) and monitoring/mentoring development team
• Wide Technical Expertise on IBM Product Stack, J2EE/Java centric technologies, Open Source products and tools, Web2.0/Enterprise2.0 tools and Cloud technologies
• Proven expertise in Technical Architecture/Solution Definitions and Roadmaps, Vendor Evaluation, RFP responses, Client Presentations, Whitepapers and SOWs
• Researching new technologies that can drive business innovation, provided Technical Solutions with proof of concept/ prototype in umpteen situations in multiple technologies

Specialties

• Helping business solve problems in innovative and cost effective ways 
• Thought Leadership

Download the resume in MS Word Doc Format here.

This excerpt covers some of the architectural challenges posed by Web Services, examines how to use (and not to use) Web Services, and describes some best practices in applying Web Services for solving tough architectural problems.

ON THE SUBJECT OF ME
I work as a Consultant in Portal and Content Management Practice for Wipro Technologies Ltd. I have co-founded a company in the area of collaborative innovation (www.ideaken.com). My main responsibility is around architecture and running of a multi-tenant application, deployed in cloud. My previous experience ranges from Architecting Portal and Content management solutions to developing back end systems for financial / transportation / travel domain projects using J2EE technologies. My areas of interest include multi-tenant application, cloud computing, portals, content management, Web Services, Service-Oriented Architecture (SOA) and Web 2.0.
I hold a Masters degree in Computer Applications from Thapar Institute of Eng & Tech, Patiala, India and ePGDBM from SIBM, Pune.

If you have something interesting for me, please check my resume here.

ABOUT THIS SITE

The information in this weblog is provided "AS IS" with no warranties, and confers no rights.

This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my own personal opinion.

CONTACT ME
I can be reached at write2munish (at) gmail dot com