The requirements for modern websites have grown rapidly in recent years. This dynamic is increasingly related to the functionality of the website, which is more often being realized as an interactive communications medium with customers or prospects, as well as to the optimization of the editorial processes.
The requirements with regard to control of this customer communication are becoming more demanding, because consumer expectations are at a very high level.
The demanding customer expects an excellent user experience
.
This term encompasses a multitude of aspects such as good usability, a target group-specific message and delivery of information at the right point in time in the correct granularity.
In addition, the performance of a website is gaining in importance, in user acceptance as well as in aspects such as search engine ranking.
In order to meet the increasingly stringent requirements, an adequate technical solution on the part of the Content Management System (CMS) is necessary. The wide spectrum of user experience requirements makes an unusually flexible architecture of the CMS essential. This particularly applies to aspects that represent the classic oppositional goals, such as:
In order to offer an optimum solution for the respective customer despite these trade-offs, FirstSpirit provides a particularly adaptable architecture, called hybrid architecture
.
The hybrid architecture of FirstSpirit makes it very easy, especially in integration-heavy scenarios, to establish a solution that fits exactly and which takes into account the specific properties and requirements of the website. Experience has shown that a "one-size-fits-all" architecture works only in very simple use cases. As the number and complexity of websites increases, however, the variety of third-party systems to be integrated also increases. Precisely in larger companies, this is a feature that is encountered frequently, because alongside the CMS component, additional systems such as e-commerce shops, enterprise portals, but also self-developed web applications are prescribed and are to be integrated. In such cases, the hybrid architecture of FirstSpirit enables a delicate balance between performance, stability, and maintainability. Most importantly, this balance is customized to the project.
With its hybrid architecture, FirstSpirit follows the rule of:
We understand a hybrid CMS to be a content management system which gives every customer the freedom to choose which elements of a website are fully dynamic and which elements are delivered already pre-generated.
Technically, the two variants mean:
A particularity of FirstSpirit’s hybrid approach lies in the fact that the decision in favor of one variant or another can be established in a fine-grained manner for each element of an individual page. Concrete examples for this type of architecture are explained in chapter Examples for operational scenarios.
With the trend toward more interactive websites, dynamic access to editorial content has a steadily increasing importance. Wherever pre-generation of content is not possible, the CMS content has to be accessed dynamically. Here, "dynamic" means that the content can change for each website user and at any point in time. Any information that is on the website longer than 1 to 2 minutes and is identical for all users (for example, an article in a news portal) is not considered dynamic here, rather as potentially pre-generated. Nevertheless, the dynamic scenarios are increasing, as personalized content delivery can make an important contribution to the user experience.
With the UX-Bridge module, FirstSpirit offers an infrastructure for the requirement of a dynamic content delivery platform. Consequently, the module expands the hybrid approach by adding a standard infrastructure for dynamic content delivery. As a rule of thumb for the two hybrid architecture variants, we can stipulate that:
It is important to note that these decisions are not global for the entire website, but can be made individually for every type of content element (see examples in chapter Examples for operational scenarios).
When using UX-Bridge, it must be decided per project and per (fine-grained) use case whether the dynamization is functionally and technically necessary or logical (see the above discussion of the trade-off between dynamics and performance). Based on this decision, intelligent and use case-optimized solutions can be implemented very easily.
Pure content delivery is insufficient to enable true interaction with the users of a website, even if it is personalized and done in a context-oriented manner. Rather, there are a multitude of use cases where information from the website has to flow back in the direction of content creation / CMS. Examples of use cases for this kind of return channel include user-generated content (UGC) or statistical data with regard to user behavior, which can be reused in a second step to optimize content delivery.
With the aid of UX-Bridge, you can store UGC content and read it back out via a standard path. At the same time, UX-Bridge can be used to allow certain information to flow back directly into the editing system from the website (for example, how many comments an article has received) in order to further process them there appropriately, such as for ranking lists.
The use of mobile end devices to display (web) content has been increasing exponentially for several years. It has now almost become a standard requirement to support a mobile presentation channel for smartphones or tablet PCs alongside a "normal" website. The "Mobile First" approach indeed goes a step further, and recommends that the mobile variant of a website be developed even before the conventional variant. The reasons are that, in the mobile channel, you have to restrict the scope and focus significantly more on the important points, in other words, the content that is relevant to the customer. Furthermore, alongside some technical limitations on mobile devices (for example, screen size), there are also advanced properties such as location tracking via GPS, gesture-based control, changing aspect ratios between portrait and landscape formats or offline capability. These have to be taken into account as soon as the initial design of a website, because they are very difficult to add later without a complete redesign.
By strictly separating content and layout, FirstSpirit makes it very easy to create content fragments that conform to mobile standards such as XML or HTML fragments.
UX-Bridge supplements this approach by adding flexible content delivery infrastructure, which optimally supports the requirements of displaying content for mobile devices. A specific example scenario is described in chapter Mobile news portal.
Modern websites place ever higher requirements on the underlying technical infrastructure.
The quantities of data to be managed are increasing by leaps and bounds because, alongside classic editorial content, increasing amounts of user-generated content (UGC) and statistical data from the website users' behavior has to be managed and evaluated. Saving and managing such large quantities of data is also associated with the term "big data".
The increasing quantity of data is accompanied by a diversification of data types at the same time. Websites strongly driven by editorial content frequently consist of unstructured data, while website data from backend systems tends to be strongly structured (e.g. product information). User-generated content, such as comments or evaluations, is usually structured very simply and flat. Dependencies or relationships (who viewed what, who knows whom, etc.) reflect an additional type of user data. This "social graph" is a particularly important source of information for user interaction in online communities. An additional use case for relationships between content elements is the so-called "semantic web". Contents are placed in relation to each other there by explicitly modeling connections, such as for improved search options. For this reason, new types of data storage will play an ever-greater role in the future. These include NoSQL or graph databases.
Along with saving editorial and user-specific data, evaluating this data is becoming more and more important. The trend for data analysis is trending increasingly towards realtime reporting. Increasingly, methods from data warehousing and business intelligence are being used to arrive at the relevant analysis.
The mentioned constraints must be taken into account when drafting future-compatible architecture for a website:
It is worth noting that classic content management repositories were not designed for these extensive requirements at all. From the trade-offs of the requirements, it is apparent that a "one size fits all" approach for the persistence of data is not feasible over the long-term (see chapter Hybrid architecture).
FirstSpirit UX-Bridge therefore follows a new approach: The UX-Bridge architecture enables a flexible selection of data storage (persistence) for dynamic access, depending on the functional and technical requirements (see chapter Polyglot persistence).
UX-Bridge was designed from the beginning so that the component can readily be used in the cloud without issue. Aspects such as
are good indicators for operating UX-Bridge in a cloud infrastructure such as Amazon. The same is also true for operating the complete website, and of course, for the FirstSpirit editing system as well. Like all architecture variants, this is an optional possibility which has to be checked for suitability in the respective customer and project situation.
Alongside dynamic delivery of editorial content to the website, transferring and forwarding content to third-party applications is an important implementation scenario for UX-Bridge.
Examples of this use case include:
While the FirstSpirit editing system functions as a content-integration platform for the backend, UX-Bridge takes on this role on the live website.
UX-Bridge is an extension of the classic, pre-generated FirstSpirit architecture. In contrast to a "fully dynamic CMS", FirstSpirit assumes that the content is compiled in the editing system (backend) and (in many cases) is provided with a suitable target layout as part of what is termed "generation". The results are then, finished HTML pages, for example. Then the generated files are transferred (deployed) to the live system, such as a web or application server. FirstSpirit serves as the content integration layer for editorial content and various connected backend systems (see figure FirstSpirit architecture).
As part of the hybrid architecture, UX-Bridge expands FirstSpirit by adding dynamic content delivery using a standard medium. Other (UX-Bridge-free) alternatives to dynamic content delivery are, incidentally, also expressly possible. First, however, a review should be carried out to determine whether or not a standard-based approach such as UX-Bridge would be more beneficial.
Unlike the usual scenario, in the UX-Bridge architecture, those content elements that are to be read out dynamically via a web application are not stored on the web server as finished (HTML) files.
Instead, what is called a live repository
takes the relevant data from FirstSpirit and forwards it to the dynamic web applications (see figure Pre-generation in combination with UX-Bridge).
It is important that both the approaches of pre-generated files (left side of the graphic) and live repository (right side of the graphic) are usually used in combination with each other (see figure Pre-generation and dynamics).
In this way, in a news portal, the normal press release can be pre-generated entirely statically (as a finished HTML fragment), while on the same page, a Top Rating Widget in the sidebar shows the press releases that have been rated the best "live" (bordered in blue in the illustration).
The hybrid architecture of FirstSpirit enables any desired mixture of such pre-generated and completely dynamic content.
To stay with the news scenario described above, then the website will be updated via the following steps:
The last workflow step consists of the deployment of the press release, which can be further subdivided:
After updating the content, a website user calls up the press overview page, which contains the latest message as the first link. Clicking on this link opens the detail page just updated (see figure Pre-generation and dynamics). To the right, in the sidebar of the page, is a dynamic WebApp, which takes up contact to the live repository at the time of the request and reads out and shows the Top News.
The architecture does not prescribe the technical mechanisms (for example, via which web framework) with which the WebApp reads out its content from the live repository. Here, any fitting frameworks and protocols can be used.
Now that the mechanism of the content update with UX-Bridge has been outlined, this chapter will explain the technical details of the module more closely (see figure UX-Bridge in detail).
On the live side (the presentation layer), UX-Bridge consists of three components:
UX-Bus forms the central infrastructure component in order to distribute content from FirstSpirit into one or more live repositories.
The reference implementation of UX-Bus is technically based on ActiveMQ (see http://activemq.apache.org/
).
At the same time, UX-Bus can also be used to provide third-party systems with relevant FirstSpirit content (for example, a search index or a recommendation engine).
A third use for the UX-Bus is the construction of a back channel from the website in the direction of the FirstSpirit backend (see chapter Connection to the customer through interaction).
UX-Bus forms the central integration component on the live website (see chapter Content integration platform), with which FirstSpirit can interact with the repositories and WebApps, but also with which the WebApps can interact with each other. With the aid of UX-Bus, all participating components can exchange data and events.
Technically, UX-Bus is based on Message Oriented Middleware (MOM).
In this way, the UX-Bridge components are only loosely coupled to one another.
Simultaneously, scalability is guaranteed through asynchronous communication and the use of queues.
To do so, the UX-Bus reference implementation uses ActiveMQ (see http://activemq.apache.org
) as a message broker and Apache Camel (http://camel.apache.org/
) for the routing and conversion of the messages.
The live repository is a data storage component which is filled by FirstSpirit and read out by web applications. Here, an important paradigm of the UX-Bridge architecture is: The type and number of repositories is not prescribed, because different repositories are differently suited based on task type (see chapter Polyglot persistence).
In many cases, it can also make sense to fill the live repository not exclusively from FirstSpirit, rather also from the website. This is, for example, relevant when administrating user-generated content (UGC). In the live repository, FirstSpirit Content (for example, press releases) is linked with UGC (for example, evaluation of the press releases).
Choosing the "correct" live repositories is an important architecture decision within the project. There are always two important questions to answer in the planning phase of a project:
In general, UX-Bridge does not make any firm specifications here, since various criteria have to be considered for the purpose of a delivery infrastructure suitable for the task:
These are all questions that have to be asked before selecting a repository. They should be answered in order to make a decision on this basis.
For an initial overview, we list some common kinds of repositories here:
With the described selection of a suitable repository for specific use cases, it is entirely possible that even within a project, multiple, different repositories are used in order to implement a solution suitable for the task. This architectural approach is also called the "polyglot persistence" strategy. This term stands for a simple approach:
Simultaneous use of different kinds of persistence is expressly permitted here for data, as long as it makes sense technically.
For more details on the topic of polyglot persistence, refer to: http://martinfowler.com/articles/nosql-intro.pdf
The UX-Bridge follows precisely this approach, since the technical requirements determine the selection of the specific types of persistence (also refer to chapter Mobile First).
To answer the question of which scenarios it makes sense to use the UX-Bridge in, following are some practical examples. To support viable architectural decisions, close attention is paid in this relation to which aspects are dynamized and which are logically pre-generated. Selection of a suitable repository is also discussed for each use case.
Let us reconsider the news scenario from chapter Architecture overview of UX-Bridge. A website has numerous messages that are administered via the FirstSpirit data sources. The website has news overview pages (with the latest 10 news items on the first page) and news detail pages (see figure News scenario). The detail pages have not only the press release (red border), but also a top news widget (blue border), which dynamically depicts the top news based on certain criteria (highest-rated, etc.).
The website requirements are:
Requirements a. and b. can be met by generating static HTML pages from FirstSpirit via the standard mechanisms. The UX-Bridge is very well suited for requirement c. (see figure Hybrid news scenario).
In this case, a NoSQL database (for example, MongoDB) is selected, in which the relevant (that is, dynamically displayed in the teaser) part of the news is saved, as well as the UGC for comments and ratings. Here, the NoSQL-DB is preferred to a classic relational database, since the UGC data has a very simple structure and the database offers particularly easy access via REST-API. Without the UGC part, a relational database would also be a good option.
A stand-alone web application is developed here with an MVC web framework (here, Grails) in order to read the news and manage (read+write) the UGC.
The choice in this example was Grails (see http://grails.org
), since it supplies finished plugins for access to NoSQL DBs and very efficient application development is possible for the described use case.
Additionally, with Grails it is easy to make JSONP available via a REST interface.
The dynamic news teaser box is directly linked into the static news pages via JavaScript. Each time a page is called up with AJAX, the box calls up the Grails web app and incorporates the results into the website.
State-of-the-art websites frequently have to be equipped with a real-time update. This means the contents are updated without the website user having to call up the page again (manually).
Technically, the same architectural approach can be used as in the previous chapter. The only addition needed is a polling mechanism in the news widget. In this case, the widget regularly (every x seconds) asks the news web application via AJAX whether new data for the current view is present. If it is, the widget downloads the new data via AJAX and updates itself. Alternatively, a pull mechanism can be used, for example, via web sockets.
In the product configurator example, a complex web application has to be developed that enables a website user to personally configure a product consisting of various versions and features (such as a car). The website essentially consists only of this application. The complete frame, that is, the layout and the content from the header and footer fields, should come from CMS. It should also be possible to fully maintain all product information (versions, features, etc.) by editing it with FirstSpirit.
Thus a central element of the website is the configurator web application, which was initially developed independently of FirstSpirit. Since the web application is based on a more complex data model, a relational database is selected as the repository in this case. Also relevant for this selection is the fact that state-of-the-art web frameworks automatically generate a relational model suitable for the object model of the web application, which enables very efficient development.
However, coordination with the FirstSpirit developer is necessary when defining the data model in the live repository, so that the structure of the FirstSpirit data sources can also be mapped to the desired repository model. The mapping, in turn, is implemented in the repository adapter, which either a web developer or a FirstSpirit developer can take over.
This yields the following architecture (see figure Product configurator).
FirstSpirit generates the suitable HTML fragments for the frame of the web application (header/footer) either once or cyclically. The web app includes the generated fragments whenever called up; otherwise it works only on the live repository (here, a relational SQL database). Each time product data is changed in FirstSpirit, the UX-Bridge generates the appropriate changes in the product database.
A branch search is a popular use case for an integrated web application that is to be linked directly into a website maintained by editors. The input form is rather simple (for example, zip code or address), as is the results list (list of the nearest branches).
To be able to embed the web application at any location in the website (for example, in a sidebar on the homepage), a useful development tool is a JSP-Taglib for visualizing results and a suitable Java servlet, which maps the actual search logic (see figure Embedded web app).
In this case, FirstSpirit generates JSP files that contain editorial content, the search form, and the presentation of results as JSP logic.
A NoSQL database (MongoDB) is selected as the repository here, since this has ready-made mechanisms for searching the surrounding area (geospatial). The search servlet addresses this geographic service directly via the MongeDB-API, while the necessary geographic data is populated by editors directly via FirstSpirit (for example, by integration of Google Maps).
The application logic within web applications is very frequently associated with the search topic. In addition to a normal full-text search, there is often the desire for a structured search, that is, the objects to be searched for have a quantity of attributes that will be used in filtering, possibly even hierarchically for a drill down.
A specific use case is, for example, the search for a contact person on the e-Spirit AG website (see figure Search for contact persons).
Every contact person has attributes there, such as region
, branch
, or contact level
.
With this kind of application, it is advisable to use an index as live repository (such as Lucene or Solr), particularly if there are very large amounts of data that have to be searched through extremely quickly (see figure Index-based repository). If there is new or changed content, FirstSpirit updates the index of the Solr server directly and thereby always keeps this consistent with the content on the website.
In this example, the other architectural components are identical with the branch search. The web app talks to the live repository via the Solr-API to answer the search requests.
At this point it is already fairly clear that it makes sense to use UX-Bridge as a technical basis for "higher-quality" modules, such as Enterprise Search. In future versions of the FirstSpirit run time modules, this path will be pursued more.
Making content available on mobile devices is a use case that is encountered with increasing frequency. In this example, a mobile news portal has to be drafted that transfers the news maintained by editors to a smartphone app. Important functional requirements here are:
An intelligent solution for implementing an offline-capable content app can be seen in figure Mobilization via UX-Bridge.
The NoSQL database CouchDB is used here as content repository (see http://www.couchdb.org/
).
The great advantage of this architecture is that the content synchronization (which is a complex topic) occurs completely through the CouchDB.
For this purpose, a local/mobile version of the CouchDB is used on the smartphone that has appropriate synchronization capabilities.
Thus there is no need here for complex programming of the synchronization logic.
This architecture is a good example of how skillful selection of the content repository frequently leads to a reduction of implementation effort.
Finally, when considering these examples of applications, you can see that different applications also mean different architecture variants.
In each case, the UX-Bridge provides the necessary flexibility to be able to implement a suitable solution in very different scenarios.
In the next chapter, possible architecture variants will be classified again in a different way. In doing so, new variants that were not in the examples described will also be mentioned.
There are various existing architecture variants involving web applications on which the web server accesses UX-Bridge. The usual variants are summarized again briefly and categorized in this chapter.
A very lightweight variant to map fairly straightforward web applications is the implementation of a JavaScript logic, which runs entirely within an HTML page in the browser (see application example in chapter News scenario including User-generated Content (UGC)).
Logical operational scenarios are:
Server-side dynamics make sense whenever more complex application logic is necessary or when security plays a particularly important role.
There are various sub-variants of this application category, in which additional variants are certainly conceivable, alongside the listed types.
The seamless integration of logic from the server is done classically via Java Server Pages
(JSP) in a Java context.
In the most simple variant (JSP Model 1), the JSP code (or the JSP Taglibs) is integrated directly into the page.
Logical operational scenarios are:
The use of Model View Controller
(MVC) frameworks lends itself to more complex web applications with complicated server-side logic.
This approach makes it possible to develop applications that can be maintained and expanded readily.
Logical operational scenarios are:
The portal technology provides a standardized infrastructure in order to integrate individual web applications into a website in the form of portlets, independent of other applications. In addition, any editorial content can be expanded, which likewise is integrated via (content) portlets.
This approach is particularly interesting, as FirstSpirit already provides finished integrations into known portal servers (SAP Netweaver, IBM Websphere Portal, Microsoft Sharepoint or Liferay).
The use of a portal server was a basic architecture decision, which must be made from various viewpoints. If you have decided in favor of a concrete portal server, however, all advantages of a standardized integration platform can be used.
Alongside development of your own applications, the more frequent use case is that existing third-party applications have to be provided with editorial contents, which are to be configured and controlled editorially from FirstSpirit.
Concrete examples for these types of applications are:
For each of these types of applications, it is to be decided on the basis of the technical requirements whether a pre-generation of appropriate HTML/XML fragments is sufficient, or whether UX-Bridge should be used alternatively or supplementally.
When using UX-Bridge in the concrete project, there are frequently recurring questions, which are answered in the following.
Operating UX-Bus on the FirstSpirit server is technically possible. In doing so, ActiveMQ is operated on the FirstSpirit server in integrated Jetty. To the extent that UX-Bus is only used to fill the live repositories, this scenario should be sufficient for most use cases. If UX-Bus has to be highly available, then UX-Bus is to be decoupled from FirstSpirit.
Additional notes on the architecture can be found in our UX-Bridge installation manual.
Sizing for ActiveMQ is largely dependent on the required availability, which can be achieved through suitable clustering and failover mechanisms.
An additional factor is presented by the number of expected messages per second.
For more reliable evidence, a performance test should be carried out in the project.
More precise notes can be found under http://activemq.apache.org/performance.html
.
Configuration recommendations can be found in our UX-Bridge installation manual.
The core of UX-Bridge presents the messaging infrastructure, based on ActiveMQ.
ActiveMQ was developed especially for high availability scenarios.
More precise information on error tolerances and clustering can be found in our UX-Bridge installation manual.
http://activemq.apache.org/support.html
Here, we differentiate between two scenarios:
Polyglot Persistence
approach can be used to write the content via UX-Bridge to a search index as well (see chapter Structured search for a contact person).
This document is provided for information purposes only. e-Spirit may change the contents hereof without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. e-Spirit specifically disclaims any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. The technologies, functionality, services, and processes described herein are subject to change without notice.
[1] The described trade-off in the repository properties is also called the "CAP theorem" (http://en.wikipedia.org/wiki/CAP_theorem
).