A Zend Architecture presentation

  • 1,677 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,677
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Only Home and Java are “connected” to content
  • Clicking “Java” in the side bar, loads the Articles and News with news items for that channel. Note how the items in the Articles list changed when navigating from “Home” to “Java”.
  • Both the “Articles” and “News” section are live, i.e. queries to retrieve content on demand.
  • Client side AJAX (Zend_Dojo) used to display the xml data that is backing the display in a tooltip upon mouseover
  • Clicking on the link for news items in either Articles or News will display the article content which it retrieves dynamically.
  • Client side AJAX (Zend_Dojo) used to display the xml data that is backing the display in a tooltip upon mouseover
  • Zend MVC. The demo uses two controllers. MainController handles all page navigation. CdsProxyController handles XmlHttpRequests (AJAX) client content requests Demo uses CdsModelMock which reads xml documents out of the local file system. CdsModelImpl can be swapped in via cds.ini. CdsModelImpl is implemented based on Cds spec documents, but has not been tested. All page fragments are static html copied from http://ba.v3.ddj.com except sidebar, articles, news, and article content. The controller determines which fragments to include on the page for the request. Zend_Navigation via navigation.xml is used to control navigation for the site.
  • DDJ is the default Zend Framework module generated by zf tool. CDS is a resusable Library for all CDS content driven sites built using Zend Framework
  • Each site will consist of one or more Zend Modules Each cross cutting functionality will be developed as a Library. A Site may choose which Library components to include (a la cart)
  • The Pages defined in the Navigator will be custom classes that extend Zend_Page which will get instantiated using the metadata in the Navigation config. The Controller (and ControllerPlugin) will get the requested Page from the Zend_Navigator and loop over the defined Sections: determine if the user has permission to the section check the cache build the appropriate Content fetch render view Cache fragment Once all the Sections have been processed, the controller will render the Page’s layout Specialized subclasses of Section (e.g. AdSection) may be used to add additional metadata or otherwise implement specialized behavior.
  • CDS and MDS data can be cached to minimize cost of making service calls across physical boundardies. Full pages can be cached. This type of caching is limited to static pages. Page Fragements (i.e. individual Section outputs) can also be cached. The cache parameters (such as expiration) will be tailored based on the nature of the data for the section. For example, the expiration of Sidebar data may be higher than that for Featured Articles because they change less frequently. APC and Memcache do not require commercial licenses while Zend Platform does. APC caching is more performant than memcache, however, APC cached data cannot be shared across a cluster of servers (i.e. each have their own local cache).
  • The ServiceProvider will intercept resource requests. It will check for a token in the request; using phpCAS it will attempt to validate the token against the CAS server. If a valid token is not on the request, it will redirect the user to the loginPage. If there is a valid token the request will be dispatched to requested Controller.
  • ControllerPlugin will invoke MdsModel to fetch UserProfile information from MDS Service. PolicyAgent will map UserProfile information into Zend_Acl definitions. Widgets that are not authorized will be removed from Page definition in the Request (i.e. the Controller will never know that they were) UserProfile and Acl information will be put in the data cache.
  • AdWidget will contain the logic (ported from existing code) for deriving the specific params to use for the section. The ads javascript with params will be embedded in page section.
  • UserProfile and Acl information will be added to all requests via the PolicyAgent ControllerPlugin. This information will be available to determine if the request is for a potential lead generating resource and if the user has agreed to share their information. If the conditions are met, the service will create a lead via the MdsModel.
  • The jive web services APIs (REST or SOAP) can be invoked by the controller or by javascript in the client (as seen in the demo for CDS web services)
  • Much of a web site’s performance under load is determined by the server hardware, network, and application servers. Load Testing must be performed early to gather empirical data on foundation design in order to identify performance issues during Architectural Proof of Concept phase rather than during Deployment phase. Performance baseline must be established and regression tests must be performed throughout the development and the results compared to the baseline.
  • The chosen site will be used to demonstrate and test the “Foundation Libraries”. It may not result in a production ready site, however, the initiatives will result in production hardened “Foundation Libraries”.

Transcript

  • 1. Zend Architecture Demo Overview
  • 2. Agenda
    • Demo
    • Demo Application Architecture
    • Future Application Architecture
    • Note: Design and Implementation level detail are available in separate presentation
  • 3. Demo – Sidebar
  • 4. Demo – Sidebar
  • 5. Demo – Articles/News
  • 6. Demo – Articles/News
  • 7. Demo – Article
  • 8. Demo – Article
  • 9. Architecture – Overview
  • 10. Modular Design
    • DDJ (“default” Zend Module)
    • CDS (Library)
  • 11. Future
  • 12. Modular Design
    • Sites (Zend Modules)
    • Foundation Library
      • CAS
      • CDS
      • MDS
      • Jive
      • Omniture
      • Adserver
  • 13. Future DynamicPage
    • Extend Zend_Navigation and Zend_Page to add additional metadata
      • Page Layout
      • Sections
        • Content Service Definition
        • Fetch strategy (server or client)
        • Caching parameters (on/off, expiration, etc.)
        • ACL
        • View Script
  • 14. Future Caching
    • Opcache (APC or Zend Optimizer+)
    • Front End Cache
      • DataCache
      • PageCache
      • Page Fragment Cache (output cache)
    • Back End Cache (APC, MemCache, Zend Platform)
  • 15. Future authentication
    • ServiceProvider (ControllerPlugin)
    • phpCAS
    • loginPage
  • 16. Future authorization
    • ControllerPlugin
    • MdsModel
    • PolicyAgent
    • Zend_Acl
  • 17. Future adserver
    • AdWidget (subclass of Widget)
    • Same javascript in client
    • Calculate section specific params to use in javascript.
  • 18. Future leads
    • UserProfile
    • Acl
    • LeadService (ControllerPlugin)
    • MdsModel
  • 19. Future jive
    • JiveModel Interface
    • JiveModel REST Impl (or SOAP)
  • 20. Future Scalability
    • Design Deployment Environment
      • Load Balancing
      • Clustering
      • Caching implementation (APC and/or memcache)
      • Apache Performance Tuning
    • Load Testing
  • 21. Next Steps
    • Roadmap for expanding the “Foundation Libraries” from Demo to Future
    • Determine scope of initial project
    • Choose site
    • Establish contract for initial project