Portals

A portal is a user-facing aggregation point where multiple, potentially unrelated functionalities and services are housed. More generally, a portal can be thought of as a gateway to a variety of resources. Usually, the user is able to manage these resources by simply adding or removing them. This allows users to customize the portal to fit their needs and interests.

A variety of portal types exist, including consumer portals, corporate employee portals, and business partner portals. They all have the same purpose: to provide a single point-of-entry or gateway to a variety of resources that are important and relevant to their users.

Some well-known portals are yahoo.com, msn.com, and amazon.com. Both yahoo.com and msn.com provide a point of aggregation for mass-market services such as electronic mail, stock prices and news. Instead of having to go to one site to retrieve electronic mail, another site to view the performance of their stock portfolio, and yet another site to read the latest news headlines, users of these portals can simply visit one site to access and use all these services.

Topical or timely resources are also usually made available and highlighted through portals. For instance, when loan interest rates are low and people are thinking about refinancing their home mortgages, having a mortgage refinance calculator available at the same place where users read news about dropping interest rates makes sense.

Figure 11-1 depicts a portal that has been configured to aggregate a stock price tracker, a news headline service, and a home mortgage refinance calculator.

Figure 11-1. A portal is a user-facing aggregation point where multiple, potentially unrelated resources are housed.

Portals provide a single location that users can turn to when they are looking for information and services. Instead of spending a lot of time searching through multiple locations, portals aggregate the relevant information at a single, easy-to-remember location.

A type of portal commonly found within enterprises is the corporate employee portal. An employee portal aggregates and makes available resources and services that are relevant to employees of a corporation. For example an employee portal may bring together the following information and services: payroll, expense report management, employment agreements and other legal documents, timesheets, 401(k) and other retirement plan information, health and medical plan information, as well as contact information for other employees.

Portals aggregate a lot of information. Not all of the information will be relevant or useful to everybody who uses the portal. Accordingly, portals allow users to configure or personalize the portal to show information and services that are only relevant to them. For example, an employee who does not or cannot participate in retirement plans may not want to clutter her portal with a lot of information and services related to 401(k)s and retirement plans. Of course, in the future, if the employee wants to participate in retirement plans, she can simply configure the portal to again display information and offer services related to the latest retirement plans offered by her company.

Now that we have seen the value and usefulness of portals and their utility as a user-configurable aggregation point, in the next section we look at different means by which to develop portals using Web services.

Programmatic and Interactive Web Service Interfaces

The promise of Web services is to simplify the development of applications by supporting the rapid composition of various software components. Individual service components provide functionalities that are composed together to implement an overall value-added capability. The composition of these service components requires custom programming that ties together the individual functionalities and perhaps includes additional business logic. This custom programming together with the consumed Web services represents the overall business logic of the application. The application user interface allows users to interact with the application's overall business logic. This is depicted in Figure 11-2.

Figure 11-2. Constructing an application by integrating together Web services.

Web services provide a data-centric, programmatic interface that allows general integration with other Web services and with application business logic. These programmatic interfaces consist of individual operations that can be invoked by a client application. To use such Web services to build a portlet a single service within the larger portal context requires developers who have expertise in that domain to first fully understand the interface of each Web service, invoke the correct service operations in the correct sequence, and finally design an appropriate user interface.

This is an expensive and time-consuming process for building each portlet. This is especially so since each portal will usually have tens of portlets and each portlet will often be used by a large number of portals. Consider the following two use cases:

• Corporate employee portals provide a single online location for employees to learn about and access the various services their company makes available to them. Some common examples of such services are expense report filing and management, as well as retirement plans such as 401(k)s. Many of these services are outsourced to third-party companies. Nonetheless, access to these services must be available through the employee corporate portal.

  If the individual services are exposed by third-party providers as Web services, they must be integrated together with custom business logic and user interface development into the corporate portal. This integration requires domain expertise and knowledge of the provider's Web service APIs. The initial customer development and, more importantly, the continuous maintenance reduce much of the cost savings and advantages of outsourcing the service to a third-party provider.

  Alternately, an ideal scenario would be one in which the IT department in charge of the corporate employee portal would simply be able to "plug in" the entire expense report filing and management capabilities including the user interface directly into the portal. The third-party service provider would handle improvements and changes to the individual Web services, integration logic, and user interface directly.

• Manufactured components retail portals provide a single online location where complex machinery and components from a large number of manufacturers can be purchased. Customers of the portal may need to consult component specifications and interact with component advisory tools before they are able to select the right parts for their needs. Unfortunately, most retail portals are unable to provide such manufacturer-specific tools and applications, and the portal's customers are forced to jump from the portal site to the Web sites of the individual manufacturers where the tools and applications are available.

  The customer's user experience and satisfaction would be greatly enhanced if all of the information, tools, and applications were available together with the retail portal's ordering and shipment handling capabilities. The customer would be able to access all required information as well as complete the purchase process easily all from a single site.

  Again, an ideal scenario would be one in which the retail portal would simply be able to "plug in" each manufacturers' tools and applications as portlets within the retail portal site. Each manufacturing company, which already has the deep domain expertise necessary to build and maintain not only the business logic but also the required user interface for each such tool, would have full control over each application with the portal being the channel into consumers. All development as well as improvements and changes to the individual Web services, integration logic, and user interface would be handled directly by each manufacturing company.

In these and other similar use cases, the difficulty in implementing a portal is that the end-user application provider is not in a position to understand the intricacies of the business or products of each of its back-end providers. For example, retail portal companies are only in the business of selling. They do not have the time nor the resources to understand the manufacturing process underlying each end product they sell.

When Web services are used to expose the information and services of the back-end provider to be integrated into the front-end portal, the challenges increase further. The data-centric interface of a Web service makes this integration difficult because:

• Front-end application developers must understand the necessary user interface and interactive flow of the back-end provider's application, requiring a significant learning curve and time.

• This interactive flow must be mapped to the individual methods of the Web service interface, necessitating an in-depth understanding of the API.

• As the back-end provider changes or updates its Web service APIs, the front-end application will also require modification and maintenance.

• It is difficult to ensure that the developed front-end application sufficiently uses the capabilities of the Web services and addresses the needs of users.

These issues could be addressed if the specific capabilities of each of the back-end providers could be made available to the front-end application by simply "plugging in" without the need for domain expertise or expensive custom development.

Figure 11-3 graphically compares the architectural differences between building custom portlets based on underlying Web services (as shown in Figure 11-3(a) with simply plugging in back-end Web services as portlets directly into a portal. In the latter case, a third-party (the provider of the Web service) develops the entire application, which is made available through a variety of portals and is directly accessible and useable by each portal's users without any custom development by the portal providers. Each of these applications is developed, managed, and maintained by the respective companies, not the portal provider.

Figure 11-3. Assembling a portal from individual Web services from (a) using the data-centric interfaces and (b) using interactive interfaces.

In order to make entire applications, including the user interface and the interactive flow, available as Web services that portals can directly plug in requires a higher-level interface than existing data-centric programmatic Web service interfaces. As shown in Figure 11-4, such an interface will expose not only business logic and database layers, but also the user interface and interactivity layer. These interactive Web service interfaces allow direct and simple integration of individual applications known as portlets with the larger portal context through the user interface aggregation layer. By using interactive instead of programmatic interfaces, developers can package their applications as portlets and make them available to portals via industry standard Web services technologies.

Figure 11-4. A client application consuming Web services using (a) data-centric programmatic and (b) interactive interfaces.

With interactive Web service interfaces, portal developers and administrators can simply "plug in" individual Web services without custom programming and development. As the back-end Web services change and are modified over time, there is no maintenance to be done by the portal developer; all changes by the Web services provider are automatically made available to the portal users. Similarly, users can manage and personalize their portal by simply plugging in and unplugging the individual interactive Web service portlets.

Now that we have seen the utility of user interaction-centric interactive interfaces to Web services in addition to data-centric programmatic interfaces, we next look at technologies and system specifications to build and consume such interactive Web services.

The WSRP and WSIA Specifications

Web Services for Interactive Applications (WSIA) and Web Services for Remote Portlets (WSRP) are specifications for user interaction-centric interactive Web services based on existing, industry standard Web services technologies.

These technologies specify a means for communication between a client application and a Web service using SOAP in which the response to a Web service invocation is a fragment of presentation code (e.g., HTML) that can be embedded within a larger set of pages, such as a portal. Moreover, links within the original presentation fragment support user actions that communicate with the Web service and returns another presentation fragment, thus enabling multi-page user interactivity.

The WSIA and WSRP specifications evolved out of multiple efforts by different vendors to provide presentation-level interfaces to Web services. Earlier initiatives such as Web Service Expression Language (WSXL) and Web Service User Interface (WSUI) as well as a number of portal integration frameworks were brought together to form the two working groups of WSIA and WSRP within the OASIS standards organization. The WSIA working group was charged with the task of specifying the means to develop and expose presentation-level interfaces to Web services, while WSRP was changed to focus on additional required capabilities specific to portals. More information about the WSIA and WSRP standards can be found at www.oasis-open.org.

In the remaining subsections, we review the WSRP specification, and the issues around building portlets and portals with WSRP.

Building Portlets and Portals with WSRP

Before we continue with the WSRP specification, it is important to define and understand the three actors involved in a flow. The WSRP standard specifies three actors involved in a flow:

• Producers are Web services that are made available as WSRP services. An example of a producer is a weather Web service that provides real-time weather information.

• Consumers use WSRP services, usually within a larger context such as a portal. An example of a consumer is a portal toolkit or framework that aggregates and manages multiple WSRP services.

• End users are actual people who use and interact with a portal that uses WSRP services.

Based on these actor definitions, WSRP specifies the calls that enable a consumer to retrieve presentation code fragments from a Producer. The specification also defines what a valid presentation code fragment is, and how these fragments can be integrated within a larger presentation context.

The WSRP protocol is segmented into four different interfaces:

• Service Description interface is implemented by the producer and includes a single, simple operation that allows the consumer to retrieve a description of the Producer.

• Markup interface is implemented by the producer and includes operations for embedding producer markup within the consumer.

• Portlet Entity Management interface includes operations that allow the consumer to customize portlet entities by setting and configuring properties.

• Registration interface includes operations that allow the consumer to register itself with the Producer.

In the remainder of this subsection, we look at the major operations of each of these four interfaces. All of the operations supported by each interface together with their signatures can be found in the WSRP specification at www.oasis-open.org.

The Service Description interface has a single operation:

• getServiceDescription returns a description as well as metadata for the Producer portlet. The information returned from this operation includes such things as the type of presentation markup, and is used by the consumer to properly manage interactions between the end user and the producer.

The key operations of the Markup interface are:

• getMarkup: The consumer invokes the getMarkup operation to retrieve the current presentation markup.

• performInteraction: The consumer invokes this operation in response to the end user interacting with the producer's markup. End user interactions can include the end user clicking on a hyperlink or submitting a form.

  End user interaction with the producer markup must pass through the consumer, and hyperlinks URLs and form URLs are referred to as Interaction URLs. Additional information and parameters are passed using these Interaction URLs and allow the consumer to know the call type as well as the parameters to use in the subsequent call to the producer.

The key operations of the Portlet Entity Management interface are:

• getPortletEntityPropertyDescription: The consumer invokes this operation to retrieve a listing of the properties available for a portlet entity.

• getPortletEntityDescription: The consumer invokes this operation to retrieve the description of a portlet entity.

• setPortletEntityProperties: The consumer invokes this operation to set the values of entity properties.

• getPortletEntityProperties: The consumer invokes this operation to retrieve the values of entity properties.

• clonePortletEntity: The consumer invokes this operation to create a new configured portlet entity.

• destroyPortletEntities: The consumer invokes this operation to destroy a created configured portlet entity.

The key operations of the Registration Management interface are:

• register: The consumer invokes this operation to register itself with the producer. As part of the registration process, the consumer passes information about itself to the producer.

• deregister: The consumer invokes this operation to deregister and end its relationship with the Producer.

• modifyRegistration: The consumer invokes this operation to notify the Producer of any changes to the consumer.

Figure 11-5 depicts the steady-state interaction between the three actors: WSRP end users, consumers, and producers. In response to the end user wanting to view a portlet, the consumer invokes the getMarkup operation of the producer. The producer generates the appropriate markup fragment and returns it to the consumer. If the end user selects a hyperlink or submits form data, the consumer captures the information and forwards it to the producer by invoking the performInteraction operation. The producer returns the updated state to the consumer. The consumer again invokes the getMarkup operation of the producer together with the updated state to retrieve the current markup fragment for the portlet.

Figure 11-5. Interaction between the three actors : WSRP end users, consumers, and producers.

Now that we have a good idea about the interaction between the end user, consumer, and producer actors within a WSRP environment, we next discuss some of the restrictions that are placed on these interactions so that producer markup fragments can be appropriately embedded and used within the larger portal context.

Restrictions

The presentation code fragments returned by a WSRP service have restrictions that allow a WSRP service Consumer to aggregate the code fragments together into the larger context of the portal.

Fundamentally, the markup fragments generated by each WSRP and returned must be aggregated together into a single markup page, which is then returned to the end user. This disallows the use of all markup language features and instead requires that the markup fragment returned is only a subset of the overall markup language.

For example, in the case of HTML, tags such as <body>, <frame>, <frameset>, <head>, <html>, and <title> are not allowed to be returned by a WSRP service. It is also usually advisable that presentation style information such as the font or color of text is not hard coded into the returned markup. This allows the portal to specify these tags and create a consistent "look and feel" for all of the consumed portlets across the entire portal page.

An additional restriction placed on the markup fragments returned by WSRP services has to do with embedded hyperlinks. Hyperlinks allow interactivity between the End-user and the WSRP Producer. However, since the end-user is interacting with the Producer via the Consumer, hyperlink URLs must be addressed to and resolved by the Consumer and not by the Producer directly.

URL rewriting techniques can be used to modify the link to be returned by the WSRP Producer by a link tag that routes the HTTP GET or HTTP POST requests to the WSRP Consumer. The prefix of the link URL routes the action to the Consumer. The suffix of the URL contains additional information, including the WSRP service, the action, and additional parameters, which can then be used by the WSRP Consumer to access the service and update the entire portal page.

These URL links can be generated in one of two ways. A WSRP Consumer can send a URL template to the WSRP Producer when it invokes the getMarkup method. In this case, the Producer returns all final interaction URLs within the markup fragment. Otherwise, the Producer can return interaction URLs that conform to a certain pattern. These URL patterns can then be parsed by the Consumer, and rewritten so that user actions are routed through the Consumer application. The first method of the Producer returning the final interaction URLs is known as Producer URL Writing, while the second method of the Consumer rewriting the URLs returned by the Producer is known as Consumer URL Writing.

Deploying and Locating Services

To use WSRP services within portals, information about the services must first be made known to potential Consumers. Typically, this will be accomplished by publishing information about the service in registries such as UDDI.

All WSRP services implement the same WSDL interface, which ensures that any WSRP service can be consumed and used by any WSRP-compliant portal. Additional information is also provided to portal administrators and end-users to easily select and use WSRP services. This information includes service name, description, and supported markup languages.

Locating WSRP services within registries such as UDDI is simply a matter of querying the registry for all services that implement the WSRP WSDL tModel. Subsetting based on particular business names or desired attributes and properties can further narrow the search. Creating, managing, and destroying instances of WSRP services will usually be handled by the Consumer platform, such as a portal toolkit. In the remainder of this section, we briefly review the key interactions supported between WSRP services and WSRP compliant portals.

Putting It All Together

In this subsection, we take a closer look at the interaction between the Consumer and the Producer as well as between the Consumer and the End-user by analyzing the exchanged messages. In this example, the Producer is a simple service that generates two HTML pages that are hyperlinked to each other.

First, the Consumer invokes the getServiceDescription operation of the Producer to understand its capabilities. Figure 11-6 shows the response returned by the Producer as a result of this invocation.

Figure 11-6. The response from the invocation of the getServiceDescription operation.

 <getServiceDescriptionResponse   xmlns="http://www.oasis-          open.org/committees/wsrp/v1/wsdl/types">   <offeredEntities>     <entityHandle>       thisHandle     </entityHandle>     <markupTypes>       <markupType>text/html</markupType>       <locales>en</locales>       <modes>view</modes>       <windowStates>normal</windowStates>     </markupTypes>     <doesUrlTemplateProcessing>       false     </doesUrlTemplateProcessing>   </offeredEntities> </getServiceDescriptionResponse> 

The response message gives the Consumer a lot of information about the Producer portlet. The view value of the modes tag specifies that the markup returned will be pages that the End-user can interact with or it may simple be interaction-free content. Other possible values include edit, which specifies that the returned markup will allow the End-user to enter customization data, help. This specifies that the returned markup will provide the End-user with context-sensitive help information to explain the usage of the portlet, and preview, which specifies that the returned markup will be a sample of how the markup that would be returned under the view mode will appear within the current configuration.

The false value of the doesUrlTemplateProcessing tag specifies that the Producer does not perform URL writing, and instead relies on the Consumer to specify the correct interaction URL. That is, this Producer Web service relies on Consumer URL Writing and does not perform Producer URL Writing.

Figure 11-7 depicts the response message from the Producer after the Consumer invokes the getMarkup operation of the Producer.

Figure 11-7. The response to the invocation of the getMarkup operation with navigationalState set to "one".

 <getMarkupResponse     xmlns="http://www.oasis-open.org/committees/wsrp/v1/            wsdl/types"   <markupContext>     <markup>       <![CDATA[         <div class=portlet-font>           <p>Hello World! This Is Page One.<p>           <a href="wsrp-rewrite?                    wsrp-urlType=render&                    wsrp-navigationalState=two&                    wsrp-mode=view&                    wsrp-windowState=normal/wsrp-rewrite">           Click Here To Go To Page Two</a>         </div>       ]]>     </markup>     <locale>en</locale>     <markupType>text/html</markupType>     <requiresUrlRewriting>true</requiresUrlRewriting>   </markupContext> </getMarkupResponse> 

The response message is an XML message that contains the HTML fragment to be displayed as part of this portlet. First, note the Cascading Style Sheet (CSS) class name portlet-font that conforms the font of the portlet to be that used throughout the overall portal.

Based on the response message of Figure 11-7, the content that is displayed within the portlet is shown in Figure 11-8.

Figure 11-8. The content displayed within the portlet.

 Hello World! This Is Page One. Click Here To Go To Page Two 

The value of the href attribute for the Click Here To Go To Page Two link specifies how the state of the portlet should be updated when the user clicks on the link. The current state as represented by wsrpnavigationalState is one. After the user clicks on the link, the wsrpnavigationalState is set to two. The states one and two are used internally by the Producer to represent the two possible portlet content segments. The wsrp-urlType=render results in the Consumer invoking the getMarkup() operation of the Producer.

Since the value of the requiresUrlRewriting tag is true, the string that is the value of the href attribute must be converted to an actual URL before it is sent to the End-user. In order for the Consumer to generate the appropriate URL, it first locates the delimiters: wsrp-rewrite? and /wsrp-rewrite within the existing href attribute value. The string contained within these delimiters is:

 wsrp-urlType=render& wsrp-navigationalState=two& wsrp-mode=view& wsrp-windowState=normal 

Each of these name-value pairs are converted to an actual URL as follows:

 http://consumer.example.org/portletContainerPath/render?mode=view&navigationalState=two&windowState=normal 

Finally, the markup fragment that is embedded within the overall portal is shown in Figure 11-9.

Multiple such markup fragments, each fragment representing the interactive user interface of a WSRP service, comprise a WSRP portal.

Figure 11-9. The HTML markup fragment that is embedded within the overall portal after the Consumer processes the markup and performs URL rewriting.

 <div class=portlet-font>   <p>Hello World! This Is Page One.<p>   <a href="http://consumer.example.org/            portletContainerPath/render?mode=view&            navigationalState=two&windowState=normal">         Click Here To Go To Page Two</a> </div> 

Summary

In this section, we looked at technologies that facilitate the development and maintenance of Web services-based portals. A portal is a user-facing aggregation point where multiple, potentially unrelated functionalities and services are housed. Usually, portals are used as a gateway to consumer type of services, such as news, electronic mail, and stock prices, or to corporate employee services, such retirement planning and account information, time cards and payroll, as well as employment agreements and other legal documents.

Many of these portal services are outsourced to or licensed from third-party providers. Since the portal developer will usually be aggregating a large variety of services, he will probably not have deep expertise in all of the domains represented by those services. Accordingly, a data-centric programmatic interface that requires domain expertise to aggregate and use each of the underlying Web services is impractical.

Instead, the WSRP specification defines a higher-level user-interface-based interactive interface to Web services. Rather than invoking fine-grained individual, service-specific operations of each Web service, the consumer makes generic, coarse-grained invocations such as getMarkup(), which returns the entire markup fragment for that portlet within the overall portal. By using WSRP-compliant Web services, a portal developer can simply embed the markup fragments returned from each WSRP portlet within the larger portal context. This can be done without having past experience with the domain of the Web service or in-depth knowledge of the specific Web service.

In the next section, we switch gears and look at how the growing development and usage of Web services is requiring an architectural layer to facilitate the management and control of these individual resources.