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.

1. From Portlets to Composite apps
Tarek Elachkar, Serge Huber

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. 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. About Tarek
• Technical consultant for Jahia since 2007
• Interface between the product team and
the customers
• Java developer since 1996

5. About Serge
• CTO & Co-founder of Jahia
• Initial developer of the software
• Apache committer on Apache Jackrabbit

6. Jahia & Open source
• Jahia code is open source
(GPL)
• Apache Jackrabbit
contributor
• Apache Slide contributor
• IKS Project contributor

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. 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. 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. 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. 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. 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. 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. 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. Request handling

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. 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. Portlet Preferences
• The portlet container is responsible for retrieving and
storing preferences through the PortletPreferences
interface via the getValues() and setValues() methods
respectively.

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. 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. 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. 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. Case Study

24. Case Study

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. 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. Portlet architecture
Portlet API
Portlet Container
Portlet
Custom views
Custom controllers
Custom model
Custom storage
Deploymentdescriptors

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. 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. 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. 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. 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. 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. Disadvantages
• No “hard” standard, only a design
recommendation (much like REST)
• Still quite young
• Mostly web specific
• No standard platform (yet)

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. 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. Composite Content
Apps
• Based on :
‣ Composite applications
‣ Content applications
• Allow for rapid application development
• Can stay simple, while quite powerful

38. Architecture
Views
Content Repository
Custom controller (optional)
Event listeners (optional)
Deploymentdescriptors
RESTServices
DependencyInjection

39. C.C.A. Java Platforms
• Apache Sling
• Jahia
• Day’s CQ 5
• Others available in
other languages...

40. Standards
• JCR
• CMIS (sort-of)
• REST
• JSON
• JSOP (http://lists.w3.org/Archives/Public/w3c-dist-
auth/2010JulSep/0008.html)
• WS-CAF (http://www.oasis-open.org/committees/
tc_home.php?wg_abbrev=ws-caf)

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. 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. Application security
• Use HTTP security
protocols (Basic,...)
• SSO / CAS / OAuth
• JAAS / Container auth
• HTTPS

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/
object.startWorkflow.do.html

45. REST CRUD
• Create -> POST
• Retrieve -> GET
• Update -> PUT
• Delete -> DELETE

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. 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. 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. 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. Apache Sling Tutorial
• Creating content :
• curl -F"sling:resourceType=foo/bar" -
F"title=some title" http://
admin:admin@localhost:8888/content/
mynode

51. Apache Sling Tutorial
Content template :
<html>
<body>
<h1><%= currentNode.title %></h1>
</body>
</html>
html.esp

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. 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. 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. 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. 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. 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. 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. 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. Application interaction
• Session
• JCR observation
• Node references
• Search
• REST

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. Comments example
• Comments CCA
actually interfaces
with other content
objects
• Two UI, one to
display comments,
the other to enter
a new comment

63. Ratings example
• Ratings CCA can be applied to any other
content object, applying ratings on it.

64. Application “splitting”
• Large application can be split into
composite applications
• Example : forum
‣ List of forums
‣ List of topics
‣ List of messages

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. 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. 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. 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. IDEs
• Make it easy to package / deploy / test
composite apps
• Apache Sling
• Jahia Template Studio

70. IDEs

71. Q & A

72. Thank you !
telachkar @ jahia dot com
shuber @ jahia dot com