Mashups and portals are both content aggregation technologies. Portals are an older technology designed as an extension to traditional dynamic Web applications, in which the process of converting data content into marked-up Web pages is split into two phases: generation of markup "fragments" and aggregation of the fragments into pages. Each markup fragment is generated by a "portlet", and the portal combines them into a single Web page. Portlets may be hosted locally on the portal server or remotely on another server.
Portal technology defines a complete event model covering reads and updates. A request for an aggregate page on a portal is translated into individual read operations on all the portlets that form the page ("render" operations on local, JSR 168 portlets or "getMarkup" operations on remote, WSRP portlets). If a submit button is pressed on any portlet on a portal page, it is translated into an update operation on that portlet alone ("processAction" on a local portlet or "performBlockingInteraction" on a remote, WSRP portlet). The update is then immediately followed by a read on all portlets on the page.
Portal technology is about server-side, presentation-tier aggregation. It cannot be used to drive more robust forms of application integration such as two-phase commit.
Mashups differ from portals in the following respects:
The portal model has been around longer and has had greater investment and product research. Portal technology is therefore more standardised and mature. Over time, increasing maturity and standardization of mashup technology may make it more popular than portal technology. New versions of portal products are expected to eventually add mashup support while still supporting legacy portlet applications. Mashup technologies, in contrast, are not expected to provide support for portal standards.
The questions to be answered are
Will Portals remain or will be replaced by Mashups?
Portals only serve the lowest denominator of end users and hence confined to limited information broadcasting. The major problem with portal is that the user cannot decide which content can be personalized or how it can be manipulated. With the rise of social networking sites and availability of free open APIs users quickly learned to build their own personal portals. With the current trend users won’t be content to operate within the confines of a single, stoic portal that restricts how they consume and manipulate information.
Implementing Mashup’s for SOA
Most vendors are now using the terms “SOA” and “Web services” interchangeably, it has become obvious that for most corporations, implementing a successful SOA will require the service-enablement of their existing applications. Mashups are a completely valid method of accomplishing this.
Mashup’s for Cloud computing.
Mashups are a natural complement to SaaS. With SaaS and mashups, you may be able to maintain the bulk of your confidential data internally and send the hosted application only small subsets of data for processing. If the network link to the SaaS vendor fails, at least you still have local access to your data.
Also good read discussing Mashups to be the future of Portals is available on http://www.expresscomputeronline.com/20080114/technology01.shtml
References:
http://wapedia.mobi/en/Mashup_%28web_application_hybrid%29
http://blogs.zdnet.com/service-oriented/?p=1861
Posts
Mashups for portals look nice. Especially about the link that u have provided .I am just trying to imagine how would Indian railways try to build portals for every of their applications, its huge , it has around 50,000 forms to be filled over the entire operations.Mashups over their portal will form a good and feasible alternative for them.
ReplyDelete