In reality the code for this framework becomes pretty simple once things are setup. The Servlet needs to be set up within the web.xml and can be invoked like any other Servlet. The web.xml would have something like this...
Initially I setup a simple function that echoed any text that a user typed into an input field. I was able to get some help from a colleague, Varad Ramamoorthy, on a second function, which polls the Servlet every 60 seconds for a time value to display. This to me can add real value to a portal, where users can receive an alert without refreshing the screen. I am thinking more about a call center type of application then an employee workplace in this scenario.
I was accessing the Servlet using the application path, i.e., /wps/PA_0_0_F/MyServlet or something like that. The problem with this is you have to wait until the .war file is installed and then determine the path. Varad was able to show me how I could use the renderRequest.getContextPath() to do it much easier. We also started taking an initial look at performance issues and how these functions may affect in session memory. We are going to dump the full code along with lots of explanations in an article over the next few weeks, which we will publish somewhere soon.
Admittedly we are just scratching the surface, but I always look at these things as an evolution of functionality and the skills required to take advantage of new technologies. And of course, as always, I often proceed with caution, because I often have to advice clients on what is the best approach. I would be curious about where folks are using this in their portal, if at all and any advantages, disadvantages they have found?
Portal in Action
with Tags: advanced X
JoeyBernal 1200007EAE Tags:  planning design portal advanced best_practice performance 2 Comments 2,799 Visits
Wow, I have a lot to talk about! I am doing some deep dives into a number of technologies, trying to come up with some ways to help customers use portal better. There are some areas around best practices that have been lagging, such as integration concepts, that are going to become even more important as folks move more toward SOA in the Enterprise, and providing interactive services using a portal. This will become more clear over the next few months as I try and explain how SOA can make your life with the portal much easier in many respects, and sometimes harder in others.
In my last entry I talked about using a service layer. There was a reason for this discussion. For portal development I often find it useful to create an abstraction layer within the portal, especially when multiple portlets share the same data or access the same back-end resource. Folks who read this know that I am always harping about JSF and how I think sometimes the tooling can give new portal teams the wrong idea. Nothing too scary, but at times it can make things too easy. Here is a quick example. Last month I was asked to build a simple example of using SDOs in a portlet. Breaking out my trusty Rational Application Developer I set to work. I created a very simple cloudscape database that contained a list of addresses for different IBM locations and started to build a portlet that could list the data.
OK, this took about 5 minutes! We'll maybe 10 but I messed around a bit trying to figure out my database structure. Then I created a datasource in RAD, and used the embedded portal test environment to test the portlet. Using the RAD tooling to build a JSF portlet and then dropping the RelationalRecord component on the resulting JSP page was pretty much all it took. I had to answer a few simple questions about what data I wanted to display, but nothing beyond my sometimes limited capability.
Being extremely pleased with myself at this point, I thought a bit about the design and decided that in many cases this probably was not the best approach. Having a portlet talk directly to the back-end, as I mentioned above, may not be the best case. While the tool allowed me to quickly put this portlet together, I thought about the possibility of using this portlet in production. Too many users and there could become a bottleneck on the database during peak loads. Plus I didn't really know that the code that was generated was doing, and adding new features, like caching might become troublesome. More realistically, since I was pulling the same set of data for each user, I probably wanted to build a simple service layer that cached the data and allowed it to be shared between multiple components.
Some of you might be thinking I could have simply implemented the portlet display cache to cache the resulting HTML for some period of time to achieve the same result. This is absolutely correct and in this particular case would work perfectly. However even in slight variations of this scenario it wouldn't always work as I might need it to. For example, what if I was pulling information from several different sources. From one source I got exactly the same data for every user, however from another source I got more personalized data, or had to calculate the data based on some submitted value. There are different ways this could be handled and knowing all your caching options is very important for good portal application design. Front end caches such as the portlet display cache, portlet filtering, or even caching out on the edge, as well as back end data caches such as the distributed map, command, or web service cache can be just as important in many cases.
OK, back to the subject at hand. One of my personal goals with this exercise was to start getting a handle on Service Data Objects (SDOs) to leam more about how I can start to use this technology in my designs. SDOs are quickly becoming an important concept in many of the WebSphere products and offerings. Many of our development approaches and adaptors are starting to be based on this concept to allow a clean separation layer between the application and the data source. There are several resources available for folks who need to start learning more about SDOs. developerWorks has several articles on the subject.
One point though, while most of the articles cover the topic from a high or conceptual level, I did find it difficult to put together what I thought was a simple JDBC data example. Why more difficult then I thought it should be, but since it was my first time, I'll put the majority of the blame on myself and not on the technology. Here is my final result. yea, I'll admit it's pretty simple, but I am OK with baby steps for now. I'll expand this sample over time to allow for more complex queries and updating the information. Here is my simple class that returns a list object that is created from the data graph.
The one component that you will find missing here is the meta-data xml file that describes the data I'm attempting to upload. Also, ignore my system.out's please. I talk a lot about development standards, so this is one of those "do as I say, not as a do moments!" : )
Defining the data structure can be done either using the API or through a file. In this case I used a simple file that I actually let the tool create for me. Here is the meta-data file:
This file basically outlines the structure of the table that I created so that the SDO API can create the right data structure for the graph. Like I said, I could have done this directly in the code also.
OK, that's all for now. This is probably one of the simplest (complete!) examples of using SDO that you can have, so feel free to build your own example and see how you like it. Take a look on developerWorks for some of those SDO articles that I mentioned and see if they are right for your next project.[Read More]
A couple of requests have come in for more information about caching portal pages with a caching proxy such as WebSphere Edge Server Caching Proxy. A recent article published on developerWorks at: High Performance WebSites with WebSphere Portal, discussed in great detail different forms of caching that are available and some of the steps that you need to take to make page caching happen.
I have been playing with this for a while getting ready for a presentation on using some of these new advances with portal. It's actually kinda cool and provides new capability when used within your portal design. Understand that only complete pages are cachable at this level.
One issue that was raised was a potential conflict with users who bookmark different pages and then send those links to users in different geographies. If the recipeint uses a different host name to access the portal through their own local edge server, then the bookmarks might route them to the wrong place. One idea I had was to stick an HTTP server in front of those edge servers and use rewrite rules to redirect folks back through their local edge instance. I love using rewrite rules, even though I'm not very good at it. I use them sometimes for controlling access I usually just hack away using some examples until it works. I'm always getting caught in redirect loops where the server just hangs.
Testing out this scenario, I was able to add the following section to my http.conf
If you take a look at the rewrite conditions, I'm basically looking for any users coming in with a specific IP address who are not using the edge server to access the http server. If that is the case, I do a simple redirect back to the edge for all subsequent calls. It appears to work ok, but I did run into some trouble not finding some bookmarked documents. I'll keep playing with it until I get it working well enough to recommend as a potential solution.
Anyway, I thought this might be of interest to folks at least from an idea standpoint. If you have experience or just want to make fun of my regular expressions : ) feel free to comment.
FYI: Another article on portlet and portal caching showed up on devWorks this week. Feel free to check it out!
Have fun![Read More]