Meet the Experts: Roland Barcia on using JMS and JSF

This question and answer article features WebSphere expert Roland Barcia who answers questions on using Java Messaging Service (JMS) with WebSphere Application Server and WebSphere MQ, developing Java Server Faces (JSF) applications with WebSphere Studio Application Developer, and building and deploying applications to WebSphere Application Server.


Roland Barcia (, Consulting IT Specialist, IBM Software Group

Photo: Roland BarciaRoland is a Consulting IT Specialist for IBM Software Services for WebSphere in the New York/New Jersey Metro area. He is the author of one of the most popular article series on the developerWorks WebSphere site, IBM WebSphere Developer Technical Journal: Developing JSF Applications using WebSphere Studio V5.1.1. He is also a co-author of IBM WebSphere: Deployment and Advanced Configuration.

14 July 2004


IBM® WebSphere® Application Server is a Java-based Web application server, built on open standards, that helps you deploy and manage applications ranging from simple Web sites to powerful e-business solutions. IBM WebSphere Studio Application Developer (hereafter called WebSphere Studio) is an integrated development environment for building, testing, and deploying J2EE and Web Services applications. For more information, see developerWorks WebSphere Application Server zone and developerWorks WebSphere Studio zone.

JavaServer Faces has been one of the most anticipated technologies in J2EE Web development. With WebSphere Studio, JavaServer Faces has arrived. JavaServer Faces (JSF) provides new development opportunities in visually developing J2EE Web applications.

Question: This is a very basic question. Can you compare the advantages and disadvantages of JSF vs. Struts. Both now, and from what you may know of futures, how and if JSF will evolve into a superior technology vs. Struts? Include how WSAD plays into the comparison if it will help differentiate the two.

Answer: This is a very popular question these days. In general, JSF is still fairly new and will take time to fully mature. However, I see JSF being able to accomplish everything Struts can, plus more. Struts evolved out of necessity. It was created by developers who were tired of coding the same logic again and again. JSF emerged both from necessity and competition.

Struts has several benefits:

  • Struts is a mature and proven framework. It has been around for a few years and deployed successfully on many projects. The WebSphere Application Server admin console is a Struts application.
  • Struts uses the Front Controller and Command patterns and can handle sophisticated controller logic.
  • In addition to the core controller function, it has many add-on benefits such as layouts with Tiles, declarative exception handling, and internationalization.

There are disadvantages:

  • Struts is very JSP-centric and takes other frameworks to adapt to other view technologies.
  • Although Struts has a rich tag library, it is still geared towards helping the controller aspect of development and does not give a sense that you are dealing with components on a page. Therefore, it is not as toolable from a view perspective.
  • Struts requires knowledge of Java™. Its goal was to aid Java developers, but not to hide Java. It does not hide details of the Java language to Web developers that well.
  • ActionForms are linked programmatically to the Struts framework. Therefore, to decouple the model, you need to write transfer code or use utilities to move data from Action Forms to the Model on input.

JSF is an evolution of a few frameworks, including Struts. The creator of Struts, Craig McClanahan, is one of the JSF specification leads. Therefore, it is not by accident to see some overlap between Struts and JSF. However, one of JSF's major goals is to help J2EE Web applications to be easily developed using RAD tools. As such, it introduces a rich component model. JSF has several advantages:

  • JSF is a specification from Sun® and will be included in future versions of the J2EE specification. All major vendors are pledging strong support for JSF.
  • JSF uses the Page Controller Pattern and therefore aids in Page rich applications. Components can respond to event from components on a page.
  • JSF has a well-defined request lifecycle allowing for plugability at different levels.
  • One powerful example of plugability is building your own render toolkit. The ability to separate the rendering portion from the controller portion of the framework allows for wonderful opportunities of extensibility. Component providers can write their own toolkits to render different markup languages, such as XML or WML. In addition, the render toolkit is not tied to JSP.
  • Because JSF has a rich component model, it favors a RAD style of development. I can now build my Web pages using drag and drop technology. In addition, JSF gives me a way to link visual components to back model components without breaking the layering.

JSF has disadvantages:

  • JSF is still quite new and evolving. It will take some time to see successful deployments and wide usage. In addition, as vendors write components, they may not do everything you want them to.
  • JSF by hand is not easier than Struts. Its goal was more oriented to RAD. Those who prefer to do things by hand (for example, the vi type guy who does not like IDEs) may find Struts easier to develop.
  • Struts navigation may be a bit more flexible and adhere to more complex controller logic.

Both JSF and Struts will continue to exist for a while. The Struts community is aware of JSF and is positioning itself to have strong support for JSF. See What about JSTL and JavaServer faces?

From a tools perspective, if you look at the support for JSF versus Struts in WebSphere Studio, the Struts tools are focused around the controller aspects. The Web Diagram editor helps build your Struts configuration and the wizards/editors build Struts artifacts. The JSF tools are geared towards building pages, and in essence, hide the JSF framework from you. Expect WebSphere Studio to support both frameworks for a while. As JSF matures, expect to see some of the controller aspects in JSF to become toolable.

Question: What's the best way to deal with migrating a large application from Struts to JSF? Is there any tool support that can help?

Answer: This is a complicated task depending on your Struts application. Because the two frameworks have different goals, there are some challenges. Migrate your response pages first. Keep the Struts controller and place and forward to JSF pages. Then you can configure Struts forwards to go through the Faces servlet. Consider looking at the Struts-Faces framework from Apache. See the framework chapter in JSF in Action.

Question: Is there a migration path from Struts to JSF? How does the maturity of JSF compare with Struts?

Answer: For the first question, see the previous answer. For the second question, see the answer to question 1.

Question: Can I replace Stateless session bean with Message-Driven bean?

Answer: Programmatically, anything is possible. But this type of change should be driven by requirements. A Message Driven Bean (MDB) is an asynchronous listener used to receiving JMS messages. A Stateless Session Bean listens either locally through a local interface or through RMI/IIOP using the Remote Interface. Application logic should be layered in such a way to service multiple clients. You may want to consider fronting the Stateless Session Bean with the MDB so that it is more accessible by multiple clients. Figure 1 illustrates the concept.

Figure 1. Concept

A good resource on this topic is Enterprise Java Programming with IBM WebSphere, Second Edition.

Question: I am using WSAD 5.1.1. With Sun's release of JSF 1.1, when will the RAD components for JSF1.1 be supported in WSAD for production use? (submitted by Jay B.)

Answer: IBM does not have imminent plans to move to JSF 1.1 because the original implementation (shipped in WebSphere Studio 5.1.2) includes corrections to defects that are addressed in JSF 1.1. Adoption of JSF 1.1 is redundant to the code IBM has already delivered. Remember that IBM was a major code contributor to the JSF project and the corrections shipped by IBM in WebSphere Studio 5.1.2 were factored into JSF 1.1. Over the longer term as the JSF standard continues to evolve, IBM will adopt newer versions.

Question: What is the proper WSAD and Portal Toolkit development environment? Our team must deploy against Portal Server 4.2.1. The team is also using Rational XDE. Full production in February 2005 is planned for WAS 5.1. We will use Struts and wish to consider JSF.

Can we use WSAD 5.1.2 with Portal Toolkit I wish to maximize developer productivity while initially deploying to Portal Server 4.2.1. What WSAD and Portal Toolkit environments do you recommend?

Answer: For deployment to WebSphere Portal 4.2.1, you can use WebSphere Studio 5.1.2 configured with the WebSphere Portal 4 test environment. WebSphere Studio is back-compatible to version 4 of WebSphere Portal. However, unlike the version 5 Unit Test Environment for WebSphere Portal 5, you need to install WebSphere Portal 4 UTE separately. There are some features, such as JSF, that are not available in version 4 of WebSphere Portal. In addition, you cannot use J2EE 1.3 APIs or the JSR 168 Portlet specification. Once you move to WebSphere Portal 5.0.2, you can begin to build JSF based portlets.

Once you move to the 5.1 based WebSphere Application Server, you can begin to use JSF features. However, given your circumstance, Struts using the IBM Portlet API seems like the best solution because it is supported in both versions 4 and 5. However, the version 4 Struts support is 1.0 based, while the version 5 is Struts 1.1. You may need to do some minor migration of the Struts code to make use of Struts 1.1.

Question: I am upgrading WAS 4 to WAS 5. Even though it's not giving any compile error, when I tested the application, it's giving the following error on the console:

[6/23/04 12:59:047 SGT] 493877ce WebGroup E SRVE0020E:
[Servelt Error]-[BF02SPINSLoginServlet]:
Failed to load servlet:
at java.lang.Class.newInstance0(Native Method)
at java.lang.Class.newInstance(
at java.lang.Class.Instantiate(
at java.lang.Class.Instantiate(

I tried adding ws-base-config in the class path, but it is still giving problems.

Answer: Migrating J2EE applications and servers can sometimes be tricky. Without more information, it is difficult to diagnose your problem. J2EE 1.2 applications should run in WebSphere Application Server without modifications. Make sure that the server contains the necessary configured resources. For J2EE 1.2 applications, for example, make sure to configure a WebSphere Application Server 4 data source.

If your migration involves updating the J2EE application from version 1.2 to 1.3, refer to Migrating to WebSphere V5.0, An End-to-End Migration Guide.

I suggest running the J2EE application as version 1.2 in WebSphere Application Server 5 to eliminate any server configuration issues. Then you can address the application migration.

Question: Are there strong cases in which I would choose JSF over SWING (or vice-versa) when writing an application?

Answer: JSF is still primarily a MVC framework for running J2EE Web applications. The component model of JSF is meant for developers to program Web applications using RAD tools that Thick client application developers are accustomed to. Although you can extend JSF by creating a custom render toolkit to render thick client controls from a server, its target is still Web based applications. Try answering the following question: "Am I building a thick GUI application or a Web based system?"

Question: I am in the middle of architecting an application right now, and considering Struts and JSF. What are the criteria that I should use to select between the two?

Answer: This is a common question. The answer to the first question may be helpful. In addition, consider the following:

  • When is the target deployment date for deployment? If deployment is soon, Struts may be an option. If deployment is further out, JSF may be an option.
  • What skill level do you developers have? Do they favor RAD IDE style approach or do they prefer to hand code things. Are your view developers different from your controller developers? I always think that one should consider the comfort level of their development team.
  • How complicated is you controller logic? How complicated are your pages? Complicated controller logic (logic where use input has a major affect on navigation) is probably better supported in Struts. Complicated page logic (many components that need a rich event model and model synchronization) favor JSF.
  • What type of Model do you have (EJB, JavaBeans, JDBC, and so on)? Check your JSF vendor for supported data components. For example, WebSphere Studio makes it simple to drag SDO or JavaBean object right to the page.
  • Are you building new pages/Web application from scratch, or reusing/migrating an existing application? If you have existing pages or an existing application implemented in Struts, you have to consider the cost of migration.
  • How important is vendor support? Both JSF and Struts are supported by IBM.
  • What type of clients will your enterprise application have? (Web Based, HTML, XML, Mobile, GUI, and so on)

Question: I am using WebSphere MQ 5.3 Publish/Subscribe functionality. How do I configure broker topology on server and client machine using WebSphere MQ 5.3? Also, how do I create topic hierarchies so as to take advantage of this feature provided by WebSphere MQ?

Answer: There are many topology options when using WebSphere Application Server with WebSphere MQ. Go to the WebSphere MQ JMS provider and configure Topic Connection Factories and Queue Connection Factories.

The following books and articles have the information you need:

On the topic of hierarchies, JMS does not stipulate how content should be structured into topic hierarchies. This is a provider-specific aspect. In MQ JMS, topics are arranged in a tree-like hierarchy. You must register Topics within the JNDI namespace and you cannot perform creation tasks in MQ. When a publisher or subscriber for a given topic is first created, the broker instantiates the topic.

Question: I am trying to fix certain problems in my wsadmin jacl scripts. On creating the Application Server, how is the following done using wsadmin scripts? 1)Enabling the ORB Pass By Reference option. 2)Setting the Generic JVM Args.

On creating the database provider: 1)The AuthData alias is not getting set (the scroll down menu for the Admin Console) for the container managed persistence even though the component managed persistence alias is getting set.

On deploying: 1)The Map Resource Reference to Resources properties - JNDI name is not set correctly.

I am trying to find the parameter names supplied in the wsadmin script. For example, I used SOAP_CONNECTOR_ADDRESS. It doesn't work, but BOOTSTRAP_ADDRESS works. If I could find a place where I could find these param names, it would be very helpful. (submitted by Nisha)

Answer: There are many examples of wsadmin in the WebSphere Application Server 5.1 Information Center. My book, IBM WebSphere: Deployment and Advanced Configuration, also has complete examples of wsadmin.

For enabling the ORB Pass By Reference option, see Configuring an ORB service using wsadmin. For setting the generic JVM args, see Configuring the JVM using wsadmin.

On creating the database provider, the information may not be in the Information Center, so I have attached a code snippet from my book. For creating a container managed alias, you must attach the J2C alias on the mapping module and not the DataSource itself.

puts "\nCreating the datasource $dsName"
set attrs2 [subst {{name "$dsName"} {description "$dsDescription"}}]
set ds1 [$AdminConfig create DataSource $jdbcProviderID $attrs2]

#Set the properties for the data source...
set propSet1 [$AdminConfig create J2EEResourcePropertySet $ds1 {}]

set attrs3 [subst {{name databaseName} {type java.lang.String} {value "$databaseName1"}}]
puts "\nj2eeresourceproperty"
$AdminConfig create J2EEResourceProperty $propSet1 $attrs3

set attrs4 [subst {{jndiName $jndiName} 
{statementCacheSize $statementCacheSize} 
{datasourceHelperClassname $datasourceHelperClassname}
{authMechanismPreference "BASIC_PASSWORD"}}]
$AdminConfig modify $ds1 $attrs4

#Create the connection pool object...
$AdminConfig create ConnectionPool $ds1 
{{connectionTimeout 1000} {maxConnections 30} {minConnections 1} 
{agedTimeout 1000} {reapTime 2000} {unusedTimeout 3000} }

#Set the auth mapping properties
set authDataAliasList [list authDataAlias $aliasName ]
set mappingConfigAliasList [list mappingConfigAlias DefaultPrincipalMapping ]
set mappingList [list $authDataAliasList $mappingConfigAliasList]

$AdminConfig create MappingModule $ds1 $mappingList

For the Map Resource Reference to Resources properties - JNDI name is not set correctly, see Wsadmin tool.

Question: My site is a medium sized bank (200,000 customers) running WebSphere 4.05 on Windows 2000 server using SQL2000 as the WebSphere repository. The first thing I would like to know is "is this an unusual setup?"" Would you be also be able to tell me what configuration most banks this size use? The other thing I want to ask about is scripting deployments, currently we deploy manually, what do most sites do? (submitted by StephenP of

Answer: On your first question, there are many things to consider with performance, such as the number of windows servers, the redundancy of your SQL2000 server, and so on. Different customers use different platforms and environments. I have seen customers run WebSphere successfully on AIX®, Solaris®, Linux, Windows®, and z/OS. This is a difficult question to give such a general answer. Consider getting the following book by my peers, Performance Analysis for Java Websites by Stacy Joines, Ruth Willenborg, Ken Hygh. This book is full of advice on sizing Web sites and performance testing applications.

On your second question, scripting is a powerful way to automate many of the tedious and manual tasks done by developers, assemblers, deployers, and administrators. Manual deployments can be successful for small to medium size applications if your application packaging is simple. However, automation can help eliminate repetitive tasks and free up resources for other tasks. This is a major theme in my book, IBM WebSphere: Deployment and Advanced Configuration. We analyze various assembly and deployment models and show why automation through scripting is beneficial.

Question: We have developed a J2EE banking Web application. After launching, we are facing serious complaints from account holders that the site is too slow to browse and unable to connect. We understood the problem that morning hours (9-11) we would get 500 concurrent connections. We are afraid that WebSphere server is unable to connect more than 500 users at a time. Is there any way to optimize the performance of the application. Please tell us the performance optimization technology that most popular sites do. (submitted by Brijesh)

Answer: There is no simple answer to performance problems. Problems can range from application issues to configuration. I once had an application crawl on garbage collection because developers did not initialize their StringBuffers in their logging framework. To solve your performance issues, see Performance Analysis for Java Websites.

In general, performance testing should be a major part of your deployment process before hitting production. I need more information to your problem. When you say 500 concurrent connections, I assume you mean the Web container. Are you clustering your application? Do you have a Web server? Examine the various topologies in the following resources:

Question: Is there a way to interface legacy RPGLE programs on an I-Series to VARPG. In other words, to front-end GUI screens to the programs already designed and running on the AS400?

Answer: This is really outside my area of expertise. However, you may want to look into the following products:

Question: I connect with MQ 5.3 languages different from Java (such as Borland Delphi and C++ ) using the library from WebSphere MQ - mqic32.dll. But, the problem is in transferring messages to JMS-format before sending. Does IBM have a dll library or something else to work with JMS operation in languages different from Java?

Answer: You need to set the Target Client Flag on the WebSphere MQ Queue configuration to MQ.

This is covered in JMS Topologies and Configurations with WebSphere Application Server and WebSphere Studio Version 5. You can set the target client under the configuration of a WebSphere MQ Queue.

Figure 2. New WebSphere MQ Queue
New WebSphere MQ Queue

By setting this to JMS, your JMS program is limited to only understanding messages written or Read by other JMS programs. By setting the target client to MQ, JMS programs inside WebSphere can understand messages written to WebSphere MQ by the other APIs supported by MQ.

Figure 3. Setting target client
Setting target client


The author would like to thank Kyle Brown and Beverly DeWitt in helping prepare this article.

Related information

About Meet the Experts

Meet the Experts is a monthly feature on the developerWorks WebSphere Web site. We give you access to the best minds in IBM WebSphere, product experts and executives, who are waiting to answer your questions. You submit the questions, and we post answers to the most popular questions.


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Meet the Experts: Roland Barcia on using JMS and JSF