Portal PoT Instructor Notes
This chart is not designed to show any specific customer network configuration, just certain elements that may be contained in any network configuration. The network configuration is also key in developing a security implementation. Anyone who is familiar developing a web application architecture will not see many differences between a portal architecture and a web architecture.
DMZ – most e-business customers implement a DMZ which is a semi-protected area between two or more firewalls. A firewall
utilizes a combination of hardware and software to enforce security rules that determine what information is allowed to pass into your network. It creates boundaries between two or more networks and stands as a shield against unwanted penetrations into your environment. A load balancer such as Edge Server may be present to balance out demand during peak periods. A reverse proxy such as WebSEAL may be present to do early authentication. Web Servers are usually in DMZ but may also be behind the DMZ.
Portal – This tier contains the WAS and Portal servers including the Portal user repository. The LDAP server may also be at this tier if there is not a separate Security tier containing an External Security Manager (ESM) such as Tivoli Access Manager (TAM).
Security – This tier is present when the customer implements a ESM. The LDAP used by ESM for authentication must also be available to Portal as the user registry.
Content – This tier may be available to support one or more content managers (CM) such as DB2 CM or Web CM. Other popular CMs are supported with portlets that can extract content generated by the CM.
Collaboration – This tier may be available to support collaboration between users such as Lotus Collaboration Center.
Backend – This tier is almost always present. It represents access to the systems the customer has invested in to actually run the business. It may consist of Enterprise Resource Planning (ERP) systems such as SAP or PeopleSoft, Enterprise Information Systems (EIS) such as CICS or IMS, Enterprise Data Systems such as DB2 or Oracle.
NEW API/ SPI
Click to Action for every Portlet (API)
Enable the Click-to-Action paradigm for standards portlets (using Semantic Tags), Integrated with server side eventing
Portal Write Model (Java SPI and REST Service)
Create your own administration portlets (supports: Content-, Navigation-, Layout- and Portlet-Model, Unique names)
Client-side JavaScript library (API)
Convenience JavaScript APIs simplifying portlet development (e.g. support authentication proxies)
Step-up Authentication (SPI)
Define your own authentication levels (beyond what Portal 6.1 provides OOB), check for the rememberMe cookie
Login/logout/session validation Filters
Plug into the login/logout/session validation flow of portal
Property broker (SPI)
Write your own wiring portlet
Extend current portlet and portal models to support JSR 286 (SPI)
All APIs/SPIs available to JSR286 Portlets
Sitemanagment command (SPI)
Write your own Sitemanagement application
Encoding and decoding of friendly URLs (SPI)
Create friendly URLs and decode friendly URLs, Integrates into the resource addressability framework
Resource Addressability Data Source API (SPI)
Serve your resource addressable data via the default content handler servlet
LocalizedContext (API)
Allows you to get the preferred locales and titles / descriptions of Localized resources
Portal Frameworks –
Supported by IBM Tooling
Java Server Faces (JSF) 1.1
JavaEE standard
Rational Application Developer (RAD) V7.0
Struts 1.1
IBM Struts Portlet Framework
Supports JSR 168 property broker extension
Rational Application Developer (RAD) V7.0
Portlet Factory
Build portlets based on models and builders instead of fine-grained UI components
Running on WebSphere Portal *
JSF V 1.2
Apache JSF Portlet Bridge
JSR 301 RI: Standard JSF-Portlet Bridge
covering JSR 168 (JSF 1.2), JSR 286 (JSF 1.2), RI part of Apache JSF Bridge
Apache Struts Portlet Bridge (V 1.x, V 2.0)
Spring MVC 2.0
Adobe Flex
Apache Wicket
And many more ...
The portlet bridge of the framework just needs to comply to either JSR 168 or 286
Portal PoT Instructor Notes
There is a specific series of steps that are required as part of the Page Aggregation Process.
Step 1, getting user, language and device type do not often change therefore can be cached.
Step 2, This step must be processed when a user selects a new page. Remember that pages and portlets are separate resources types, therefore access to a page does not automatically mean you have access to the portlets on that page.
Step 3, All of the markup fragments are collected that will be used to build the page.
Step 4, All of the processing by a portlet is done on this step. This is sometimes referred to as the event phase. All events and actions must be completed in this step before the portlet can be rendered.
Step 5, Since all events and actions have completed, each portlet can render content in parallel for faster processing. The parallel rendering uses Asynch Beans from Enterprise to render each portlet on a separate thread. Parallel rendering is set for the Portal as well as for the Portlet. The default for the Portal is parallel while a portlet must specify that it will support parallel rendering, it is not automatically set.
Think of each portlet skin as being an AJAX-enabled wrapper that calls back to the portal to get the embedded portlet's content.
The server builds the code for the skin that contains and HTTP reference back to the portlet, embedded within an AJAX javascript call, and the browser invokes that.
Note that WAS supports only one realm. For multiple realms it must be configured in Portal.
* Default Portal Install (federated, file based)
VMM replaces the WebSphere Member Manager (WMM) that came with WebSphere Portal prior to release V6.1
Using a file for the user registry ootb makes it easier for a development (or POC) environment
VMM documentation available at http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.wim.doc.en/welcome.html
VMM API is based on Service Data Objects (SDO)
Comprehensive VMM coding samples available at http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.wim.doc.en/integratingwim.html
Sample VMM adapter available from the WebSphere Application Server V6.1 Information Center at http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/rwim_dev_vmmca.html
New infrastructure supports Web 2.0 theme
More responsive user interfaces provide better context awareness for the user through client-side aggregation of portal pages.
Client-side mashups and interactive portal applications can be developed using Asynchronous JavaScript and XML (AJAX) with a Dojo-based client-side JavaScript programming model.
Portal models like Navigation, Page Layout, and User information are remotely accessible through REST Services.
Improved scalability results from enhanced caching capabilities. Page fragments can be cached separately rather than caching entire pages.
Dynamic behaviors such as context menus, annotations, highlighting, and drag-and-drop interaction can be applied by an extensible set of semantic tags.
The new Feedreader portlet is based on AJAX.
This slide lists all the ways that pages, applications and content can be put into Portal. Listed generally from easiest (least codig) to most.
For this presentation we are focusing on new features in Portal 6.1, so existing methods for adding content, such as Web Clipping, should be briefly covered on this page, since they will not be addressed further in this presentation.
Web Application Integrator was actually introduced with Portal V6.0.1.2
Displaying Existing HTML/Web Apps does includes SSO and common navigation, truly making that content a “part of portal”
Reuse is fundamental for Portal TCO
“Time to Value” is a key design goal for WebSphere Portal
Composite Applications enhance functionality
Note tha Portlets can be administrative, e.g., “Manage Pages” and functional, e.g., “WSRP Proxy”, as well as user-oriented
REST Services open up portal for mashup applications – services for server persistence, portlet settings and user profile access to simplify Web 2.0 application development
AJAX Portlet Programming Model Extensions based on Dojo + IBM Extensions
Client Side Aggregation and Customization using REST Services for better UX and improved performance
AJAX Client Side Feed Consumption to enable highly efficient integration of information through feeds (Atom and RSS)
Semantic Tags to allow smart markup to enable value add by portal, e.g. dynamic menus
Client Side C2A/Property Broker and Drag & Drop based on Semantic Tags integrated with server side property broker and C2A support to enable cross-portlet interaction locally in the browser as well as with server side code
Sample AJAX Portlets with source exploiting the new capabilities to demonstrate and give samples are providing a jumpstart for you.
Quickly connect to an author or an expert as a way to add more depth to an interaction in context to a Portal-enabled task/process; facilitates knowledge sharing and innovation
Advanced profiles within a Portal enable an entirely new method to facilitate expertise location
Communities are a good way to understand who else is a resource and has shared interests.
Dogear is a new a way to add depth to Portal content and applications
Read an article, see the dogears from the author and learn more
Blogs are a simple and easy way to share expertise in context with more formalized documents or application
Activities are a simple and fast way to get a project up and running. You can add them into a Composite Application or use it as a simple to do list mechanism
WWCM 6.1 starts by adding a new user friendly “Welcome Page” entry point for content authors, editors and managers.
This new design provides a simplified authoring environment with access to templates, search, libraries, personalization, task bar and help information.
We will delve deeper into WCM later today.
Advanced Personalization extends on the traditional strength of personalization by allowing personalization rules to apply to both portlets and applications. This allows for a more dynamic user experience, wherein the business logic within a personalization rule could, for example, display a particular enrollment application on an HR benefits page during open enrollment. Personalization rules can now also be edited in context with the related applications and pages. All of which provides for added business value, allowing business users to map the current needs of the business to the portal.
Portal Application Templates allow for easy creation of composite applications that can then be more easily deployed to different communities (e.g. departments, teams, other groups of users). Since such factors as ‘look and feel’, members and roles, as well as other definable parameters, are externalized via the templates, application owners can more easily change their applications to meet new requirements.
Deprecated the Portal Event Declaration Builder and Click to Action Builders—replaced by microformats. Can still use simple Event Declaration for communication between Portlet Factory portlets.
Prior to WPF 6.0 Cooperative Portlet support was limited to Click-2-Action (C2A) events through the use of the C2A Builders. The C2A Builder set did not allow support for use with the WebSphere Portal Wiring tool. Events could be triggered by selecting the target from the C2A menu, but you could not have the action selection from the menu saved persistently.
The new cooperative portlets support in WPS 6.0 primarily addresses the following two enhancements.
Allow Click-2-Action portlets to be wired (only supported on IBM Portlet API not JSR 168) - Depending on the browser, a user can hold either CTRL or ALT while clicking a Click-to-Action icon action and chooses to have the action selection(s) from the menu saved persistently. This results in the property associated with the icon being wired to the target action(s). If a wire is present the next time the user clicks on the icon, no selection menu is shown. Instead the wired action(s) are automatically fired. Subsequent updates to that property are transferred without further deliberate user choice. Wires can also be created using the Portlet Wiring Tool.
Enable Property Broker events in JSR-168 (WebSphere Portal JSR 168 API only – not supported on IBM Portlet API) - At runtime, the property broker matches the data type of output properties from a source portlet with the data type of input properties from one or more target portlets. If a match is determined, the portlets are capable of sharing the property. JSR-168 Portlets must be configured using the Portlet Wiring Tool in order to enable Property Broker events. The new Builder functionality allows you to trigger the event through a page link, or method action.
Workflow capabilities in your portal run off Process Server and BPEL engine. Allow us to define forward running business processes with many forks and joins. The user interaction interface can then be exposed through websphere portal. Additionally portal can keep track of where you are in the business process and what tasks need your attention.
Portal PoT Instructor Notes
Point out that tools are needed to create portlets and there are several tools available. Only RAD is shipped with the Portal package. Bowstreet is sometimes shipped it depends on if we are running some sort of “deal”
Portal PoT Instructor Notes
Before you decide to implement a SSO solution you need to understand that shared desktops will need to address security issues. Someone may not log out of their workstation and then the person that “shares” the workstation will have access to all applications that were provided through SSO.
The definition of single sign-on (SSO) is that if a user has successfully authenticated once in the Single Sign On domain, then that user is not required to present his/her authentication information again. The established credentials are used to automatically authenticate them to the applications participating in the single sign-on domain. The SSO solution with External Security Managers such as Tivoli/Siteminder/etc will only work with the scheme level (security level) for Portal and the back end applications is the same and that they are all on the same domain. If they aren't then the Credential Vault solution will be needed.
Many portals are required to access external applications that need some form of user authentication. In most cases, the user credentials required by these applications will differ from those used by WebSphere Portal. While it is possible for the portlet to prompt the user for this credential information and then present it to the external Application, such an approach is seldom implemented due to the unsatisfactory user experience. Hence the requirement for SSO in a Portal solution is to provide seamless access to the different applications.
There are multiple approaches to SSO, this chart just covers some the ones commonly implemented in Portal. Use this chart to briefly introduce each approach, there is a separate chart that covers each approach in more detail. As an aside, shared desktops may have security concerns with SSO as a pure solution could allow users to accidentally access unauthorized resources.
