Loading in 2 Seconds...
Loading in 2 Seconds...
Web 2.0, AJAX, REST and others. Matthew Tan ( email@example.com ) Senior Solution Consultant, IBM Asia Pacific, SWG HQ 30 th October 2007. Agenda. Overview of Web 2.0 About AJAX About Rest and Others Application of AJAX, REST in ATOM / RSS and Web 2.0. What is Web 2.0 ?.
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Matthew Tan (firstname.lastname@example.org)
Senior Solution Consultant,
IBM Asia Pacific, SWG HQ
30th October 2007
Business Models that survived and have promise for the future
Approachessuch as services instead of products, the Web as a platform, ...
Conceptssuch as folksonomies, syndication, participation, reputation, ....
Technologiessuch as AJAX, REST, Tags, Microformats, ...
And many others ...
In the typical web application, each request causes acomplete refresh of the browser page
An Ajax application begins the same way.
in contextPortals provide governedbusiness mashups combining public information, enterprise apps and data
Security-Rich Composite application or view, that assembles and delivers services in the form of portletsin the context of a business process
Standards based access to integration and innovation
Common PIM Portlets
for Mail and Calendar Access
Custom Situational Application:
Simple AJAX Mail / Cal summary
views with awareness
Activity, Blog Services
Portlets, Notes Plugin,
Sametime Plugin, Desktop Integration
Persona, Community Services
Team Space Services
Custom Situational Application:
Problem tracking application
allowing to see author presence
and location in map and contact via IM
Client Side Aggregation
Web 2.0 Fragment
Dojo Widget Markup
REST Calls to Portal Services
User Profile Access
Persistence Service Access
REST Calls to other Services, e.g. other WPLC services
Weather Info, News, Sports, …
CRM, HR, … Services
REST-accessible Markup Fragments
from WP Portlets or any other URL
Atom / RSS Feeds
Services created with Google Gadgets
IBMST Thomas SchaeckST 5 Technology Park Dr 555-5555ST Westford, MAST
Click to dial
From an end user perspective, Google Gadgets integrated in WebSphere Portal behave just like local portlets: viewable and customizable like any local portlet
Google RSS Feed
Lists, Doc Libs,
HTTP or other Server)
AJAX Programming Model Extensions
(Dojo Framework & Widgets + AJAX.0 + REST accessor JS functions + Semantic Tags + Client Side Click-2-Action)
REST style Portal Services
(Persistence, User Profiles, Portlet Settings, Navigation, Pages, etc)
WebSphere Portal Foundation
WebSphere Application Server
This article introduces the idea of integrating Ajax into your portal applications. Since there are many Ajax articles already available (see Resources), we assume that you understand the basics of Ajax. This includes what Ajax means, how it got its name, the fact that it's not new, and how Google brought this technology into the mind set of every executive and technologist on the planet.
My intention is to equip you with useful information related to using Ajax in your portal applications, so when the CTO's office asked if your portal applications are Ajax enabled, you can stand up and say, “Definitely.”
Therefore, this article describes areas to consider if you decide to inject Ajax into your portal. While the focus is on portal applications, the tips are generally applicable to most complex applications. This article also prepares you for a future tutorial, in which we will detail the creation of an Ajax portlet application.
One of the most expensive actions in a portal environment is to refresh the page.
When the user clicks a link or takes some other action on the page, the portal processes theactionPerformed()methodfor the target portlet and thedoView() methodsfor each portlet on the page. Then, it aggregates the results and sends the entire HTML document down to the browser.
While caching can reduce a lot of the overhead, there is still a lot going on.You could use Ajaxto handle many of the user interaction events in the background, and then to update portions of the page,without requiring a full portal refresh cycle. This technique greatly improve the end-userexperience by increasing theresponsiveness of individual actions, and the overall application performance. In many circumstances, using Ajaxcontributes to a cleaner overall architecture of your application. Having a secondary Ajax controller (such as a servlet or Web service) forces a stronger separation of your model code.
When applying a full Ajax controller design to your application, you should let the Ajax controller handle all basic user input actions and segmented display updates. Only use the portal actionPerformed() method for page-level transitions or to process major state changes.
So, why would you not want to use this new fangled paradigm in rich internet applications? All the weekly technical magazines insist that this is the way to go, and besides, your boss told you to use it because it's "one of our business goals." OK, we won't tell you not to use it, but we do want you to know about some potential pitfalls:
Using multiple controllers (for example a portlet, a servlet, and a Web service) adds to the complexity of the application.
Your application might not require extra data updates to the browser between pages.
So with all that said, you might decide that Ajax isn't for you and you will find another article to read. Wait, that's no fun. Read on, my friend, this stuff is way too cool not to add to your applications.
The bottom line is to take it slow. Find an application that could use a little kick, and add a dash of Ajax to a user form or wizard. Once you get your feet wet and understand how a little effort can produce some effective user enhancements, you will be ready to really add some magic to your portal applications.
Listing 1. Servlet mapping in the web.xml<servlet> <servlet-name>MyAjaxServlet</servlet-name> <display-name>MyAjaxServlet</display-name> <description></description> <servlet-class> com.ibm.ajax.MyAjaxServlet </servlet-class> </servlet> <servlet-mapping> <servlet-name>MyAjaxServlet</servlet-name> <url-pattern>/Ajax</url-pattern> </servlet-mapping>
As with any external resource to be added to a portlet page, you must encode the URL and set the base context, as in Listing 3.
There are several issues that you should be aware of when implementing Ajax in a portal application.
Tip: If you use an Ajax toolkit, the abstraction layer will resolve any naming conflicts.
ID attributes are often used in Ajax to quickly update a portion of the page. Because ID attributes within any HTML tag are global to the DOM, you need to make sure they are unique. If you have duplicate ID attributes, then results are unpredictable but generally not what you want, and the problem can be maddening to track down.
To be safe, namespace all ID attributes, even though doing this can make your code difficult to read, as you can see in Listing 5.
Listing 5. Safely namespacing an ID attribute.
Other state issues that can easily trip you up are the back button and bookmarked URLs. In general, avoid major state changes based on Ajax. Leave that to real portal actionPerformed() calls.
Action URLs can be very tricky to deal with when using Ajax. In general, you should not attempt to store Action URLs in the shared session, because they are only valid for the current doView(). Attempting to use an ActionURL that was stored in the session from a previous doView() cycle will cause unpredictable results.
An example of when you would want to store Action URLs into the session is an Ajax-driven paging data table that contains Action URL links as part of the data set. When the user clicks Next, the browser generates an Ajax call to the servlet. Then, the servlet extracts the next page of data from the session, and it must have predefined Action URLs. Just be sure that anytime a doView() call is processed that any session data holding any Action URLs is regenerated.
Portal pages are often very busy, with a lot of aggregated information stuffed onto a single page. Because Ajax calls are performed in the background and they do not trigger the activity icon on the browser, you need to provide a consistent, visual mechanism to inform the user that something is going on. Otherwise, they can get confused and not know that the application is busy processing some action. (We surely don't want confused users.)
You could implement this notification using a floating DIV section display during activity, or using a simple message on the browser's status bar (although this is considered bad form by some). You could also integrate a custom theme extension that would display a common Please Wait message for any Ajax-enabled portlet on the page.
In this article, we described how and why you would use Ajax in your portal applications.
Introduction to Ajax on DeveloperWorks
Mozilla Developer Center
Ajax in Action
Dynamic HTML, The Definitive Guide, O'Reilly
Build enterprise SOA Ajax clients with the Dojo toolkit and JSON-RPC
Get products and technologies
Ajax Toolkit Framework (IBM alphaWorks)
Ajax Toolkit Framework (eclipse.org)