A number of organisations use Portal technology as an onramp to SOA. Have you ever wondered why?
A SOA architecture style enables a number of services to be exposed that can be consumed by a number of other services or business components. A key issue in this environment will be the granularity of the service. This is such an interesting topic! I could really spend the next few months writing about it. However, a Portal, normally through discrete portlets, allows a service to be consumed in an atomic manner. That is the portlet will utilise the capabilities of that service with out the potential need to interact with one or more other services, thus introducing the need to ensure control transactional consistency across the services.
Many portlets can be assembled on a page, and through the use of wires, these can be assembled into a composite application. As the user selects something in one portal a message is sent through the wire to the other portlets. Normally there will only be one update type portlet hence only one update service engaged in transaction. Therefore it becomes the responsibility of the ESB, if being used, or the service being invoked to maintain transactional integrity.
One could argue, that this is working around some issues and in reality it is! I would suggest not trying to overcome these limitations at this time. If you have a different argument leave a comment, would love to hear about it.