Sunday, 31 July 2011

Spring WebFlow- Hello WebFlow

Spring WebFlow is an extension point to spring MVC. In a typical spring mvc model, all requests are processed via controllers. In Spring Webflow, requests are processed through flow executor. Spring Web Flow (SWF) is a component of the Spring Framework's web stack focused on the definition and execution of UI flow within a web application. Spring Web Flow, like Spring, is a layered framework, packaged in a manner that allows teams to use the parts they need and nothing else. For example, one team might use Spring Web Flow in a Servlet environment with Spring MVC and thus require the Spring MVC integration. Another team might use SWF in a Portlet environment, and thus require the Portlet MVC integration. Another team might mix and match. A major benefit of SWF is that it allows you to define reusable, self-contained controller modules that can execute in any environment. Spring Web Flow allows developers to build reusable, self-contained controller modules called flows. A flow defines a user dialog that responds to user events to drive the execution of application code to complete a business goal.

For creating this example,i refereed Spring Web flow tutorial.

In Web.xml,
    <!-- Map all spring requests to the DispatcherServlet for handling -->

In HelloWebFlow-Servlet.xml

<!-- Map paths directly to view names without controller processing. Use the view-name attribute if necessary: by convention the view name equals the path without the leading slash -->
   <mvc:view-controller path="/" view-name="index" />
<!-- Maps request paths to flows in the flowRegistry; e.g. a path of /hello looks for a flow with id "hello". -->
    <bean class="org.springframework.webflow.mvc.servlet.FlowHandlerMapping">
        <property name="order" value="-1"/>
        <property name="flowRegistry" ref="flowRegistry" />
<!-- Dispatches requests mapped to flows to FlowHandler implementations -->
<bean class="org.springframework.webflow.mvc.servlet.FlowHandlerAdapter">
    <property name="flowExecutor" ref="flowExecutor" />

<!-- Executes flows: the central entry point into the Spring Web Flow system -->
    <webflow:flow-executor  id="flowExecutor"/>
    <!-- The registry of executable flow definitions -->
    <webflow:flow-registry id="flowRegistry">
        <webflow:flow-location path="/WEB-INF/flows/hello.xml" />

Saturday, 16 July 2011

LOT 959-IBM WebSphere Portal 6.1 Application Development

Architecting a Portal Solution
  1. Demonstrate familiarity WebSphere Portal Web 2.0 features
  1. Demonstrate knowledge of WebSphere Portal Platform features
  2. Identify portal dependencies on existing software
Not Known
  1. Identify supported portlet frameworks
          IBM supported frameworks

              The following is a list of the primary IBM tools that enable portlet development using the various frameworks:
·         Java Server Faces (JSF) 1.1
·         JavaEE standard
·         IBM Rational Application Developer (RAD) v7.0 / 7.5
·         Struts 1.1
·         IBM Struts Portlet Framework
·         IBM Rational Application Developer (RAD)v7.0 / 7.5
·         IBM WebSphere Portlet Factory
  1. Identifying scope for custom portlets
  1. Know the authentication levels provided by WebSphere Portal
  1. Understand how portal features and portlets use user identity to personalize
  1. Understand patterns and methods for application integration with WebSphere Portal
Not Known
  1. Understand portal page aggregation modes
  1. Use out-of-the-box portlets

Install, Setup and Configuration of a Developer Environment
  1. Compile, packaging, and deploying portal artifacts using Rational Application Developer
  1. Configuring Rational Application Developer for remote testing and debugging with WebSphere Portal
  1. Create portlets in Rational Application Developer and WebSphere Portlet Factory
NOT Known
  1. Creating Portal projects in Rational Application Developer
  1. Diagnose problems with development environment installation
NOT Known
  1. Identify Software Requirements
  1. Optimize development environment
  1. Understand software prerequisites (including compatibility questions)
NOT Known

Portlet Development
  1. Create cooperative portlets using Click-2-Action and Property Broker
  1. Demonstrate knowledge of core Java Portlet Objects
Not Known
  1. Demonstrate the differences between, events, render parameters, public render parameter, and scoped attributes; request, session, shared session, and application scope.
  1. Describe the portlet life cycle for JSR-168 and JSR-286
  1. Effectively use JSP and JSTL to render portlet markup
  1. Have knowledge of WSRP for JSR-168 and JSR-286 portlets
Not Known
  1. Identify supported portlet modes and custom portlet modes
  1. Implement portlet actions and events with Java 5 annotations
  1. Understand portlet descriptor files for each portlet type and utilize WebSphere Portal extend features
Not Known
  1. Understand WebSphere Portal client side portlet API
  1. Use AJAX to update state and trigger actions with JSR-286 portlets
Not Known
  1. Use Remember Me API to provide anonymous portlet content personalization
  1. Utilize client profile information (JSR-188)
  1. Utilize of standard portlet cascading style-sheet classes

Theme Development
  1. Demonstrate understanding of Theme Extensions
  1. Develop custom themes, skins and screens
  1. Identify Portal and Drag-and-Drop JSP tags
  1. Implement Client Side Aggregation
  1. Implementing Portal Navigation
  1. Portal Cascading Style-sheet classes
  1. Using Theme Customizer Portlet to modify a theme
  1. Using theme policies and custom page settings

Portal Frameworks and Portlet Services
  1. Creating a custom Portlet Service
  1. Develop Login, Logout, and Session validation filters
  1. Parsing ATOM Feeds
  1. Understand key Service Providers (SPI) and Application Programing Interfaces (API)
    1. Login Service SPI
    1. Portal User Management SPI
    1. Portal Write Model SPI
    1. Property Broker SPI
Not known
    1. Resource Addressability Framework (SPI)
    1. Step Up Authentication SPI
  1. Use REST protocol to access SPI's

Testing, Debugging and Performance Monitoring of Portlets

  1. Debug a portlet on a local server
  1. Debug a portlet using WebSphere Portal remote
  1. Effective use of logging
  1. Running code profiling in Rational Application Developer
  1. Troubleshoot portlet applications
  1. Using portlet PMI statics

Additional Development Concepts
  1. Assembling Composite Application Templates
  1. Collaboration API
  1. Creating custom portal search interfaces
Not Known
  1. Developing Personalization Resources
  1. Have knowledge of Portlet Bridge Frameworks; Struts, JavaServer Faces, etc.
Not Known
  1. Search the Business Solutions catalog
  1. Using and extending the Credential Vault
  1. Using Web Content Management API's
  1. Writing Personalization and Visibility Rules

Difference between WAS and WPS

WPS(Websphere Portal Server)
WAS(Websphere Application Server)
It is one of enterprise Application in WAS(wps.ear)
It provides platform of WPS
It is depend on database
It is not depend on database
Provides very good  personalization
Personalization   is limited to each application
Configuration / personalization data’s are stored in database ,XML and property files
Configuration  data’s are stored in XML and property files
WPS can do only authorization
WPS Authecation is done in WAS
Performance Measurement about page/portlet is not measured  in WPS
Performance Measurement about page/portlet is measured in WAS.
Only war files can be deployed
Both war/ear files can de deployed
Can develop only portlet  application
Can develop Plain J2EE application, advanced J2EE Application. Using portlet container in WAS6.1, we can develop portlet application.
In WebSphere Portal, you cannot directly access a portlet through a URL.
Portlet is directly accessible using URL
Security role references are not maintained in WebSphere Portal Server.
Security role references are currently only supported by WebSphere Application Server.

Monday, 4 July 2011

Differences between WAR files and predeployed EAR files of Portal Application

Affected portal areaWAR filePredeployed EAR file
Portlet applicationThe portlet application is provided as WAR file. The portal configuration is read directly from the file stream. The WAR file is deployed into the application server by the portal.The portlet application is already extracted and deployed into the application server as part of the EAR file. The portal server reads the available portal configuration information (portlet.xml, etc.) from the location where the contained WAR file was extracted to.
Context RootThe context root is assigned by the portal during WAR deployment.The context root is assigned by the EAR developer and stored in the fileapplication.xml. You must ensure that the context root that you specify when you register the portlet matches the one specified in the EAR application.xml.
Display nameThe display name is assigned by Portal during WAR deployment.The display name is assigned by the EAR developer and stored in the fileapplication.xml.
WebSphere Application Server policy for portlet applicationsThe policy is stored in the WAR file and promoted to the EAR file by the portal during WAR deployment.The policy is stored in the EAR file.
Portlet administrationYou administer WAR files using the XML configuration interface and the administration portlets.You can register EAR files only by using an XML script with predeployedmode. You can remove EAR files by using either the administration portlet or an XML script.