Recent Posts

RSS Feeds

Portal Talk


Just finished Paul's talk on Portals. Very interesting. I can't wait to get back to normal life so that I can spend some time playing with all the cool stuff that I've learned here...

my notes

Paul Giangarra – Portals

 

Third or forth generation portals are about collaboration? Missed the detail on that comment.

 

What is a portal?

1)    a place to start for your users

2)    a place to aggregate the stuff that people want to do

 

Value of Portals

1)    simplify access to resources

2)    eliminate information overload

3)    personalize for the one-to-one marketing appeal

4)    collaboration meets applications

5)    the enterprise now ‘owns’ the desktop

 

The Portal helps to aggregate the information that we want to see, personalized etc. Allows us to avoid info-overload.

 

Why Portals – employee productive, increase efficiency through automation, quicker response to customer

 

Gen0/Gen1 (-1998 to 2000) portals simple hyperlinks and search, homepages on sterids

 

Gen2 (2000 to 2001) robust app framework, collaboration, Mobile and wirelss, management framework, being deployed today

 

Gen3  (2002+) context personalization, cascading portals, web services, process integration, abstraction layers, federated search, federated portals, p2p offline support, proactive notification, mainframe support, knowledge management

 

Why are biz portals so important?

1)    eventually all web apps will be portal apps

2)    portals will be the most visible software infrastructure in a company’s e-business strategy

3)    the need for integration drives the growth and importance of portals

4)    application vendors are using portals as UI and Integration

5)    Portal frameworks…

 

Portal Planning Process – or how to get a portal into your company

1)    obtain sponsorship

2)    analyze drivers and expected benefits

3)    inventory the features desired

4)    conduct an infrastructure impact assessment

5)    select products

6)    sell internally

Basically laid out how to decide if you want to build a portal, decide what you want/need, a portal for portal sake is stupid.

 

Don’t confuse a Portal with a web site. The are not the same, the portal is window into web applications/web sites.

Portal Infrastructure

1)    knowledge arch

2)    community arch

3)    security arch

4)    tech arch

5)    dev and dep

6)    operational arch

Important for B2C portals to truly aggregate the info instead of sending you off (i.e. looking at CD players and linked off to Sony, you just lots a customer, Sony.com has a link to ‘find someone to sell this to you’).

 

Knowledge management is important in building a portal. Unstructured info is just info, if you can organize it its knowledge. We need knowledge.

 

(Paul spawned a thought: Interesting thing to think about: A development portal for open source communities. Why don’t we have something like a portal for developers. Aggregate information into knowledge, connect people in great ways that makes the community more effective.)

 

Lots of detail about objectives that you’d want to build a portal for. This was a lot like a marketing pitch of why portals are important, i.e. why do a portal.

 

Technical arch of the portal

1)    Portlet container services

a.     Content access

b.     Web clipper

c.     Search

d.     Document manager

e.     Po9rtlet data

f.      Admin

g.     Collaboration

h.     Credential vault

i.      Portlet proxy

j.      Single sign-on

2)    J2EE

3)    Page aggregation

a.     Themes and skins

b.     Transcoding

c.     JSP tag library

d.     translation

 

Base portal design – think about it, users, admin, roles etc.

Think through your page layout as well. Title bars, menu’s, hierarchies of portlets etc.

 

JetSpeed is a great spot to play with portlets.

 

Themes do most of the hard work for cross-browser support and accessibility.

 

Delta from JSP/Servlet to Portlets,

1)    portlets are very dynamic

2)    portlets can know personalization info, locale, devices etc.

 

Building a poral –tasks

1)    creating page definitions

2)    create themes ad skins

3)    developing portlets

Cool thing is that all this can happen independently.

 

JSR 168 gives us – interoperability between local portlets and portals, i.e. we can put a portlet written WLS can be deployed into WebSphere

 

WSRP – goals

1)    enable the sharing of portles (markup fragments) over the internet with a common interface

2)    enable cross vendor publishing and consuming of content

 

WSRP allows us to build a portlet and let it be vended into another portal?

A proxy portlet receives info from a web-services interface and then render that portlet in the local Portal.

 

On the portal server the generic proxy (only one, we don’t need to implement it) and it goes off via SOAP and asks for some rendering to be done. The proxy then takes the rendering from the back end and displays it. Very interesting.

Permalink     No Comments



Post a Comment:
  • HTML Syntax: Allowed