Apache Shindig, from Server Side Portlets to Open Social Gadgets Tyrell Perera  (Product Manager WSO2 Gadget Server and WS...
Outline <ul><li>The Role of Portals in SOA
The Google Gadgets Specification
Apache Shindig
A Case Study </li></ul>
The Role of Portals in Today's Service Oriented World
<ul>An SOA is ... </ul><ul><li>Essentially a collection of  </li><ul><li>self contained,
pluggable,
loosely coupled services </li></ul><li>Which have  </li><ul><li>well-defined interfaces and
functionality  </li></ul></ul>
Therefore, a Service is ... <ul><li>A function that is  </li><ul><li>self-contained and
immune to the context or state of other services  </li></ul><li>These services can communicate with each other </li></ul>
Services are ... <ul><li>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! </li></ul>
A Portal Framework (a) <ul><li>Provides presentation capabilities for these software agents
It is also responsible for providing  </li><ul><li>the required resources and
environment for proper functioning of the components plugged into it </li></ul></ul>
A Portal Framework (b) <ul><li>Is also an extra layer in the architecture that provides  </li><ul><li>A standard (presenta...
Independent of programming languages or platforms </li></ul></ul>
A Portal Framework (c) <ul><li>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, </li><ul><li>by providin...
Ideally ... <ul><li>A portal should be able to bring together,
services and their presentation logic, created using any platform </li><ul><li>Java
PHP
.Net
Etc., </li></ul><li>running anywhere in the world,
to provide a single unified view to the end user </li></ul>
But ... <ul><li>Most portal technologies restrict developers of Portlets in to a platform, one way or the other </li><ul><...
interoperability is a big deal in SOA! </li><ul><li>A Portal is no exception </li></ul></ul>
Then again ... <ul><li>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  </li></ul>
What If? <ul><li>We can write a Portlet and give its URL to the Portal?
The Portal only needs to know this URL and nothing else? </li></ul>
Then ... <ul><li>Let's talk about Gadgets :) </li></ul>
Upcoming SlideShare
Loading in …5
×

Apache Shindig, from Server Side Portlets to Open Social Gadgets

6,102 views

Published on

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

Published in: Technology
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,102
On SlideShare
0
From Embeds
0
Number of Embeds
77
Actions
Shares
0
Downloads
41
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide

Apache Shindig, from Server Side Portlets to Open Social Gadgets

  1. 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. 2. Outline <ul><li>The Role of Portals in SOA
  3. 3. The Google Gadgets Specification
  4. 4. Apache Shindig
  5. 5. A Case Study </li></ul>
  6. 6. The Role of Portals in Today's Service Oriented World
  7. 7. <ul>An SOA is ... </ul><ul><li>Essentially a collection of </li><ul><li>self contained,
  8. 8. pluggable,
  9. 9. loosely coupled services </li></ul><li>Which have </li><ul><li>well-defined interfaces and
  10. 10. functionality </li></ul></ul>
  11. 11. Therefore, a Service is ... <ul><li>A function that is </li><ul><li>self-contained and
  12. 12. immune to the context or state of other services </li></ul><li>These services can communicate with each other </li></ul>
  13. 13. Services are ... <ul><li>Software agents which are the building blocks of SOAs
  14. 14. They are self-contained, which means they should not be modified
  15. 15. Individually, they may or may not have a presentation layer
  16. 16. But the end users need a unified view to make use of all this! </li></ul>
  17. 17. A Portal Framework (a) <ul><li>Provides presentation capabilities for these software agents
  18. 18. It is also responsible for providing </li><ul><li>the required resources and
  19. 19. environment for proper functioning of the components plugged into it </li></ul></ul>
  20. 20. A Portal Framework (b) <ul><li>Is also an extra layer in the architecture that provides </li><ul><li>A standard (presentation) interface for business logic, that is
  21. 21. Independent of programming languages or platforms </li></ul></ul>
  22. 22. A Portal Framework (c) <ul><li>The portal not only presents the application logic contained in the software agents
  23. 23. But can be used to coordinate different, loosely coupled services into a single concrete service, </li><ul><li>by providing the gluing framework </li></ul></ul>
  24. 24. Ideally ... <ul><li>A portal should be able to bring together,
  25. 25. services and their presentation logic, created using any platform </li><ul><li>Java
  26. 26. PHP
  27. 27. .Net
  28. 28. Etc., </li></ul><li>running anywhere in the world,
  29. 29. to provide a single unified view to the end user </li></ul>
  30. 30. But ... <ul><li>Most portal technologies restrict developers of Portlets in to a platform, one way or the other </li><ul><li>If you want your Service to appear in a JSR-168 Portal, you better learn JSR-168 </li></ul><li>Services should be self contained and
  31. 31. interoperability is a big deal in SOA! </li><ul><li>A Portal is no exception </li></ul></ul>
  32. 32. Then again ... <ul><li>Portals are rendered in the browser, aren't they?
  33. 33. In essence, a Portlet's output finally reaches the user as HTML, Javascript or any browser friendly medium </li></ul>
  34. 34. What If? <ul><li>We can write a Portlet and give its URL to the Portal?
  35. 35. The Portal only needs to know this URL and nothing else? </li></ul>
  36. 36. Then ... <ul><li>Let's talk about Gadgets :) </li></ul>
  37. 37. The Google Gadgets Specification
  38. 38. The Google Gadgets Specification <ul><li>Gadgets are web-based software components based on HTML, CSS, and JavaScript
  39. 39. They allow developers to easily write useful web applications that work anywhere on the web without modification
  40. 40. 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: </li><ul><li>standalone web pages, web applications, even other gadgets. </li></ul><li>A gadget and its XML are synonymous. The gadget XML contains all information needed to identify and render a web application. </li></ul>Source: http://code.google.com/apis/gadgets/docs/spec.html
  41. 41. A Gadget Container (Portal) <ul><li>A context into which a gadget is embedded is called a gadget container
  42. 42. The container is responsible for managing the gadgets' layout and controls,
  43. 43. as well as supporting various functionality on behalf of the gadget </li><ul><li>Maximise (or Canvas view)
  44. 44. Passing the user's locale (for i18n)
  45. 45. Storing user preferences
  46. 46. Authentication ... </li></ul></ul>
  47. 47. Gadgets <ul><li>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
  48. 48. The <Module> tag indicates that this XML file contains a gadget
  49. 49. The <ModulePrefs> tag contains information about the gadget such as its title, description, author, and other optional features
  50. 50. The line <Content type=&quot;html&quot;> indicates that the gadget's content type is HTML
  51. 51. <![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
  52. 52. </Content> signifies the end of the Content section
  53. 53. </Module> signifies the end of the gadget definition </li></ul>
  54. 54. In a nutshell ...
  55. 55. A Typical Gadget Based Portal iGoogle, Orkut, Hi5
  56. 57. Apache Shindig <ul><li>Apache Shindig (a word meaning party)
  57. 58. Originally started by Google in 2007 </li><ul><ul><li>as a reference container for hosting OpenSocial compatible widgets in any website </li></ul></ul><li>A port of Google's iGoogle gadget container
  58. 59. Supports </li><ul><li>The Google Gadgets Specification and
  59. 60. The OpenSocial Specification </li></ul></ul>
  60. 61. Status Source: https://www.ohloh.net/p/10942/analyses/latest
  61. 62. Who's using it? <ul><li>LinkedIn
  62. 63. hi5
  63. 64. Partuza, based on PHP Apache Shindig
  64. 65. WSO2 Gadget Server, based on Java Apache Shindig
  65. 66. etc., </li></ul>
  66. 67. Components of Shindig <ul><li>Gadget Container Javascript
  67. 68. Gadget Rendering Server </li><ul><li>Used to render the gadget XML into JavaScript and HTML for the container to expose via the container JavaScript </li></ul><li>OpenSocial Container Javascript
  68. 69. OpenSocial Data Server </li></ul>
  69. 70. Gadget Rendering Metadata Translate Prefs Features
  70. 71. Source: http://chrisschalk.com/shindig_docs/rajdeep/shindig-overview/onjava-shindig-overview-tidy.html
  71. 72. Our Experience With Apache Shindig
  72. 73. What we did with shindig <ul><li>We used shindig to host our portlets </li><ul><ul><li>The provided XML is rendered in to an HTML and returned to the browser </li></ul></ul><li>We let shindig do the communication for us </li><ul><ul><li>Shindig handled gadget specific settings, cross-domain calls etc. </li></ul></ul><li>We made shindig, a component in our server space </li><ul><ul><li>We bundled it in our OSGi environment </li></ul></ul></ul>
  73. 74. The result...
  74. 75. Other bits and pieces of Tech we used <ul><li>For thousands of lines of javascript jQuery helped </li><ul><ul><li>With jQuery the rendered iFrames were smoothly sortable </li></ul></ul><li>We used OSGi to bundle up everything </li><ul><ul><li>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 </li></ul></ul><li>We heavily used Apache web services stack </li></ul>
  75. 76. Tweaks we did to make it fast <ul><li>We enabled caching </li><ul><ul><li>We enabled caching in shindig so the gadgets are refreshed without a delay </li></ul></ul><li>We made the gadget metadata to be fetched in one go
  76. 77. The gadget preferences were loaded asynchronously </li></ul>
  77. 78. Finally what we've got <ul><li>A comprehensive portal server with open standards </li><ul><ul><li>Portlets can be simply written in Javascript, XML and HTML
  78. 79. Write once, run anywhere ability </li></ul></ul><li>A gadget repository and a browser </li></ul>
  79. 80. What's next <ul><li>Enable open social features in shindig </li><ul><ul><li>By supporting open-social features in shindig in the container level we believe an enterprise portal can be more interactive </li></ul></ul><li>Provide single sign-on for all the gadgets in container level </li><ul><ul><li>By implementing a signal sign-on framework via shindig features </li></ul></ul></ul>
  80. 81. More Information <ul><li>Google Gadgets Specification http://code.google.com/apis/gadgets/docs/spec.html
  81. 82. Open Social http://code.google.com/apis/opensocial/
  82. 83. Gadgets Developer Reference http://code.google.com/apis/gadgets/docs/dev_guide.html
  83. 84. Apache Shindig Project Page http://incubator.apache.org/shindig/
  84. 85. WSO2 Gadget Server Project Page http://wso2.org/projects/gadget-server </li></ul>
  85. 86. Q&A

×