WebSphere Portal Web 2.0 Overview, Google Gadgets Integration & Client Programming Model

1. WebSphere Portal Web 2.0Overview, Google Gadgets Integration & Client Programming Model • Stephan Hesmer • WebSphere Portal Architect, Web 2.0

2. Strict „Web 1.0“ site „Web Master“ runs web site, users consume Few content editors Web site provides content and applications for users View-only markup Only human users Accumulates relatively small amounts of information and content Fixed categories / Taxonomy Unidirectional Modern „Web 2.0“ site Users collectively contribute to the web site, they don‘t just consume Every user is a content editor and rater Web site provides content, applications, and collective contributions of all users Semantically tagged markup Humans and applications as „users“ Accumulates huge amounts of information and content FlexibleTagging / Folksonomy Bi-directional App Data App Portal Portal App Data App Web 1.0 compared to Web 2.0

3. Web 2.0 Concepts that are interesting for enterprise use • Self-establishing Communitiescollaborating around topics of common business interest • Support User Contribution, treat users as co-authors and leverages their skills better • Accumulation of user knowledge to make apps smarter the more people use them • Enable users to add value by adding meta data, e.g. rate, tag, bookmark, comment • Allow users toTake Control and let them make applications most useful to them • Separate User Interface from Servicesto make services re-usable • Fine grained access to data supporting mashups • Mashupscombining existing services into new, useful applications joining information • Situational Development of applications through line of business can help make businesses more agile • AJAXto enable rich, interactive, highly responsive Web UI • Use of Semantic Tags and Microformats to enable dynamic augmentation with contextual menus or information

4. New Portal View for every mouse click Portal cluster unnecessarily stressed by rendereing entire pages Same Theme / Navigation View – no need to rerender Portal Server Cluster New Portlet View Same Portlet View – no need to re-render All data flows through portal and is rendered on portal HTTP GET/POST Data Server Data Server Data Server Button Data Server Data Server Clusters Same Portlet View – no need to re-render AJAX in Portal 1/2 - AJAX Enabled AggregationOne component model Full Page Update (traditional): • Portal Pages are assembled Server side • User Interactions trigger Full page reload • Backend Data is delivered through Portal • Single entry Point • Supports all types of browsers and security settings Approach can be selected based on • Admin choice • User choice • Browser capabilities • … Portal cluster less stressed than when rendereing entire pages Same Theme / Navigation View – no need to rerender New Portlet View Portal Server Cluster New Portlet View Client Side Aggregation: • Portal Pages are assembled in the browser • Page assembly managed by Portal • User Interactions trigger Portlet(s) reload only • Backend Data is delivered through Portal • Single entry Point • Supports most types of browsers and security settings • Improved performance and responsiveness • uses less network bandwidth Same Portlet View – no need to re-render All data flows through portal and is rendered on portal HTTP GET/POST Data Server Data Server Data Server Button Data Server Data Server Clusters Same Portlet View – no need to re-render Future Refreshed Markup Constant Markup ** Some of the ideas presented here may be delivered in future version of WebSphere Portal, but some will not.

5. Portal cluster less stressed than when rendereing entire pages or portlets Portal only renders Initial views Same Theme / Navigation View – no need to rerender Same Theme / Navigation View – no need to rerender Portal cluster gets no significant load from the AJAX portlet Server-rendered markup Portal Server Cluster Portal Server Cluster Other than Control View 1, no need to re-render Cachable AJAX Portlet View rendered in JWL Other than Control View 1, no need to re-render, no portlet view change, only data changes Same Portlet View – no need to re-render All data flows through portal and is rendered on portal Same Portlet View – no need to re-render HTTP GET/POST JSF Control View 1 JWL Client Ctrl All data delivered directly to browser, portal is no longer a bottleneck Data Server Data Data Server Data Server Data Server Data Server Button Data Server Data Server Button Data Server Data Server Clusters HTTP GET/POST Data Server Clusters Many Data Servers can be utilized via the single portal Same Portlet View – no need to re-render Same Portlet View – no need to re-render AJAX in Portal 2/2 - AJAX Enabled Components Single Widget Refresh (today): • Components are assembled Server side • User Interactions trigger Single Widget refresh • Backend Data is delivered through Portal • Single entry Point • Supports most types of browsers and security settings • Improved performance and responsiveness • uses less network bandwidth Accessing XML on Server (today): • Layout and View separated from Data access • User Interactions trigger data retrieval • Backend Data is delivered directly • Multiple entry Points • Needs to consider Browsers and security settings • Highly Improved performance and responsiveness • uses much less network bandwidth Refreshed Markup Constant Markup

6. REST style Web Services exposing Portal to Mashups • Goals: • Separate portal user experience from portal data • Expose relevant data separately for use by other apps ( Mashups) • Public REST style Web services for • Access to Navigation Node Hierarchy • Access to Page Definitions • Access to User Profiles • Access to generic Content Persistence • Access tomarkup fragments of individual portlets • Mashups can use these services to implement custom applications leveraging portal infrastructure services • WebSphere Portal’s Web 2.0 Client Side Aggregation uses these services as well

7. Emerging WPLC Services&Feeds and Application Examples Messaging Calendar Services Product: Common PIM Portlets for Mail and Calendar Access Mail Services Real Time Collaboration IM Service Custom Situational Application: Simple AJAX Mail / Cal summary views with awareness Conference Service Awareness Service Ventura Activity, Blog Services Geneva Portlets, Notes Plugin, Sametime Plugin, Desktop Integration Persona, Community Services Geneva Team Space Services Documents Services Custom Situational Application: Problem tracking application allowing to see author presence and location in map and contact via IM WebSphere Portal Search Service Contacts Service Persistence Service Product: WebSphere Portal Client Side Aggregation Portal Services Portlet Service User Service Google Maps

8. Web 2.0 Fragment Model for Web 2.0 components • Simple and extensible Web 2.0 fragment programming model • Agnostic of how fragments are generated, may be • generated by portlets on WebSphere Portal • generated by PHP code on Web.0 or PHP servers • generated by .NET servers • Can start simple, with option to grow more sophisticated • Basic fragments – HTML only • Slightly more advanced – add use of Semantic Tags • More advanced – add use of Dojo and custom JavaScript • Fragments can use public JavaScript interfacesto conveniently invoke WebSphere Portal’s REST style Web services

9. Web 2.0 Fragment Programming Model Web 2.0 Fragment Semantic Tags Dojo Widget Markup JavaScript Functions REST Calls to Portal Services User Profile Access Settings Access Persistence Service Access REST Calls to other Services, e.g. other WPLC services Weather Info, News, Sports, … CRM, HR, … Services etc

10. Web 2.0 Client Side Aggregation • Browser-side Aggregation, Navigation and Customization • Superior user experience • Highly reactive and direct user interface • Many actions possible without server roundtrips • Avoids page flickering • Accesses and manipulates portal information through REST services • Renders XML obtained from the server on the browser side • Implemented using AJAX, XML, Dojo, and JavaScript • Improved performance and scalability through • Reduced server side processing - offloads rendering to browser • Reduced bandwidth requirements between server and browser • Reduced client-side processing – mostly fragment reloads, few page reloads • Improved cachability, all artifacts can be cached independently

11. Semantic Tags, Context Menus and Drag&Drop Conference Participants ... IBMST Thomas SchaeckST 5 Technology Park Dr 555-5555ST Westford, MAST GroupST LocationsST‘ Click to dial D&D D&D • Extensible set of tag types such as person, address, phone number, document, ... is used to mark content elements with types (semantic tagging) • Behaviours like e.g. context menus, annotations, highlighting, drag & drop, etc can be applied to everything that is semantically tagged • Investigating use of UIMA for auto-tagging of markup

12. Google Gadget Integration

13. Google Gadget Integration • Enable customers to easily integrate Google Gadgets into pages • Allow admins to define Gadget Portlets for direct use by users • Additionally, allow users to drag Generic Gadget Portlet on their pages • Generic Gadget Portlet initially lets user select Gadget to displayfrom the Google Gadget Catalog (http://www.google.com/ig/directory) • The Generic Gadget Portlet then wraps the selected Gadget • User can use portlet customization to access Gadget customization • Business and technical discussions have already been started

14. Google Gadget IntegrationView Mode  Viewing the gadget • The portlet uses iFrames to display the gadget • iFrames are recommended by google • Still working on... • inline/html integration - some work on google needed • dynamic height • Accessed Google Service • The following URL is accessed to fetch the view mode of the gadget • http://gmodules.com/ig/ifr?url=<gadget-spec>&synd=ibmwsp&up_<name>=<value> • url  url to the google gadget spec • synd  identifier for the service • up_<name>=<value>  user personlization for this gadget

15. Example

16. Google Gadget IntegrationEdit mode  entering user personalization • The portlet directly embedds the HTML returned from the google service • the edit html fragment contains input form elements and a submit button. • The integration framework is required to put a FORM element around the retrieved HTML fragment. • This FORM element contains the POST url that is executed when pressing submit • Still working on: • CSS • Internatilization • Accessed Google Service • The following URL is accessed to fetch the view mode of the gadget • http://gmodules.com/ig/ifr?url=<gadget-spec>&synd=ibmwsp&output=edithtml&mid=<#> • edithtml  defines that embeddable HTML should be returned • mid  namespace for the paremeters created in the HTML fragment • Returned Content • m_<mid>_numfields  defines the number of fields to be filled in by the end user • m_<mid>_<#>  name of the element X (zero based) • if m_<mid>_numfields is 4, then there would be 4 parameters from m_0_0 to m_0_3 • m_<mid>_<name>  name/value of the element X

17. Example

18. Google Gadget IntegrationConfig mode  selecting gadgets from a catalog • The portlet transforms the RSS feed content into HTML using XSLT • Content is always fetched directly from google using various query parameters • search, number of elements, start number of elements, category, ... • Still working on: • Internatilization • dynamic categories, right now it is a fixed set • ... • Accessed Google Service • The following URL is accessed to fetch the view mode of the gadget • http://gmodules.com/ig/ifr?url=<gadget-spec>&synd=ibmwsp&output=rss&q=<search>&start=<#>&num=<#>&cat=<category> • rss  defines that rss feed should be returned • q  search string • start  start element • num  number of elements to be returned in the feed • cat 

19. Example

20. Google Gadget IntegrationHelp Mode  Show info about the gadget • Help mode not yet available on Google Gadgets • Current recommendation. Do not use Help Mode.

21. Web 2.0 - Portal Demo

22. Client Side Portlet Programming Model Draft

23. Overview • This CDD defines the programming model for client component such as portlets. • The Programming Model defines all required parts on the client and on the server. • On the client the programming model is based on DoJo and Javascript • On the server the programming model is based on JSP and tag libraries. • Wherever possible the programming model is aligned with open standards such as JSR 286 and WSRP

24. Design Requirements and Applicability • This design applies to the Portal Web 2.0 Techpreview • Easy programming model on the client and on the server • Needs to work in Server Side Aggregation and Client Side Aggregation • Needs to support IE 5+, FF 1.0+ and Safari x.y

25. Server - Basics • On the server a tag library is provided that is aligned to the DoJo model. • Define URI: http://www.ibm.com/xmlns/prod/websphere/portal/v6.1.0/web2-portlet • Through the tag library one can define which modules (e.g. dojo.*) are required • The tag lib will include required markup and other artifacts required to use the "required" module on the client • Defined Tags: • init • main tag, provides two variables: • portletWindowID: The serialized portlet window id • portletPageID: The serialized page id the portlet is on • required • only allowed within the init tag. Defines the client side artifacts that one wishes to use.

26. Server - Basics - Example <%@ taglib uri="http://www.ibm.com/xmlns/prod/websphere/portal/v6.1.0/web2-portlet" prefix="web2-portlet" %> <web2-portlet:init> <web2-portlet:require module="dojo.*"/> <web2-portlet:require module="com.ibm.portal.xml.*"/> <web2-portlet:require module="com.ibm.portal.portlet.*"/> </web2-portlet:init>

27. Client - Portlet Modules • Available Portlet Modules (Module: com.ibm.portal.portlet.*) • PortletWindow • Represents the portlet window of a portlet. Allows to access and store portlet state and portlet preferences objects. • PortletState • Represents the portlet state for a given portlet window • must be retrieved and stored using PortletWindow • PortletPreferences • Represents the portlet preferences for a given portlet window • must be retrieved and stored using PortletWindow • XMLPortletRequest • Allows to issue an XHR to the corresponding server side portlet • UserProfile • Provides access to user attributes of the current user

28. Client - Portlet Modules • com.ibm.portal.portlet.PortletWindow • Defined methods return /*Object*/ getAttribute(/*String*/ name) return /*Object*/ setAttribute(/*String*/ name, /*Object*/ value) return /*Object*/ removeAttribute(/*String*/ name) return /*synchronously: Object{ portletWindow, status, returnObject } asynchronously: NULL*/ getPortletState( /*Function(portletWindow, status, portletState)*/ callbackfn) return /*synchronously: Object{ portletWindow, status, returnObject } asynchronously: NULL*/ setPortletState( /*PortletState*/ state, /*Function(portletWindow, status, portletState)*/ callbackfn) return /*synchronously: Object{ portletWindow, status, returnObject } asynchronously: NULL*/ getPortletPreferences( /*Function(portletWindow, status, portletPrefs)*/ callbackfn) return /*synchronously: Object{ portletWindow, status, returnObject } asynchronously: NULL*/ setPortletPreferences( /*PortletPreferences*/ preferences, /*Function(portletWindow, status, portletPrefs)*/ callbackfn)

29. Client - Portlet Modules • Defined methods return /*synchronously: Object{ portletWindow, status, returnObject } asynchronously: NULL*/ getUserProfile( /*Function(portletWindow, status, userProfile)*/ callbackfn) return /*synchronously: Object{ portletWindow, status, returnObject } asynchronously: NULL*/ setUserProfile( /*UserProfile*/ userProfile, /*Function(portletWindow, status, userProfile)*/ callbackfn)

30. Client - Portlet Modules • com.ibm.portal.portlet.PortletPreferences • Defined methods return /*object[] {"name": string, "values": string[], "readonly": boolean}*/ getMap() return /*String[]*/ getNames() return /*String*/ getValue(/*String*/ key, /*String (Optional)*/ def) return /*String[]*/ getValues(/*String*/ key, /*String[] (Optional)*/ def) return /*boolean*/ isReadOnly(/*String*/ key) return /*void*/ reset(/*String*/ key) return /*void*/ setValue(/*String*/ key, /*String*/ value) return /*void*/ setValues(/*String*/ key, /*String[]*/ values) return /*PortletPreferences*/ clone()

31. Client - Portlet Modules • com.ibm.portal.portlet.PortletMode • Defined constants & variables VIEW: "view" EDIT: "edit" EDIT_DEFAULTS: "edit_defaults" HELP: "help" CONFIG: "config" • com.ibm.portal.portlet.WindowState • Defined constants & variables NORMAL: "normal" MINIMIZED: "minimized" MAXIMIZED: "maximized"

32. Client - Portlet Modules • com.ibm.portal.portlet.PortletState • Defined methods return /*PortletMode*/ getPortletMode() return /*void*/ setPortletMode (/*PortletMode*/ portletMode) return /*WindowState*/ getWindowState() return /*void*/ setWindowState(/*WindowState*/windowState) return /*object[] {name: string, values: string[]}*/ getParameterMap() { return /void*/ setParameterMap( /*object[] {name: string, values: string[]}*/map, /*boolean*/replace) return /*void*/ setParameter(/*String*/name, /*String or String[]*/values) return /*void*/ removeParameter(/*String*/name)

33. Client - Portlet Modules • com.ibm.portal.portlet.XMLPortletRequest • Defined methods return /*void*/ open(/*String*/ method, /*String*/ uri) return /*void*/ open(/*String*/ method, /*String*/ uri, /*boolean*/ async) return /*void*/ setRequestHeader(/*String*/ header, /*String*/ value) return /*void*/ send(/*String or Document*/ data) return /*void*/ abort( ) return /*String[]*/ getAllResponseHeaders( ) return /*String*/ getResponseHeader(/*String*/ header)

34. Client - Portlet User Profile • com.ibm.portal.portlet.UserProfile • Defined methods return /*String*/ getAttribute(/*String*/ name) return /*void*/ setAttribute(/*String*/ name, /*String*/ value) return /*UserProfile*/ clone()

35. Client - Portlet Modules - Example <%@ taglib uri="http://www.ibm.com/xmlns/prod/websphere/portal/v6.1.0/web2-portlet" prefix="web2-portlet" %> <web2-portlet:init> <web2-portlet:require module="dojo.*"/> <web2-portlet:require module="com.ibm.portal.xml.*"/> <web2-portlet:require module="com.ibm.portal.portlet.*"/> </web2-portlet:init> <script> … </script>

36. Client - Portlet Modules - Example <script> function <%=namespace%>_handleLoadPortletPreferences(portletWindow, status, portletPrefs) { if (status==com.ibm.portal.portlet.PortletWindow.STATUS_OK) { portletWindow.setAttribute("preferences", portletPrefs); alert("Preferences.getValue()\n"+portletPrefs.getValue("test")); var prefs = portletPrefs.getMap(); var mapStr = "Preferences.getMap()\nnumber of preferences: "+prefs.length + "\n"; for (var i=0; i<prefs.length; i++) { mapStr += i+" - "+prefs[i].name+" - "+prefs[i].values+" - "+prefs[i].readonly + "\n"; } alert(mapStr); } else { alert("error loading feed"); } } <%=namespace%>_portletWindow = new com.ibm.portal.portlet.PortletWindow("<%=portletWindowID%>"); <%=namespace%>_portletWindow.getPortletPreferences( <%=namespace%>_handleLoadPortletPreferences); </script>

37. Portlet state/mode actions • Portlets may either use traditional, server-side state handlers for edit/config, etc • Define javascript api for portlets to register client-side state/mode handler functions • <namespace>do<mode>(){ alert("hello");} • Example: <portlet:namespace/>doView(){ // do some view mode here} <portlet:namespace/>doEdit(){ // do some edit mode here} <portlet:namespace/>doConfig(){ // do some config mode here}

38. Thank You