Apache Shindig is an open source gadget container that allows developers to easily write reusable web applications using HTML, CSS and JavaScript. It supports the Google Gadgets specification and OpenSocial specification, allowing gadgets to be embedded into various contexts like websites and portals. The authors used Apache Shindig to power their portal server, bundling it using OSGi and enabling features like caching to improve performance. They were able to build a comprehensive portal with open standards and a gadget repository browser.

1. Apache Shindig, from Server Side Portlets to
Open Social Gadgets
Tyrell Perera
(Product Manager WSO2 Gadget Server and WSO2 Mashup Server)
&
Nuwan Bandara
(Software Engineer, WSO2 Gadget Server)

2. Outline
• The Role of Portals in SOA
• The Google Gadgets Specification
• Apache Shindig
• A Case Study

3. The Role of Portals in Today's
Service Oriented World

4. An SOA is ...
• Essentially a collection of
– self contained,
– pluggable,
– loosely coupled services
• Which have
– well­defined interfaces and
– functionality

5. Therefore, a Service is ...
• A function that is
– self­contained and
– immune to the context or state of other services
• These services can communicate with each
other

6. Services are ...
• Software agents which are the building blocks
of SOAs
• They are self­contained, which means they
should not be modified
• Individually, they may or may not have a
presentation layer
• But the end users need a unified view to make
use of all this!

7. A Portal Framework (a)
• Provides presentation capabilities for these
software agents
• It is also responsible for providing
– the required resources and
– environment for proper functioning of the
components plugged into it

8. A Portal Framework (b)
• Is also an extra layer in the architecture that
provides
– A standard (presentation) interface for business
logic, that is
– Independent of programming languages or
platforms

9. A Portal Framework (c)
• The portal not only presents the application
logic contained in the software agents
• But can be used to coordinate different, loosely
coupled services into a single concrete service,
– by providing the gluing framework

10. Ideally ...
• A portal should be able to bring together,
• services and their presentation logic, created using
any platform
– Java
– PHP
– .Net
– Etc.,
• running anywhere in the world,
• to provide a single unified view to the end user

11. But ...
• Most portal technologies restrict developers of
Portlets in to a platform, one way or the other
– If you want your Service to appear in a JSR­168
Portal, you better learn JSR­168
• Services should be self contained and
• interoperability is a big deal in SOA!
– A Portal is no exception

12. Then again ...
• Portals are rendered in the browser, aren't
they?
• In essence, a Portlet's output finally reaches
the user as HTML, Javascript or any browser
friendly medium

13. What If?
• We can write a Portlet and give its URL to the
Portal?
• The Portal only needs to know this URL and
nothing else?

14. Then ...
• Let's talk about Gadgets :)

15. The Google Gadgets Specification

16. The Google Gadgets Specification
• Gadgets are web­based software components based on HTML,
CSS, and JavaScript
• They allow developers to easily write useful web applications that
work anywhere on the web without modification
• They are defined using a declarative XML syntax that is processed
by a gadget server into a format that allows them to be embedded
into various contexts:
– standalone web pages, web applications, even other gadgets.
• A gadget and its XML are synonymous. The gadget XML contains
all information needed to identify and render a web application.

17. A Gadget Container (Portal)
• A context into which a gadget is embedded is called a
gadget container
• The container is responsible for managing the gadgets'
layout and controls,
• as well as supporting various functionality on behalf of the
gadget
– Maximise (or Canvas view)
– Passing the user's locale (for i18n)
– Storing user preferences
– Authentication ...

18. Gadgets
Gadgets are specified in XML. The first line is the standard way to start an XML file. This must be the first
•
line in the file
The <Module> tag indicates that this XML file contains a gadget
•
The <ModulePrefs> tag contains information about the gadget such as its title, description, author, and other
•
optional features
The line <Content type="html"> indicates that the gadget's content type is HTML
•
<![CDATA[ ...insert HTML here... ]]> is used to enclose HTML when a gadget's content type is html. It tells
•
the gadget parser that the text within the CDATA section should not be treated as XML. The CDATA section
typically contains HTML and JavaScript
</Content> signifies the end of the Content section
•
</Module> signifies the end of the gadget definition
•

19. In a nutshell ...

20. A Typical Gadget Based Portal
iGoogle, Orkut, Hi5

22. Apache Shindig
• Apache Shindig (a word meaning party)
• Originally started by Google in 2007
• as a reference container for hosting OpenSocial
compatible widgets in any website
• A port of Google's iGoogle gadget container
• Supports
– The Google Gadgets Specification and
– The OpenSocial Specification

23. Status

24. Who's using it?
• LinkedIn
• hi5
• Partuza, based on PHP Apache Shindig
• WSO2 Gadget Server, based on Java Apache
Shindig
• etc.,

25. Components of Shindig
• Gadget Container Javascript
• Gadget Rendering Server
– Used to render the gadget XML into JavaScript and
HTML for the container to expose via the container
JavaScript
• OpenSocial Container Javascript
• OpenSocial Data Server

26. Gadget Rendering
Metadata
Metadata Translate
Translate Prefs
Prefs Features
Features

27. Source: http://chrisschalk.com/shindig_docs/rajdeep/shindig­overview/onjava­shindig­overview­tidy.html

28. Our Experience With Apache Shindig

29. What we did with shindig
• We used shindig to host our portlets
• The provided XML is rendered in to an HTML and
returned to the browser
• We let shindig do the communication for us
• Shindig handled gadget specific settings, cross­domain
calls etc.
• We made shindig, a component in our server
space
• We bundled it in our OSGi environment

30. The result...

31. Other bits and pieces of Tech we
used
• For thousands of lines of javascript jQuery helped
• With jQuery the rendered iFrames were smoothly
sortable
• We used OSGi to bundle up everything
• Rather than using shindig as a deployed web­app we
OSGi­fied it, so it would work in harmony with other
modules in the portal server
• We heavily used Apache web services stack

32. Tweaks we did to make it fast
• We enabled caching
• We enabled caching in shindig so the gadgets are
refreshed without a delay
• We made the gadget metadata to be fetched in
one go
• The gadget preferences were loaded
asynchronously

33. Finally what we've got
• A comprehensive portal server with open
standards
• Portlets can be simply written in Javascript, XML and HTML
• Write once, run anywhere ability
• A gadget repository and a browser

34. What's next
• Enable open social features in shindig
• By supporting open­social features in shindig in the
container level we believe an enterprise portal can be
more interactive
• Provide single sign­on for all the gadgets in
container level
• By implementing a single sign­on framework via shindig
features

35. More Information
• Google Gadgets Specification
http://code.google.com/apis/gadgets/docs/spec.html
• Open Social http://code.google.com/apis/opensocial/
• Gadgets Developer Reference
http://code.google.com/apis/gadgets/docs/dev_guide.html
• Apache Shindig Project Page http://incubator.apache.org/shindig/
• WSO2 Gadget Server Project Page http://wso2.org/projects/gadget­server

36. Q&A