Shindig Apachecon Asia 09

Preview:

DESCRIPTION

The presentation done at Apache Asia 09 in Colombo about Apache shindig

Citation preview

   

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="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

   

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

MetadataMetadata TranslateTranslate PrefsPrefs FeaturesFeatures

   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 single 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