Always-on Distributed Spreadsheet Mashups

cipi Centro di Ricerca sull’Ingegneria delle Piattaforme Informatiche

Always-on Distributed Spreadsheet Mashups

Pierpaolo Baglietto (1), Fabrizio Cosso (2), Martino Fornasa (1), Simone
Mangiante (1), Massimo Maresca (1), Andrea Parodi (2), Michele
Stecca (1)
(1) Computer Platform Research Center (CIPI) - University of Padova, University of Genova, Italy
(2) M3S S.r.l. - Genova, Italy

Mashups’10
Ayia Napa, Cyprus, Dec. 1st 2010
m.stecca@cipi.unige.it

cipi Computer Platform Research Center - CIPI

Agenda

1. Introduction
2. Requirements
3. Platform architecture and operating principles
4. Platform implementation
5. Hierarchical Enterprise Spreadsheet Mashup
6. Discussion
7. Conclusion

2


Introduction (1/2)
CIPI’s research activities
 Mashups are composite applications that allow to merge different
functionalities, data sources, user interfaces, etc.

 Mashups are usually defined as lightweight tools. According to the
classification provided by Fischer et al. (2009), it is possible to identify some
paradigms aiming at supporting the easy creation of composite services:
• Wiring paradigm (e.g., JackBe Presto, Yahoo Pipes!, etc.)
• Spreadsheet-based frameworks (e.g. SpreadATOR, IBM A1, etc.)
• Programming by demonstration (e.g., Dapper)
• Automatic creation of Mashups (e.g., MaxMash)

 In this paper we propose to improve the current generation of Spreadsheet-
based Mashup tool by adding two new features:
 The Distributed Spreadsheet Composition functionality, and
 The Always-on functionality (i.e., the Spreadsheet Mashup is updated
even if one or more components are offline)
3


Introduction (2/2)
Spreadsheets vs Wiring Paradigm
 In Spreadsheets-based frameworks, both the Service Creation
Environment and the Execution Environment are implemented in a
spreadsheet tool which represents the “integration point” for different
sources
 According to the Wiring Paradigm, Mashups are created by linking
together basic blocks. In this case spreadsheets have a marginal role
because they are just a data source (i.e., one of the possible basic blocks)
instead of been the “core” technology as in the previous case
 The system presented in the paper can be seen as a mixture of the two
approaches because:
 It explicitly exploits the spreadsheet technology for Mashup creation;
 It implicitly uses the Wiring Paradigm at execution time because a spreadsheet
composition can be seen as a set of basic blocks (i.e., the spreadsheets)
linked together

UserA UserC UserD
UserB 4


Agenda

1. Introduction
2. Requirements
6. The Car Dealers case study
7. Discussion
8. Conclusion

5


Requirements for Mashup tools
Here is a list of 4 requirements that we identified for the usage of Mashup
tools in the Enterprises

1. Support of lightweight creation of Situational Applications 
Spreadsheets are well known tools;
2. Support of reuse of already existing data  Spreadsheets
are widely used to store enterprise data;
3. Compliance with the distributed and hierarchical structure of
enterprises  different units of the same company may be
geographically distributed;
4. Support of automatic updates and Always-on distributed
Composite Spreadsheets  synchronize the linked
spreadsheets automatically even when one or more
components of the distributed spreadsheet are offline.

6


Agenda

1. Introduction
2. Requirements
6. Discussion
7. Conclusion

7


Platform architecture and operating principles (1/2)

 Spreadsheet types:
 Importer: it imports data from other spreadsheets;
 Exporter: it exports data to other spreadsheets;
 Intermediate: it is both an importer and an exporter at the same time,
and at least one exported cell is a function of an imported cell (via
direct inclusion or formulas).

 Components of the platform:
 A centralized server-side Composition Platform supports the
execution of spreadsheet data exportation and importation, manages
user accounts, and synchronizes data across dependent
spreadsheets;
 A Client Plug-in integrated in the end-user spreadsheet application. It
interacts with the composition platform by means of messages
exchange and allows the user to import/export data through a
graphical UI.
8


Platform architecture and operating principles (2/2)

 Operating principles:

 The exporter contribution update is periodically performed by each
exporter Plug-in towards the platform;
 The importer spreadsheet update is periodically performed by the
importer Plug-in. The Plug-in periodically polls the platform for new
contributions or updates;
 The data propagation function works as follows:
• When a client Plug-in realizes that the spreadsheet is intermediate it
uploads the entire spreadsheet on the platform. Every time an intermediate
spreadsheet is updated the Plug-in performs a new upload.
• When an intermediate spreadsheet is offline, the platform runs a local
spreadsheet engine in order to recalculate the exported ranges based on
fresh import ranges.

9


Agenda

1. Introduction
2. Requirements
6. Discussion
7. Conclusion

10

Computer Platform Research Center - CIPI

Platform implementation

 The Client Plug-in must be installed on nodes running the MS Excel
software (developed through the Visual Studio Tool for Office)
 The Plug-in and the Composition Platform communicate by means
of SOAP-based APIs
 The DB stores the importations, exportations, and the
dependencies among spreadsheets
 The Excel Server component runs the intermediate spreadsheets
when needed (i.e., an update in the exporting file occurred)
 The importing spreadsheets poll the Composition Server to retrieve
updated data 11


Agenda

1. Introduction
2. Requirements
6. Discussion
7. Conclusion

12


Hierarchical Enterprise Spreadsheet Mashup – HESM (1/3)

 The main concepts in HESMs are:
 Master Organizational Unit (MOU)
 Contributing Organizational Units (COU)
Composition Platform
 Space Composition Platform
Unit 1 spreadsheet
 Master Spreadsheet A-COU1 range B-COU1
range
 Chain of spaces “A” space A-COU1 range A-COU2 range

A-COU2 range
B-COU2 range
“A” space
“B” space

Unit 1
“A” Master Organizational Unit (A-MOU)
Unit 5 Unit 4 Unit 1
Unit 1 spreadsheet
“B” Master Organizational Unit (B-MOU)
Unit 3 Unit 2
“A” Master Organizational Unit (A-MOU)
“B” Contributing Org. Unit 2 (B-COU2) “A” Co
“A” Master spreadsheet “A” Contributing Org. Unit 2 (A-COU2) “B” Contributing Org. Unit 1 (B-COU1) (A-COU1)
“A” Contributing Org. Unit 1
Unit 5 spreadsheet Unit 4 spreadsheet
“B” Master spreadsheet “A” Master spreadsheet
Unit 3 spreadsheet Unit 2 spreadsheet
Unit 1 spreadsheet
A-COU1 range B-COU2 range

A-COU1 range
B-COU1 A-COU2 range A-COU1 range
range B-COU1
A-COU2 range
B-COU2 range range
A-COU2 range

“B” space
“A” space
13 space
“A”


Hierarchical Enterprise Spreadsheet Mashup
– HESM (2/3)
Case Study: the Car Dealer Example
 The company is organized in an hierarchical way:
 Car Dealers – CDs interact with costumers
 A set of CDs located in a certain area are managed by the same Area
Sales Manager - ASM
 A set of ASMs located in a certain region are managed by the same
Regional Sales Manager – RSM

 There are different relationships among actors:
 CDs keep track of their sales in their own spreadsheets
 CDs are the COUs of the spreadsheet owned by the related ASM (i.e.,
the MOU of this relationship)
 ASMs keep track of the regional sales in their own spreadsheets
 ASMs are the COUs of the spreadsheet owned by the related RSM
(i.e., the MOU of this relationship)
14


Hierarchical Enterprise Spreadsheet Mashup – HESM (3/3)
Case Study: the Car Dealer Example (Screenshots)

15


Agenda

1. Introduction
2. Requirements
6. Discussion
7. Conclusion

16


Discussion

 Other Spreadsheet-based Mashup tools focus on the integration of
different data sources into Spreadsheets
 On the contrary we focus on the distributed and always-on composition of
spreadsheets
 Our approach can be seen as complementary with respect to the platforms
that import different data sources and convert them to spreadsheet cells

 The proposed solution aims at modeling the hierarchical structure
of enterprises as shown in the Car Dealer case study

 The proposed solution may take advantage of the emerging Cloud
Computing paradigm in two different ways:
 In a Infrastructure as a Service – IaaS scenario, the Composition Platform
might run on a Virtual Machine deployed “in-the-cloud” (e.g., it might be an
Amazon Machine Image – AMI deployed on the Amazon EC2 Cloud)
 In a Software as a Service – SaaS scenario, the Composition Platform might
rely on the Google Spreadsheet APIs which allow to manipulate spreadsheets
stored “in-the-cloud”
17


Agenda

1. Introduction
2. Requirements
6. Discussion
7. Conclusion

18


Conclusion

 We designed a spreadsheet Mashup tool which allow to:
 Create distributed spreadsheet composition
 Update the spreadsheet composition automatically even if one or more
components are offline (Always-on feature)
 Reflect the hierarchical structure of enterprises where actors working at
different levels contribute to the creation of aggregated information

 We implemented a prototype of the system presenting the following features:
 The client Plug-in is implemented to run on the Microsoft Office system
 The Client/Server communication architecture is based on SOAP messages
exchange
 It manages the automatic update of complex spreadsheet composition
through the execution of intermediate spreadsheets
 Future works
 Security
 Versioning
 Spreadsheet Mashups “in-the-cloud”
19


Thank you for
your attention

20


Other CIPI’s research activities
Few words about our prototype based on the Wiring paradigm…
 It aims at combining data and services regardless the specific
technologies used for their implementation (e.g., RSS Feed, Rest WS,
SOAP WS, etc.)
 We re-use the Service Creation Environment developed during the FP6
project called OPUCE (Open Platform for User-Centric Creation and
Execution)
 We developed a platform for the execution of Event Driven Mashups (i.e.,
each basic block may generate one or more events during its execution)
 We implemented different versions of the execution platform based on
different technologies (Web Services, Java Message Service – JMS, and
Plain JAVA code over Virtualized environments)

21

Always-on Distributed Spreadsheet Mashups

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Always-on Distributed Spreadsheet Mashups

Ähnlich wie Always-on Distributed Spreadsheet Mashups (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Always-on Distributed Spreadsheet Mashups