Patent Application
20080077851
The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:
Like reference numerals are used to refer to like elements throughout the drawings. The detailed description explains the preferred embodiments of the invention, together with advantages and features, by way of example with reference to the drawings.
Portlet B 113 and servlet 111 may be written by software developers, adopted from existing applications, or both. Portlet B 113 may be accessed as servlet 111 is accessed, using a URL or an SPI. Such a URL is illustratively in the form of http://host/context/portlet-name. A specialized manifestation of portal context is defined in URL form in order to allow portlet B 113 to be called via the URL. When using an SPI, any arbitrary URL can be created and employed. A suitable SPI is provided in the form of a RequestDispatcher, to be described in greater detail hereinafter.
There are multiple techniques for calling portlets such as portlet B 113. Pursuant to a first technique, invoker SPI 109 of portlet container 115 provides for multiple aggregation of portlets on a page. Illustratively, a caller is provided with flexibility to change the behavior of the portal context. Pursuant to a second technique, URL addressability is employed via a URL. This technique does not allow for aggregation of multiple portlets on a page. Any of two types of URL addressability may be employed, including a RequestDispatcher and a URL entered into a browser.
Invoker SPI 109 of portlet container 115 is only accessible from a servlet such as servlet 111. Invoker SPI 109 of portlet container 115 uses a Java interface available through a ServletContext attribute. Any servlet can call portlets using this Java interface. An example of this interface is as follows:
Portlets and servlets, including portlet B 113 and servlet 111, can be defined together in one WAR file. However, due to URL addressability considerations and security features (described below), the following restrictions may be applied to servlet and portlet descriptors. First, a portlet and a servlet can never use the same name. Second, a servlet mapping cannot be the same as any /<portletname>/ or /portlet/<portletname>/. These restrictions are validated during application install and, if either or both of these conditions are violated, the WAR file is rejected. URL addressability defines a URL format, such as http://host:port/context/portlet-name/portletwindow. Additional path parameters could, but need not, be utilized to specify version, action, mode, state, render parameters, query parameters, or other parameters as, for example: http://localhost/demo/weather/default/action/mode=edit/state=max. URLs may, but need not, be defined with reference to RFC 2396 of the Public URL Form.
URL addressability preferences are stored in a cookie. The attributes of the cookie are defined as Path, Name, and Value. Path contains context, portlet name, and window ID in the form of /context/portlet/window. As a consequence, these preferences are scoped per portletwindow. Name is a fixed value, such as “PortletPreferenceCookie”. Value is a list of preferences with the following structure:
URLs are employed in the context of RequestDispatcher as follows. The same URL structure may be adopted as previously discussed in connection with URL addressability. Include is used to call action and render. Forward is not supported. If the URL contains an action, the action is automatically processed. The caller should find out if the URL contains an action by processing the URL. A portlet URL helper may be provided in the form of PortletURLHelper. The caller can control whether or not portlet container 115 should return directly after the action or proceed with the calling render. The caller can set a servlet 111 request attribute with a name ‘com.ibm.websphere.portlet.action’ and value ‘redirect’. Exceptions are wrapped into ServletExceptions.
RequestDispatcher supports a simple aggregation of multiple portlets. In order to ensure that all portlet capabilities are operational, the following functionalities may be provided: URL handling, action handling, portlet preferences, render parameters and, optionally, exception handling. The URL handing functionality operates to allow portlet container 115 to generate correct URLs. Correct URL generation is made possible by passing a template URL into portlet container 115 using a request attribute. The attributes with a name “com.ibm.websphere.portlet.url.prefix”, “suffix”, and “queryparams” describe the URL to a containing JSP. Between prefix and suffix, portlet container 115 will complete a portlet specific URL. An example of this process is as follows:
The action handling functionality mentioned above operates as follows. In order to call the action method of a portlet, the containing servlet or JSP has to call the portlet with the action before any content is written onto an output stream. In some cases, it is also sufficient to only call action before any other link on the page has been generated, such as in situations where preferences are not stored in cookies. It is recommended to always perform a redirect after calling action. This enables the ability to bookmark, as well as providing functionality for a back button of the web browser to operate, as otherwise these features would not operate.
The interface for portlet preferences are cookies as defined previously. A containing servlet or JSP should consolidate all preferences and store these preferences in the form of structured data. It is recommended to store the consolidated preferences in a cookie as well. Since preferences can only be changed within the action method of a portlet, the cookie can also be set on the not yet committed response. The render parameters of all portlets on at least one page have to be stored for a length of time that extends beyond one request. There are two alternatives to such storage. First, a URL can be employed. However, such a URL would be very long and complex. Errors are possible due to URL length limitations. On the other hand, the URL would permit book marking and back button support. Second, a session can be employed to hold as much information as necessary without limitation. Unfortunately, this second approach will not support book marking and back button functionalities.
A plurality of tags are incorporated into a Java server page (JSP)-compliant page or JSP-compliant page fragment to insert portlet content from a portlet directly onto a page without using an enterprise portal application. The plurality of tags may be provided in the form of a tag library for simple aggregation. The following tags may be provided to allow portlet aggregation from within a JSP: (a) portlet-fw:init, (b) portlet-fw:state, and (c) portlet-fw:insert. Other tags may optionally be used in addition to the three aforementioned tags. Portlet-fw:init is an initialization tag that uses a mandatory attribute of portletURLPrefix=“X”, and possible optional attributes of portletURLSuffix=“Y”, and portletURLQueryParams=“Z”. Portlet-fw:init should be called at the beginning of any JSP. Portlet-fw:state is a state tag that uses a mandatory attribute of URL “X”, and possible optional attributes of mode “Y”, WindowState=“Z”, and more. Portlet-fw:insert is an insertion tag that uses a mandatory attribute of URL=“X”, and possible optional attributes of windowld=“Y”, contentVar=“A”, contentScope=“B” (default: page), titleVar=“C”, titleScope=“D” (default: page), and flush=“true/false” (default: false), and more.
Assume that a user issues a request to access HTML page 200. A browser URL is http://localhost/hello/framework. An HTTP session is empty. A URL is constructed in the form of: http://localhost/hello/framework/demo/weather/default/ver=1.0/mode=edit/something?p1=v1&p2=v2. The user issues a second request by clicking on a link in a weather portlet. The browser URL is: http://localhost/hello/framework/demo/weather/default/ver=1.0/mode=edit/something?. The HTTP session (URL is parsed in portlet.init): demo/weather/default: mode=edit. The URL in response is: http://localhost/hello/framework/demo/weather/default/ver=1.0/rparam=page=2/something?p1=v1&p2=v2.
Pursuant to a third request, the user clicks on a link in a time portlet. The browser URL is: http://localhost/hello/framework/demo/time/default/ver=1.0/rparam=page=2/something?. The HTTP session (URL is parsed in portlet.init): demo/weather/default: mode=edit, and demo/time/default: rparam=page=2. The URL in response is http://localhost/hello/framework/demo/weather/default/ver=1.0/action=something?. A fourth request is issued when the user clicks on a link in the weather portlet. The browser URL is: http://localhost/hello/framework/demo/time/default/ver=1.0/action=something?. The HTTP session (URL is parsed in portlet.init): demo/weather/default: mode=edit, and demo/time/default: rparam=page=2. An action method of demo/weather is called and a redirect is issued after that.
Invoker SPI 109 (
Error and exception handling operates as follows. Invoker SPI 109 of portlet container 115 generates PortletExceptions and PortletContainerExceptions. When called via browser, the exceptions are converted into HTTP error codes. Internal server errors are converted into standard 500-category errors. User errors are converted according to different error codes, such as a wrong URL format error may be converted into a 400-category “Not Acceptable” error. When called via RequestDispatcher, the PortletExceptions and PortletContainerExceptions are wrapped into one or more ServletExceptions. PortletUnavailableExceptions are transformed into ServletUnavailableExceptions. Portlet container 115 logs one or more root causes for the exceptions.
An optional extended portlet deployment descriptor may be used, such as ibm-portlet-ext.xmi. This deployment descriptor is optional and may be used to define Websphere extensions for portlets. The following setting is supported: portletServingEnabled=Boolean [default: true]. This setting defines whether or not a portletServingServlet is created for each portlet.
A portal may be equipped to allow the portal to suppress portlet serving. A portlet serving flag may be turned off pursuant to a default setting. Any of two acceptable options may be employed. First, the default for portlet serving servlet is set to false. During deployment of a portlet application, an additional step is displayed to the user whereby the user can select if this capability should be turned on or off. Second, the default for portlet serving servlet is set to true. The portal would automatically turn off this value during installation and allow an administrator to change the flag in the future if necessary. This would either require an administrator console enhancement or portal administration enhancement.
A portlet only delivers fragment output whereas a servlet normally delivers document output. In order to address portlets like servlets, a default servlet is introduced similar to a FileServingServlet which, for example, is termed a PortletServingServlet. A default document ServletFilter is applied to the PortletServingServlet in order to return the portlet's content inside of a document. Other servlet filters can be applied to enhance this capability. This filter only applies for requests, not for includes or forwards. The servlet is developed to support the URL format of the portlet context. The PortletServingServlet can be disabled in an extended portlet deployment descriptor named ibm-portlet-ext.xmi.
Servlet filter 107 (
From time to time, there might be situations where multiple servlet filters 107 are called and it is not known if a fragment was already converted into a document. Therefore, a new request attribute is defined with the name ‘com.ibm.websphere.portlet.filter’. This attribute needs to be set to the value ‘document’ as soon as one filter starts converting the fragment into a document. This allows servlet filter 107 to check for a situation where multiple filters may be engaged in converting a document, so as to avoid invalid markup.
A new XML structure is defined that can be used to add new document servlet filters 107. The file named portlet-document-filter-config.xml resieds in a META-INF/directory of any JAR file in <WAS-HOME>/lib or a shared library bound to a server. An illustrative example of a suitable XML file is as follows:
An optional web server plug-in may be employed. Portlet mapping is not part of web.xml and thus is not automatically passed on to the web server plug-in. A mechanism should be provided to pass this information on to the web server plug-in. The web server plug-in includes generation code that obtains a reference to a portlet deployment descriptor, illustratively in WCCM Model form. The code also checks to see if PortletServingEnabled is turned on. Depending on whether PortletServingEnabled is turned on, a corresponding URL pattern is added for each portlet /<portlet-name>/.
Portlet container 115 (
A model for portlet container 115 is stored in server.xml of application server 101 (
Since a portlet can be addressed directly via a URL, the URL can be leveraged based upon an authentication mechanism provided by web.xml of web.xml role definitions 124. As a result, a directly accessible portlet can be secured from direct access. If one defines a TransportGuarantee in web.xml role definitions 124 as well as in portlet.xml role references and transport guarantee 126 using the same name or mapping, the value of portlet.xml wins, meaning that the web.xml value is overwritten. For example, a portlet with the name “HelloWorld” is defined in portlet.xml, role reference and transport guarantee 126. This portlet can be secured by defining an authentication constraint with the URL mapping ‘/HelloWorld/*’ in web.xml role definitions 124. In this manner, a user would be challenged if they attempted to access the portlet.
A portlet fragment can contain a state in a response that does not belong to this fragment. When this state changes, the cached fragment needs to retain its validity. One solution is to use a DynamicContentProvider of dynacache 505 to solve the problem of not having cacheable content in the fragment. The problem may be introduced due to a state describing parts outside of the cached fragment which are part of the portlet URL. The cacheable data of the portlet URL are set as request attributes, setting a callback with the DynamicContentProvider. Portlet URL creation is not triggered directly, but rather through callback, when a cache hit occurs. Therefore, portlet container 115 (
Referring now to
The capabilities of the present invention can be implemented in software, firmware, hardware or some combination thereof.
As one example, one or more aspects of the present invention can be included in an article of manufacture (e.g., one or more computer program products) having, for instance, computer usable media. The media has embodied therein, for instance, computer readable program code means for providing and facilitating the capabilities of the present invention. The article of manufacture can be included as a part of a computer system or sold separately.
Additionally, at least one program storage device readable by a machine, tangibly embodying at least one program of instructions executable by the machine to perform the capabilities of the present invention can be provided.
The flow diagrams depicted herein are just examples. There may be many variations to these diagrams or the steps (or operations) described therein without departing from the spirit of the invention. For instance, the steps may be performed in a differing order, or steps may be added, deleted or modified. All of these variations are considered a part of the claimed invention.
While the preferred embodiment to the invention has been described, it will be understood that those skilled in the art, both now and in the future, may make various improvements and enhancements which fall within the scope of the claims which follow. These claims should be construed to maintain the proper protection for the invention first described.
