The Web Services Advisor
(To receive this column in your inbox,
click Edit your Profile and subscribe.).
Continued from Part One
Web services-based portals are a new wave information resource that can give employees and managers powerful tools for gathering information, making decisions and getting their work done most effectively. These new portals may well be the wave of the future in the enterprise.
In my previous column, I looked at what Web services-based portals are, what benefits they offer and whether they really are the wave of the future. In this second part, we'll look at the standards and technologies that make the portals possible.
A look at Web services-powered portals
Before we can examine the technology, we need a brief look at what a portal is. Portals are Web pages or sites that serve as front-ends to enterprise data and applications and offer access to a wide variety of enterprise resources. So a product manager, for example, would be able to sign into a portal that could give him access to applications and data that he otherwise would have to spend many hours finding and signing into -- one application showing current sales, another showing projected sales, another showing the current status of the manufacturing process, yet another showing him his staff's vacation schedules and so on. Some companies also offer external portals to customers and business partners over the Internet, not just on a company Intranet.
Portals have been around for some time, but Web services can supercharge them. They can make it easier to connect to applications and data with little programming required and can offer other benefits such as offering a single sign on -- sign into the portal and then never have to sign into each individual application.
The standards that make it all work
Two related relatively new standards make all this possible. One handles building "portlets" and "portlet containers" and the other handles building portals. A portlet is a Java-based Web component that takes requests from a user and then generates dynamic content based on that request -- in essence, the front end to data and applications. It's a pluggable user interface to specific data or applications. So, in our example, one portlet would provide the product manager with information about the status of the manufacturing process, another portlet would show him his staff's vacation schedules, and so on. Portlet containers are components that hold the portlets and control access into and out of them. The portal itself is made up of an interface and many individual portlets, which can be easily changed and swapped in and out of the portal. Portals can be customized as well, so that a product manager's portal can have one set of portlets on it and a CEO's portal could have a different set of portlets.
Let's take a look at how the three components work together on a typical Web-based portal to deliver information or applications:
1. A user logs into a portal, is authenticated and makes a request for information from the portal, via HTTP over the Web.
2. The portal receives the request and checks whether the request can be handled by any of the portlets on the portal.
3. When the portal finds which portlets can handle the request, it asks the portlet container to invoke the portlets to process the request.
4. The portlets process the request through the portlet container and send along content fragments that can be used on the portal page.
5. The portal aggregates the content fragment outputs of the portlets, creates a new page out of them and sends the portal page, complete with the data or application, back to the person doing the requesting.
The standard that covers portlets, called JSR 168, was developed by the Java Community Process (JCP); the current 1.0 spec was approved only recently, in October of 2003. (To see the full spec itself, go here: http://jcp.org/aboutJava/communityprocess/final/jsr168/index.html.) The specification, in its own words, defines "a portlet API that provides means for aggregating several content sources and applications front ends. It will also address how the security and personalization is handled." It handles not just portlets, but portlet containers as well.
The standard that covers portals, Web Services for Remote Portlets (WSRP), is also a relatively new standard, having been approved by OASIS in August of 2003 and is in version 1.0. (To see the full spec itself, go here: http://www.oasis-open.org/committees/download.php/3343/oasis-200304-wsrp-specification-1.0.pdf.) Its purpose is to create a standard that allows for the dynamic integration of business applications and content into a plug-and-play portal solution. It's been designed to work with JSR 168. While the spec itself is necessarily complicated, the idea behind it is simple. A portal should be able to be created quickly and easily using Web services standards. That way, when a company creates a Web service for some specific purpose, for example to make it easy to access a legacy application, that Web service will be able to be easily reused in a portal. So entirely new programming would not have to be done; the service could be easily reused.
For more information about Web services-based portals, go to POST, the Portlet Open Source Trading Site at http://sourceforge.net/projects/portlet-opensrc. It's an open source site that not only includes information about Web services portals, but also includes open source code and downloads.
What the future holds
Both standards are relatively new and Web services portals are being talked about at this point rather than being used to any great degree. To a great extent, though, whether they become widely used will be largely dependent on whether vendors integrate WSRP into their products, says Neil Macehiter, Research Director for Ovum.
"For (Web services portals) to really take off, it requires the widespread use of WSRP and that depends on how many vendors will provide an WSRP interface in their products," he says.
But if it does happen, expect a new generation of portals to help corporations and their business partners and for Web services to become even more embedded in the daily life of enterprises.
For related Articles and Commentary:
- Portals and Web services: Services at the user interface
- Web services integration may hinge on portals
About the Author
Preston Gralla, a well-known technology expert, is the author of more than 20 books, including "How the Internet Works," which has been translated into 14 languages and sold several hundred thousand copies worldwide. He is an expert on Web services and the author of a major research and white paper for the Software and Information Industry Association on the topic. Gralla was the founding managing editor of PC Week, a founding editor and then editor and editorial director of PC/Computing, and an executive editor for ZDNet and CNet. He has written about technology for more than 15 years for many major magazines and newspapers, including PC Magazine, Computerworld, CIO Magazine, eWeek and its forerunner PC Week, PC/Computing, the Los Angeles Times, USA Today, and the Dallas Morning News among others. As a well-known technology guru, he appears frequently on TV and radio shows and networks, including CNN, MSNBC, ABC World News Now, the CBS Early Show, PBS's All Things Considered and others. He has won a number of awards for his writing, including from the Computer Press Association for the Best Feature in a Computer Publication. He can be reached at firstname.lastname@example.org.