Portlets communicating to Google Gadgets

By Nick Hortovanyi

Just checked IBM Developer Works and found an article regarding inter portlet communication between Portlets and Google Gadgets.

I was extremely excited with the original announcement for the inclusion of Google Gadgets  in WebSphere Portal, as it was breaking down the traditional barriers of the enterprise with usage of internet based services outside the firewall. In my original post on this, I had noticed that the Gadgets could not receive wires from the property broker, thus were static in nature and unable to participate in a composite page.

So its great to see movement here on this front. However, after reading the article, I think some other tools will be needed to simplify the integration, configuring lots of XML files and writing Mapper classes takes time.

But none the less, we will have to try it soon.
 

Tags portal portlets ipc google+gadgets   |  Comments 0

Portal technology as an onramp to SOA

By Nick Hortovanyi

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.

Tags esb portal soa portlets   |  Comments 1