Compare JSR 168 v/s IBM Portlet API

This section gives a high level comparison between the new JSR 168 Portlet API and the IBM Portlet API. First, it covers the concepts that are similar; then, it explains some of the differences between the two.

Similarities

The following concepts are very similar in JSR 168 and the IBM Portlet API.

Feature	Similarities	Differences
Portlet modes	Both support the basic portlet modes: Edit, Help, and View.	The config mode is optional in the JSR 168. The other optional JSR 168 modes (About, Edit_defaults, Preview, Print) are not supported by the IBM Portlet API.
Window states	These window states are supported: Maximized, Normal, and Minimized.	The Solo window state is only supported by the IBM Portlet API.
Portlet lifecycle	The lifecycle life cycle is the same: init, process requests, destroy.	none
Request processing	Request processing is divided into an action phase for processing user actions and a render phase for producing the markup.	none
URL encoding	Both support creating URLs pointing to the portlet or to a resource.	none
Include servlets/JSPs	Servlets and JSPs can be included in the portlet.	none
Portlet session	Portlets can store transient information that should span requests in a session.	none
Portlet application packaging	Both package portlet applications as WAR files with an additional deployment descriptor called portlet.xml.	The portlet.xml format differs.
Expiration-based caching	The portlet can support expiration based caching.	The APIs use different mechanisms to implement this functionality. The IBM Portlet API uses a polling mechanism where the portal queries the portlet for how long the markup will be valid, whereas in the JSR 168 the portlet can attach an expiration time to each created markup. Sharing the cache entry across users is only possible in the IBM Portlet API.

Differences

The JSR 168 and the IBM Portlet API differ in the following ways.

Feature	IBM Portlet API	JSR 168
Portlet application entities	Lets you define an abstract portlet application and different instance of this portlet application as concrete portlet applications via the deployment descriptor. This allows reusing settings of the abstract portlet application and only overwriting the parts that are unique for each concrete portlet application.	The deployment descriptor follows the web.xml deployment descriptor and defines one portlet application and the portlet definitions for this application.
Portlet entity	There is one portlet object instance per portlet configuration in the Web deployment descriptor. There may be many PortletSettings objects parameterizing the same portlet object according to the Flyweight pattern, provided on a per-request basis. Changes in the PortletSettings apply to all portlet instances of this concrete portlet. The user can also have personal views of concrete portlets that are rendered using the PortletData for customization of the output.	PortletSettings and PortletData are merged into one object called PortletPreferences.
Request/Response objects	The request/response object that the portlet receives in the render call is the same as the one received in the action call.	In the JSR 168 these are two different objects.

Exclusive to JSR 168

These items are only available in the JSR 168.

Feature	Description
Render parameters	Render parameters allow the portlet to store its navigational state. Render parameters stay the same for subsequent render requests and only change when the portlet receives a new action. This enables bookmarkability and solves the browser back button problem.
Global HttpSession scope	Portlets can store data not only with the visibility of the portlet, but also with the visibility of the whole Web application.
Redirect	Portlets can redirect to other Web resources in the action phase.

Exclusive to the IBM Portlet API

The following concepts are only available in the IBM Portlet API.

Feature	Description
Eventing	Events can be sent between portlets.
Additional lifecycle listeners	Lifecycle listeners besides action and render, (such as begin page) are not available in the first version of the JSR 168.
Portlet menus	Lets the portlet contribute content to a menu bar to facilitate navigation through portal pages.
Invalidation based caching	Lets the portlet explicitly invalidate cached content.

Click here to View more...

Basics of Portlet Development

Portals became popular in the early years of this decade. They promise easier and more standardized aggregation of web applications under a common framework. If you have the need to do such a thing, which is often the case for company intranets, web sites that service customers, or partners etc. portals are very useful.

There are portals that are built on Java technology. There are open source portals such as Pluto, Liferay, eXo Platform (RedHat GateIn), Open Portal, and commercial ones such as Oracle WebLogic Portal, Oracle Web Center (old ALI), Vignette (Open Text) Application Portal, etc.

There are not many public resources, examples and books and tools on how to build generic portlets so I decided to keep a series of blog entries to highlight the fundamentals.

Web Applications, Portals and Portlets

These concepts can be confusing sometimes; For example, lets say we have developed a really nice Java web application for blogging. Other than its obviously amazing features, it is just another web application. It runs on the server, displays in a web browser. When you need for it to do anything, a request is submitted from the client browser to the server. The web application on the server renders a new page and send it back with an http response . The following figure demonstrates this. The web application owns the browser window. It receives the complete http request, and prepares the complete response.

Simple Web Application

In contrast, when we use a portal, our blog application is one of many that will be displayed in the browser. The portal, which is a web application very much like the above, owns the screen real estate. It manages a group of other applications called portlets. Our blog becomes one of these applications. The portal receives the http requests. It partitions this request into many small pieces for each portlet. It receives their responses and includes them in its own response. Our portlet is not in full control. It must learn to co-exist with other portlets.

Portal and the Portlets

Portlets

There are many portals, and therefore as many different APIs and ways to create these portal components, called portlets. Portlets are supposed to be potentially reusable components between many portals. However, the incompatible APIs is a constant problem developers. As a result, IBM and Sun started to define a portlet specification. JSR-168 is a set of APIs for defining portlets for interoperability between portlets and portals. This initial version had some deficiencies suc as inter-portlet communications so it was followed by JSR 286.

The Portlet Package

Every portlet and all the resources it needs are packaged into a standard web application archive (WAR). A war may contain multiple portlets. As usual, the web.xml file specifies things about the web application and a new file named the portlet.xml specifies portlet resources.

Portlet Modes and Window States

A portlet has one mandatory and other optional modes. These are:

• VIEW (Mandatory)
  • Display the Portlet
• EDIT
  • Customize Portlet properties and preferences
• HELP
  • Provide help

Windows states determine how a portlet is displayed on a portal page among other portlets:

• NORMAL
  • Sharing the page with other Portlets, the output size shoule be restricted
• MAXIMIZED
  • Portlet rendered as the only portlet on the portal page, the output can be richer
• MINIMIZED
  • Portlet should display minimal out put or no output

Click here to View more...

Inter Portlet Communication in JSR 286 Portlets

Coordination between portlets is a very common requirement. An example of information sharing between portlets can be a weather portlet displaying the weather information of a city and a map portlet displaying the location of the city. Since, both the portlets would be using the same zip code for a user, there should be mechanism provided by the portlal containers to allow portlets to share the zip code.

Prior to JSR 286, the support for inter portlet communication was rather minimal and information sharing between different portlets was accompalished primarily using application scoped session objects or vendor specific APIs. Both of above methods were rather problematic as in the former maintaining the uniqueness of the session attribute over a complex aaplication was a concern and in the later portability of the portlet was hampered. In order to provide coordination between portlets the Java Portlet Specification v2.0 (JSR 286) introduces the following mechanisms:

1. public render parameters in order to share render state between portlets.
2. portlet events that a portlet can receive and send.

Let's have a look how to use the above features.

Public Render Parameters

In JSR 168, the render parameters propagated by one portlet were only available in the render method of the same portlet. This is explained in the following figure.

In JSR 286, the render parameters propagated by one portlet can be made available to the render methods of other portlets. This is explained in the following figure.

In order to allow coordination of render parameters with other portlets, within the same portlet application or across portlet applications, in JSR 286 portlets, the portlet can declare public render parameters in its deployment descriptor using the public-render-parameter element in the portlet application section. In the portlet section each portlet can specify the public render parameters it would like to share via the supported-public-render-parameter element. The supported public-ender-parameter element must reference the identifier of a public render parameter defined in the portlet application section in a public-render-parameter element. The portlet should use the defined public render parameter identifier in its code in order to access the public render parameter.

Let's see how it works..
Consider the following example..

1. Set the public render parameters at the portlet application level.

<public-render-parameter>
 <identifier>id1</identifier>
 <qname xmlns:x="http://sun.com/params">x:param1</qname>
</public-render-parameter>
<public-render-parameter>
 <identifier>id2</identifier>
 <qname xmlns:x="http://sun.com/params">x:param2</qname>
</public-render-parameter>

2. Specify the render parameter the portlet would like to share in the portlet section.

<portlet>
<portlet-name>PortletA</portlet-name>
<supported-public-render-parameter>id1</supported-public-render-parameter>
<supported-public-render-parameter>id2</supported-public-render-parameter>
<portlet>
<portlet>
<portlet-name>PortletB</portlet-name>
<supported-public-render-parameter>id1</supported-public-render-parameter>
</portlet>
<portlet>
<portlet-name>PortletC</portlet-name>
<supported-public-render-parameter>id2</supported-public-render-parameter>
<portlet>

The public render paramters declared above are processed as explained in the figure below.

Now, since the public render parameters are encoded in the URL, the values that can be shared between portlets are restricted to String and String arrays. Since, public render parameters are available only in the render method, the information shared by the portlets should be used for rendering the view rather than for processing the shared information.

Portlet Events
Portlet events could be generated as a result of a user interaction with other portlets. The portlet event model is a loosely coupled, brokered model that allows creating portlets as stand-alone portlets that can be wired together with other portlets at runtime. Portlet programmers should therefore not make any specific assumptions about the environment of portlets they are running together with. The means of wiring different portlets together is portal implementation specific. An example where a portlet may want to offer receiving events is for state changes triggered by simple user interactions, e.g. adding an item to a shopping cart. By offering this as an event to other portlets these can trigger adding items to the shopping cart based on the user interactions happing inside these portlets.

EventPortlet Interface
In order to receive events the portlet must implement the EventPortlet interface in he javax.portlet package. The portlet container will call the processEvent method for each event targeted to the portlet with an EventRequest and EventResponse object.

Events are targeted by the portal / portlet container to a specific portlet window in the current client request. Events are a lifecycle operation that occurs before the rendering phase. The portlet may issue events via the setEvent method during the action processing which will be processed by the portlet container after the action processing has finished. As a result of issuing an event the portlet may optionally receive events from other portlets or container events. A portlet that is not target of a user action may optionally receive container events, e.g. a portlet mode changed event, or events from other portlets, e.g. an item was added to the shopping cart event.

The JSR 286 event processing is explained in the following figure.

To create portlets that use the eventing feature, follow these steps
1. Declare the events in the portlet.xml
(i) Set the event definition at the portlet application level. This specifies the event name and the object type.

<portlet-app ...>
<portlet>
. . .
. . .
</portlet>

<event-definition>
<qname xmlns:x="http:xebia.com/address">x:Address</qname>
<value-type>com.xebia.Address</value-type>
</event-definition>
</portlet-app>

@XmlRootElement
public class Address implements Serializable {
public Address() {
}
private String street;
private String city;
private String country;

//getters and setters
}

Note: The object must be serializable and must be instrumented with valid JAXB annotation. This might be required to ensure that portlets can send events to and receive events from remote portlets. However, in case of local communication, portal containers, for optimization purposes, might not serialize event payload.

(ii) In the portlet section, specify the event name defined above for those portlets that want to publish this event.

<portlet>
<description>ContinentPortlet</description>
<portlet-name>ContinentPortlet</portlet-name>
 .................
<supported-publishing-event>
  <qname xmlns:x="http:xebia.com/address">x:Address</qname>
</supported-publishing-event>
</portlet>

(iii) In the portlet section, specify the event name defined above for those portlets that want to process this event.

<portlet>
 <description>ContinentMapPortlet</description>
<portlet-name>ContinentMapPortlet</portlet-name>
 <supported-processing-event>
   <qname xmlns:x="http:xebia.com/address">x:Address</qname>
 </supported-processing-event>
</portlet>
<portlet>
 <description>ContinentInfoPortlet</description>
<portlet-name>ContinentInfoPortlet</portlet-name>
 <supported-processing-event>
   <qname xmlns:x="http:sun.com/events">x:Address</qname>
 </supported-processing-event>
</portlet>

2. Issue an event in the portlet that was specified as supported-publishing-event in the portlet.

public class ContinentPortlet extends GenericPortlet {
public void processAction(ActionRequest request, ActionResponse response)
throws PortletException,IOException {
QName qname = new QName("http:xebia.com/address" , "Address");
    Address add = new Address();
    //set values in address
    response.setEvent(qname, add);
}
}

3. Process the event in the portlet that has specified as supported-processing-event in the portlet

public class ContinentInfoPortlet extends GenericPortlet {
public void processEvent(EventRequest request, EventResponse response) {
Event event = request.getEvent();
if(event.getName().equals("Address")){
  Address payload = (Address )event.getValue();
  //process payload here
}
}
}

Portlet events provide more sphisticated way of exchanging information between portlets as compared to public render paramters as they can be used to share objects rather than simple string values. They also provide an additional callback method, processEvent, which can be used to process the event information before the view for the portlet in rendered. Also, portlet events share the information in a type safe manner as the event payload id bound to a type which we declare in the portlet.xml. Also, portlet specification does not standardizes how to wire the portlets, so, portal containers are free to choose convenient mechanisms to wire the portlets together.

However, as per the portlet specification, portlet events are not as reliable means of communication as is JMS, since the specification does not mandate the portal containers to persist the portlet event data. So, in case of server failures, the portlet events can be lost.

Summary
In this blog, we discussed about the JSR 286 inter portlet communication features. First, we discussed about the public render parameters and how it works. Secondly, we discussed about the portlet events, and it's working. So, how to decide when to choose either of the above two portlets. I would use the following principle

In case, the receiver portlet, does not need to do any processing/businees logic, it is advisable to use public render parameters as they avoid the overhead for portlets event creation and wiring the portlets together, which is required in case of portlet events. As already discussed, wiring portlets together is portal container specific and is an addtional overhead. However, to allow receiver portlets to process the shared information and sending type safe values, we need to use portlet events.

Overall, JSR 286 portlet coordination features make complex portal applications modular and manageable.

Click here to View more...

JSR 316: Java EE 6 Specification

This JSR is to develop Java EE 6, a release of the Java Platform, Enterprise Edition targeted to ship in 2008.

Supporting this JSR:

• Hani Suleiman
• Apache
• TmaxSoft
• Charlton Barreto
• Pramati
• Oracle
• Kingdee Middleware Co., Ltd.
• JBoss (Red Hat Middleware)
• Capgemini
• BEA
• Sybase
• Felipe Leme
• Interface21
• IBM

Section 2: Request

2.1 Please describe the proposed Specification:

This JSR is to develop Java EE 6, a release of the Java Platform, Enterprise Edition targeted to ship in 2008.

In the past 8 years, the Java EE platform has grown and matured, and is now able to cover a wide range of enterprise and web application development needs. In addition, the Java EE platform has fostered a vibrant community and marketplace for additional technologies, frameworks, and applications that work with the platform. Some of these provide facilities that are missing from the platform. Others provide alternatives to platform facilities. A major theme for this release is to embrace and support those technologies as part of the overall Java EE landscape, while also continuing to simplify the platform to better target a wider range of developers. To that end we propose two goals for this release - extensibility and profiles.

Extensibility

It would not be appropriate for the Java EE platform to grow without bound to include all the interesting and useful technologies desired by web and enterprise application developers. Instead, we believe it is desirable to enable more of these technologies to cleanly layer on or plug in to Java EE application servers. By adding more extensibility points and more service provider interfaces, these other technologies can plug in to platform implementations cleanly and efficiently, and be just as easy to use for developers as the facilities that are built into the platform.

Profiles

The reach of the Java EE platform has become so broad that it has lost some of its original focus. To refocus the Java EE platform on particular classes of developers and applications, we propose the introduction of Java EE platform Profiles. Profiles will reference the Java EE platform, as defined by the JCP process, and may include a subset of Java EE platform technologies, additional JCP technologies not part of the base Java EE platform, or both. In addition to defining the base Java EE platform, this specification will define the rules for referencing Java EE platform technologies in Java EE Profiles.

This expert group will also define the first version of a Java EE Web Profile - a subset of the Java EE platform targeted at web application development. This profile will provide a more gentle introduction to the Java EE platform, providing only those technologies needed by most web application developers, without the enterprise technologies that sometimes confuse such developers.

Pruning

The use of profiles is one tool to address the ever increasing size of the Java EE platform. It's also the case that some technologies included in the Java EE platform are no longer as relevant as they were when they were introduced to the platform. There needs to be a way to "prune" these technologies from the platform in a careful and orderly way that minimizes the impact to developers using these technologies while allowing the platform to grow even stronger. We propose to use the process defined by the Java SE expert group. In short, that process defines two steps:

1. The Umbrella Expert Group (UEG) for release N of the platform decides to propose that a particular feature be removed. The specification for that release documents the proposal.
2. The UEG for release N+1 decides whether to remove the feature from that release, retain it as a required component, or leave it in the "proposed removal" state for the next UEG to decide.

The result of successfully applying this policy to a feature is not the actual deletion of the feature but rather the conversion of the feature from a required component of the platform into an optional component. No actual removal from the specification occurs, although the feature may be removed from products at the choice of the product vendor.

As defined by that process, this expert group will consider technologies that should be marked for possible removal in a future Java EE platform specification. Possibilities include:

• EJB CMP - effectively replaced by Java Persistence
• JAX-RPC - effectively replaced by JAX-WS

This specification will only define the technologies that a future expert group may consider to make optional in a future platform specification, as described in the first step of the process. None of these technologies will be made optional in this release.

SOA Support

The Java EE platform is already widely used for SOA applications. As more and more enterprises realize the benefits of a SOA architecture, requirements on the platform have increased, both in terms of functionality and interoperability.

J2EE 1.4 delivered basic web services support, including support for the WS-I Basic Profile, for the Java platform. Java EE 5 delivered additional web services support. Web service standards continue to evolve and it is critical that the Java platform support the latest web service standards. Java EE 6 will need to consider additional web services support. While basic web services support is now part of the Java SE 6 platform, this specification will require newer versions of these technologies that provide additional web services support.

The Service Component Architecture is defining facilities that could be used by composite applications in a SOA environment. This expert group will consider whether any of the SCA-defined facilities are appropriate for inclusion in this release of the Java EE platform.

Other Additions

Java EE 5 represented a major step forward in making it easier to develop applications for the Java EE platform. Additional improvements in this area are expected in this release.

This JSR will not itself define any new APIs, rather it will enumerate APIs defined in other JSRs or through the JCP maintenance process.

Java EE 6 is the Enterprise Edition of version 6 of the Java platform, and thus will be built on Java SE 6.

We propose to include the following new JSRs in Java EE 6:

• JSR-196 Java Authentication SPI for Containers
• JSR-236 Timer for Application Servers
• JSR-237 Work Manager for Application Servers
• JSR-299 Web Beans
• JSR-311 JAX-RS: Java API for RESTful Web Services

In addition, we expect to update the following existing technologies for Java EE 6:

• Enterprise JavaBeans
• Java Persistence API
• Servlets
• JavaServer Faces
• JAX-WS
• Java EE Connector API

The exact set of technologies to be included will be determined by the expert group and will be based on partner and customer requirements.

Deferred

Consideration of the following JSRs, while important to the Java EE community, will be deferred to future Java EE Profiles:

• JSR-168 Portlet Specification
• JSR-170 Content Repository for Java technology API
• JSR-207 Process Definition for Java
• JSR-208 Java Business Integration (JBI)
• JSR-225 XQuery API for Java (XQJ)
• JSR-235 Service Data Objects
• JSR-286 Portlet Specification 2.0
• JSR-289 SIP Servlet v1.1
• JSR-301 Portlet Bridge Specification for JavaServer Faces

To better support the extensibility goals of the platform it would be useful to have a more general concept of modules. Such work is underway in JSR-277 - Java Module System, which is targeted for Java SE 7. We anticipate that Java EE 7 will build on that technology and thus we will defer specification of any potentially conflicting technology to a future release.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

This specification defines a release of the Java EE platform.

This expert group will also define a Profile based on this release of the Java EE platform.

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

This JSR updates a platform edition and defines how profiles may be created based on that platform edition.

Should this JSR be voted on by both Executive Committees?

No. SE/EE EC Only.

2.5 What need of the Java community will be addressed by the proposed specification?

Java EE 6 will extend the capabilities of the Java EE platform to include many new technologies under development in the JCP.

2.6 Why isn't this need met by existing specifications?

While existing (in progress) specifications provide the base capabilities, no other specification can unite these components into a coherent Java platform.

2.7 Please give a short description of the underlying technology or technologies:

A detailed description of Java EE functionality can be found in the Java EE Specification, http://java.sun.com/javaee/download.html#platformspec.

2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

The Java EE platform itself does not require a package name. All of its requirements are reflected in the packages of its constituent Java APIs.

2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No.

2.10 Are there any security issues that cannot be addressed by the current security model?

Java EE 6 addresses mechanisms and policies required for secure usage of its constituent component models and access APIs. These mechanisms must be compatible with the security facilities of Java SE 6.

In addition, Java EE 6 will define additional Service Provider Interfaces, including those that allow security technology vendors to integrate with Java EE application servers.

2.11 Are there any internationalization or localization issues?

Java EE uses the I18N support in Java SE and defined in constituent technologies.

2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

Other than the Java EE specification itself and the new versions of its constituent component models and access APIs, Java EE 6 should not require other existing specifications to be revised. Java EE 6 may recommend deprecation of some items as described above under "Pruning".

2.13 Please describe the anticipated schedule for the development of this specification.

We hope to deliver the final specification, reference implementation, and TCK by the end of 2008. This implies that the specification must reach Proposed Final Draft by early 2008. A rough schedule would be:

Jul 2007	Expert group formed
Aug 2007	First expert draft
Oct 2007	Early Draft Review
Dec 2007	Public Review
Mar 2008	Proposed Final Draft
Q2 2008	RI beta release
Q4 2008	Final release

2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.

The primary means of communication will be email, with conference calls and face-to-face meetings scheduled as needed.

2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.

The code for the Reference Implementation for all Sun-led components will be developed as part of the open source GlassFish Project. In addition, new features of the JCP web site will be used to keep the community up to date on the progress of the specification.

2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

The RI and TCK for Java EE 6 will be delivered in the same way they were delivered for Java EE 5. The RI and TCK for the Java EE 6 Web Profile will be delivered in a similar manner.

2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

N/A

2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

Pursuant to Section 2.2.1 of the Java Community Process version 2.6, the following is a summary of Sun's anticipated principal license terms and conditions for Java Platform, Enterprise Edition 6.

Java EE licensing terms have not changed. Sun has no plans to introduce changes to the existing license terms for Java EE and previously J2EE. We do not intend to place any additional restrictions on this license.

There is one new item in the business terms regarding the new Java EE Web Profile. All aspects of the Java EE 6 Web Profile will be available for use by Java EE licensees under the terms of their license, with no new restrictions imposed. The creation of the Web Profile was inspired by feedback from the Java EE licensees. The intent of the Web Profile is to expand the market and community for Java EE by lowering the barrier to entry. Licensees will have the option of providing a complete Java EE compatible implementation or a subset by providing a compatible Web Profile. Any additional Java EE subset profiles will also be available to Java EE licensees under their Java EE business terms.

Non-Commercial Use

As required by the Java Specification Participation Agreement (JSPA), the Java EE 6 Compatibility Test Suite (CTS) will be licensed at no charge without support to qualified not-for-profit entities. Such qualification will be verified by the Compatibility Testing Scholarship Program. Support may also be provided at no charge with approval of the scholarship board. For more information, please refer to: http://java.sun.com/scholarship/.

Reference Implementation (RI) source and binary will be available at no cost under an open source license.

Commercial Use

Covers all use that doesn't fall under "Non-Commercial Use" above.

Compatibility Fee

There are two Compatibility licenses available to commercial users which include access to the CTS and brand licensing.

Option 1: Java EE Brand Maintenance without the RI, for a flat fee of $350K per year per Marketed Product*. To promote broader distribution of the Java EE technology, companies may alternatively elect to pay $100K plus a Compatibility fee of 2% of Adjusted Revenues* per year, subject to an annual cap of $700K per year per Marketed Product.

Option 2: Java EE Brand Maintenance with redistribution rights to the RI for a flat fee of $500K per year per Marketed Product. To promote broader distribution of the Java EE technology, companies may alternatively elect to pay $100K plus a Compatibility fee of 3% of Adjusted Revenues per year, subject to an annual cap of $1,000K per year per Marketed Product.

Support

CTS Support is required for commercial use, and will be sold in increments of 10 hours/week of compatibility testing support for a fee of $135K per year. CTS Support includes updates and upgrades to the CTS at no additional charge.

Reference Implementation Source support is available in 20 hours/week increments for a fee of $200K per year.

RI and CTS

The Java EE 6 RI and CTS will be made available to Sun's Java EE licensees for such technology according to their Java EE licensing terms.

The RI source and binary will also be made available for commercial use at no cost without support under an open source license.

Definitions

For purposes of these terms:

Marketed Product is intended to describe a licensee's product that has its own differentiation and marketing collateral. It may comprise one price list entry, or in some cases multiple entries (for example, to account for different localizations or delivery packaging). By way of example, in terms of Sun's product line we wouldn't consider Sun's Java System Application Server to be a Marketed Product, but Sun's Java System Application Server Platform Edition, Standard Edition, and Enterprise Edition are three Marketed Products. Sun's Java Studio Enterprise is a fourth Marketed Product.

Adjusted Revenues is intended to include all gross corporate revenue related to Marketed Products, and includes without limitation both licensing and services.

Java Platform, Enterprise Edition Web Profile

Pursuant to Section 2.2.1 of the Java Community Process version 2.6, the following is a summary of Sun's anticipated principal license terms and conditions for Java Platform, Enterprise Edition 6 Web Profile.

All aspects of the Java EE 6 Web Profile will be available for use by Java EE licensees under the terms of their license, with no new restrictions imposed. The creation of the Web Profile was inspired by feedback from the Java EE licensees. The intent of the Web Profile is to expand the market and community for Java EE by lowering the barrier to entry. Any additional Java EE subset profiles will also be available to Java EE licensees under their Java EE business terms.

Non-Commercial Use

As required by the Java Specification Participation Agreement (JSPA), the Java EE 6 Web Profile Technology Compatibility Kit (TCK) will be licensed at no charge without support to qualified not-for-profit entities. Such qualification will be verified by the Compatibility Testing Scholarship Program. Support may also be provided at no charge with approval of the scholarship board. For more information, please refer to: http://java.sun.com/scholarship/.

Reference Implementation (RI) source and binary will be available at no cost under an open source license.

Commercial Use

Covers all use that doesn't fall under "Non-Commercial Use" above.

Compatibility Fee

A Compatibility license is available to commercial users which includes access to the TCK and brand licensing. TCK and brand licensing for the Java EE 6 Web Profile will be made available to Sun's Java EE licensees according to their Java EE licensing terms.

For new licensees, Java EE Web Profile Brand Maintenance will be available at a flat fee of $280K per year per Marketed Product*. To promote broader distribution of the Java EE Web Profile technology, companies will be able to alternatively elect to pay $80K plus a Compatibility fee of 2% of Adjusted Revenues* per year, subject to an annual cap of $560K per year per Marketed Product.

Support

TCK Support is required for commercial use and will be sold in increments of 10 hours/week of compatibility testing support for a fee of $135K per year. TCK Support includes updates and upgrades to the Web Profile TCK at no additional charge.

RI and TCK

The Java EE 6 Web Profile TCK will be made available to Sun's Java EE licensees for such technology according to their Java EE licensing terms.

The RI sources and binary will also be made available for commercial use at no cost without support under an open source license.

Definitions

For purposes of these terms:

Marketed Product is intended to describe a licensee's product that has its own differentiation and marketing collateral. It may comprise one price list entry, or in some cases multiple entries (for example, to account for different localizations or delivery packaging). By way of example, in terms of Sun's product line we wouldn't consider Sun's Java System Application Server to be a Marketed Product, but Sun's Java System Application Server Platform Edition, Standard Edition, and Enterprise Edition are three Marketed Products. Sun's Java Studio Enterprise is a fourth Marketed Product.

Adjusted Revenues is intended to include all gross corporate revenue related to Marketed Products, and includes without limitation both licensing and services.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

Java Platform, Enterprise Edition Specification Version 5, and related specifications
http://jcp.org/en/jsr/detail?id=244

Java Platform, Standard Edition, v6 API Specification
http://java.sun.com/javase/6/docs/api/index.html

3.2 Explanation of how these items might be used as a starting point for the work.

These specifications will be the basis for Java EE 6.

Click here to View more...

JSF Portlets

Why JSF and Portlets?

Why should I combine JavaServer Faces (JSF) and Portlets? Why did you build up such a website?


If you have questions like these, be assured:

JSF and Portlets are a great team in order to
create modern und powerful websites.



Portlets have been available for some time now. There
are plenty of websites based on the portlet technology.
But programming portlets is sometimes a bit exhausting,
because you have to use "old" JSP- and Servlet programming
technologies.



On the other hand you have quite powerful webframeworks like
JavaServer Faces. With JSF you have a fantastic base for
creating user interfaces for web applications.



In December 2006 a new JSR was born: JSR-301. The main goal
of this JSR was the combination of JSF and Portlets.
So for the future it will be possible you have both powerful
technologies without feeling any pain during integration.



The main target of this website is to provide tutorials and
knowhow, how you can use this great combination.


JSR-168 and JSR-286


All started with JSR-168 some years ago. This was the first specification for
a portlet standard. Though the JSR-168 was not catching all aspects of portlet programming,
it was still a great success to have a common standard in the industry.
Nowadays, nearly all developers build their portlet application based on this standard.



Because of the lack of some very important features in the specification, a second
version (or an enhancement of JSR-168) was started: JSR-286. This specification is
going to standardize features like eventing, public render parameters or portlet filters.



Now, with the enhanced specification of the portlet development it will be possible
to create powerfull AND standard-based portlet applications.

In my opinition, this is a big step towards the acceptance of Portals and Portlets in
the industry.



JSR-127, JSR-252 and JSR-314


With JSR-127, a new user-interface framework was standardized. The process began in 2001.
The expert group defined the first standard for a framework targeting the user interface
in web applications.



JavaServer Faces, the name of the framework, was very successful from the beginning. A lot
of companies used this standard for building their web user interface.
With JSR-252 a next step of the specification (and reference implementation) was done. The
main new thing was, that JSF 1.2 belongs to Java EE 5. That means, every Java EE 5 compatible
Application Server runs with JSF.



JSR-314 is the next version of JSF. JSF 2.0 is developed at the moment within this
JSR. Hopefully at the end of 2008 we will see the result of the expert group.





JSR-301


Portlets and JavaServer Faces are both great frameworks. Both are based on standards
and both technologies are acknowledged in the industry.



But the combination of JSF and Portlets was not easy in the past. It was hard to create
a mapping of the lifecycles of each framework and also to use all aspects of JSF within
the portlet container.



With JSR-301 (Portlet Bridge Specification for JavaServer Faces), a new JSR started with
the goal to standardize a bridge for using both technologies.









Combining JSF with Portlets - Step 1


In the following pages a simple portlet based on JavaServer Faces
is created. It is shown, how you can integrate JSF and Portlets using
the JSR-301 Portlet Bridge.


This tutorial is the first approach to demonstrate the usage of the
JSR-301 bridge. As the bridge is still "work in progress", changes could
occur in the future :-)



Within the following pages we will build a very simple portlet with some
JSF-pages and components. The example is based on Apache Pluto 1.1.4,
Apache Tomcat 6.0.14, JSF 1.2_05 (Reference Implementation) and JSTL 1.2.

Click here to View more...