Enterprise portals have been called the doors to Web services because some believe they serve as the most painless way to begin working with Web services. SearchWebServices.com asked IBM Corp.'s Thomas Schaeck, chief architect of IBM's WebSphere Portal Server and chairman of the OASIS Web Services for Remote Portlets (WSRP) technical committee, how Web services can be integrated with portals and which standards efforts will impact portal-based Web services.
Schaeck: There's WSRP, and that is somewhat related to JSR 168 [a Java specification for portals and portlets under...
review by the Java Community Process]. WSRP is focused on Web services, and JSR 168 defines a set of APIs for portlets running locally. WSRP-based Web services can be integrated into JSR 168 portals, so it's possible to integrate both ways.
OASIS' last face-to-face TC [technical committee] meeting on WSRP was in January. We agreed on all the technical items. The current plan is for the TC to have the spec ready at the end of March, then it can be implemented into products, and we also want to submit this as an OASIS standard. That means the entire OASIS community would support it, and that could happen in the summer 2003 time frame.
Can you explain why some experts see portals as a natural entry point for Web services technology in the enterprise?
Schaeck: Basically, you use portals to provide a front end for users to Web services. So if you have a Web service that can access business information, you can write the corresponding portlets that make the business information available to Web services, and you can indirectly use Web services to generate information. What we're doing with WSRP is introducing a new notion of interactive Web services, which are more data-driven. This is very useful in portals because in your portal you can have a user-facing Web service that could be provided by a third party or in the same company, because you just need to plug them into your portal server.
In a recent survey, Jupiter Research found that 80% of companies are implementing portals for their employees. Why do you think there's so much interest in portals?
Schaeck: Essentially, portals provide unified access to all resources in a company. When the Internet was introduced and companies introduced their own Web sites, there was a large set of different Web site technologies within large corporations. Now they see that [they] have to consolidate this information, and they're using portals to combine all these different sites into a common infrastructure. Web services provide a common way applications can exchange data. They've simplified integration in companies and can save corporations huge amounts of money, so there's an immediate ROI when you introduce a portal.
Do you think the introduction of Web services has augmented that ROI?
Schaeck: I think the ROI would have probably been the same if you'd introduced a portal one or two years ago, but the market has now matured and the portal offerings are advanced enough to fulfill the promises.
Jupiter Research also found that the portal market is very fragmented and that IBM trails Oracle, PeopleSoft and SAP. What's your response to that?
Schaeck: We will have a new release of WebSphere Portal Server (version 5.0) in [the second quarter of] 2003, which we feel will have superior functionality. But if you look at the marketplace, we are quite well positioned, and we have a significant share in the portal marketplace.
With the fragmented market, I would say there are many products, but they use similar concepts. That's actually one of the reasons we're driving this WSRP standard. We want different companies that have different portal products to be able to share services and portlets between companies and products.
Can you give me an example of a business case that justifies application integration using Web services and portals?
Schaeck: If you have, for example, different back-end applications -- like a PeopleSoft app and an SAP app, then you could build certain business portlets for those back-end systems. If you have common entities, such as customer numbers or such data, you can use the portal to correlate disparate data, moving it from one portlet to another, so you can reduce user interactions and automate things to a certain extent. It makes those back-end apps more usable and simplifies the data transformation for users across multiple applications.
How can security be maintained by an organization whose users are accessing Web services via the company portal?
Schaeck: Actually, you can apply security on two levels. First, you can apply access control on portal resources like pages and page groups, or on individual portlets. You can basically determine which portal-users are allowed to see which pieces of content. The other option is to have a second level of access control behind the portal using a Web services gateway. In that layer, you could apply access control on the Web service level.
What are the pros and cons of each?
Schaeck: You can't really compare them. The first method of protecting resources, pages and page groups is something you do to apply access control on the portal level. Now access to a Web service, of course, can be restricted via the portal server, but it can also be accessed directly, so the second security level is required as well. It's not really an either/or situation. Actually, I think you will need both security methods in the end. If the portal is the only way to get at these Web services -- they aren't accessible outside the firewall -- then that's a different story, but that only applies if you have not made your Web services directly accessible.
For enterprises that have already implemented portals, does it make sense to go back and consider adding Web services?
Schaeck: Certainly it makes sense. Architecturally, if you have a portal, it basically provides a user front end to the IT infrastructure of the corporation, and you can also have Web services available to end users. Potentially, Web service technology basically means you can split up the applications you have in your company into well-defined units, and can reduce the cost of accessing them across the company. It makes sense in general, but it also makes sense in the portal environment. I think abstracting or encapsulating components in Web services will always make sense.
FOR MORE INFORMATION:
CLICK for expert advice on connecting a portal to a Web service
CLICK for a Tech Tip on building a powerful corporate portal
CLICK for other stories by News Editor Eric B. Parizo