ibm api or jsr 168 api?

[kuri rao]

Hi,
I am newbie to portal development.which api better(ibm api or jsr 168 api)in ibm websphere portal development.what are things need to consider to choose correct api.
plz let me now.
thanks.

[Mark Spritzler]

Not sure if there is a difference or not. But JSR is a specification, not an actual implementation. So IBM Api should be an implementation of the JSRs specification. You want to use anything that is complying and completely implementing the SPecification so you are following a standard that everyone agrees on, which removes you from vendor lock/porting issues, and make it easier for someone to come in and work on your application without having to learn a new spec or proprietary API.

Mark

[Dhananjay Inamdar]

Hi Curi,

The recommended practice is to use the JSR 168 portlet API unless you need a function that is only available in the IBM portlet API. The JSR 168 portlet API is required for portability and compatibility, or if your portlet will be published as a Web Service for Remote Portlets (WSRP) service. WSRP is a portal-based standard used to integrate remote portlets, provided by Web services, to the local portal page.

IBM will continue to support the IBM portlet API in current and future releases of WebSphere Portal. IBM is committed to open standards, and will continue to enhance the JSR 168 specification. WebSphere Portal provides full support for JSR 168.

Concepts unique to the IBM portlet API:
The following functions are only available using the IBM portlet API.

- Events can be sent between portlets.
- Portlets can add content to the portal navigation menu.
- Portlets can explicitly invalidate cached content.
- Portlets can use portlet services provided by WebSphere Portal. Some services will be available to JSR 168 portlets in WebSphere Portal v5.1.
- Portlets on the same page can exchange properties using the Property broker (Click-to-Action) service.

Concepts unique to the JSR 168 portlet API:
- Portlets can store their navigational state using render parameters.
- Portlets can make data available to the entire Web application.
- During the action phase, portlets can redirect to other Web resources.
- Portlets can adapt to the calling portal using PortletContext objects.
- Portlets can access a portal user profile.
- Portlets can validate preference properties using a preference validator class.


Now you are ready to take a decision depending on your applications requirement.

Thanks
Dhananjay

[Dhananjay Inamdar]

Hi Kuri,

You can refer to following URL for more detailes comparision between these 2 different APIs

http://www-128.ibm.com/developerworks/websphere/library/techarticles/0312_hepper/hepper.html

Thanks
Dhananjay

[Cameron Wallace McKenzie]

JSR-168 is the way to go, especially now with IBM WebSphere Portal.

In earlier days, the JSR-168 API couldn't access great features like PortletServices, or even do things such as Click to Action (C2A). Now though, JSR-168 portlets can do all of those things.

Go with JSR-168. I actually wrote a book on the JetSpeed API and never published it, because I just didn't think there'd be enough interest. If you want a copy of it, you can have it.
[ August 27, 2006: Message edited by: Bear Bibeault ]