• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Apache Shindig, from Server Side Portlets to Open Social Gadgets
 

Apache Shindig, from Server Side Portlets to Open Social Gadgets

on

  • 7,427 views

Slides from the talk that I did on the 4th December 2009 at Apache Con Asia '09.

Slides from the talk that I did on the 4th December 2009 at Apache Con Asia '09.

Statistics

Views

Total Views
7,427
Views on SlideShare
7,360
Embed Views
67

Actions

Likes
5
Downloads
41
Comments
0

5 Embeds 67

http://www.slideshare.net 51
https://pramati.qontext.com 8
http://www.linkedin.com 4
http://www.ishindig.com 2
http://203.183.132.150 2

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Apache Shindig, from Server Side Portlets to Open Social Gadgets Apache Shindig, from Server Side Portlets to Open Social Gadgets Presentation Transcript

    • 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)
    • Outline
      • The Role of Portals in SOA
      • The Google Gadgets Specification
      • Apache Shindig
      • A Case Study
    • The Role of Portals in Today's Service Oriented World
      • An SOA is ...
      • Essentially a collection of
        • self contained,
        • pluggable,
        • loosely coupled services
      • Which have
        • well-defined interfaces and
        • functionality
    • 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
    • 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!
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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?
    • Then ...
      • Let's talk about Gadgets :)
    • The Google Gadgets Specification
    • 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.
      Source: http://code.google.com/apis/gadgets/docs/spec.html
    • 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 ...
    • 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=&quot;html&quot;> 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
    • In a nutshell ...
    • A Typical Gadget Based Portal iGoogle, Orkut, Hi5
    •  
    • 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
    • Status Source: https://www.ohloh.net/p/10942/analyses/latest
    • Who's using it?
      • LinkedIn
      • hi5
      • Partuza, based on PHP Apache Shindig
      • WSO2 Gadget Server, based on Java Apache Shindig
      • etc.,
    • 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
    • Gadget Rendering Metadata Translate Prefs Features
    • Source: http://chrisschalk.com/shindig_docs/rajdeep/shindig-overview/onjava-shindig-overview-tidy.html
    • Our Experience With Apache Shindig
    • 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
    • The result...
    • 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
    • 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
    • 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
    • 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 signal sign-on framework via shindig features
    • 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
    • Q&A