Portals are central points of access for applications and content for both internal and external use in an enterprise through interactive and rich presentation interfaces.

Personalized access to information, applications, processes, and people is provided to portals by getting information from local or remote data sources such as databases, transaction systems, content providers, or remote Web sites. This information is then rendered and aggregated into meaningful pages to provide information to users in a compact and easily consumable form. In addition to pure information, many portals also include applications like e-mail, calendars, organizers, banking, bill presentation, host integration, and many more.

Different layout, profile, content, and access criteria are the cornerstones for the display and selection options that shape the information that can be accessed through a portal. Today portals are made up of building blocks - portlets - that plug into a portal's base infrastructure and enable the aggregation of interactive rendering markup. A personalized Web page in a portal can be made up of numerous portlets that provide specific functionality and expose various external services and content.

The lack of standards has led portal server platform vendors to define proprietary APIs for local portal components and for invocation of remote components that create interoperability problems for portal customers, application vendors, content providers, and portal software vendors. The Java Portlet API and Web Services for Remote Portals (WSRP) standards are being developed to overcome these problems, providing interoperability between portlets and portals, and between portals and user-facing Web services.

Let's consider that a Road Warrior Portal manager for a sales organization wants to include a Travel Expense service to calculate travel expenses, and an external Map service to provide useful location-based information.

To add more functionality and services to a portal, you need to add more portlets to render and display the new features, leading to increased cost and time investment. It would be much more convenient if the Travel Expense Authorization and Map Web services included both business and presentation logic.

WSRP are interactive Web services that can be called through an interface built into the portal itself - a proxy. This eliminates both the need for code on the portal as well as the redeployment of presentation details each time (see Figure 1).

 

Web services can enable the seamless and hassle-free integration of various applications and content into the portal software through cost-effective integration and adherence to open standards. Web services are software applications and functionality that can be delivered over the Web. Portlets, the individual components delivered by portals, can be treated as Web services.

How do we ensure that Web services can deliver custom marked up content to various devices through a portal, and secondly, how do we control access to Web services and other portal content. The two technologies available for handling these complexities are the Open Solution and J2EE.

Delivering Custom Content
When you compare Web services and portal technology you see that they have a lot in common. At the heart of Web services is an obvious dependence on HTTP and XML, which are also the building blocks of Web technology, and hence portal infrastructures.

At this point you should understand the difference between the processing capabilities of mobile devices and Web services clients. Mobile clients can typically receive and consume some form of markup that the device is built to handle, over HTTP or a wireless protocol. Web services clients, on the other hand, have to do some heavy lifting in the sense that they have to process XML messages.

Being ubiquitous - or the adherence to the anytime, anywhere, and anyhow paradigm - is the real driver for enterprises to embrace mobile computing. Mobile clients are highly suited to consuming services and content provided by enterprise portals and other intranet applications. Tailoring content based on a device's capabilities is known as transcoding. Two approaches can be followed for handling the presentation for mobile devices, based on device capabilities and the network service available.

Design-time, or static, transcoding has different versions of the same content developed and placed in the file system of the Web server. The main problem is in selecting the right version of the content for a particular user with a particular device. The disadvantage of this approach is that a number of disparate pages and applications have to be developed and maintained; with an increase in the number of devices to be supported, this becomes a daunting task.

Runtime, or dynamic, transcoding enables the clear separation of the creation of content from the creation of different presentations (see Figure 2). Here, content is massaged based on the presentation requirements for a particular user on a particular device and on a particular type of network service. Dynamic transcoding uses style sheets to convert XML documents into desired presentation relevant to a particular device or translation from HTML into various markup languages.

 

These approaches can be combined to meet the requirements of particular applications. Portals are the centralized entry point into a system from which a user initiates a Web browsing experience, and can be seen as a delivery mechanism for content transcoded for specific devices.

Controlling Access
Portal technology involves both authentication and authorization as security mechanisms for ensuring the credibility of users and the user's privileges. Single Sign-On (SSO) is one way of enabling this. Once the user's credentials are validated and the application access profile is checked, no further authorization restrictions are placed on the user. This system ensures dependability and ease of maintenance, while providing a high level of convenience for a user who wants to access multiple applications.

Portals can use Web services to integrate disparate applications and systems, each replete with specific authentication mechanisms. An obvious application of SSO to Web services for portals could lie in the management of authentication credentials into one scheme.

Security Access Markup Language (SAML) enables the encoding of authentication and authorization information in XML format. Under this standard, a Web service interface can request and receive SAML Assertions from a SAML-compliant authority to authenticate and authorize a service requestor. SAML can then pass credentials off to multiple systems and to SSO solutions for controlling access to Web services and portal content.

The Open Solution: OASIS WSRP and OASIS Provisioning
The OASIS WSRP Technical Committee (www.oasis-open.org/committees/wsrp) addresses the use of Web services as pluggable components for portals. These services will enable businesses to provide content or applications to portals without massaging the same for specific form and presentation requirements, thus providing a cost-effective and efficient way to integrate and deploy Web and portal systems.

A portal can find and bind remote portlet Web services using a portlet proxy just as it would through any portlet. This proxy works on the standard Web services request-and-response mechanism where a SOAP request can be built, forwarded to the WSRP service, and the response then delivered to the portal. The WSRP service can then be easily published for discovery and consumption for administrative portal users through dynamic integration. Through this initiative, remote portlet Web services can be implemented for both Java and .NET technologies. WSRP will use standards such as SOAP, UDDI, and WSDL.

The OASIS Provisioning Services Technical Committee (PSTC) ( www.oasis-open.org/committees/provision) defines an XML-based framework for exchanging information between provisioning service points - Service Provisioning Markup Language (SPML). The technical committee is developing an open specification detailing the semantics for provisioning service points to exchange requests relating to the managed provisioning service targets. SPML requests will facilitate the creation, modification, activation, suspension, enablement, and deletion of data on managed provisioning service targets. This specification is expected to facilitate SPML exchanges such as provisioning requests between provisioning service points within one or more organizations provisioning requests between provisioning service points hosted by third-party providers, aggregators, and ASPs; and provisioning requests between provisioning service points with support for chained or forwarded requests.

The J2EE Solution: Java Community Process JSR 124
Client provisioning is an end-to-end paradigm by which client applications, Web services, and content that is stocked or aggregated can be administered - or vended - to a variety of client devices. There are many such devices available, varying in memory footprint, size, functionality, and features. Whether these devices are built on J2ME, J2SE, or even non-Java platforms, a number of challenges are presented in their administrative tasks. Management, upgrade, and usage tracking of such devices are replete with technical challenges which the client provisioning paradigm seems to address by providing an infrastructure to mediate and manage the client applications, Web services, and content delivered.

Sun Microsystems' Java Community Process (JCP) features the JSR 124 J2EE Client Provisioning Specification ( http://jcp.org/en/jsr/detail?id=124). Based on this, client provisioning can be defined as activities of advertising client services to a client device, and to the process of delivering the service to the device.

The main components of a client provisioning infrastructure are comprised of a Provisioning Portal and APIs that enable delivery of client applications; Web services and content based on various policies using J2EE components; a Provisioning ARchive (PAR), which is a standardized file format for handling the packaging of applications, Web services, and content and their delivery to the portal; and a Service Provider Interface (SPI) that is extensible and enables the provisioning of new types of Java and non-Java devices by the provisioning server. The SPI consists of a provisioning adapter - software that hides the system details for provisioning a particular type of device and enables the secure discovery and delivery of client applications.

Applying the Client Provisioning Paradigm
Consider a traditional vending machine from which users can select from a display of available items and have their selections delivered. A vending machine is an infrastructure that is accessible to multiple device types, provides services to multiple device types, delivers content tailored to a device, must be extendable across enterprises, eases development for extending services, and enables a scalable and open architecture. The services of such an infrastructure may include presentation, personalization, content management, enterprise application integration, and page transformation.

Derived from the client provisioning paradigm, the vending machine consists of a service developer interface, a service consumer interface, and a service vendor interface (see Figure 3). Through authentication, enrollment, metering, billing, and managing operations that control the behavior during use, applications, Web services and content may be vended.

 

A synopsis of the end-to-end client request, discovery, stocking, delivery, and administration, comprehensively termed as vending of a Web service in the context of the vending machine paradigm, may be broken into three steps: development and deployment, enrollment and subscription and usage (see Figure 4).

 

Conclusion
In our previous article ("Extending Web Services to the Real World - Using SOAP to Access a Mobile Device," WSJ, Vol. 3, issue 3), you saw how a Web service is accessed from a SOAP client running on a J2ME mobile device. In this article we looked at accessing a Web service through a centralized portal, using the Client Provisioning paradigm to manage access based on a user and device profile, and usage based on billing and metering. We also looked at how specific client presentation requirements can be transparently dealt with using transcoding techniques, thus enabling the use of any device to access back-end functionality. By applying the client provisioning paradigm and the Java Vending Machine analogy to a device-independent portal based software solution, we can demonstrate ubiquity, or the discovery and delivery of applications, Web services, and content - anytime, anywhere and anyhow.