Portlets & JSR 168

-Rahul Gupta

In this section, we explain the basic definitions used in the portlet specification, including a portal's basic architecture, the portlet container, and a portal page.

Portal
               A portal is a Web-based application that provides personalization, single sign-on, and content aggregation from different sources, and hosts the presentation layer of information systems. Aggregation is the process of integrating content from different sources within a Webpage. A portal may have sophisticated personalization features to provide customized content to users. Portal pages may have different sets of portlets creating content for different users.
The portal Web application processes the client request, retrieves the portlets on the user's current page, and then calls the portlet container to retrieve each portlet's content. The portlet container provides the runtime environment for the portlets and calls the portlets via the Portlet API. The portlet container is called from the portal via the Portlet Invoker API; the container retrieves information about the portal using the Portlet Provider SPI (Service Provider Interface).

  The portal page itself represents a complete markup document and aggregates several portlet windows. In addition to the portlets, the page may also consist of navigation areas and banners. A portlet window consists of a title bar with the portlet's title, decorations, and the content produced by the portlet. The decorations can include buttons to change the portlet's window state and mode

Portlet
               Portlet is a Java-based Web component that processes requests and generates dynamic content. The content generated by a portlet is called a fragment, a piece of markup (e.g., HTML, XHTML, or WML (Wireless Markup Language)). A fragment can be aggregated with other fragments to form a complete document. A portlet's content normally aggregates with the content of other portlets to form the portal page. A portlet container manages a portlet's life cycle.
Web clients interact with portlets via a request/response paradigm implemented by the portal. Usually, users interact with content produced by portlets by, for example, following links or submitting forms, resulting in portlet actions being received by the portal, which then forward to the portlets targeted by the user's interactions.
The content generated by a portlet may vary from one user to another depending on the portlet's user configuration.

Portlet container
                  A portlet container runs portlets and provides them with the required runtime environment. A portlet container contains portlets and manages their life cycles. It also provides persistent storage mechanisms for the portlet preferences. A portlet container receives requests from the portal to execute requests on the portlets hosted by it. A portlet container is not responsible for aggregating the content produced by the portlets; the portal itself handles aggregation.
A portal and a portlet container can be built together as a single component of an application suite or as two separate components of a portal application.

JSR 168
                        With the emergence of an increasing number of enterprise portals, various vendors have created different APIs for portal components, called portlets. This variety of incompatible interfaces generates problems for application providers, portal customers, and portal server vendors. To overcome these problems, JSR (Java Specification Request) 168, the Portlet Specification, was started to provide interoperability between portlets and portals.
                           JSR 168 defines portlets as Java-based Web components, managed by a portlet container, that process requests and generate dynamic content. Portals use portlets as pluggable user interface components that provide a presentation layer to information systems.

JSR 168's goals are the following:
• Define the runtime environment, or the portlet container, for portlets
• Define the API between portlet container and portlets
• Provide mechanisms to store transient and persistent data for portlets
• Provide a mechanism that allows portlets to include servlets and JSP (Java Server Pages)
• Define a packaging of portlets to allow easy deployment
• Allow binary portlet portability among JSR 168 portals
• Run JSR 168 portlets as remote portlets using the Web Services for Remote Portlets (WSRP) protocol

The IT industry has broadly accepted JSR 168.


Portlet life cycle of JSR 168
The basic portlet life cycle of a JSR 168 portlet is:
• Init: initialize the portlet and put the portlet into service
• Handle requests: process different kinds of action- and render-requests
• Destroy: put portlet out of service

The portlet container manages the portlet life cycle and calls the corresponding methods on the portlet interface.

Portlet interface
                 Every portlet must implement the portlet interface, or extend a class that implements the portlet interface. The portlet interface consists of the following methods:
• init(PortletConfig config): to initialize the portlet. This method is called only once after instantiating the portlet. This method can be used to create expensive objects/resources used by the portlet.

• processAction(ActionRequest request, ActionResponse response): to notify the portlet that the user has triggered an action on this portlet. Only one action per client request is triggered. In an action, a portlet can issue a redirect, change its portlet mode or window state, modify its persistent state, or set render parameters.

• render(RenderRequest request, RenderResponse response): to generate the markup. For each portlet on the current page, the render method is called, and the portlet can produce markup that may depend on the portlet mode or window state, render parameters, request attributes, persistent state, session data, or backend data.

• destroy(): to indicate to the portlet the life cycle's end. This method allows the portlet to free up resources and update any persistent data that belongs to this portlet.

JSR 168 - Portlet modes
                      A portlet mode indicates the function a portlet performs. Usually, portlets execute different tasks and create different content depending on the functions they currently perform. A portlet mode advises the portlet what task it should perform and what content it should generate. When invoking a portlet, the portlet container provides the current portlet mode to the portlet. Portlets can programmatically change their mode when processing an action request.

JSR 168 splits portlet modes into three categories:

1. Required modes: Every portal must support the modes Edit, Help, and View. A portlet must at least   support the View mode used to render markup for a page. The Edit mode is used to change per-user settings to customize the portlet markup, and the Help mode is used to show a help screen.

2. Optional custom modes: These are modes that a portal may support; while in an optional mode, a portlet might not be called. The optional modes include the About mode to display an "about" message; the Config mode to let administrators configure the portlet; Edit_defaults mode to let an administrator preset the Edit mode's values; the Preview mode to show the portlet's preview; and the Print mode to render a view that can easily print.

3. Portal vendor-specific modes: These modes are not defined in the specification and are therefore vendor specific.

JSR 168 and Window States
                  A window state indicates the amount of portal page space that will be assigned to the content generated by a portlet. When invoking a portlet, the portlet container provides the current window state to the portlet. The portlet may use the window state to decide how much information it should render. Portlets can programmatically change their window state when processing an action request.

JSR 168 defines the following window states:
• Normal: Indicates that a portlet may share the page with other portlets. This is the default window state.
• Maximized: Indicates that a portlet may be the only portlet on the portal page or that the portlet has more space compared to other portlets in the portal page, and can therefore produce richer content than in a normal window state.
• Minimized: Indicates that the portlet should only render minimal output or no output at all.
In addition to these window states, JSR 168 allows the portal to define vendor-specific window states. A portlet can be called in any of these three window states, but is free to produce the same markup for all three states.

Persistent store
                           The portlet can store persistent data for a specific user by using the PortletPreferences object. Preferences can be read and written in the action phase, and read in the render phase. The preferred mode to write preferences is the Edit mode, which provides the user with a customization screen. The preferences can be either strings or string array values associated with a key of type string. Preferences can be preset with default values in the deployment descriptor.
Preferences and the portlet's definition in the deployment descriptor together define a portlet, sometimes called a portlet entity.

JSR 168 Sessions
                       JSR 168's session concept is based on the HttpSession defined for Web applications. As portlet applications are Web applications, they use the same session as servlets. To allow portlets to store temporary data private to a portlet, the default session scope is the portlet scope. In this scope, the portlet can store information needed across user requests and specific to a portlet entity. Attributes stored with this scope are prefixed in the session by the portlet container to avoid two portlets (or two entities of the same portlet definition) overwriting each other's settings.
In addition to the portlet session scope, JSR 168 supports the Web application session scope. In this scope, every component of the Web application can access the information. The information can be used to share transient state among different components of the same Web application (e.g., between portlets, or between a portlet and a servlet).

Portlet as a Controller
                           To support the Model-View-Controller pattern, the portlet must be able to include content generated from servlets and JSP pages. This way, the portlet can act as controller, fill a bean with data, and include a JSP page to render the output.
In JSR 168, the include mechanism for servlets and JSP pages is the same for the Servlet API. Via the portlet context, a request dispatcher is retrieved for a given path; the include() method is then called on this request-dispatcher object.

PortletRequestDispatcher rd = getPortletContext().getRequestDispatcher(editJSP);
   rd.include(portletRequest, portletResponse);                

Alignment with WSRP
                     WSRP(Web Services Remote Portlet) aggregates content produced by portlets running on remote machines that use different programming environments, like J2EE and .Net. WSRP services are presentation-oriented, user-facing Web services that plug and play with portals or other applications. They let businesses provide content or applications without requiring any manual content- or application-specific adaptation by consuming portals; portals can easily aggregate WSRP services without programming effort.
                                  The JSR 168 expert group carefully aligned the concepts between JSR 168 and WSRP. The following list overviews how much the major concepts have been aligned between both standards:

• Portlet modes and window states are fully aligned.

• URL encoding and creating URLs pointing to the portlet are fully aligned.

• Both standards have user-to-portlet interaction, with the action and render phases.

• State that allows the current portlet fragment to correctly display in subsequent render calls is supported in WSRP under the term navigational state and in JSR 168, with the render parameters, which can map to WSRP's navigational state.

• Both standards store transient state across requests with a session. The WSRP sessionID references JSR 168's session when mapping WSRP calls to JSR 168 portlets and vice versa.

• Storing persistent state to personalize a portlet's rendering is realized in WSRP through properties of arbitrary types, whereas JSR 168 supports only preferences of type string or string array. This means that WSRP producers based on JSR 168 use only a subset of the WSRP functionality.

• Information about the portal calling the portlet is called RegistrationData in WSRP and is represented as a PortalContext object in JSR 168. All data represented through the PortalContext to a JSR 168 portlet is available in WSRP's RegistrationData, therefore allowing mapping between PortalContext and RegistrationData.

                      As evident from this list, all these concepts map between JSR 168 and WSRP. Thus, you can implement JSR 168 portlet containers that can be accessed via WSRP and expose JSR 168 portlets as WSRP services.

What is Web Service

-Satya Prakash

 The Internet has become something it never has been. We are connected to every other in a way that has never been in human history. This is a web of information, interaction, but at the same time it is a web of possibilities. Possibilities of friends, collaboration, learning and also a possibility of service providing and consuming. Business-to-business (B2B) relations through computer networks have a comparably long history, but a history with a separation of protocols, languages, standards. But The Web is one. With its user and producer-friendliness, HTML became universal, as well as XML that is similar. And a technology of a more connected world is being developed: Web Services.

                                          Simply put, Web Services are service requesting and providing, by sending and receiving messages of some format. The messages are commonly XML formatted. Most desired features of Web Services are interoperability between different systems, perfect security and quality (as it is for business use), easy interpretation and implementation.

BASIC CONCEPTS
Let us look at some basic concepts concerning this technology.

A human friendly format: XML
                                       In Web Services, many message formats are based on Extensible Markup Language (XML) which is a very general purpose markup language that is used in variety of applications. In every XML file, there are entities that are structured as a tree. It is a method of representing information that is both human readable and machine readable. Positive attributes of XML are:

         • Being both human and machine-readable
         • Unicode support, thus supporting nearly every human language
         • The tree structure is very appropriate for computer science abstractions
         • Names and values are openly written, making it a self documenting format
         • The format allows efficient parsing

And its weaknesses:
        • Its redundant, unnecessarily long format is a problem for efficient storage and transmission
        • With the same reason, every XML parser must check a file's format thoroughly to prevent errors
        • In XML there is no data type such as int or float, everything must be expressed through strings
        • The hierarchical model of XML is limited, compared to relational models such as databases. Representing non-hierarchical data in XML is difficult.

 Message format: SOAP
                         Web Services generally use SOAP as a message envelope format. Simple Object Access Protocol (SOAP) is a messaging protocol that is based on XML used usually with HTTP. The original acronym was dropped with version 1.2 as it was misleading, it became only SOAP. SOAP forms the second layer of Web services protocol stack, more abstract layers build on it. These are “service description” protocols such as WSDL, and “service discovery protocols” such as UDDI.
                                      Most widely used messaging pattern of SOAP is Remote Procedure Call (RPC). In fact, SOAP evolved from XML-RPC that was only capable of RPC messaging. SOAP was designed by Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein in 1998. Its specifications are currently maintained by XML Protocol Working Group of W3C. It was intended to be a protocol to allow software applications to interact on the internet or any network.

Let us look at an example SOAP request and response:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetails xmlns="http://warehouse.example.com/ws">
<productID>007</productID>
</getProductDetails>
</soap:Body>
</soap:Envelope>

Above is a SOAP formatted request example. It uses the operation “getProductDetails” to get information about the product with ID 007. This message is independent of the operating system or any inner structure of the server.

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetailsResponse xmlns="http://warehouse.example.com/ws">
<getProductDetailsResult>
<productName>Toptimate 3-Piece Set
</productName>
<productID>007</productID>
<description>3-Piece luggage set.Black Polyester.</description>
<price>96.50</price>
<inStock>true</inStock>
</getProductDetailsResult>
</getProductDetailsResponse>
</soap:Body>
</soap:Envelope>

This is the response of the server. The operation is realized, and product details are returned to the client. SOAP messages are text based and very easy to read. This is also a weakness as a limitation to transfer speed, because the messages are very long and this may affect network performance. Some other technologies such as CORBA use binary format and do not bear this weakness. This is a general problem of XML-based protocols.

Transferring messages: HTTP
                                  SOAP messages are transferred using Hypertext Transfer Protocol (HTTP). HTTP is a method used to transfer or convey information on the World Wide Web. Its original purpose was to provide a way to publish and retrieve HTML pages. It is also used to transfer XML files and XML-based file formats such as SOAP.
HTTP is used between clients and servers as a request/ response protocol. The connecting agent, a client, a web browser, or any other end-user application, is described as the “user agent”. The destination server is called the origin server. Resources such as HTML files and images are stored or created in the server. In between the user agent and origin server may be several intermediaries, such as proxies, gateways, and tunnels.

Service description: WSDL
                                  Web Services Description Language (WSDL) is an XML based language for communicating descriptions of Web Services. WSDL defines services as a collection of “ports” that receive and send “messages”. But these are taken as abstract concepts and separated from their concrete use or instance.
                                                        A “port” is a network address that can be reused through binding. A “port type” is an abstract collection of supported operations. A “service” is a collection of ports. “Message” is defined as abstract definitions of data that is transferred. WSDL describes the public interface for a particular Web Service by using these concepts.
WSDL is generally used with SOAP. If a client program connects to a Web Service, it can get the WSDL to understand what operations are available on the server. Special data types are written in WSDL in XML Schema format. Then SOAP messages are used for calling the functions on the server.

A universal registry: UDDI
                                    There is a standard registry for Web Services. It is Universal Description, Discovery, and Integration (UDDI). UDDI is an XML-based list of businesses. It was written in August 2000, and it is sponsored by OASIS. It is like a platform or market that different businesses find each other's services and interact over the Internet. Every business registers on the following:

              • White Pages that include addresses, contact information
              • Yellow Pages that include sectoral categorizations based on standard classifications
              • Green Pages that include technical information about the services proposed

UDDI is queried by SOAP messages. Clients send SOAP messages to the UDDI to get service descriptions in WSDL. And then, using the protocol bindings and message formats described in WSDL documents, the client can use any service that is offered in UDDI by several businesses.

What is Portal?

- by Rahul Gupta

A portal is a single web interface that provides personalized access to information, applications, business processes and much more. With portal technology, your organization can lower development and deployment costs and significantly increase productivity. You can aggregate and integrate information within a particular working environment, application or service, or use a single interface to target individual users' needs and interests.

Portals help to harmonies content, commerce and collaboration with business goals. This section describes their potential to enable collaborative work, manage large amounts of disparate content and power high-end e-commerce facilities.

In the simplest terms, a portal is a web site that provides content and application functionality in a way that is both useful and meaningful to the end user.

It also serves some purpose from the portal provider's perspective, whether it is a public portal trying to attract web traffic to the site or an enterprise desiring to provide a central location for employees to obtain company information.

Initially, a portal was simply a mechanism to aggregate a related set of content presented as a set of links to the originating site. Over time, portals have evolved to enable the ability not only to provide a unified look and feel to the entire site, but to apply personalization and customization to the content. In this way, a person who accesses a portal and logs in with a pre-defined username and password can customize not only what portal content is displayed for them, but how that content is displayed.

Most portals and portal frameworks contain the concept of a "portlet" as a window to a specific set of content within the overall context of the portal page. Most portlets support the ability to customize the information displayed within this window.

From the perspective of the portal framework, portlets tend to look and behave much the same as individual windows running in any windows-based operating system. They can be minimized, maximized and re-arranged to suit the individual portal user.

From the developer perspective, a portlet is really a piece of code that plugs into a generalized framework. Different portal frameworks implement the concept of a portlet differently. In some cases, the portlet is a collection of JSP pages.

In other cases, it may a special type of class that implements certain interfaces. Regardless of how it is implemented, the portlet is generally responsible for presenting a specific set of content that may be tailored to a user's preferences. The portal framework is responsible for handling the infrastructure services, such as providing the overall presentation, user management, security and personalization.

When a user authenticates or logs into a portal, there typically is a set of characteristics of the portal that are tailored specifically to that user or users within a pre-defined group. At the very least, this would include which portlets are available to the user to display. For example, a regular employee logging into an employee portal may see the stock price of the company, company news, and even department news based on the group they belong to. A manager logging into the portal may see all these things as well as an expense authorization portlet that would list expense reports their employees have submitted that are waiting for approval.

Associated with personalization is the ability to customize the portlets within the portal for a specific user that has logged on. This may mean choosing which portlets to display, how to organize them on the page and even the specifics of the content within the portlet.

One final important concept associated with portals is commonly referred to as "skins". A skin is the idea that the portal can define a standard look and feel for all the portlets and the page the portlets are displayed on. This may include such things as background page color, font color, font type, special logos, etc. In many cases a user can choose a skin from a list offered by the portal provider.

Technical Advantages of Portals

The technical advantage of portals is their capability to help organisations harmonise and rationalise IT operations. The result is greater efficiency in development and deployment, as well as security, management and user acceptance.

Addressing Complexity

Portals are cost-effective from a technical standpoint. They leverage existing technology and simplify development and administration by reducing the number of required systems. However, to reach their full advantage, portals must not be seen as standalone projects. Rather portals should be considered in terms of a broad enterprise-wide endeavour.

Taking an integrated approach to portals means IT departments can reduce the complexity and variance of the technology in use. Where implementation is fragmented, developers may be familiar with one portal technology and not another.

Software code and the overall approach taken in one portal technology may not apply to another. Different databases, disparate content management systems and dissimilar web page rendering technologies can all consume time and resources. Instead of improving efficiency, costs will rise. When an organisation approaches the development of a portal correctly, the project will offer major advantages. In such cases the portal will be part of a framework that is scalable and flexible.

Security

One great advantage of portals is that they enable "single sign-on" capability. In contrast to having many systems, each with its own user ID and password, portals simplify the issues around management and security.

Application Integration

Linking separate systems together is key to developing an environment that fully supports business processes. Exposing information from a range of systems via portals supports this approach. Systems such as HR and accounting need not be directly integrated within a portal implementation but relevant information can be made available on demand through a portal.

Content Aggregation and Search

The proliferation of documents and information resources demands that organisations aggregate content and provide advanced tagging and search capabilities. A portal brings together content from disparate sources, displaying results through a single interface.

The key factors in developing a superior search function are the quality of the taxonomy and categorisation processes and having the capability to find information held in a variety of file formats via keywords and other methods. Any user security conditions in place will also need to be applied to the search process.

Web Content Management

This describes the process and practice of managing information created in a web environment, in contrast to content management systems handling information created via alternative means. Web content management encompasses the entire process of authoring, storing and managing resources created purely in that domain. Creating and managing unique content developed for the web is increasingly seen as an essential organisational capability.

Analytics and Reporting

Online business analysis and reporting functions assist organisations to become more effective. Gigabytes of data can be held within a web environment, recording click through data, user behaviour patterns and more. This data can reveal important trends and developments on a website and introducing online analytics can lead to more intelligent decision making. Many companies fail to use this data adequately.

Multilingual Capabilities

Portals are capable of delivering content in multiple languages, while maintaining design consistency based on templates. Where content is localised you can ensure that it conforms to centralised content controls and appearance.

Rendering Content on Different Devices

Portals enable information to be delivered to multiple devices. This includes different forms of PC, as well as the full range of mobile technologies. PDAs, smart phones and other handheld devices are all capable of receiving information. A portal must accommodate this diverse set of browsing devices without requiring extensive re-programming or maintenance of multiple portal sites.

What is SOA?

-by Sudhamayi

SOA (Service Oriented Architecture) is an architectural style for building software applications that use services available in a network such as the web. It promotes loose coupling between software components so that they can be reused. Applications in SOA are built based on services. A service is an implementation of a well-defined business functionality, and such services can then be consumed by clients in different applications or business processes.


SOA allows for the reuse of existing assets where new services can be created from an existing IT infrastructure of systems. In other words, it enables businesses to leverage existing investments by allowing them to reuse existing applications, and promises interoperability between heterogeneous applications and technologies.

SOA provides a level of flexibility that wasn't possible before.

1. Services are software components with well-defined interfaces that are implementation-independent. An important aspect of SOA is the separation of the service interface (the what) from its implementation (the how). Such services are consumed by clients that are not concerned with how these services will execute their requests.

2. Services are self-contained (perform predetermined tasks) and loosely coupled (for independence)

3. Services can be dynamically discovered.

4. Composite services can be built from aggregates of other services.

The figure depicts a typical Service consumer/producer flow.

Registry: This is something like a common place where are the services will be registered.

Service Consumer: Service consumer could be anything starting from a stand alone application to a Web application, which basically uses the service that is exposed.

Service Provider: Service provider is the one who provides the service that’s been published in the registry to be accessible by all consumers.

Typical work flow: Service provider writes some service and publishes it to the registry. As described, registry is something like a common place where all the services will be registered. Then the consumer searches for a service and if he finds it in the registry and then binds it and uses it by invoking it.

Service could be as simple as a java method or a servlet or an EJB that’s been deployed