Thursday Aug 23, 2007

SAW is Ready

SAW Is AvailableAs indicated in one of the previous blog entries, the SAW API and its implementation for Sun Java CAPS is now available for download here.
Lot of exhaustive material viz. Understanding SAW, SAW User Guide, Java Docs of the API and its implementation for Sun Java CAPS are provided. Please go through them and let us know your feedback to Do check out this blog for more details
There are many more things viz. Out of the box task management portlet, Netbeans Tooling to develop workflow portlets on their way. Do explore, join SAW and help us enrich it.
Please feel free to contact us at and we would be happy to answer any question regarding SAW.

Thursday Jul 26, 2007

Welcome new contributor to SAW

PyramidsThe recently launched SAW (Simple API for Workflow) project seems to be attracting lot of interest and momentum.

I would like to welcome Hisham Galal, to SAW as a non-Sun contributor. Hisham, who hails from the beautiful country of pyramids Egypt, is currently working for an Information Technology company. He is currently working in the area of workflow.

Quoting Hisham about his inclination towards SAW -- "I am interested in SAW because in my work I saw a lot of requests on workflows from the customers but most of the systems have their own implementation of designing workflows and I found your project will be very helpful in that."

Monday Jun 11, 2007

Gartner: Portal, Process and Middleware Market on the Rise

eWeek logo writes that "The market for portal, business process and middleware applications rose 16 percent in 2006, according to a new report from Gartner..".  Read more here..

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.

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) ; )

Wednesday Jul 12, 2006

Atomized Services

Today I added to my blog a start of the description of Atomized Services - and why the opensource community for portlets can become a great asset to enterprises, governments, and individuals. 

See link.

<script src="" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-898027-2"; urchinTracker(); </script>


Tuesday Jul 11, 2006

What a Portal Provides

Why use a portal when building a new service for your community rather than a web page, or a web site, or a web application or a rich application or other presentation layer method?

Below are a few items which initially seem like a set of criteria for determining if a project should be constructed with a portal or not, however, they may be even more insightful when thinking about the evolution of presentation services and the combination of user interface and web site design methods.
  1. Portal Services - a portal platform comes with several items, a portlet design tool, a page layout tool, a portlet container and support for WSRP and Interportlet communication, a desktop personalization system (individual can select / arrange content), a content management system, a human workflow application development system, an integrated search engine, an identity / policy management system or integration, a system for end user service creation and group collaboration.
  2. Presentation Service Aggregation - A portal provides a desktop to assemble multiple portlets into portal pages with associated navigation.  As an example, a set of portlets could be grouped into a portal page (aka, a tab) and added to an existing portal desktop.  A different set of portlets can be grouped into another page and added as a tor as as a subtab to an existing tab, etc.  Aggregation allows new services to be either added/deleted/modified to the default presentation layer or "made available" to users allowing them to add/delete/modify their displayed content.
  3. Identity Based Content Delivery - A portal fully integrated with an identity management system allows the content to be deployed to the portal depending on a users role.  A specific portal page or portlet can then be made available to individuals based on their identity realms, orgs, roles, etc.  IBCD provides one of the most significant developments in portals, and provides a powerful method for both determining an organization's productivity as well as ensuring security  / policy compliance for all services in an enterprise.
  4. Atomized Presentation Services -  A web application can be built in a portlet as either, a full application inside a single portlet with full page flow, a set of portlets, with interportlet communication and individual page flow, or as an atomized function of a full web application.  As an example for this last method, an inventory control system could be built as a full web application.  Additionally, a portlet can be developed which allows managers (if given access to the portlet using IBCD), to see when widgets cross below a specific threshold.  The portlet could have additional functionality which allows the manager to set thresholds per widget.  The portlet could further allow the manager to click widgets displayed, which would open a new browser window, passing the widgets attributes to a web application allowing the manager to order new widgets.  A portal page could contain multiple atomized services which is then deployed to specific users, groups, orgs depending on identity policy.  Additional atomized services can then be easily added to the enterprise (or modified, or deleted, or replaced) without affecting the existing enterprise site design.
  5. User Preferences and User Personalization - As stated in Presentation Service Aggregation, a great number of portlets can be available to users which they individually can add/delete/modify from their default display.  Utilizing the new AJAX desktop from Sun, users can drag/drop/preview/add portlets to their pages, creating a customized view/desktop which suites their needs best.  Leveraging the concept of atomized services, the enterprise could more services which users leverage or not depending on the services usefulness to them "individually".
  6. Centralized Navigation -  A portal can become an enterprise's central navigation unifying web applications, web sites and portals, regardless if the top level is aimed at "all customers", "all employees", "public", or "managers", etc.  Using the concept of centralized navigation, administrators can design the navigation within an enterprise combining web applications, web sites and portals.  The portal home page becomes the entry point for all navigation, and leverages or becomes the basis for the look/feel for all other content.  This last aspect also helps to centralize the "look/feel" repository for a company, allowing a single change to proliferate across all web sites, web pages, web applications and portal pages.  Integrated search additionally provides a central method to add extended navigation to an enterprise wide site.  As navigation becomes deeper, users can search for services or save searches for their own customized navigation.
  7. End User Service Creation - The newest technology to be made available to portals is allowing end users to build web pages, web sites, and web presentation services utilizing communities, wiki's and atomized presentation services (portlets).  Users can define their community, their participants, can create web pages on the fly utilizing html, text, and even portlet services.  The last item is very significant to the community, as it means that the collaboration capabilities are based on open standard portlet services.  Infinitely expandable, true non-proprietary, true open expansion and long term life cycle. 
  8. Enterprise Productivity Design - Last, a portal can improve productivity for users interacting with systems.  Web site design and  human interface design only account for a single application, service or site - a portal is concerned with the interaction on a personal level.  Additionally, this design methodology focuses on three areas:
    1. Individual Productivity - Because users can select from multiple available services, and can customize their desktop, and provides Single Sign On, and other personalized aspects., an individual can improve their productivity because they can design their environment to suit their needs, conditions and their desires.
    2. Team Productivity - Because users can create communities, can self publish, can leverage a selectable set of portlet services specific to their community, team productivity within a portal can be dramatically improved.   While IBCD helps the formal organizational structure, End User Service Creation helps the ad-hoc informal organizational structure.  Example, a user may be responsible for ProjectX - they create their community, add their applications, and content, and determine their users.  This becomes their site, and is added to their portal pages.
    3. Organizational Productivity - Using IBCD, an organization can determine what services are available to which individuals, which are default, which are locked in place and which are modifiable.  An enterprise can determine how all services, all navigation is made available to all users depending on their identity, e.g., a new help desk service is create which provides a list of all customer cases which have escalated in the last 5 days - this portlet could be default added to the home page of all product delivery managers (rather than as a separate URL which they may or may not leverage).  Services then become "targeted" and their usage climbs according to enterprise policy.  This allows the "default" content to be specific to an individual - and thus increase the productivity of all individuals from an organizational level.

<script src="" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-898027-2"; urchinTracker(); </script>





« July 2016