Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Portets to composite applications


Published on

This presentation, given at the Alpes JUG in Grenoble France, talks about how to go from portlet development to composite applications development. Composite applications are a great way to speed up web application development.

Published in: Technology, Education
  • Be the first to comment

Portets to composite applications

  1. 1. From Portlets to Composite apps Tarek Elachkar, Serge Huber
  2. 2. About Jahia !  Geneva (2002) !  Paris (2003) !  Washington (2006) !  Klagenfurt (2007) !  Düsseldorf (2008) !  Montréal (2009) !  Since 2002, Jahia’s headquarter is located in Geneva Business development Account management Services & support client R&D team
  3. 3. About Jahia • Open source CMS vendor • Product mixed CMS and portal features from the first version • Mostly sells through a network of 50 partners in 18 countries • Used by over 300 clients including Garmin, BNP Paribas, Université de Nice, ...
  4. 4. About Tarek • Technical consultant for Jahia since 2007 • Interface between the product team and the customers • Java developer since 1996
  5. 5. About Serge • CTO & Co-founder of Jahia • Initial developer of the software • Apache committer on Apache Jackrabbit
  6. 6. Jahia & Open source • Jahia code is open source (GPL) • Apache Jackrabbit contributor • Apache Slide contributor • IKS Project contributor
  7. 7. Jahia and the portal • Jahia has embedded full JSR-168 (then 286) functionality since 2006 (first Jetspeed 2, then Pluto) • Jahia customers have leveraged the Portlet standards in real-life projects • Jahia experts have often been consulted on what technology is better suited for portal needs
  8. 8. What is a portlet? • Pluggable user interface software components managed and displayed in a web portal • Managed by a portlet container (e.g. Pluto) • Generating HTML fragments aggregated by the container, following certain rules and allowing for personalization
  9. 9. What is a portlet? • Portlets produce fragments of markup code that are aggregated into a portal page. • Typically, following the desktop metaphor, a portal page is displayed as a collection of non- overlapping portlet windows, where each portlet window displays a portlet.
  10. 10. Java Portlet standards • Java Portlet Specification 1.0 (JSR168) and 2.0 (JSR 286) • Goal was to make standard Portlets deployable on any standard-compliant portals ➡Implement once - Deploy anywhere
  11. 11. Portlet 1.0 - JSR168 • The portlet container contract and portlet life cycle management • The definition of window states and portlet modes • Portlet preferences management • User information • Packaging and deployment • Security • JSP tags to aid portlet development
  12. 12. Portlet Contract • Portlet Container similar to Servlet Container • Contract allows container to call methods during the life cycle of the portlet • Standard methods: init(), destroy(), processAction(), render(), doView(), doEdit(), doHelp()
  13. 13. Portlet lifecycle • The processAction phase lets the portlet respond to events • The render phase is used by portlets to generate content as HTML fragments
  14. 14. Portlet Lifecycle • Portlets are defined as a standard portlet descriptor file, portlet.xml. Portlets can access two different types of persistent data: • Initialization Parameters - Read-only data defined in the portlet deployment descriptor file • Portlet Preferences - User-dependent read- write data, usually acquired from the portlet in Edit mode
  15. 15. Request handling
  16. 16. Window state • Window state indicates the amount of portal page space that will be assigned to a portlet. • The portlet can use this information to decide how much information to render. • The three window states for each portlet are minimized, maximized, or normal.
  17. 17. Portlet mode • Each portlet has a current mode, which indicates the function the portlet is performing. Standard modes areView, Edit, and Help. • These modes are used by the default render method to decide which lower level display method to call.
  18. 18. Portlet Preferences • The portlet container is responsible for retrieving and storing preferences through the PortletPreferences interface via the getValues() and setValues() methods respectively.
  19. 19. User Information • The Portlet Specification provides a mechanism for portlets to access user information—such as name, email, phone, and address—in the portlet application’s deployment descriptor, and then access them through an unmodifiable Map object. • The Map object can be retrieved through the USER_INFO constant defined in the Request interface.
  20. 20. Packaging / Deployment • The Portlet Specification specifies the packaging and deployment of portlets as part of standard Web Application Archive (WAR) files that may contain other web components, such as JSPs and servlets. • In addition to the web.xml deployment descriptor now found in WAR files, there is an additional portlet.xml descriptor that defines all portlets and portlet-related configurations.
  21. 21. Security • The Portlet Specification includes several features to help developers create secure portlets - e.g. a flag can be set to restrict the portlet to running only over HTTPS. • Portlet API includes authentication facilities for querying user and role information. • The Portlet Specification does not address how users and roles are implemented, leaving it to each vendor to apply its own solution.
  22. 22. Tag Library and API • A JSP Tag library is included to help display portlet pages with JSP technology. • The Java API offers classes and interface for portlet development: ‣ Portlet: Interface for portlets ‣ PortletContext: Similar to ServletContext; ‣ PortletSession: Similar to HttpSession. ‣ RenderRequest, RenderResponse: Similar to ServletRequest and ServletResponse for the render() method ‣ ActionRequest,ActionResponse: Similar to ServletRequest and ServletResponse for the processAction() method ‣ ...
  23. 23. Case Study
  24. 24. Case Study
  25. 25. Case Study • Customer had existing business web apps following the Struts framework • Those apps had to be deployed in the new website • Re-development of those applications was not wanted • Work to make those apps portlet 1.0 compliant was minimal thanks to the Struts Bridge • Deploying the apps as JSR168 portlets took less time, cost and risk than any other solution
  26. 26. Portlet 2.0 additions Events Portlets can communicate with each other through sending and receiving events Shared render parameters Portlets can specify which render parameters they can share with other portlets. Resource serving Portlets can serve resources within the portlet context Support for non-html generation and Ajax Others Java 5 support, inc. annotations Read/Write HTTP headers Portlet Filters
  27. 27. Portlet architecture Portlet API Portlet Container Portlet Custom views Custom controllers Custom model Custom storage Deploymentdescriptors
  28. 28. Portlet advantages • Standardized packaging / deployment • Limited to interactions with portlet container and basic event dispatching between portlet • Portlets may be deployed in different web applications, good for “hosted” deployment • Possible to re-use existing portlets, if they are compliant to the specification of course :)
  29. 29. Portlet disadvantages • No standard storage defined, not much out of the box • Interactions between portlets are limited, or portlets become quite tied together • Requires a full-blown portlet container even for simple applications • Portlets deployed in separate web applications have trouble sharing code, especially on various application servers (each one has a different way of doing it)
  30. 30. Mashups vs Portal Portal Mashup Classification Older technology, extension to traditional Web server model using well defined approach Using newer, loosely defined "Web 2.0" techniques Philosophy/Approach Approaches aggregation by splitting role of Web server into two phases: markup generation and aggregation of markup fragments Uses APIs provided by different content sites to aggregate and reuse the content in another way Content dependencies Aggregates presentation-oriented markup fragments (HTML,WML,VoiceXML, etc.) Can operate on pure XML content and also on presentation- oriented content (e.g., HTML) Location dependencies Traditionally content aggregation takes place on the server Content aggregation can take place either on the server or on the client, but usually happens on the client Aggregation style "Salad bar" style:Aggregated content is presented 'side-by- side' without overlaps "Melting Pot" style - Individual content may be combined in any manner, resulting in arbitrarily structured hybrid content Event model Read and update event models are defined through a specific portlet API CRUD operations are based on REST architectural principles, but no formal API exists Relevant standards Portlet behavior is governed by standards JSR 168, JSR 286 and WSRP, although portal page layout and portal functionality are undefined and vendor-specific Base standards are XML interchanged as REST or Web Services. RSS and Atom are commonly used. More specific mashup standards such as EMML are emerging.
  31. 31. Mashups vs Composite Mashup Composite Source Usually web (free) services Usually enterprise business logic Technology AJAX AJAX, REST,WS Location dependencies Usually on the client Part of the logic on the client, part of it on the server Relevant standards XML, REST,Atom, RSS,Web Services. XML, JSON, REST, CMIS, JCR, native
  32. 32. What are composite apps? • Various definitions out there • Built on top (or aggregate) existing logic • Based on AJAX/REST/ WS principles • Mostly technology agnostic
  33. 33. Advantages • Loosely coupled • Integration of multiple technologies • Lightweight apps that build value from their integration • Security framework uses the default behavior setup for the overall application • Can be executed on the server and/or the client
  34. 34. Disadvantages • No “hard” standard, only a design recommendation (much like REST) • Still quite young • Mostly web specific • No standard platform (yet)
  35. 35. Vs. web services • Lighter technologies, mostly WS “clients” • No XML required, but possible • Easier to integrate with legacy apps • URIs reference objects, not endpoints or methods • Not a “standard”, but more a development philosophy, much like REST.
  36. 36. Content apps • Content driven • Use the JCR as a backbone • Modular, may be hot-deployed • Have full access to the JCR, but use default security information
  37. 37. Composite Content Apps • Based on : ‣ Composite applications ‣ Content applications • Allow for rapid application development • Can stay simple, while quite powerful
  38. 38. Architecture Views Content Repository Custom controller (optional) Event listeners (optional) Deploymentdescriptors RESTServices DependencyInjection
  39. 39. C.C.A. Java Platforms • Apache Sling • Jahia • Day’s CQ 5 • Others available in other languages...
  40. 40. Standards • JCR • CMIS (sort-of) • REST • JSON • JSOP ( auth/2010JulSep/0008.html) • WS-CAF ( tc_home.php?wg_abbrev=ws-caf)
  41. 41. Java Content Repository • Shared content repository • Applications may be built on top of it • Similar to database apps, except in Java and more dynamic (structure can change at runtime) • Now at 2.0, quite mature, and has multiple implementations (Apache Jackrabbit, Exo JCR, ModeShape, Oracle Beehive) • Existing bridges for PHP (Jackalope)
  42. 42. Java Content Repository • Tree-based data storage, retrieval & search • Out of the box features : • Advanced searching (SQL-like query language) • Versioning • Observation • Structured or unstructured data modeling • Import / export
  43. 43. Application security • Use HTTP security protocols (Basic,...) • SSO / CAS / OAuth • JAAS / Container auth • HTTPS
  44. 44. REST • Every content object has an URL • HTTP methods map to basic operations • Extended operations may be added as “actions” Example : POST /root/list/
  45. 45. REST CRUD • Create -> POST • Retrieve -> GET • Update -> PUT • Delete -> DELETE
  46. 46. REST Extension • Applications might define “actions” that can extend basic REST CRUD • Additional HTTP methods could be added to provide for more possible actions on object (although might not be complient with HTTP specification) • Payload may be either form/multipart, or XML, or JSON, ...
  47. 47. CMIS • Yet another content interoperability standard • Just reached version 1.0 • Implementations quite young (nor compatible), but promising • Available on lots of platforms : .NET, PHP, Java • More complex than REST
  48. 48. CMIS • Two bindings :AtomPub & Web service • Some implementations offer both, or one of the two bidings (only one is required) • Java implementation at Apache Chemistry project • Bridges to JCR possible, but not yet implemented • Mostly designed for file access, maps to JCR using “folders”
  49. 49. Mobile integration • REST API • Custom UI on mobiles • UI may be HTML, HTML 5, native (with/ without web views) • Must integrate with application security • Layout must be adapted for mobile screens
  50. 50. Apache Sling Tutorial • Creating content : • curl -F"sling:resourceType=foo/bar" - F"title=some title" http:// admin:admin@localhost:8888/content/ mynode
  51. 51. Apache Sling Tutorial Content template : <html> <body> <h1><%= currentNode.title %></h1> </body> </html> html.esp
  52. 52. Apache Sling Tutorial To select the script, Sling: 1. Looks under /apps 2. Appends the sling:resourceType value of our node ( which is foo/bar ) 3. Appends html.esp, as the extension of our URL is html and the language of our script is esp.
  53. 53. Apache Sling Tutorial • Installing content template : • curl -X MKCOL http:// admin:admin@localhost:8888/apps/foo • curl -X MKCOL http:// admin:admin@localhost:8888/apps/foo/bar • curl -T html.esp http:// admin:admin@localhost:8888/apps/foo/ bar/html.esp
  54. 54. Apache Sling Tutorial • Rendering the content node : • http://localhost:8888/content/ mynode.html • A script named POST.esp instead of html.esp would be called for a POST request, DELETE.esp for DELETE, xml.esp for a GET request with a .xml extension, etc.
  55. 55. Jahia Tutorial • Create content : <form action="http://localhost:8080/cms/render/default/en/*" method="post"> <input type="hidden" name="nodeType" value="jnt:post"/> <textarea rows="7" cols="35" name="content"></textarea> <input type="submit" value="Submit”/> </form> or curl -F"nodeType=jnt:post" -F"content=some content" http://localhost:8080/cms/render/ default/en/*
  56. 56. Jahia Tutorial • To select the script, Jahia : 1. Looks in the modules/* directories 2. Appends the nodeType to the directory, by replacing columns with underscores (jnt:post -> jnt_post) 3. Appends the rendering type as a directory (/html/ or /rss/) 4. Looks for a file that corresponds to the type without the namespace and with any supported script extension (post.jsp, post.groovy, post.php, ...) 5. If no file is found, it will use parent definition (nt:base or other) and start back at 1
  57. 57. Jahia Tutorial • Create a file named jnt_post/html/post.jsp in the modules/default directory <html> <body> <h1><jcr:nodeProperty node="${currentNode}" name="content" /></h1> </body> </html> post.jsp • We could have created a jnt_post/rss/post.jsp file that would be called when rendering a node with a .rss extension
  58. 58. Jahia Tutorial • Scripts, custom code, REST actions, rules, etc may be packaged as modules • Modules may inherit from other modules • Modules may be hot-deployed • Modules may include tag libraries, librairies • Modules may contain templates sets, import files
  59. 59. Out of the box • Can be combined to create new composite applications • Means that components must be designed to be “pluggeable” • JCR & REST act as common ground API • Some platforms come bundled with out of the box components, others with examples, but usually there is no need to start from scratch
  60. 60. Application interaction • Session • JCR observation • Node references • Search • REST
  61. 61. Interaction example • Content “binding” : ‣ An application is setup with a reference to another node ‣ The application adds content underneath the referenced node, for example comments ‣ The application builds the UI and logic to handle the added content
  62. 62. Comments example • Comments CCA actually interfaces with other content objects • Two UI, one to display comments, the other to enter a new comment
  63. 63. Ratings example • Ratings CCA can be applied to any other content object, applying ratings on it.
  64. 64. Application “splitting” • Large application can be split into composite applications • Example : forum ‣ List of forums ‣ List of topics ‣ List of messages
  65. 65. Forum example • Comments composite application may be re-used to build message list • Topics list may be useful outside of forum, for example to build an FAQ • Ratings could be added easily onto forums, topics or individual messages
  66. 66. Performance • Make sure your operations stay short • Cache GET requests • Partition your REST URI space • Avoid searches that retrieve large amount of content • Use pagination, lazy loading
  67. 67. Import / export • Content tree may be export in part or in full • Import can be used to address multiple scenarios : ‣ Migration between versions ‣ Content re-structuring ‣ Backup / restore
  68. 68. Scalability • Each component can stay focused on a simple feature • Executing components needs to be fast • Small REST calls can scale ! • Components can be moved to other nodes if developed in a compatible way
  69. 69. IDEs • Make it easy to package / deploy / test composite apps • Apache Sling • Jahia Template Studio
  70. 70. IDEs
  71. 71. Q & A
  72. 72. Thank you ! telachkar @ jahia dot com shuber @ jahia dot com