This chapter is from the book
This chapter is from the book
This chapter is from the book
Choosing a Mashup Style
There are some clear reasons for picking one mashup style/domain over another. Depending on the goal of the mashup, you should weigh the pros and cons of each mashup style before beginning work.
Pros and Cons of Presentation-Oriented Mashups
Presentation-oriented mashups are popular because they are quick and easy to build. They rely primarily on data and UI artifacts retrieved from sites using service APIs, data feeds, and so on. This model is often referred to as a Software-as-a-Service (SaaS) model, although many of the artifacts used in this model are not technically services. Presentation-oriented mashups often require no preauthorization, no installation steps, and no other technologies than those found within any standard web browser.
It is easy to implement presentation-oriented mashups because you can usually use services, components, and script libraries that are publicly accessible without requiring you to install application platforms or tools. In this model, you can simply embed or include the scripting code or service call right in an HTML page as needed. Many publicly available scripting components today allow you to customize the look-and-feel of the UI artifacts that they generate.
Presentation-oriented mashups typically don't require any service coding or deployment; all service coding is provided by external processes/sites to be used by service consumers at will.
Performance is typically quite responsive with presentation-oriented mashups, since all requests are made directly to a service provider or script provider. This direct-access model eliminates any interactions with an intermediary process through which data is retrieved or functionality is derived. However, this also creates a direct coupling to the service or services that can eventually turn into broken links, partially drawn pages, and/or slowly drawn pages if one or more of the services fail or become nonperforming.
Relying on presentation-oriented techniques and technologies, enterprise mashups can reduce the load that might otherwise be shouldered by one or more corporate servers. Since requests are made directly between a service or data consumer and the provider, the use of presentation-oriented techniques and technologies in at least part of a mashup places the processing burden outside the corporate development domain.
One of the biggest challenges with presentation-oriented mashups is attempting to access services hosted on a site other than the site from which the original page was retrieved. Most standard web browsers enforce a sandbox security model in which a given web page is not allowed to access a site/service located external to the host in which the page originated. This is referred to by a number of names including the server-of-origin policy, the browser security sandbox, the same-origin policy, and the same-domain policy.
The browser security sandbox is in place as an attempt to secure sensitive information and ward off attacks from rogue scripts and components attempting to violate privacy and security. Figure 1.2 illustrates the browser security sandbox.
)
Figure 1.2 The browser security sandbox
Many mashups employ the use of AJAX to communicate with a server and retrieve data. AJAX is a technology that uses a standard JavaScript object—XMLHttpRequest—to pass data from the JavaScript container (browser) to a web host. AJAX enables web pages to perform in a manner more similar to desktop applications, for example, less page refreshing and use of dynamic data updating. However, this dynamic communication model opens the door to malicious scripts; hence the need for the browser security sandbox. The browser security sandbox only allows JavaScript code to use the XMLHttpRequest object to communicate with the host or domain from which the containing page originated. This restriction is a major constraint for building mashups. Therefore, alternative mechanisms are needed if a presentation-oriented mashup is to incorporate data and services from multiple sites. Alternatives have been developed, specifically the use of a technique known as "on-demand scripting" or "dynamic scripting." This technique, which I talk about in detail later, exploits the inclination of a browser to execute JavaScript as it is encountered in the process of interpreting an HTML page.
Pros and Cons of Data-Oriented Mashups
Data-oriented mashups present their own set of challenges and benefits. Primarily, a data-oriented mashup must deal with the intrinsic requirement to act as the data mediator and/or broker. The mashup in this model must take data from multiple sites and mix it together in a form that will be useful to the mashup application or page. As a data broker/integrator, the mashup must deal with multiple data formats and, possibly, communication protocols, such as office document formats, message queue exchange protocols, and HTTP.
In-Process
Mashing data together within a web browser can be a formidable task. Depending on the type of data, browser-based scripts and technologies are not particularly suited for data integration. Most data-mashing techniques performed within a browser involve manipulating XML-based or JSON-based (http://json.org/) data using various JavaScript techniques and applying the results to the web page using DOM manipulation.
Figure 1.3 illustrates the flow of data in an in-process mashup. As illustrated, data is received from multiple sites/hosts and is processed using scripting technologies within a browser page.
)
Figure 1.3 Flow of data in an in-process mashup
Out-of-Process
Mashing data together outside a web browser is nothing new. Any web application or desktop application framework will provide some form of time-tested data integration technology. Frameworks for processing plain text, comma-separated text, XML, relational data, and so forth have been around for decades and optimized to process heterogeneous data very efficiently. New technologies built specifically for disparate data integration, such as enterprise service buses, are also available in this mashup model.
Figure 1.4 illustrates the flow of data in an out-of-process mashup. As illustrated in the figure, a mashup server receives data from multiple sites/hosts and integrates the data using languages, libraries, and frameworks well-suited for data parsing, assembly, mediation, and so on.
)
Figure 1.4 Flow of data in an out-of-process mashup
Mashing data out-of-process can typically handle many more data formats and apply more robust transformations and data-augmentation techniques than an in-process model.
Out-of-process data mashing offers the advantage of evaluating the data payload before returning the result to the mashup client. In this model a mashup server can monitor a data feed for just the data updates and return the updates to the client rather than the entire payload.
Data caching at the mashup server and returning results directly to the client rather than invoking the data request on a remote host is also a benefit of mashing data out-of-process.
Pros and Cons of Process-Oriented Mashups
In a process-oriented mashup, service requests are transmitted from a mashup client to the mashup server in the same fashion as an out-of-process data-oriented mashup. So, from the perspective of the mashup client, the process is the same. However, from the perspective of the mashup server, things change.
A process-oriented mashup server deals with integration of data as well as integration of services and processes. Just as data can be retrieved from multiple different internal and external sources in a data-oriented mashup, services and processes can be invoked on multiple different internal and external service hosts and/or processes.
As illustrated in Figure 1.5, a process-oriented mashup server deals with integration of processes and services from many different internal and external processes and hosts. Since this situation exists in most standard web application or server-oriented environments, it is inevitably encountered in most mashup environments where any form of processing takes place outside the mashup client (browser). The pros and cons of this model are also shared with standard service-oriented server environments, including the intricacies of IPC, transaction management, and service availability.
)
Figure 1.5 Flow of services and processes in a process-oriented mashup
Process-oriented mashups and out-of-process data-oriented mashups allow you to deal with shared security keys, tokens, credentials, and so on using many currently available technologies and frameworks such as SAML, OpenID, and OAuth. Shared security mechanisms are becoming available more and more from an in-process mashup domain, but server technologies still dominate. Handling data security at the server level also allows you to incorporate data-retrieval and security in the same step resulting in fewer hops from client to server.
Out-of-process, data-oriented mashups and process-oriented mashups allow data and services to be processed asynchronously, often resulting in a more efficient use of processing power and time. Browser-based concurrency is usually limited to far fewer calls than server-based concurrency.