"LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks...
Integration of complex external applications with multi-site CMS implementations: MRM
1. In
feedback,
please
refer
to
this
*mestamp.
20091008-‐11:50am
•
Integra*on
of
complex
external
applica*ons
with
mul*-‐site
CMS
implementa*ons
Ben Peter, Day Ignite Zürich, October 2009
2. Agenda
Setting the scene
Application Integration
Approaches and Selection Criteria
2
Web Clipping in detail
Upstream data in the content domain
Team
4. What applications?
CQ is content centric,
and great for implementing resource oriented applications as
well
4
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
5. Challenges
State
Many applications assume state, either by nature or because of
underlying application architecture
CQ is designed to be stateless
5
Applications that need to share state between them
Managed Content in Applications
Upstream Data in the middle of managed content
6. 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 6
Be able to manage the text on our application’s
“Next step” button from within CQ?
8. 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 8
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?
11. Approaches: UI-Level (Pop-Up, iframe)
✦ Immediately rejected
✦ Unsatisfactory user experience
✦ No formal approach for shared model possible
✦ Search engine optimization malus
11
CQ
App
Server
13. 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.
13
✦ 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
Port
let
14. Approaches: AJAX
CQ
UI and App Content Assets 14
Application Logic & Data
App Server
15. 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 15
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)
UI and App Content Assets CQ
Application Logic & Data
App
Server
17. 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 17
✦ 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 CQ
User Funnel API
to services.
App Code
✦ This design is comparable to the Model1
Architecture for Servlet and JSP applications.
19. 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. 19
✦ 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.
20. 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. 20
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)
21. Evaluation: CQ5 integration vs Flow and State
CQ5 Integration:
• JSR-286 can use Portlet
integration
• AJAX through Embedded JS
• CQ5 through Page Components
• Clipping through HTTP subrequest
Page Flow, State transitions
21
• JSR-286 and CQ5 direct restricted
to Model 1
• AJAX can use application CQ5 Integration
controller
• Clipping can follow traditional
MVC patterns
JSR-286
AJAX
CQ5 Direct
Page Flow & State Transitions
Web
Clipping
22. Evaluation: Look & Feel vs Links & Navigation
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
22
• JSR-286 and CQ5 direct:
Programmatic
• AJAX: Mixed Content + JS
• Clipping: URL convention Look and Feel
JSR-286
AJAX
CQ5 Direct
Links and Navigation
Web
Clipping
23. Evaluation: Delineation vs Skill Requirements
Delineation:
• JSR 286 offers standard API
• AJAX requires controller in Frontend
• No delineation with direct CQ5
integration
• Physical delineation for Web Clipping
Skill Requirements:
23
• AJAX: Few experts that combine JEE
and AJAX skills
• JSR-286: new standard, few experts
• CQ5: CQ5 experts required
• Web Clipping: Standard Approach
Delineation
JSR-286
AJAX
CQ5 Direct
Skill Requirements
Web
Clipping
24. Evaluation: Model Access vs Service Access
Model Access:
• Uniformely through Beans
• AJAX must use JS variables
Service Access:
• OSGI-Adapter for JSR286 and CQ5
direct integration
24
• Resource Servlet + Adapter for
AJAX
• Direct access or Adapter for Web
Clipping Model Access
JSR-286
AJAX
CQ5 Direct
Service Access
Web
Clipping
27. 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! 27
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
28. 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
29. 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 29
placeholder
CSS is globally defined
31. Webclipping: Operational Aspects
Publish and Author both use the same JEE Server
JEE Server should be physically independent from Publish and Author
(stability, scalability) Publish
Webclipping can leverage Proxy between CQ and JEE application
Reverse Proxy (bypass) 31
Webserver
JEE
Author
33. 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 33
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?
34. 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 34
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….
35. 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 35
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
36. Team
Benjamin Peter Jeff Gilliard
Senior IT Consultant, MRM Worldwide Andy Jacobs
Frank Ladner
Karsten Lauth
Uwe Wardenbach
Heiko Maass 36
Beratender IT Architekt
John Mozayani
Kai Müller
Robert Prech Timo Münkenwarf
Senior Software Engineer, namics
