DOC PREVIEW
UB CSE 486 - Edge Mashups for Service-Oriented Collaboration

This preview shows page 1-2 out of 5 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

computer 90WEB TECHNOLOGIESPublished by the IEEE Computer Society 0018-9162/09/$25.00 © 2009 IEEE Edge Mashups for Service-Oriented CollaborationNetworked collabora-tion tools may be the key to slashing health-care costs, improving productivity, facilitating disaster response, and enabling a more nimble information-aware military. Better applications could even make pos-sible a world of professional dialog and collaboration without travel. We term such tools service-oriented collaboration (SOC) applications. SOC systems are more and more appeal-ing because of the increasingly rich body of service-hosted content, such as electronic medical health records, data in various kinds of databases, image repositories, patient records, and weather prediction systems. They may also tap into sensors, medical devices, video cameras, microphones, and other real-world data sources.Many kinds of applications are con-structed as mashups, in which data from various sources is combined in a single multilayered interactive GUI, and it may seem natural to use mash-ups to build SOC applications as well. The collaborating team could pull the various data sources it is using into a single interactive application, which would be shared among the users.But building SOC applications isn’t going to be as simple as many believe. Media streams generate high, bursty update rates, and many require low latencies and tight synchronization between collaborating users. Some also require client-to-client security and can’t “trust” a Web services plat-form or any other third party. For example, in many medical scenarios, only the collaborating physicians are permitted to see the communication that occurs; military applications may involve classified information. These requirements represent seri-ous issues because in today’s Web services standards, client-to-client data must be relayed via a hosted ser-vice—typically, an enterprise service bus (ESB) using a publish-subscribe model, RSS feeds, a message-queuing (MQ) middleware product like the Java Messaging Service (JMS), and so on. Relaying introduces delay and scal-ability issues. Moreover, Web services security models focus on client-to-server security. If a server can’t be trusted, Web services security offers no help.Something new is needed: a way to create SOC applications that seam-lessly integrate hosted content with the kinds of peer-to-peer (P2P) pro-tocols capable of responding to these needs. Cornell’s Live Distributed Objects platform solves this prob-lem, enabling end users to construct mashups that live directly on client platforms and can be operated even without connectivity to the Inter-net. These edge mashups enable a powerful style of Web-services-sup-ported collaboration (K. Ostrowski, “Programming with Live Distributed Objects,” Proc. 22nd European Conf. Object-Oriented Programming, LNCS 5142, Springer-Verlag, 2008, pp. 463-489).Today’s Web services approach Let’s look more closely at the way today’s developers build mashups to support SOC applications. SOC sys-tems focus on interactive scenarios, hence the client will often be running a browser or some other form of GUI. In such cases, it is becoming common for service platforms to export a minibrowser component. This is an interactive webpage with embedded script, commonly developed using JavaScript/Ajax, Flash, Silverlight, or a similar technology, and optimized Ken Birman, Jared Cantwell, Daniel Freedman, Qi Huang, Petko Nikolov, and Krzysztof Ostrowski, Cornell UniversityThe Live Distributed Objects platform makes it possible to combine hosted content with P2P protocols in a single object-oriented framework.Authorized licensed use limited to: SUNY Buffalo. Downloaded on March 04,2010 at 13:23:49 EST from IEEE Xplore. Restrictions apply.91mAY 2009for some type of content, for example interactive maps from Google Earth or Virtual Earth. The embedded script is often tightly integrated with back-end ser-vices in the data center—services that may not even be directly accessible at a programmatic level. As a result, the only way that new content can be “mashed” into the data available from the service is to have the data center itself compute the mashup. For example, Google’s minibrows-ers expose composite images that draw on multiple data sources, pre-sented to the client as selectable layers. If the client pans or zooms the minibrowser window, the data associ-ated with the mashup is also zoomed or panned. Google also offers tools to help end users define new kinds of mashups. When these are used, however, the data is combined by Google’s platform, not on the client system. This point will turn out to be important: A mashup built this way won’t be functional unless a connec-tion to Google is available, and won’t be able to incorporate protocols that run directly between the client machines. Developers could incorporate these kinds of content and protocols in a second way: by running multiple minibrowser windows in a single webpage. However, they won’t talk to one another. Another possibil-ity is to access the data centers at a programmatic level. This, though, is hard because many of the features accessible through minibrowsers are difficult to access, or not available at all, via programmatic APIs.To illustrate this point, consider Figure 1a, which shows a SOC appli-cation constructed using a standard Web services approach, pulling content from the Yahoo maps and weather Web services and assem-bling it into a webpage as a set of tiled frames. Each frame contains a minibrowser with its own interactive controls and comes from a single con-tent source. To highlight one of the many restrictions: If the user pans or zooms in the map frame, the associ-ated map will shift or zoom, but the other frames remain as they were—the frames are not synchronized. Implicit in the example is a second, and perhaps even more serious, issue. We noted that SOC applications will need a snappy response, even with substantial numbers of collaborat-ing users. In today’s Web services architecture, when one client wants to send an event to some set of other clients, the event needs to be relayed through an ESB, a catch-all term that covers everything from a JMS applica-tion to a publish-subscribe product to an RSS feed. The problem is perfor-mance and scalability. Bouncing data off a remote server can be slow. If the server is


View Full Document

UB CSE 486 - Edge Mashups for Service-Oriented Collaboration

Download Edge Mashups for Service-Oriented Collaboration
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Edge Mashups for Service-Oriented Collaboration and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Edge Mashups for Service-Oriented Collaboration 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?