Home > SOA Tips > The Web Services Advisor > Web services based portals: The wave of the future? Part two
SOA Tips:
EMAIL THIS
 TIPS & NEWSLETTERS TOPICS 

THE WEB SERVICES ADVISOR

Web services based portals: The wave of the future? Part two


Preston Gralla
12.23.2003
Rating: -4.75- (out of 5)


Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us   



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:


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 preston@gralla.com.

Rate this Tip
To rate tips, you must be a member of SearchSOA.com.
Register now to start rating these tips. Log in if you are already a member.




Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us   



RELATED CONTENT
The Web Services Advisor
Where does BPEL fit in?
Some notes on ESB configuration
Open source application development frameworks offer alternatives
What to expect with the new JavaScript standardization (ECMAScript 5)
Restlet framework wrestles RESTful Web applications
3 tips for choosing whether to use EGL
Use SoaML to facilitate Model Driven Architecture
Enterprise mashup patterns act as API enablers
XQuery learns to write using XUF
Descriptive Languages for RESTful Services

RELATED RESOURCES
2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems
Search Bitpipe.com for the latest white papers and business webcasts
Whatis.com, the online computer dictionary

DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.



SOA Trends and Strategy - SOA Education, SOA Development, SOA Implementations
About Us  |  Contact Us  |  For Advertisers  |  For Business Partners  |  Site Index  |  RSS
SEARCH 
TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations' technology projects - with its network of technology-specific websites, events and online magazines.

TechTarget Corporate Web Site  |  Media Kits  |  Site Map




All Rights Reserved, Copyright 2001 - 2010, TechTarget | Read our Privacy Policy
  TechTarget - The IT Media ROI Experts