Skip to Content

What does SOA mean for the Portals?

Enterprise portals have been around for about 10 years now and evolved into the key user interface for information workers. Portals have become commodity and Gartner even predicted the dead of stand alone portals in 2003. By now we know that enterprise portals didn’t pass away, quite on the contrary, the demand for portals is growing steadily. Service Oriented Architecture is a major shift in the IT industry and it contributes to the further success of portals. This enormous SOA trend, however, brings about important changes in enterprise portals, which are described in the following four points.


The portal is the main presentation layer, the “face” of a service-oriented architecture.


Portals enable the consumption of enterprise web-services, which can be considered to be a loosely coupled integration. On the other hand, portals still support non-SOA, tightly-coupled ways-of-working, e.g. direct RFC-based communication to back-end systems not following open standards, therefore it depends on the implementation of the portal “to which extent it will be service-oriented.”


Enterprise portals are becoming integral parts of business process platforms (BPP). 


Together with the application servers, integration software, and other SOA-enabling tools, portals constitute delivery platforms for application services. It goes as far as not providing the presentation layer, “just” some reusable portal services (e.g. role-based access, personalization, etc.) which can be called by other applications of the platform. Delivery channel of such portal services doesn’t necessary have to be the portal, but can be the desktop, mobile devices, etc.  The formation of the business process platforms resulted in a strong consolidation on the portal market: good example is that BEA bought Plumtree and later Oracle bought BEA. SAP is well-positioned for this new market structure, because its NetWeaver Portal is an integral part of the SAP BPP.


Portals become service providers (e.g. UI services), but more importantly service consumers.


The consumed services can be internal or can be provided by suppliers, distributors or any type of business partners. Even public portals such as Yahoo! and Google can become service providers, which will result in aggregation among public and enterprise portals. (The idea of integrating content between public and enterprise portals is not new (see e.g. the SAP-Yahoo! partnership in 2001), but today’s and tomorrow’s service-oriented technologies offer far better possibilities.) This services based componentization of enterprise applications in the whole value chain allows automated processes to cross enterprise boundaries. Security issues and identity management will be challenges in this area.


Portals allow content syndication across a network of portals. Web Services for Remote Portlets (WSRP) is an OASIS-approved network protocol standard which supports the communication of remote portlets, i.e. portlets running in different portals. A portal can be content provider or consumer in this context. The provider makes presentation-oriented web services available to the consumer, which will aggregate the content. The need for this federated approach is underlined by the fact the number of portals deployed in an enterprise has expanded recently. 


Mashups are another technique portals use to combine services. Mashups aggregate data just like standard portal technology. The difference is that while in mashups the aggregation takes place inside a component, in portal technology, various portlets provide various content and the portal pages combine the portlets. Mashups are also similar to SOA-style composite applications. While mashups use web-based feeds and services (sometimes web-services) on top of HTTP and focus on the presentation, composite applications require deeper programming, provide more flexibility and are managed in the process layer e.g. in SAP NetWeaver BPM. 


Composite applications are applications which consist of pieces of other applications. Composites can use the enterprise portal both for runtime and for design time. Runtime means that custom made or packaged out-of-box composite applications can be deployed in the portal (like Visual Composer in NetWeaver 7.0) or made available in the portal (like Visual Composer in NetWeaver 7.1). In design time, the portal offers/hosts the framework for composite application creation.


Portals offers an easy entry to the SOA world.


It is the portal where users interface with services and thus the portal can make SOA more visible, more understandable to the business. SOA is a paradigm shift in terms of people, processes and software. These new concepts are difficult to understand in theory, but seeing SOA working on portal screens really helps to gain acceptance. Consequently, the portal offers an easy entry to the SOA world.

You must be Logged on to comment or reply to a post.
  • I don’t believe the SAP portal is designed to consume web services. I think its main job is to be a role based, personalizable menu system that is used to launch web based applications. This might include applications that use web services, but that is secondary.

    On the other hand, the SAP composition environment (CE) is a proper web service consumer, amongst other things. CE also includes some portal functionality to make it easy to be a one stop shop as a menu plus web service consumer.

    • Hi Michael,

      I agree, of course, the SAP Portal is still mostly responsible for providing web- and role-based access to applications. In my blog, however, besides mentioning this point (paragraph about composites), I was trying to cover all impacts of SOA on Portals. Some are generally true for portals, but less relevant for the SAP Portal, some are still in the making e.g. mashups. I went through the options in a logical order, and here you have a point, didn’t make clear which are more and which are less common. This could a good idea for a follow-up blog 😉

      Thanks for your good comment!