Architecture Guide Jahia EE v6.1

Transcription

1 Documentation Architecture Guide Jahia EE v6.1 Jahia delivers the first Web Content Integration Software by combining Enterprise Web Content Management with Document and Portal Management features. Jahia April route des Jeunes, CH-1227 Les acacias Geneva, Switzerland The Company website The Community website

2 Summary 1 Overview Introduction What s in this documentation? The big Picture UI Components Authentication and Authorization Templates Caches CACHE TYPES THE BROWSER CACHE LAYER THE FRONT-END HTML CACHE LAYER OBJECT CACHES DATABASE CACHES Content Objects Portal Mashup Server File Repository Engines Search and Indexing Administration Spring Integration Event Listeners and rules Jahia request flow Pipelines Import / Export RELATION TO COPY & PASTE Clustering JAHIA BROWSING NODES JAHIA AUTHORING NODES PROCESSING NODES INDEXING SERVER...41 Page 2 of 42

3 1 Overview 1.1 Introduction Jahia delivers the first Web Content Integration software by combining Enterprise Web Content Management with Document Management and Portal features. By leveraging state of the art Open Source frameworks and libraries, Jahia offers a complete solution for developing, integrating, delivering, and managing content across intranets, extranets, and internets with a much lower total cost of ownership than proprietary systems. 1.2 What s in this documentation? This document provides a high-level view of Jahia s architecture, and should help the reader understand the various components of the software, and how they fit together. It may also serve as a basis to understand the source code, as it is available for free. We will present a lot of architectural diagrams in this document, and every attempt has been made to make them both understandable and logical, but it is clear that it is possible to view the sub-systems in different ways. Should you have questions, please do not hesitate to contact us as mentioned on our website ( or Community website ( Page 3 of 42

4 2 The big Picture Jahia has a lot of features, and the main idea is to integrate them in a way that makes sense for its users. The following illustration gives a good idea of the categories of features that are included in Jahia: We will now present all of them, starting from the top, going down: UIComponents: starting with Jahia EE v6.1, Jahia has moved to use the GWT (Google Web Toolkit) AJAX framework, which allows for strong reusability of user interface components. This allows both Jahia developers and integrators to build responsive UIs that work in all major browsers. Caching: in order to serve pages as fast as possible, Jahia includes multiple layers of caches, from the database level all the way up to the HTML level. Theses caches are cluster-compatible and allow for scalability and performance. Cache implementations are also pluggable. Page 4 of 42

5 SSO: Jahia is compatible with all the major SSO implementations, including NTLM, CAS, JEE containerbased authentication, etc. Again this implementation is pluggable through the pipeline mechanism, which we will describe later in this document. WCM: Jahia was born as a web content management system, and therefore this component is the most mature. Features such as direct in-the-page content editing; granular content objects which allow integration with portlets are features that have been part of the WCM since version 2.0. Portal: Jahia is not really a portal server is the strictest of senses, since it offers a lot more customizability that what is traditionally accepted in this field. The back-end supports the full support of the JSR-286 standard, and therefore it is possible to integrate portlets on a page managed by Jahia just as easily as using a regular content object. File repository: Jahia also integrates a JCR (Java Content Repository)-based file repository, which allows users to both publish binary data on their website, as well as access the file repository through various user interfaces or standards (such as WebDAV or Windows Shared Folders). ACLs or Access Control Lists: Jahia features a very granular content management system, which is strongly tied to access control sub-systems. This means that users can finely control who can see what, and make sure that only authorized users have access to secured content. This sub-system is available throughout Jahia and also offers administrators the possibility to control permissions such as administration access, action limitations, etc. Clustering: Jahia allows for cluster deployment, and therefore allows for redundancy and load distribution. This document will look into the communication architecture required for clustering. Search & indexing: at the basis of most content management systems is strong support for searching & indexing. Jahia not only offers this throughout the content management system but also on its embedded file repository. Jahia also offer the possibility to search precisely within families of content objects, as well as offloading of indexing tasks to separate servers. Administration: Jahia features a separate user interface for both server and site administrators, which allows for a clean separation of administrative tasks. These interfaces allows users to control all of Jahia s sub-systems including user and group administration, permissions, deployed templates and portlets, categories, etc The lower layers are not systems included in Jahia but that are necessary or optional and provide the storage and retrieval of information that Jahia processes to work it s magic. Page 5 of 42

6 Database: Jahia supports all major database vendors, including the major open source ones such as MySQL and PostgreSQL. The code architecture is actually not tied to any database, as it uses the Hibernate ORM technology, and integrators or developers could add support for new databases simply by adding scripts for database creation. Filesystem: the file system is required for indexation storage, and optional BLOB and CLOB storage, should the administrator configure Jahia to store large content on the file system instead of the database. The filesystem must be distributed if the Jahia installation is going to be clustered, and it is the responsibility of the file system to properly handle distribution. LDAP: Jahia supports most LDAP servers right out of the box, including OpenLDAP and ActiveDirectory. It is most commonly used with SSO technologies to provide a seamless experience to end-users. For example using NTLM authentication and ActiveDirectory, a Jahia installation can then use the domain authentication that the Windows user enters when logging onto his machine. Page 6 of 42

7 3 UI Components The above illustration describes the various user interface components that are offered by Jahia, as well as the frameworks they rely upon. The basis for all UI components, starting with Jahia EE v6.1 is the Google Web Toolkit. This framework provides all the modern requirements of AJAX-based user interface, as well as the possibility to build new components rapidly and easily. On top of it, Jahia uses the GXT library of GWT components, to avoid re-developing components such as advanced tables, navigation trees, and so on. The tri-panel component is a standard Jahia user interface built on top of the previous frameworks that allows for display of tree-like panels, with children listing and info view. The toolbar component is used for displaying tools on the page that the user can use to either launch other components or trigger other navigation/edition modes. They are similar in behavior to standard desktop Page 7 of 42

8 application toolbars, except that they are also integrated with the context, such as the user s permissions and the current browsing mode. On top of all these frameworks is a full set of user interface components. They range from file management to category management, including other browsing components such as breadcrumbs or bookmarks. Page 8 of 42

9 4 Authentication and Authorization Page 9 of 42

10 Jahia offers the following features in terms of authentication mechanisms: CAS SSO support NTLM support JEE container authentication support Pluggable authentication pipeline that can be easily implemented to add support for more SSO solutions Once the user is properly identified, the authorization part of the framework is composed of: Access control lists on content objects Permissions on any user actions Pluggable user services Pluggable group services Compatibility with LDAP Default storage in database The above illustration shows how the different layers interact, especially the pluggable interfaces. The routing service implementation allows for simultaneous interfaces to both the database and LDAP repositories of users, and more could be added by implementing the service provider interfaces. Page 10 of 42

11 5 Templates Jahia s templating system is quite central to how information is displayed on a page. Templates are regrouped into template sets, which are the basic deployment block. A site can select a template set to use, and template sets may inherit from other sets, much in the same way JARs can contain classes that may override other classes in separate JARs. Page 11 of 42

12 Template sets may contain: Content definition (CND) files JSP templates Themes and skins A template set deployment descriptor (mandatory) Resource bundles Java classes Upon startup, Jahia will detect all the templates that have been deployed into its WEB- INF/var/shared_templates directory and deploy them in the server. In development mode, any update to the template descriptor file will trigger an undeployment/re-deployment of the template set and allow for a rapid development experience for template developers and integrators. As illustrated above, template sets have quite a lot of services available to them: Tag libraries: the aim of Jahia template development is to avoid scriptlets as much as possible, in order to ease maintenance and especially upgrade paths. So the Jahia taglibs are quite extensive, and interact well with the Java Standard Tag Library (JSTL). They provide all kinds of features such as content object querying; UI elements such as toolbars or inheritance-compatible include mechanisms (the Jahia Include tag). Please refer to the template developer guide for more details on these libraries. Inheritance mechanism: in order to avoid having to copy all the templates into a new set just to make a few changes, templates can benefit from an inheritance mechanism that is quite similar to the Java language inheritance. Only the templates that need customizing need to be overridden, all the others can be inherited as such. This is also possible for included files when using the Jahia Include tag, which allows a file inclusion mechanism that is capable of looking up the parent template tree for the file to include if it has not been overridden locally. Deployment: as mentioned previously, template sets can be deployed into a Jahia installation upon startup of the server. It is therefore quite easy to add new template sets when deploying a new installation of Jahia. Once deployed, template sets become available to site administrators that can either use separate template sets on their sites, or re-use a template set between multiple sets. This allows them to guarantee consistency over large number of sites, while still having the possibility to use a completely different set of templates for a specific site. Page 12 of 42

13 Themes and skins: themes are used to give a different look to a template set. An example would be a template set that could have seasonal themes: a winter theme, a spring theme, etc. These themes can then be either enforced by an administrator or selected by the user. Skins offer the possibility to content authors to customize the look of content objects and therefore, while using the same content definition, offer a significantly different look when displaying objects of a same type. Content definitions: Jahia uses the standard JCR content definition format for content definitions, which have been augmented to allow more powerful typing on content. All the definitions benefit from the standard inheritance of definitions, but also allow for extensions such as internationalization, stronger typed content elements, and so on. Page 13 of 42

14 6 Caches Caches are essential to high performing web systems such as Jahia in order to be able to avoid recreating dynamic content under large system loads. In the graph above, we can see the basic architecture of the cache sub-system. All the different cache types are on the top layer, sitting on top of the cache service, which is the provider for cache implementations. Below this service, various cache implementations may be plugged, and some of these such as the Reference Cache implementation may depend on other Jahia services such as the Cluster service that provides messaging throughout the Jahia cluster installation. Page 14 of 42

15 6.1 CACHE TYPES The cache types all use the same cache service that is responsible of providing cache implementations. In Jahia 5, we have introduced in service pack 4 the possibility to provide different cache implementations for different cache types, making the system extremely flexible in terms of configurations. For example it is possible to use the EHCache implementation for the front-end HTML caches and use the ReferenceCache implementation for the rest of Jahia s caches. This is the default configuration for Jahia 5.0SP4 and Jahia EE v6.1. It is also of course possible to integrate other cache implementations by plugging into the service provider interface (SPI) that Jahia provides. Page 15 of 42

16 Jahia uses multiple cache layers to optimize the performance of page delivery: the browser cache front-end HTML caches object caches database caches Each of theses cache layers plays a different role in making sure values are only computed once. 6.2 THE BROWSER CACHE LAYER While not integrated in Jahia but in the browser, the browser cache plays a critical role in guaranteeing good performance for the end-user. For example, Jahia s usage of the GWT framework makes it possible for AJAX source code to be aggressively cached in the browser cache, therefore making sure we don t reload script code that hasn t changed. Jahia also properly manages the browser cache to make sure it doesn t cache page content that has changed. It also controls expiration times for cached content, so that the browser doesn t request content that is rarely changed. 6.3 THE FRONT-END HTML CACHE LAYER Historically, Jahia has had many front-end HTML cache layer implementation. The first was the full-page HTML cache. While very efficient when a page was already available in the cache, it didn t degrade very well for pages that had a fragment of the HTML that changed from page to page, or from user to user (for example by displaying the user name on the page). In Jahia 5 we introduced the ESI cache server, which added the possibility to cache fragments of HTML. This technology required a separate cache server that executed in a separate virtual machine to perform it s magic. While much better than the full-page cache for dynamic page rendering, the ESI caching system suffered from problems with inter-server communication, which was very tricky to get to work efficiently. Also, integrating the ESI cache required good knowledge of the fragment caching model when developing templates, which was an additional burden on integrators. Page 16 of 42

17 Jahia EE v6.1 takes the best of both worlds, by combining the sheer efficiency of the embedded full-page cache with the fragment handling of the ESI cache server. This new cache implementation is called the «Container Cache» and integrates fragment caching at a container level, making the interaction with templates very natural. Template developers usually don t have to add any markup in order to have their fragments correctly cached. Even when they need to control the fragment generation, this is much easier to do than in previous versions of Jahia. The Skeleton Cache is also an HTML front-end cache that basically caches everything around the fragments, and by regrouping both cache sub-systems we obtain the equivalent in terms of performance to the full-page HTML cache that existed in previous versions of Jahia while retaining the flexibility of a fragment cache. 6.4 OBJECT CACHES The next layer below the front-end HTML cache sub-systems are the object caches. This layer handles all Java objects that represent content objects, users, groups, categories, content definitions, etc. It serves as a layer on top of the database caches in order to avoid reconstructing objects for each model request. This is all handled internally by Jahia and it is only important to interact with these caches if integrators are directly calling Jahia s API to perform object changes that don t automatically update the caches. 6.5 DATABASE CACHES The last layer of caches is the database cache layer that makes sure that only minimal interaction with the database happens. This is important as, database communication requires object (de-) serialization and network communication so the overhead of a database query can be quite substantial. This layer is, in Jahia, completely handled by the Hibernate ORM layer. Page 17 of 42

18 7 Content Objects Jahia s content objects are composed of the following objects: Pages (either content pages, internal links or external URLs) Container lists (lists of containers that all have the same structure) Containers (that contain fields of different types) Page 18 of 42

19 Fields and metadata fields (that may be of different types such as SmallText, BigText, Integer, Date, File reference, etc ) All these objects have in common the following: they may be part of categories they may have access control defined on them using Access Control Lists (ACLs) they are defined using content definitions files (*.cnd) The content definition format is an extension of the Java Content Repository (JCR) standard definition (CND) file format, that adds support for the following features: multi-language values more precise typing of property types resource bundle support for types choice lists and more All the content objects are loaded from the database and the various layers of caches that were previously presented. They are then exposed to the template sub-system so that integrators may build the final rendering using the Jahia tag libraries. Page 19 of 42

20 8 Portal Jahia includes an embedded portal server, which is based on the Apache Pluto reference implementation of the JSR-286 Portlet API specification. The goal of this implementation is to offer support for integrators who need to embed portlets on content pages. This means that any portlet API compliant application may be integrated with Jahia in a few steps. In the above graph we have illustrated the different types of portlets that may be deployed in a Jahia installation. Jahia s content object fields include an application field type that references a portlet, therefore allowing integrators to define where an application may appear in the structured web content tree. Portlets may also be Page 20 of 42

21 categorized and access to them may be controlled using access control lists. These services are built on top of the Pluto back-end and are the same as the ones used on top of content objects. Jahia EE v6.1 also uses portlets internally to perform some of it s magic. These portlets may now include content definitions and render content objects layouts. This makes for re-usable building blocks that may be used to re-use functionality throughout a Jahia installation. The same mechanism is used to built upon the portal server what is called the mashup server. Page 21 of 42

22 9 Mashup Server Introduced in Jahia EE v6.1 is the new mashup server. Recognizing the raise in usage of Javascript integration, Jahia now includes the possibility to define and re-use mashups inside of Jahia-powered websites. The mashup server is built on top of the portal server, and therefore allows for easy deployment of new mashup types, simply by deploying new portlets. In the above graph we have illustrated different mashup types such as Google Gadgets, YouTube videos, HTML & Javascript fragments. These types are actually portlet types that include a content definition that will automatically customize the user interface for mashup configuration & rendering. Site administrators may then build mashup instances that they may categorize, Page 22 of 42

23 control with ACLs, and offer to content authors to use on the section which they are creating. Developers can either package mashups as portlets or simply re-use one of the existing portlets if they fit their needs (the HTML mashup portlet is quite generic and may fit a lot of needs). Mashup instances may also be imported using Jahia s import/export feature. As with any new technology, Jahia will constantly refine this user story to make it even more powerful. Standards for mashups are still under definition at the time of this writing, and of course Jahia will strive to integrate the new possibilities, provided of course they fit it well with our users. Page 23 of 42

24 10 File Repository Jahia s file repository was completely rewritten for Jahia EE v6.1. In Jahia 5, it was based on a strong integration with the Apache Slide library, which was the de-facto open source standard file repository at the time. Since the rapid rise and strong quality of the Java Content Repository reference implementation (Apache Jackrabbit), Jahia EE v6.1 has started including it as its standard file repository and build services on top of it. Actually the integration architecture of Jackrabbit has no strong dependencies to it, but uses the standard JCR API to offer access to multiple repositories. In Jahia EE v6.1 it is already possible to access CIFS/SMB file repositories, and a few other implementations are available in the sandbox repositories that will mature as the need arises (among these are FTP, Alfresco, Exo Platform, Nuxeo connectors). In the above graph you might also notice that the Jahia Content listed available as a JCR provider. This is also new to the Jahia EE v6.1. This is initial compatibility work and is not (yet) the most performance optimal content interface in Jahia EE v6.1, but future versions of Jahia will constantly improve compatibility with the JCR APIs as they evolve. Page 24 of 42

25 On top of the file repository services, different interfaces expose content through various interfaces such as WebDAV, browsing files in templates and Jahia s AJAX UI. On the other side of the repository, integration with a rules engine is used among other things for image thumbnail generation and metadata extraction. This rule engine is also pluggable and can be extended by integrators to perform other specific logic upon repository events. Page 25 of 42

26 11 Engines Page 26 of 42

27 Jahia s engines may be compared to Struts actions. They are blocks of application logic that perform a specific task. Jahia s sub-engines are even smaller blocks, and are used to control interactions with small UI elements such as field editing. The most important engine is the core engine, which is the content page rendering engine, and is called whenever Jahia is asked to display a content page. Other engines are self speaking such as the Login or Logout engines, that simply handle authentication UI and processing. Content editing engines also integrate with the validation framework that allows integrators to define input value validation rules to limit user input. Engines also integrate with Jahia s AJAX UI, and the design goal is that over time all the UI logic will become more and more re-usable, so that integrators may have access to large component libraries to build solutions for customers. This work has already started in Jahia EE v6.1, which introduces re-usable GWT components such as the category picker or the tri-panel file manager. Sub-engines are used by Jahia to display container edition interfaces. As containers may contain any field types, the container edition engine dispatches to the specific sub-engines for the corresponding field type currently being edited. This allows the sub-engine to have control over the UI displayed to edit different types of content. For example the file field that references a file will present a UI that allows a user to browse directories and select a file, while the small text field will simply display a text input field. Jahia resolves the engine to dispatch to by using the /enginename URL parameter. When no value is given, Jahia defaults to the core engine. The string values that are used for engine names are actually declared by the engines themselves. So in the JahiaEngine class, the getname() method will identify a key for the /enginename URL resolution mechanism. Page 27 of 42

28 12 Search and Indexing Jahia s search and indexing subsystem will be presented here only briefly, as it is quite a large sub-system in itself. We have illustrated above the main building blocks of this system. New to Jahia EE v6.1 is the integration of the OpenSearch standard. Jahia may act as both a consumer and a producer of OpenSearch queries. This means that users may for example integrate their browser search box with Jahia and directly input search queries from their browser toolbar. On the opposite side, Jahia can consume multiple OpenSearch providers and present aggregated results for searches on Jahia, Google, MSN,.. all on a single page view. Page 28 of 42

29 On the more traditional web search solutions, Jahia offers tag libraries to search Jahia content either in very basic full text search formats or using advanced search queries. The advanced queries integrate with Jahia s UI components to build powerful value selectors that guide the user when building advanced queries. These UI components are built using Jahia s AJAX framework and are the same ones used to input values in the authoring user interface. Another alternative for querying content objects is to directly build the queries at the template level, which means that the users will simply be viewing the result of the prepared query. This is called container queries, and may be used for example to retrieve all latest 5 content objects within the news content definition, which will in effect present the latest news on the page. Below these front-end technologies are the back-end systems that make all this possible. The Jahia search engine offer the possibility to perform full-text or precise queries on both Jahia and file content, which the container query sub-system is optimized to perform queries for content objects of similar types. The underlying open source libraries that power the searching & indexing are the excellent Compass and Apache Lucene frameworks. They store and retrieve their index information from an underlying file system, but also have other options to store their data in databases or distributed file systems. The standard file system implementation is currently the most production-ready and efficient one, so Jahia comes bundled with this setup. Page 29 of 42

30 13 Administration Jahia s administration user interface is a one-stop place to control all the various sub-systems targeted at either site or server administrators. It allows administrators to perform all kinds of tasks such as : create, update, delete users, groups, virtual sites and categories setup global permissions setup categories and permissions on templates and portlets view internal cache status and flush them setup password policies define site languages setup remote publishing many other things Please check the user s guide for more information. The administration UI is based on a servlet that acts as a central dispatch to a collection of application logic classes that control the UI for the various settings of a Jahia server. It also integrates with the AJAX UI components to offer a consistent experience to Jahia administrators. Page 30 of 42

31 14 Spring Integration Starting with version 5, the Spring framework has gradually been introduced into all parts of Jahia, and is a very strong foundation for building a really solid, fast, flexible and portable server implementation. This means that integrators have multiple options to integrate with Jahia s sub-systems, as they can decide to plug-in to many services simply by using the well-known dependency injection and configuration mechanisms that the Spring framework is appreciated for. The graph above details how the configuration is used to initialize all the various Jahia sub-systems using Spring. As you can see even external libraries such Apache Pluto, Hibernate or Apache Lucene are integrated with Spring, which makes for a powerful server architecture and lifecycle. Page 31 of 42

32 Jahia s experience with Spring has been an excellent one, and despite all the integration there is almost no dependency to this framework that has been introduced, which gives the implementation the freedom to move to the next great framework should the need arise. Page 32 of 42

33 15 Event Listeners and rules Page 33 of 42

34 Actions performed by Jahia users trigger events that may be used to perform custom logic. Jahia allows integrators to register event listeners to add the desired logic when an action is performed. The above graph illustrates how events are propagated through the different sub-systems and how they may be used by developers. The birth of an event is a Jahia action, which could be directly resulting from a user command, a time-based event or another background process. This action will call the event generator to create an event object. This event object will then be passed to the listeners registry, which will in turn call all the registered event listener classes to perform their specific logic. Some of the event listeners are simply proxies to other implementations that may use different logic technologies. This is the case of the Groovy event listener that allows integrators to use the Groovy language to implement event listeners, or the JSP event listeners that does the same for JSP files. Another particular listener is the JCR observation manager that actually bridges Jahia s event mechanism with the standard JCR observation technology. Below this, is the integration with the JBoss Rules observer, that allows integrators to use rules to process events. Page 34 of 42

35 16 Jahia request flow Page 35 of 42

36 The above diagram is an overview of the way Jahia processes a browser request. This serves as a map to orient integrators and developers towards the corresponding sub-systems they may be interested in. The browser request may be directed either towards the Jahia servlet or the WebDAV servlet (in the case of requesting a binary file). In the latter case, this request will then access Jahia s file repository service to validate access to the desired resource and then stream it back to the navigator. In the other case, the Jahia servlet will then be called. Jahia will immediately create a context object called the ParamBean. This object contains all the computed request information, including things such as the requested content page, the current user, the current navigation language, and so on. Internally it uses a pipeline mechanism to resolve the user, and this pipeline is customizable to integrate new user resolution mechanisms. For more information, see the Pipelines section in this document. Once the ParamBean object has been created, Jahia then hands over handling to the OperationManager object, which also uses a pipeline to handle requests. The operation pipeline is also described in the Pipelines section later in this document. The pipeline operations will interact with Jahia services to perform the desired actions, and the result will depend on which engines have been called in the pipeline. In the case of the core engine, the operation pipeline will have constructed all the necessary contextual objects that will give the template developer the content he will layout in the JSP file. Therefore Jahia then dispatches to the corresponding JSP template to perform the layout. Finally the end result is sent back to the browser, and that s it. Of course this is a very simplified example of a request flow but should serve as a good starting point to understand request processing in Jahia. The interaction with the caches has been omitted in order to simplify the explanation of the request processing, but it is clear that integrators will have to take them into account when developing solutions. Page 36 of 42

37 17 Pipelines Page 37 of 42

38 As presented in the previous section Jahia Request Flow, Jahia uses pipelines to offer customizable chains of processing logic. A pipeline is an ordered list of valves that are called in succession. What is specific to the pipeline design pattern is that it is the responsibility of each valve to call the next one. Said another way, this means that a valve can choose whether or not to pass on execution to the next. This is very useful when resolving objects, where we want to continue on searching for an object until we have found it. This is the concept for the authentication pipeline, which is called by the ParamBean object to resolve the user based on the current context. Users may be found using all kinds of criteria such as looking them up in the session if they were previously resolved, through integration with a single-sign on system such as CAS, or using JEE container-based authentication. On the above graph, the lower pipeline is the authentication pipeline and shows the various valves used to resolve users. We won t go here into the details of each valve, but it is interesting to note that this resolution mechanism is customizable through Spring XML files, making it easy for integrators to integrate their own custom valves. The operation pipeline (top part in the above graph) is used by Jahia to offer a pluggable request processing chain. Again the valves may decide to stop processing at any point, which is especially interesting for the frontend HTML cache valves. If the content may be read in the cache, processing may stop at that point and this avoids executing unnecessary operations, making the whole process very efficient. The valve responsible for cache reads in the above graph is called the Skeleton aggregator. Other valves such as the URL history valves are simply used to trace all the URLs requested by a user in order to build up the data for the breadcrumbs view. Integrators might also find it interesting to customize the operations pipeline to extend Jahia s request processing flow. It should be noted that the ordering and placement of valves is very important, and that it is not recommend to change it without a good knowledge of how Jahia works. Page 38 of 42

39 18 Import / Export Jahia s import/export feature is an extremely powerful mechanism for migrating content in very different ways between Jahia sites, or even between Jahia installations. It uses the JSR-170 (or JCR) XML format as a basis for content export, along with other specific files such as file hierarchies for binary data export. All these different files are compressed in a ZIP file that may be used by the import sub-system. This makes it possible to export a complete Jahia installation, a set of sites, a single site or even a sub-section of a site using the same import/export technology. Using these users can migrate content between sites, or even between sections of sites, or also use it to export content to non-jahia systems or import from non-jahia systems. Jahia also uses the import/export technology for its remote site publishing feature. This is basically an export / import triggered by a scheduler. The import/export technology is capable of detecting modified content and will simply update a content object instead of creating a new instance RELATION TO COPY & PASTE While not obvious, the copy & paste feature also uses the import/export technology behind the scenes. This also explains why content may only be copy and pasted between compatible content definitions, as Jahia must know how to map content types between the source and the destination. Linked copies also use the import/export technology when content is pushed to the destination. Page 39 of 42

40 19 Clustering Deploying Jahia in a cluster is a very powerful way of distributing CPU and memory load to handle larger traffic sites. A typical Jahia cluster installation is illustrated in the above graph. Jahia nodes communicate directly with each other through direct messaging, but also access shared resources: a shared filesystem and the database. The filesystem is used for the content indexes, as well as binary content if the server is configured to store it on the filesystem, or in the database if the default configuration is used. The database stores everything else. It is therefore very important to have a high-performance database installation, as Jahia will depend on it to scale well. Jahia can also differentiate nodes in a cluster setup in order to offer more specialized processing. We will review here quickly the different node types. Page 40 of 42

41 19.1 JAHIA BROWSING NODES Jahia browsing nodes are specialized Jahia nodes that only serve as content publishing nodes. They also interact with portlets to render pages. Using this node specialization allows to separate the browsing load from authoring and background processing loads JAHIA AUTHORING NODES Jahia authoring nodes are cluster nodes that can be used to either browse or edit Jahia content. This is the most common usage of Jahia nodes, and therefore it is interesting to have multiple instances of these nodes in order to distribute the load PROCESSING NODES In Jahia, long-running tasks such as workflow validation operations copy & pasting, content import and indexing are executed as background tasks. This way while these long operations are executed, other nodes are still able to process content browsing and editing requests INDEXING SERVER File and content indexation can be a very expensive operation both in terms of CPU usage and memory load. For example, in order to index PDF files, the server must actually execute the script instructions that are contained within the file in order to extract the text content. This requires the execution of a full Postscript-like language, including its memory management and instruction processing, just to extract text content. Indexing large files also requires memory that cannot be freed until the actual extraction has been completed. Indexation is usually considered to be an operation that is not needed in real-time, and therefore can run as a background task. In order to reduce the load on the Jahia servers doing the actual content editing or processing, it is strongly recommended to install a separate content indexing server, especially if the content will contain a lot of typical office files. It is also possible to install multiple indexing nodes, so that there is no single point of failure for this type of operation. Page 41 of 42

42 9 route des Jeunes, CH-1227 Les acacias Geneva, Switzerland The Company website The Community website