The report breaks down the use of social media by Social Technographic role by type of social media involvement (types explained in this PPT):

(Click To Enlarge)

The “Overall” column indicates what percentage of those surveyed fell into that type of social media activity. Note that, obviously, there is overlap between roles—Creators, who generate online content, can also be Critics, who leave blog comments, etc.

Takeaways here:

• 91% of these decision-makers consume social media including blogs, video, and customer reviews.
• 69% of Spectators use social media for business purposes.
• 55% of the B2B buyers in this survey are Joiners—they’ve created profiles on social networks.
• After Spectators, the most popular role is Critics (again, people who leave comments on blogs, review products, etc.), with 58% of those sampled engaging in this activity, and 37% using it for business purposes.
• Other than the Inactives, B2B buyers in IT fields were more engaged in social media—but the gap between IT buyers and non-IT buyers is narrowing.
• 43% are creating media, including blogs and videos.

The report also made some recommendations and general observations, including:

• Buyers use social technology but don’t rate it highly in terms of its influence on their buying decisions, despite the fact that they count on peers’ opinions to make decisions.
• Social applications should be integrated into other marketing. For example, National Instruments makes technical content from its customer community central in its marketing activity—this is a model other B2B sellers should follow.
• Reach out to people by role—people with the same job description form natural communities.

What other applications can we see from this information?

Comments

“InterAction5.5 provides more ways to collect information, more ways to distribute that information to professionals, marketing and business development teams, and more ways to leverage Relationship Intelligence internationally,” said John McDonnell, vice president and general manager of LexisNexis InterAction. “We’ve built upon the rock-solid InterAction platform and expanded its capabilities . . .”

One of the most touted features of InterAction 5.5 is its ability to generate a large variety of reports. These include Who Knows Whom, Win/Loss Analysis on Opportunities, Marketing Event Analysis, and Customized Overview Reports. Reports can also be created in Microsoft Reporting Services, Crystal Reports and common file formats including Microsoft Access (.mdb), Microsoft Excel (.xls) and Extended Markup Language (.xml).

Gregory Trinh, Director of Marketing Technology at Pillsbury Winthrop Shaw Pittman LLP, seemed pleased with these advances. “InterAction’s new reporting facility will significantly enhance our ability to respond quickly to professionals’ information requests by enabling us to aggregate and deliver internal and external information.”

InterAction is intended to work in a wide variety of settings and countries, as it supports Unicode data, which will allow for the integration of contact information in any language or character set. Additionally, “InterAction 5.5′s internationalization and global mailing support will greatly enhance our ability to effectively communicate with clients and market to prospects worldwide,” said Sunny Bane, marketing CRM manager at DLA Piper Rudnick Gray Cary US LLP.

Synchronization with the Microsoft Outlook is another feature of the software, as is the ability to securely link with almost any type of document. This latest version of InterAction should be a useful upgrade for followers of the product.

“The breadth, depth and quality of this new release demonstrates LexisNexis’ commitment to the InterAction platform and to ensuring that it continues to raise the bar by which all professional services CRM solutions are judged,” said McDonnell.

Add to | DiggThis | Yahoo! My Web

Technorati:

Doug is a staff writer for WebProNews. Visit WebProNews for the latest eBusiness news.

Tacit interactions require judgement or expertise, not entirely rules based. Using IT to support tacit interations was more difficult before. More difficult to automate because users are trying to do something different every time. In the next phase of software they think it is possible.

Four categories of opportunity:

1. Timely access to information and context: Increases access to data and information at the right time in the right context for decision makers

2. Improved decision making: Supports decision making through tools that allow a better use of data and the presentation of relevant information

3. Enchanced communication: Enhances and expands the reach of communications and increases the richness of the message

4. Better collaboration: Enables and improves collaboration by facilitating transfer, sharing and simultaneous process of information

General apps and back office applications are moving to SaaS, Infrastructure and Tools are not.

On Tacit Interaction, this has been a constant thread of this blog and something John Seely Brown has been expanding upon for some time using different language (social fabric as 5% of IT spending, focus on exceptions. etc.).

Add to | Digg | Yahoo! My Web

Technorati:

Ross Mayfield is CEO and co-founder of Socialtext, an emerging provider of Enterprise Social Software that dramatically increases group productivity and develops a group memory.

He also writes Ross Mayfield’s Weblog which focuses on markets, technology and musings.

It’s a good overview of what’s happening and makes the case well. None of it will be news to anyone in the business blogging community, but will be a great starting point for those who aren’t (ie, the paper’s general readership).

Key message:

[...] It’s the interaction between blogs that makes them so interesting and influential. A single blog can be akin to a ranting madman on the corner. However, when linked together into massive intertwining communities, they have the vibrancy and passion of a massive street market, with information, opinions and whispers exchanging hands at light speed. And it’s no longer confined to techy chats. Conversations about every conceivable subject take place. And as the quantity and quality of these conversations grows, so does the blogosphere’s influence beyond the internet, including the commercial sector.

Links:
The Independent newspaper
James Cherkoff
Open Source Marketing

Reader Comments…

Neville Hobson is the author of the popular NevilleHobson.com blog which focuses on business communication and technology.

Neville is currentlly the VP of New Marketing at Crayon. Visit Neville Hobson’s blog: NevilleHobson.com.

This article cuts through all that and reveals to you the two most important things you need to know about creating a website that brings more profit to your business..

Secret Number 1 – Information

Yes – that’s all it is – information. Just think about this for a minute – what is the sole reason for anyone surfing any website anywhere across the world? Every single one of them is looking for just one thing – information. The information might take the form of text, an image, a sound file or whatever but at the end of the day it is information. This is the first biggest and best-kept secret of success on the internet and now you know it!

What do you mean ‘So what?’. The sole purpose of your website is to provide its visitors with information – think about this the next time some combat-trousered graphic designer tells you a big Flash graphic would be a good thing to have instead of a homepage.. People are looking for information – don’t put anything in the way of them getting this. Make sure the information you have on your site is easy to find, worthwhile reading and ideally easy for your visitors to disseminate onto their friends and colleagues.

Information is also essential if you are going to gain any influence with the search engines. They might only be computer programs but those search engine critters can be quite clever at discerning a website that contains nothing of any use and one that has useful information relevant to its target audience. Lots and lots of high quality relevant content on your website will do more for your website’s overall success than a fancy graphic or rotating picture of your head on the homepage.

Secret Number 2 – Interaction

Goto your website. Just look at it. Go through a few pages. Imagine that you had hit ‘Print’ on each of those pages. Would the experience of reading the pages in hardcopy be exactly the same as reading them on the screen? If it would you don’t own a website – you own an expensive brochure. Interaction is why the internet was born – it is the one attribute and opportunity that sets the medium apart from print and anything else. Your website needs to be littered with things that enable interaction between you and your visitors. Feedback forms, downloads, bookmarking tools, contact options, newsletters etc.

Information and interaction – together these are the only things that matter when it comes to the internet. Now go back, look at your site and appraise it honestly in terms of how well it addresses each of the two facets. Is it full of interactive features that enable people to get closer to your business and control their browsing experience? Does it provide lots of valuable information that is easy to find? Armed with these two secrets you can start to truly harness the real power of the internet. Good luck!

You can get free access to lots more of my articles plus a FREE Special Report “How To Turn Your Website Into A Customer Magnet” worth a value of 47 ($85) here: http://www.magnet4web.com/website_services/?page=freeguide

The new Tomcat 5 server takes filters to a new level of deployment flexibility. Tomcat 5′s support for the upcoming Servlet 2.4 and JSP 2.0 specifications gives filter writers a new way to integrate and deploy these flexible components — tapping directly into the request dispatcher’s operations. In this article, Sing Li takes you on a guided tour of the new enhancement and gives you some hands-on training. See how Tomcat 5 can benefit Web application frameworks and lead ultimately to the design of maintainable high-performance systems.

Back in June 2001, I wrote an article that previewed the (then) brand-new Servlet 2.3 feature called filtering (see Resources). The Tomcat 4.x server supported this feature, and filters enabled Web application developers to create flexible application components that could be inserted and chained into the application server’s request flow — before and after the actual request was processed. And because filters are packaged as application-level components, on a par with JSP pages and servlets, they can easily be bundled in the same WAR file for deployment on any Servlet 2.3-compliant server. Since then, major application server vendors have embraced the Servlet 2.3 standard to support filtering, and filters have become a cornerstone component of many Web applications.

Readers who are unfamiliar with filtering operations — or who would like a refresher on how to construct filters and how filters work — are encouraged to read the first Tomcat filtering article.

Servlet 2.4 filter enhancements

Based on actual “in-the-field” feedback from the Web development community, the Servlet 2.4 specification — now being finalized — gives filters a single, highly important new capability. This new capability finally enables filters to play on completely level ground with servlets and JSP pages, enabling Web application designers to add major application functionality using filters. This new capability also facilitates a highly popular new style of Web application design called JSP Model 2, or Model View Controller (MVC) Web application design. (See Resources for more information on JSP Model 2 or MVC-styled Web application design.)

Filters in the request dispatcher’s processing flow

The new filtering feature in Servlet 2.4 basically alleviates the restriction that filters can only operate in the request flow before and after the actual request processing by the application server. Instead, Servlet 2.4 filters can now interact with the request dispatcher at every dispatch point. This means that when a Web resource forwards a request to another resource (for instance, a servlet forwarding the request to a JSP page in the same application), a filter can be operating before the request is handled by the targeted resource. It also means that should a Web resource include the output or function from other Web resources (for instance, a JSP page including the output from multiple other JSP pages), Servlet 2.4 filters can work before and after each of the included resources. Figure 1 illustrates the difference between Servlet 2.3 and Servlet 2.4′s dispatcher interactions.

Figure 1. Servlet 2.3 and Servlet 2.4 filter differences

Controlling filter dispatcher interactions

The interaction of filters with the container’s request processing flow is configured through the element definition in the deployment descriptor (web.xml file). This is the convention established in the Servlet 2.3 specification, and it has not changed in Servlet 2.4. Instead, the new ability to interact with the dispatcher is controlled through a new optional sub-element. Listing 1 shows a element in a deployment descriptor that uses the sub-element to apply a filter called “Blue Filter” to any JSP page that may be included (assuming that all the JSP pages in the application are mapped to the /jsp/* URL pattern):

Listing 1. Servlet 2.4-styled filter mapping

Blue Filter /jsp/* INCLUDE

To apply the same filter to dispatcher-forwarded resources as well as included resources, we simply add another sub-element, as shown in Listing 2:

Listing 2. Mapping forwards and includes

Blue Filter /jsp/* INCLUDE FORWARD

The values that a sub-element can contain are shown in Table 1:

Table 1. Possible values for a sub-element

All of the values in Table 1, of course, are still subjected to the match specified by the sub-element of . Essentially, only the URLs that match the and the sub-element will be filtered.

To better appreciate the operation of the new filter/dispatcher interactions, let’s put some filters to work in a Tomcat server.

Configuring Tomcat 5 filters

Assuming you have Tomcat 5 installed and running with the JSP Standard Tag Library 1.0 (see the sidebar “Downloading and installing Tomcat 5 plus JSTL”), we can now work with some actual filter examples. Download the source code to get our sample Web application.

Let’s look at the coding of a couple of JSP pages and filters. The resources we’ll work with initially are:

• /jsp/filtercount.jsp
• /jsp/included.jsp
• AddAttributesFilter
• RedFilter

The filtercount.jsp resource is quite simple, and consists of the code shown in Listing 3:

Listing 3. Code for filtercount.jsp

<%@ taglib uri="http://java.sun.com/jstl/core_rt" prefix="c" %> developerWorks Tomcat 5 Filters The BlueFilter has been activated ${requestScope.BlueCounter} times. The RedFilter has been activated ${requestScope.RedCounter} times.

This JSP page calls the dispatcher to include another JSP page called /jsp/included.jsp. It also uses the JSTL Expression Language to print out the value of two counters (RedCounter and BlueCounter) that are attached as attributes to the incoming request, if the counter exists, and if the count is greater than zero.

In fact, each counter is used to count the number of times that either RedCounter or BlueCounter is called during request processing. Table 2 shows the filters we will use and what they actually do.

Table 2. Names and functions of filters in experiment scenarios

All of the filters in Table 2 are part of the com.ibm.dvworks.filters package.

The code for com.ibm.dvworks.filters.AddAttributesFilter is presented in Listing 4. Note that it simply creates the two counter attributes as java.lang.Integer type, which has a value of 0.

Listing 4. Code for AddAttributesFilter.java

package com.ibm.devworks.filters; import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public final class AddAttributesFilter implements Filter { public static final String RED_COUNTER_ATTRIB = "RedCounter"; public static final String BLUE_COUNTER_ATTRIB = "BlueCounter"; private FilterConfig filterConfig = null; public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { request.setAttribute(RED_COUNTER_ATTRIB, new Integer(0)); request.setAttribute(BLUE_COUNTER_ATTRIB, new Integer(0)); filterConfig.getServletContext().log("Inside AddAttributesFilter"); chain.doFilter(request, response); } public void destroy() { this.filterConfig = null; } public void init(FilterConfig filterConfig) { this.filterConfig = filterConfig; } }

The construction of this filter follows the basic filter coding pattern. Again, refer to the first article for more details on coding filters.

Similarly, com.ibm.dvworks.filters.RedFilter has the code shown in Listing 5. Note that the code simply looks for the RedCounter attribute and increments it if found.

Listing 5. Code for RedFilter.java

package com.ibm.devworks.filters; import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public final class RedFilter implements Filter { public static final String COUNTER_ATTRIB = "RedCounter"; private FilterConfig filterConfig = null; public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { filterConfig.getServletContext().log("Inside RedFilter"); Integer curCount = (Integer) request.getAttribute(COUNTER_ATTRIB); if (curCount != null) request.setAttribute(COUNTER_ATTRIB, new Integer(curCount.intValue() + 1)); chain.doFilter(request, response); } public void destroy() { this.filterConfig = null; } public void init(FilterConfig filterConfig) { this.filterConfig = filterConfig; } }

The com.ibm.dvworks.filters.BlueFilter class has identical code to RedFilter, except the constant COUNTER_ATTRIB is defined to be BlueFilter, as shown in Listing 6:

Listing 6. Code change for BlueFilter

public static final String COUNTER_ATTRIB = "BlueCounter";

The filtercount.jsp file uses the dispatcher to include the included.jsp file. The included.jsp file simply creates a table that is filled with the color specified by the input parameter called BoxColor. Note the use of the Expression Language (EL) in rendering the color in the table, as shown in Listing 7:

Listing 7. Code for included.jsp

this page is included in-line using dispatcher

With these filters and JSP pages, we are ready to begin our exploration of five different filter configuration scenarios.

Scenario 1: Standard Servlet 2.3 filter interaction — REQUEST only
In this first scenario, we will configure our filters to work in a manner supported by older Servlet 2.3 containers.

The element that we will use is shown in Listing 8:

Listing 8. Filter mapping for Standard Servlet 2.3 compatibility

Add Attributes Filter /jsp/* Red Filter /jsp/*

Edit your web.xml to reflect the Listing 8 configuration. Here, we are not specifying a sub-element. This means that the filters will be applied on a REQUEST-only basis, as it did in Servlet 2.3 containers. The configuration in Listing 8 is operationally identical to the code in Listing 9:

Listing 9. Equivalent Servlet 2.4 filter mapping

Add Attributes Filter /jsp/* REQUEST Red Filter /jsp/* REQUEST

Start Tomcat 5, and access the Web application using the http://:8080/dvworks/jsp/filtercount.jsp URL. Figure 2 shows the response generated by filtercount.jsp:

Figure 2. Servlet 2.3-compatible REQUEST filtering

According to the filtercount.jsp response, RedFilter has been called only once in this scenario. Figure 3 is a detailed interaction diagram showing the request flow through the request processors:

Figure 3. Servlet 2.3 filtering request flow

In Figure 3, the filter chain is called only once — as the request enters the system from the client.
The filter chain, of course, consists of AddAttributesFilter and RedFilter, as shown in Figure 4:

Figure 4. Details of the filter chain

In this Servlet 2.3-styled configuration, RedFilter is applied only once on the incoming request directly from the client.

Scenario 2: Combining REQUEST and INCLUDE interactions
The filter mapping we will use for this scenario is shown in Listing 10. Note the use of the Servlet 2.4 syntax and the addition of the INCLUDE dispatcher sub-element to RedFilter.

Listing 10. Filter mapping for combined REQUEST and INCLUDE interactions

Add Attributes Filter /jsp/* REQUEST Red Filter /jsp/* REQUEST INCLUDE

Restart Tomcat 5 and access the application again with the http://:8080/dvworks/jsp/filtercount.jsp URL. The response shown in Figure 5 displays the filter count.

Figure 5. REQUEST and INCLUDE filtering

Now RedFilter has been called twice — once during the incoming request, and the second time with the inclusion of included.jsp. The two calls are detailed in the interaction diagram shown in Figure 6. Note that we have simplified the diagram by showing only the flow of the request into the system (and not the detailed return flow as was done previously).

Figure 6. Combined REQUEST and INCLUDE interaction

Scenario 3: Combining REQUEST, INCLUDE, and FORWARD interactions
Next, we will bring in another simple JSP page, called forwarder.jsp, shown in Listing 11. It simply uses the dispatcher to forward the incoming request to filtercount.jsp.

Listing 11. Code for forwarder.jsp

Now we can add BlueFilter to the deployment descriptor, as shown in Listing 12:

Listing 12. Filter mapping for combined REQUEST, INCLUDE, and FORWARD interactions

Add Attributes Filter /jsp/* REQUEST Red Filter /jsp/* REQUEST INCLUDE Blue Filter /jsp/* FORWARD

BlueFilter is configured to handle forwarded requests only, while the rest of the filter mapping remains unchanged.

Restart Tomcat 5 and access the application with the http://:8080/dvworks/jsp/forwarder.jsp URL. Figure 7 shows the response.

Figure 7. REQUEST, INCLUDE, and FORWARD filtering

In this case, we see that BlueFilter is actually called once — during the forwarding of the request from forwarder.jsp to filtercount.jsp. The interaction diagram in Figure 8 shows the flow.

Figure 8. Combined REQUEST, INCLUDE, and FORWARD interactions

Scenario 4: Combining REQUEST, INCLUDE, FORWARD, and legacy Servlet 2.3 interactions
In this scenario, we are adding a filter from the previous filtering article (see Resources). You can use ReplaceTextFilter to replace text in the response. We configure it using initial parameters in the definition shown in Listing 13:

Listing 13. Filter definition for ReplaceTextFilter with initialization parameters

Replace Text Filter com.ibm.devworks.filters.ReplaceTextFilter search color="red" replace color="green"

We then add the following to the ones used in the previous scenario, as shown in Listing 14:

Listing 14. Filter mapping for combined REQUEST, INCLUDE, FORWARD, and legacy Servlet 2.3 filter interactions

Replace Text Filter /jsp/* ...

Note that we are not specifying a sub-element here, and therefore this filter is defaulting to REQUEST-only processing.

Restart Tomcat 5 and access the http://:8080/dvworks/jsp/forwarder.jsp URL. You should see something similar to Figure 9. Unlike the previous configuration, now the included box is green.

Figure 9. Combined REQUEST, INCLUDE, FORWARD, and legacy filtering

The interaction diagram shown in Figure 10 illustrates how ReplaceTextFilter is handed the response for final processing before passing it back to the client. It is here that the color of the table is changed from red to green.

Figure 10. Combined REQUEST, INCLUDE, FORWARD, and legacy interactions

Servlet 2.4 containers are completely backward compatible with Servlet 2.3 filters, definitions, and mappings.

Scenario 5: Filtering on ERROR dispatch
For the final scenario, we will briefly examine the application of a filter when dispatching to an error-handling page. The filter mapping that we will use is in Listing 15. Make sure you remove all other filter mappings in web.xml.

Listing 15. Filtering on ERROR

Red Filter /jsp/* REQUEST INCLUDE ERROR

To purposely generate an error, we create a JSP page, called errorgen.jsp, which sets up a page called errorhdlr.jsp to handle an error, and then throws an exception, as shown in Listing 16:

Listing 16. Code for errorgen.jsp

<%@page errorPage="/jsp/errorhdlr.jsp" %> <% if (true) throw (new Exception("Purposely generated exception!")); %>

When an error is caught by the page, the container forwards the request to the /jsp/errorhdlr.jsp page, as specified in the @page directive. The errorhdlr.jsp page contains the code shown in Listing 17:

Listing 17. Code for errorhdlr.jsp

<%@ taglib uri="http://java.sun.com/jstl/core_rt" prefix="c" %> <%@page isErrorPage="true" %> developerWorks Tomcat 5 Error Page The BlueFilter has been activated ${requestScope.BlueCounter} times. The RedFilter has been activated ${requestScope.RedCounter} times. Error information: ${pageContext.errorData.throwable.message}

The errorhdlr.jsp prints out the filter counter values, then prints out the message of the exception being caught using the EL.

Restart Tomcat 5 and access the http://:8080/dvworks/jsp/errorgen.jsp URL. Even though you attempt to access errorgen.jsp, it is errorhdlr.jsp that will be displayed (because an exception is explicitly thrown). The error page that you will see is shown in Figure 11:

Figure 11. REQUEST and ERROR filtering

Note that RedFilter has been called twice — once at the REQUEST level and a second time when the container forwards to the error page.

You can apply Servlet 2.4 filters just before the processing of a custom error-handling Web resource.

Filters and Model 2 Web application frameworks
The enhanced filtering capability in Tomcat 5 provides new deployment opportunities when using popular application frameworks. Frameworks such as Struts and Turbine (see Resources) use a JSP Model 2 architecture to separate data operations (the Model in an MVC pattern) from the business logic operations, and the presentation operations (the View). Their functionality centers around the use of a switching servlet (the Controller servlet) that forwards incoming requests to different user-created Action components, either according to a static XML directive file or using runtime introspection. These requests are typically further forwarded between components, until the response is complete. The Model 2 architecture enables designers to componentize their server-side coding for adaptability to change and easier long-term maintenance.

Because the dispatcher is used extensively to forward requests between the controller servlet and the application components, as well as between application components, you can readily add filters to the processing flow. With the Servlet 2.4 enhancements, filters can now become an integral part of a Web application’s components mix — when using Model 2 application frameworks.

Pipelining your application toward a high-performance future
Pipelining is a request flow-centric view of componentized request processing. It focuses on the multistage processing of a single request as it flows through the application server.

In the pipeline model, a request flows through an assembly line (the pipeline) while at each stage being modified/transformed/processed by a series of processors, until finally the response is generated and expedited back to the client. Popular Web application frameworks such as Jakarta Struts and Turbine, through the virtue of their JSP Model 2 architecture, already componentize the server-side logic in a pipelined fashion.

Figure 12 shows the typical pipeline stages that a Web application or service request may flow through when displaying a page of data:

Figure 12. Typical stages of the pipeline model

In summary, the request is passed through the three pipeline stages shown in Table 3:

Table 3. Pipeline model stages

By placing design focus on the request processing pipeline, Web application design is entering a new era of performance tuning and optimization possibilities. Many of the same techniques being exploited in modern microprocessor hardware design — in the optimization of pipelines — can be leveraged in the near future for optimization of Web application server software and hardware.

For example, in a Web application that has similar requirements for every request flowing through the data fetch stage of processing, the optimized application server/hardware platform can prefetch and locally cache the most commonly accessed data — completely eliminating the data fetch overhead for most incoming requests. Another example — for requests that demand significant CPU processing resources in the rendering stage, such as XSLT transformation or other XML parsing — a parallel bank of hardware-accelerated XML processors can be configured in the rendering stage of the pipeline. While these optimizations are still slightly futuristic in terms of practical ability to implement them today, designing Web applications with consideration for the pipeline model is a necessary element to make them reality.

Conclusions

Tomcat 5′s new filtering feature enables us to tap into every stage of the Web application’s request-processing flow. This capability facilitates the use of filters with application frameworks and opens up new performance optimization and tuning possibilities.

Resources

• Download
  the Web application, filters, and JSP source code for this article.
• For an introduction to Tomcat filters, how they work, and how to code them,
  read “Filtering
  tricks for your Tomcat“, also by Sing Li (developerWorks, June 2001).
• Download the latest version of Apache Tomcat at the official
  Tomcat Web site. You can download the alpha
  release of the Tomcat 5.0 server.
• Download the latest version of JSTL at the Apache
  Jakarta Taglib site. You can obtain the specification at JSR-52.
• At the time of publication, Mark Kolb is in the process of writing a four-part
  series on JSTL. Part 1, “The
  expression language” (developerWorks, February 2003), introduces JSTL
  and the EL; Part 2, “Getting
  down to the core” (developerWorks, March 2003), details flow control
  and URL management through custom tags.
• Filtering enhancements are described in the Servlet 2.4 specification. You
  can find the latest in JSR-154.
• The latest status and more information on the JavaServer Pages 2.0 specification,
  including coverage of the proposed Expression Language (EL), can be found in JSR-152.
• Learn more about Model 2 Web application development using the Struts application
  framework. See the official
  Struts Web site for detailed information and the latest developments.
• Learn how to use
  JSP and custom tags within VisualAge for Java and WebSphere Studio in this
  tutorial from WebSphere
  Developer Domain.
• Discover how to create “Advanced
  JSP Tag Libraries using Apache Tomcat and VisualAge for Java” (WebSphere
  Developer Technical Journal, July 2001).
• You’ll find hundreds of articles about every aspect of Java programming in
  the developerWorks
  Java technology zone.

First published IBM developerWorks (http://www-106.ibm.com/developerworks/java/library/j-tomcat2).

Sing Li is the author of Early Adopter JXTA and Professional Jini, as well as numerous other books with Wrox Press. He is a regular contributor to technical magazines and is an active evangelist of the P2P evolution. Sing is a consultant and freelance writer and can be reached at westmakaha@yahoo.com.