•  

Integra*on  of  complex  external  applica*ons  with  mul*-­‐site  CMS  implementa*ons  

Ben Peter, Day Ignite Zürich, October 2009

In  feedback,  please  refer  to  this  *mestam

p.  20091008-­‐11:50am  

Agenda   Setting the scene

 Application Integration

 Approaches and Selection Criteria

 Web Clipping in detail

 Upstream data in the content domain

 Team

2

Setting the Scene 3

What applications?

 CQ is content centric,

and great for implementing resource oriented applications as

well

 But what do you do about applications like….

 “Phone and Plan Advisor” on a telco website

 “Meal Planner” on a canned goods website

 “Book a flight” on an airline’s website

 “Build your own vehicle” on an automotive website

4

Challenges

 State

 Many applications assume state, either by nature or because of

underlying application architecture

 CQ is designed to be stateless

 Applications that need to share state between them

  Managed Content in Applications

  Upstream Data in the middle of managed content

5

So, what do we do to…  Have a “Build your own vehicle” on our CQ enabled

website?

 Be able to show a flight schedule on a content page

 Be able to manage the text on our application’s

“Next step” button from within CQ?

6

Approaches and Criteria

Application Integration

7

Evaluation Criteria   Integration with CQ5 content model

Applications are embedded in content pages that provide layout, navigation and surrounding content.

Consider: placement and arrangement, editorial control

  User Experience / Look and Feel Consider: uniformity of the UI and user experience, reuse of global resources (e.g. CSS)

  Links and Navigation CQ5 and Applications each have their own URL patterns / addressing schemes.

Consider: links from apps to content, links into apps (including “deep links”, initiating state), links from the application to

itself

  Page Flows and State Transition Applications need the capability to implement their own page flows / state models without changing the CQ page

  Shared Model Access Applications and CQ need to share context through a model (e.g. brand, region, market, language). How well can that be

achieved?

  Service Access How well can required services (SOAP, REST, others) be accessed?

  Delineation Can applications be developed, tested, and operated independently of the WCMS implementation?

  Required skill sets / complexity How long does it take, and are the required resources available?

8

Integration Approaches Considered

A.  UI-Level (Pop-Up, iframe)

B.  JSR-286

C.  AJAX

D.  Directly in CQ5

E.  Webclipping 9

Confidential and Proprietary Information of MRM Worldwide

Approaches: UI-Level (Pop-Up, iframe)

CQ

App Server

10

Approaches: UI-Level (Pop-Up, iframe)

✦  Immediately rejected

✦  Unsatisfactory user experience

✦  No formal approach for shared model possible

✦  Search engine optimization malus

CQ

App Server

11

Approaches: JSR-286

CQ

Portlet

12

Approaches: JSR-286

✦  The Application’s UI is created as a Portlet (Portlet-API 2.0)

✦  The controller in this case is the portlet itself and individual views are usually JSPs

✦  Requests are routed to the controller by CQ. The controller wraps results in request beans

and dispatches to the appropriate view.

✦  State transitions are propagated through HTTP Submits and require a page reload.

✦  allows linking back to the same page

(render parameter + resource URLs)

✦  No support for complex state models.

✦  Access to services is handled through OSGi integration.

CQ

Portlet

13

Approaches: AJAX

CQ

App Server

UI and App Content Assets

Application Logic & Data

14

Approaches: AJAX

✦  The application UI is created as a combination of Javascript controls. These can be

intermixed with content.

✦  State transitions of applications are implemented as asynchronous XmlHttpRequests. No

page reload is required for state transitions in applications.

✦  Model access and service access are similar in this approach. Both use HTTP Requests for

Resource URLs that live in the same web context but potentially different web

applications.

✦  No separation of views and controllers.

✦  Services need to be publicly exposed

(browser needs to access the service) CQ

App Server

UI and App Content Assets

Application Logic & Data

15

Approaches: Directly in CQ5

CQ

Component Template

Code

Use

r Fu

nnel

API

App

Code

16

Approaches: Directly in CQ5

✦  UI is composed of several page components.

✦  One component acts as the front controller (state controller).

✦  Other components represent views for each application state.

✦  Model access:

✦  Either apps deduct context from JCR context

✦  Or requires session in CQ

✦  Front controller can augment the model by creating request-level beans shared between

components of a single application.

✦  The CQ5 OSGi model is used for access

to services.

✦  This design is comparable to the Model1

Architecture for Servlet and JSP applications.

CQ

Use

r Fu

nnel

API

App

Code

17

Approaches: Webclipping

CQ

App Server

18

Approaches: Webclipping

✦  Web applications are created using traditional technologies (like Struts or other MVC

frameworks).

✦  A CQ5 component includes the application through a subrequest.

✦  URLs for submits and other links need to be redirected to the enclosing content page, and

any parameters need to be maintained in this process.

✦  State transitions are communicated through page reloads (but AJAX is still possible).

✦  Embedded applications need to follow some restrictions to be easily embeddable.

✦  Most readily ingtegrateable are applications that deliver XHTML and are formatted through

CSS alone.

19

Evaluation

✦  The portlet solution and direct CQ integration share the same characteristics in the

evaluation criteria.

✦  Access to the model is available in all approaches. Level of complexity for model access is

similar.

✦  Access to services also is similar. Ideally, services should be accessed through an adapter.

Architecturally it is not significant whether that is achieved through OSGi, a resource

servlet or directly.

✦  The AJAX approach will probably offer the best user experience.

✦  Direct CQ5 integration requires CQ5 knowledge in the application developers.

✦  Direct CQ5 integration offers the best integration between content and applications.

✦  Complex state models can only be handled appropriately through AJAX or external web

applications (web clipping)

20

Evaluation: CQ5 integration vs Flow and State

21

CQ5

Inte

grat

ion

Page Flow & State Transitions

JSR-286

AJAX

CQ5 Direct

Web Clipping

CQ5 Integration:

•  JSR-286 can use Portlet integration •  AJAX through Embedded JS •  CQ5 through Page Components •  Clipping through HTTP subrequest

Page Flow, State transitions

•  JSR-286 and CQ5 direct restricted to Model 1 •  AJAX can use application controller •  Clipping can follow traditional MVC patterns

Evaluation: Look & Feel vs Links & Navigation

22

Look

and

Fee

l

Links and Navigation

JSR-286

AJAX

CQ5 Direct

Web Clipping

Look and Feel

•  All offer coherent look and feel •  For JSR-286 and CQ5 direct, a coherent look and feel is integral to the model

Links and Navigation

•  JSR-286 and CQ5 direct: Programmatic •  AJAX: Mixed Content + JS •  Clipping: URL convention

Evaluation: Delineation vs Skill Requirements

23

Del

inea

tion

Skill Requirements

JSR-286

AJAX

CQ5 Direct

Web Clipping

Delineation:

•  JSR 286 offers standard API •  AJAX requires controller in Frontend •  No delineation with direct CQ5 integration •  Physical delineation for Web Clipping

Skill Requirements:

•  AJAX: Few experts that combine JEE and AJAX skills •  JSR-286: new standard, few experts •  CQ5: CQ5 experts required •  Web Clipping: Standard Approach

Evaluation: Model Access vs Service Access

24

Mod

el A

cces

s

Service Access

JSR-286

AJAX

CQ5 Direct

Web Clipping

Model Access:

•  Uniformely through Beans •  AJAX must use JS variables

Service Access:

•  OSGI-Adapter for JSR286 and CQ5 direct integration •  Resource Servlet + Adapter for AJAX •  Direct access or Adapter for Web Clipping

Web Clipping in Detail 25

Application Integration

Webclipping in detail

  Stand-Alone Applications!

 Addressing resources: bypass URL

  Self-references: base URL

 HTML, CSS, Javascript

 Operational Aspects

26

Web Clipping in Detail

  Implemented as an OSGi Service + CQ5 Component

 Clipping component makes HTTP sub request to Application that should be included

 Relevant Content Context is transported through HTTP Headers

 Country, Language (, Brand, Product Line, Affiliate Program, etc)

 => Multisite capable!

 Clipping Component passes prefix-URL as a header

 Application prepends this prefix to each link generated

 => Application can run stand alone + no rewriting in clipping component

  (Clipping Component can optionally include only the HTML Body)

  Scheme defined for GET-Parameters that the application passes to itself

 => Clipping component needs to extract application parameters and include them in

the sub request

27

Webclipping: Resources and References

How does an application reference its own resources, like images and other assets?

  This should not go through the clipping component (overhead for subrequest)

  Possible solution is a “bypass URL” configured as a reverse proxy on the webserver

that directly points to the application

28

Webclipping: HTML, CSS, Javascript

 Need to make sure HTML and CSS for surrounding content are aligned

 Our approach:

 define HTML for overall page up-front, irrespective of whether it’s application or

content

 CMS team uses surrounding HTML to build templates and components

 Application team uses HTML from application parts and uses surrounding HTML as

placeholder

 CSS is globally defined

29

Webclipping: Operational Aspects

30

Publish

Author

Webserver JEE

Reverse Proxy (bypass)

Webclipping: Operational Aspects

31

Publish

Author

Webserver JEE

Reverse Proxy (bypass)

  Publish and Author both use the same JEE Server

  JEE Server should be physically independent from Publish and Author

(stability, scalability)

  Webclipping can leverage Proxy between CQ and JEE application

 

Upstream Data in the Content Domain

Data Integration

32

Upstream Data in Content

How do we include application data in content pages where required?

Scenario: a flight booking application is available and integrated into an airline website

as described above. Flight schedules can be extracted through the application’s API

(Web Service, whatever).

There’s an “Airports” section on the website with all the airports that the airline’s

flights start from. Next to general information, floor plans, etc, a flight schedule is

shown for each airport.

Challenge: how can we avoid maintaining the flight schedules as content when a

backend system already has that information available?

33

Upstream Data: Approaches Considered

 CQ Component that extracts the information from the backend system on publication.

 Pros: Easy, straightforward

 Cons: Consistency – flight schedules can only be updated if the page can be

published

 View of the web-clipped application

 Pros: Existing mechanism, just another view in the JEE application

 Cons: Performance – although data changes infrequently, a hit is incurred on the JEE

application for each view

 Make data available as Sling resources

This is a variation of the CQ component, but with a different data access model

Same Cons: requires page publish to show new data on flight schedule

hang on….

34

Upstream Data: Gold Approach

 New data in backend application triggers deployment process

 All views required for the flight schedules are pre-rendered at this point

 HTML Fragments

 Deployed in JEE flight booking application

 CQ Component for Flight Schedule writes Server Side Include that points to the HTML

Fragment

 HTML Fragment is included on web server level through SSI

 Reverse Proxy with Cache for these fragments on Webserver, Expiry 5 seconds

  (Don’t let Tomcat serve 100s of requests per second)

 Variation: Prerender JSON, not HTML.

 Does not require SSIs if you don’t like them, but

 Creates a latency before the data is shown, as the browser needs to render it

35

Team

 Benjamin Peter

Senior IT Consultant, MRM Worldwide

 Uwe Wardenbach

Beratender IT Architekt

 Robert Prech

Senior Software Engineer, namics

  Jeff Gilliard

 Andy Jacobs

 Frank Ladner

 Karsten Lauth

 Heiko Maass

  John Mozayani

 Kai Müller

 Timo Münkenwarf

36

Thank you 37