Campbellodeon

• Speaker: Doug Bateman (D)
  • My impression of him was that he had an excellent attitude and was in an excellent mood considering it was 8 am on a Tuesday and he was about to give a 3 hour lecture.
  • He started out by chatting with the attendees and not acting like a lecturer.
  • He is relatively young, which isn’t unexpected, but he still seemed young to be presenting at a conference.
  • He is an experienced presenter - I gathered this from his comment about being videotaped.
  • My assumption is that he is involved with TheServerSide.com in some form or fashion as he appears to know the editor of the website personally.
• There were 14 attendees plus at least one guy from TheServerSide.com
• D: The presentation is not scripted (i.e. there are no slides, he worked from an outline in Notepad) and he is more concerned with answering our questions about portal.
• D: Starts the presentation by generating a list of questions from the attendees
  • What’s a portal? <demo>
  • What’s making stakeholders EXCITED about portals? (JEC)
  • How do I do content management in Portals?
  • We want single sign on, how do we approach bringing multiple apps together?
  • What development practices and coding exercises are portable across portal server applications? What’s portable, what’s not? (JEC)
  • How close are portals to being commoditized?
  • Where are the portlet repositories? Why so few?
  • Inter-portlet communication
  • What is WSRP?
  • What’s the best way to approach the architecture to make portal applications?
  • Advice on estimating portlet development.
  • How do you get a portal production ready?
  • State of the union on different portal servers.
  • What to do when a vendor isn’t standards compliant?
  • How to handle different levels of authorization in portals? What is the impact on user experience?
  • Summary of different development tools for portlets.
• What is a portal?
  • Google News
    • different regions on the screen
    • navigation bar
    • Edit link for each region: allows personalization (hallmark trait of a portal)
    • aggregation of data/information on a portal (another hallmark trait)
  • My Yahoo
    • banner at top of screen
    • regions of information are separate applications which share real estate on the screen
    • allows minimize/maximize portions
    • provides ability for the user to design the screen at runtime
  • Separates page design from the actual content: content can be static or dynamic
  • The guy who builds the page (the web page served by the portal server) may not be the guy who writes the portlets contained within the page
    • portlet developers have to assume that their portlet will run on screens with other portlets
    • beware of dependencies between portlets
  • Portals allow end-users to design pages
  • TheServerSide.com: doesn’t allow much personalization
  • Portals have independent content sharing screen real estate
  • Vocabulary Word: regions - the manner in which screen real estate is divided up
  • Vocabulary Word: theme - the standard look and feel for a group of pages
  • Business users don’t know what portals are (either)
    • at least, they know less than developers
    • they have to be educated on portals
  • JEC Follow-up: research examples using BEA Portal - real world sites
  • Vocabulary Word: windowlet - little window
  • Teams need a common vocabulary
  • Jetspeed: Apache’s portal server
  • There are themes within a windowlet
  • Vocabulary Word: skin - how the windowlets look, the rendering of the frame for the portlet
  • Single Sign-on
    • log in once, go anywhere
    • important to portals AND outside of portals
  • Jetspeed Demo
    • portal page stays the same, portlet changes based on user interaction
• What is a Portlet?
  • By design, they should be self-contained applications that will run independent of the other portlets on the screen
    • allows separation of page design from portlet development
  • A portlet is an independent application that can be dynamically included in a web page
  • Problem: real estate sharing
    • 2 types of portlets: greedy, non-greedy (sidebars)
  • Problem: two portlets on a page and both portlets contain a form -> who/what handles the form submission?
  • Problem: links and page flow between portlets
  • Portlets have to play nice with other “unknown” portlets
  • Tip: portlet specific navigation should be contained within the portlet/windowlet
  • Portlet developers can only control what’s inside their portlet, not the entire portal page
  • Vocabulary Word: pagelet - individual screens within a portlet (welcome pagelet, catalog pagelet, etc.)
  • Vocabulary Phrase: portal page - web page containing portlets served up by a portal server
  • The easiest, fastest, lowest cost, lowest pain way to convert an existing app/site to portal is to use a single portlet
• Beginning of the second hour
• D: there are two big questions that haven’t been asked
  • Can we see some portal/portlet code?
  • Portal Architecture?
• D: uses the Oracle JDeveloper 10g product for the demo
• Why do business users want portal?
  • Personalization
  • Central area for aggregation of information/content/data from separate existing applications
• What can I build rapidly?
  • What can’t I build rapidly?
• D talks a lot about what salesmen are selling vs. what can actually be done vs. how it should be done
• Portals are actually designed to be used for corporate intranets
• Oracle’s portal product
  • has instant change functionality with rich text editing (the bleeding edge version)
  • traditional portal builder (current/older version) is a web app that builds the portal page - layout
• A good portal product will make it easy to create basic pages
• How to design a page has not been standardized
• JEC Follow-up: There is a Java standard for portlets - JSR 168 (research)
• JEC Follow-up: WSRP - Web Services for Remote Portlets
• Oracle product demo
  • the entire page refreshes when an action occurs within a portlet
    • Side Note (JEC): look for a future post on how this can be avoided with Ajax
  • provides a web-based wizard to create custom portlets based on existing portlets
• Portals are glorified CASE tools
  • at least, that is how they are being sold
• How do I build a portlet in Java and add it to a page?
  • D: uses JDeveloper
    • has a Java Portlet development wizard
    • all the Java Portlets within Oracle developer expose a webservice - there is a SOAP Servlet that handles communications between the portlet and the web server
  • Java Server Faces (JSF): makes portlet development in Java easy; JSF to portal conversion is easy
    • Side Note (JEC): The comment above inspired me to attend a session about JSF.  Unfortunately, the session was underwhelming but in case I don’t write about it - JSF is an immature Java version of asp.net and it is the idea of an “ExternalContext” that makes portal/portlet development so easy.
  • There is a Struts migration kit/info
  • Portlets are packaged up as WAR files
  • Portlets are basically a standalone Java web application that has a built-in “gateway” for communication with the web/portal server
  • Portlets can be deployed remotely (WSRP) or within the portal itself
  • The portal page(s) can be managed/developed separately from the development of the portlets
    • the portal pages can tie into and display the portlet regardless of the state of the portlet in the development cycle, i.e. as new versions of a remotely deployed portlet are created and deployed, the portal page will simply show them and won’t require a re-build or re-deploy
    • the point above simplifies the build and release process, however it doesn’t simplify QA
  • D: uses notepad to create the outline for the presentation which is what the entire presentation is based on - no powerpoint
  • The core of Portal development is the same as the core of a Content Management system
    • The questions they try to answer when a user event occurs:
      • What is on the page?
      • What did the user request?
      • What should the next page look like?
    • Portal vendors will sale the content management capabilities
  • JSR 168 example
    • portlet.xml
      • name
      • return type
      • implementation: java class
    • javax.portlet.*
    • looks a lot like a servlet
      • doDispatch
    • taglibs are provided for the JSP representation of the portlet
    • a lot like a webapp
      • able to run inside a box
    • All the major java/web development frameworks are adding support for portal/portlet development
    • Forms have to work with restrictions since there could be multiple forms spread across multiple portlets on a single portal page
      • processAction: handle the form submit (step 1)
      • doDispatch: render all the portlets for the next page (step 2)
    • Homegrown frameworks (developed in-house) will require a large development effort to add portal support
      • D recommends migrating to an established framework, and then going to portal
    • D: JSF is the future, “hands down”
    • JSF Example
      • action class and form class (Struts) are put together - they are called “backing beans”
      • provides a “graphicImage” tag that handles URLs to images in a portal environment - ExternalContext
      • JSF is a cleaned up version of Struts with more power
• How do you design an application to run in Portal (a portal app)?
  • porting an existing application
    • create one big portlet to contain the entire app
    • anything more than that requires a redesign
  • designing a new application
    • “would this portlet work well and make sense all by itself?” if not, then it is not a portlet - it is a component
    • decompose an existing application or design by determining what functionality could be contained within it’s own application
    • no inter-portlet communication: they should be independent applications
    • JSR 168 supports “shared session” for portlets that are deployed in the same WAR file
    • each portlet should be capable of loading and saving it’s own data (load and save itself)
      • this can be accomplished by making a service call within each portlet
      • login is handled by the portal server and then the portlets figure out “who they are”
  • D drew a picture that had the web tier including the “shared session” (whose use should be minimized, i.e. only when it makes sense) which sent requests to a stateless service layer which used something like Hibernate to connect to a database
    • performance boosts could be achieved in the service layer by using caching
    • JEC Follow-up: AppFuse

A couple of finishing points:

• Doug was careful to say if your processes and tools are doing the job for your particular situation, then there is no reason to change them.
• Doug also said that he had little experience with BEA’s Portal Server because he had never been hired to work on it.  His assumption was that either no one was using it or no one had any problems.  He did mention that BEA Portal had built-in functionality to support inter-portlet communication, and while it was supported it should only be used in instances that make sense.

I enjoyed Doug’s presentation style - I heard another attendee describe it as “shooting from the hip”.  He made it more like a discussion and little like a lecture.  Based on the other sessions I have attended (and hopefully, they will be written up as well), Doug’s style is superior to Powerpoint slides and minimized interaction with the audience.

The content was applicable because I had little knowledge of and no experience with portal technologies prior to the session.  Overall, I would say the session made the first day worthwhile.  Unfortunately, Doug’s follow up session in the afternoon did not live up to the standard set by the morning.  Doug struggled with the shorter timeframe (70 minutes) and he was unable to provide enough new content to the returning attendees (like me) or enough background on Portal technologies for the new attendees.  He ended up going through best practices again, which are valuable but were old news for the returning attendees.  My impression is that it had more to do with the scheduling of the sessions throughout the conference - which hasn’t been that great.  So far, the two morning sessions (the second of which I hope to write up tonight or tomorrow) have made the conference worthwhile.  I have high expectations for tomorrow as there will be two more Ajax sessions and a morning session that compares all the major web frameworks.