Last month I did a fair bit of research into mash-up options for developing a framework that collates widgets from different sources. A couple of articles on the oracle site (that strangely seem to have been de-linked) are a good starting point -
Mashup Overview and Server Side mashups -
http://192.9.162.55/developer/technicalArticles/J2EE/mashup_1/
Client side mashups -
http://192.9.162.55/developer/technicalArticles/J2EE/mashup_2
My evaluation is based on an enterprise environment where multiple teams host their modules independently but now need to be collated into a mashup style. This, of course, is a big company problem. You know, the sorts that buy multi million dollar enterprise bus solutions.
In this instance mashup refers to the case when multiple sources contribute to the creation of a single page. these multiple sources provide both widgets and data that are displayed on the page. The container page is simple a holder for the widgets and does not interpret any data or design provide by the widget sources.
There are 2 high level options for building a mashup framework - Server side and client side.
Server Side Mashup
As the name suggests, this approach involves collating the widgets on the server side from multiple sources and composing a single page that is sent out to the client. Subsequent data (ajax) calls from the widgets are all routed through this central server and the responses channelled back to the client.
This, of course is the simplest solution as the client side code / browser is not even aware of any composition. This is the same in concept as any regular client server application. All the complexity of composing from multiple sources is on the server itself.
There are a couple of flavours to this approach. Both the widget html and the data can be sourced off the widget server OR only the data can be sourced off the widget servers and the html composed on the mashup server.
 |
| Option A |
 |
| Option B |
In an enterprise environment there are some issues with this approach
- Infrastructure for the mashup server. Assuming that the individual widgets servers are already scaled for capacity, an additional mashup server means that this hardware layer now needs to scale to usage of the most heavily used widget.
- In case of option B, operationally, this creates a big challenge to now maintain the API connectivity between the widget HTML and the widget source API for the widget data.
- In case of option A, a widget design and interaction guideline must be developed and adhered to by the widget source owners. This may prove to be challenging in a large scale deployment.
- Requires the creation of a team to maintain this mashup server and its contents
There are also advantages to this approach -
- No complexity on the client side to understand the mashups. The client simply works as a regular client-server application.
- Potential for data caching and other operations on the mashup server.
- Of option B selected, then it's easier to standardize the UX elements.
Client Side Mashup
In the client side mashup design, the widgets are composed and aggregated purely on the client side, i.e. - browser. Although this may seem like the logical option simply because it eliminates the middle man, remember that browsers are specifically implemented to disallow cross-domain requests. This is known as the
same-origin policy.
What it means that a single HTML page (excluding frames in this context) can only communicate with a single domain. This is to prevent malicious sites from getting jiggy with data they are not supposed to in the web page. This also means that legitimate mashups are a little bit more difficult to implement.
There are a few options to get around this security issue
Proxy Server
In this approach we place a proxy server in between the container page and the widget source servers. This means that all requests go through this proxy server and are routed to the respective servers. It's similar to the server side composition option, but the server is a dumb router. It could even be a purely hardware based solution. All we are doing is satisfying the same origin policy requirement.
An IFRAME within a HTML document allows loading content from different sources. However, since iframes cannot communicate with each other, achieving a seamless look on the page is a big issues. Without DOM level communication, sizing and merging the frames in a consistent manner is nearly impossible. So, even though technically the content is on the same page, each iframe processes and displays its data independently.
With the HTML 5 specification of postMessage, this limitation can be worked around. It is only available on IE 8 and above.
For older versions of IE there are libraries like easyXDM to get around the X-domain communication issue between frames.
JSON-P
Another way to get around this limitation is to exploit the fact that scripts can be requested from different domains. JSON with Padding requests for JS code using the <SCRIPT> element. Except that instead of receiving pure code, now a javascript function along with data will be returned to the browser. Since this is interpreted by the javascript engine, the function will be executed which usually invokes a callback on the main page with the data. The final result is that this enables data to be served up from multiple domains.
JSONP, however is not a recognized standard even though there exists libraries to support usage. It also means that source servers have to put out data in a certain non-standard format to enable consumption by the JSON P technique.
Cross Domain Requests
CORS is
the HTML 5 specification to enable cross domain requests from browsers. Only IE
10 has support for this standard
IE 8 has support for
XDR,
which is a Microsoft proprietary way of enabling cross domain requests. This
implementation has some limitations, but should be mostly workable.
