Real Story Group. Make Better Technology Decisions.

Apoorv Durga

Follow Apoorv on Twitter @apoorv

How Does Your Portal Expose its Services?

4-Feb-2010

Tags: Portals and Content Integration, Marketplace at Large, Selecting Technology

Enterprises have traditionally used portal technology to aggregate content and functionality from different applications. In that sense, portals have typically been consumers of services.

Nevertheless, despite what vendors may tell you, it's very rare that a single portal instance becomes the only place where you access all your enterprise information.  Most enterprises support multiple portals (or delivery environments) in an organization, and so a single portal server becomes just one component of the enterprise technology landscape.

This means that any portal must not only consume services but also expose its own services in a manner that other components of your enterprise architecture can consume.

Why would you want to do that? Well, many enterprise portal software products have services or functionality that could work well across your enterprise (i.e., not just within the portal). As an example, you might want to use a portal's in-built search engine to be able to index your Web CMS or you might want to use your portal's wiki services more broadly across your intranet.

Of course there may be licensing implications here, but in general you get the idea: de-coupling a portal service so that you can "white label" it or extend its functionality to suit a different environment.

How do you do this?  For starters, you can choose among many standard integration mechanisms to integrate portal services with other applications.  Among others, you can use Web Services, iFrames, Web Clipping, directly access a Portal's data source, or employ an Enterprise Service Bus (ESB) to access the relevant functionality. All of these have their drawbacks and are typically very complex to implement, especially if you want to access a "service" rather than just a "page."

Other approaches are potentially promising.  The Oasis standard, Web Services for Remote Portlets (WSRP), provides a mechanism to expose portlets to other delivery engines. However, while many portal tools can consume WSRP, they do not often comply with WSRP for exposing their own functionality.

Some portal products now expose their services using simpler mechanisms like REST-based APIs, which provide a URI-based way to access a specific feature or subset of a functionality For example, you could obtain a list of top 10 blog posts using a URL from a portal's built-in blogging engine.

The other alternative that some vendors have implemented is the ability to expose every portlet as a "gadget" that you can then include in another web page using simple JavaScript.

As you can see, there are many ways of exposing a Portal's functionality and I'll not go into all the details in a short blog post. Obviously you face trade-offs, as some of these approaches are more complex than others, while some are more presentation-oriented than others.

So if you're evaluating portal products, make sure to understand how the product exposes its services and not just how it consumes services from other applications. We delve into the pros and cons of these different approaches -- and how each vendor covers them -- in our Portals research.