Thursday Jun 07, 2007

SPEAK OUT! Portlets and Web Services

When bringing an application into a portal, when is a Web service better than an old-school portlet? That's not a rhetorical question  - what do you think?

 The answer will probably vary, based on the type of application you want to expose. My work has been primarily with commercial ISV's (Citrix, Elluminate, Documentum, etc.), maintaining our Core Portal Ecosystem. Originally, every portlet project was 100% custom. Most ISV's had decent API's, but it was still a lot of manual work (not to mention constant business negotiations, measurement, etc.). The rapid adoption of the Java Portlet Specification (JSR 168) standard helped (by providing a container, consistent authentication mechanisms, etc.), as did WSRP's enabling of Web service consumption. Better still, many ISV's began publishing and supporting portlet sets of their own, taking over about 80% of the portlet development work.  However, even with these advances, code to support portal-specific features (e.g. single sign on and, in our portal's case, Secure Remote Access) was still done largely by hand.

This Google spellcheck portlet is actually a Web service.

This Google spellcheck portlet started with a Web Service. To learn how to build this yourself, visit the tutorial

Clearly, Web services are the future for commercial ISV portlets. Some are already phasing out portlets in favor of publishing Web services (Interwoven and Business Objects come to mind). SIDE NOTE: I've been advocating the creation of a core series of reusable infrastructure services (e.g. a single sign-on service, a secure remote access service) to glom\* together with the ISV services as our model for supporting commercial portlets going forward. Some of our gifted engineers are validating the concept as we  speak. What's your take? 

Also, almost half of the proposed features in the upcoming Portlet Specification 2.0 address WSRP alignment. So where does that leave the portlet as we once knew it? Is it strictly to be used for obscure, one-off tasks or ...?

Which method do you prefer in which circumstances? Please share your ideas and experiences.

Thanks-
Kim Buck

 

PS - If you're interested in portals, you're probably interested in SOA. For a glimpse into Sun's SOA ISV community, feel free to visit my SOA Solar System blog. Most of the content is business oriented vs. technical, but it's a good place to learn about  how SOA vendors - from established platform players to innovative startups - are shaking up that space.

 

\*glom - to mash, to moosh, to adjoin with reckless abandon (trademark pending) ; )

Thursday Jul 27, 2006

The Best Opensource Portlets


With Sun Portal's entrance (NOT foray!) into the Opensource community, [whose goal is deeply focused on the betterment of the world community of users and developers (see my posts)]- our developers have started two distinct efforts each with their own benefits. 

1.) Opensource Portlet Repositories: 
My new four wheel beast came with a very large engine, navigation, super-wide low profile-rims, satellite radio ... and an iPod integration.  That's ~400hp and ~10,000 songs - all controlled at the steering wheel.  Sweet.  But, where'd I get those 10,000 songs? iTunes is free  but the songs are not.  What good is a luxury sports car without an iPod integration and what good is iTunes without songs?  

desciTunes allows you to purchase songs from their store, and allows you to rip CD's you already own, but wouldn't it be great if you could go to independent sites and download songs, ones that are cheaper (50 cents) or have other catalogs (has Steve Jobs ever heard of the Beetles) or frees songs from new artists?  Maybe then I'd have 20,000 songs for that saturday afternoon drive to Julian for apple pie.

It's the same for a portal server.  A portal doesn't do anything without portlets.  Sort of like a web server.  Who cares what web server you use, as soon as you finish the install, it does nothing until you build some web pages and put them in doc root.  But a portal allows three categories for content, not just web pages,  1.) content (like the web server) 2.) portal-specific applications and 3.) portal independent applications.    So wouldn't it be great if you could get portlets for free?

desc A portal's unique capability is that it allows you to easily build a page or set of pages consisting of each of these elements.   A portal should be designed to simplify #1, and #2 should come with a portal (for free because it has something to do with the function of the portal - example, delegated administration of users or portal pages).  But for #3 today, most portal customers have to either develop each portlet themselves or purchase them from their vendor's proprietary library - making the customer even more tied to the vendor from whom they thought they purchased a capital expenditure (visualize the fat cat smoking a cigar laughing and counting his piles of money with smoke stacks in the background...).  Can you imagine only being able to buy gas from the same auto dealer and only at one location?


Sun's vision for the opensource portlet repository is to end this dependency on proprietary portlet repositories.  As the repository grows, the portal installer will install the portal of their choice, then add to that installation functions from an opensource repository.  Customers can download and own the code and migrate it through their own lifecycle or contribute back to the community.  ISV's will be able to provide tot the community their integrations - reducing their costs required today to support multiple portal vendors.  Governments may and should provide all their integrations back to the community that funded their projects.  Over time with thousands of customers our community should develop thousands of portlets - but first we must start with a set of core portlets.  Those portlets which provide the greatest value.

descSo what are the 10 core portlets we need?  What should the community be looking to develop?  A few categories are (I will provide deeper detail on these to community members over time):

 

  1. Collaboration
    • Project / Task Mgmt
    • Surveys  / Polls / Decision Making
    • File sharing, document routing
    • Workgroup Networking (blog post coming soon)
  2. Communication Suite Integration
    • individual email -no
    • individual calendar - maybe
    • individual summary - maybe
    • individual address book - maybe
    • community email - maybe
    • community calendar - yes
    • community addressbook - yes
    • enterprise wide address book - yes
  3. Enterprise Applications Integrations
    • standard applications  (alerts, quick data entry, human workflow, repetitive function interface)
  4. Business Intelligence and Analysis
  5. Desktop Integration
    • Windows Sharepoint Services (tasks, events, photos)
    • Citrix, Sun SGD (Tarantella)

2.) Next time, I'll discuss the benefits of the Portal repository to CIO's, Division VP's and even SI's and ISV's.

<script type="text/javascript" src="http://www.google-analytics.com/urchin.js"> </script> <script type="text/javascript"> _uacct = "UA-898027-2"; urchinTracker(); </script>

 

About

atul

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today