0



22Sep2012

Why you should upgrade to Oracle WCS11g… or at least to Fatwire 7.6

Almost in all the  projects I worked this year, I was plagued with legacy Fatwire  versions  that are still around. An outdated version of the software was often a major problem on all the development and the issues I was called to solve. And the worse is that customers often did not feel any need to upgrade.

I discussed so many times the reasons to upgrade at least to  7.6 that... I decide to write this blog post, both to share the wisdom with other,  and both as a reminder for myself to shorten  future discussions on this subject .

Fatwire 7.6 is still largely compatible with  7.x and 6.x: users won't notice any significant difference,  so (unless you have a heavily customised UI) upgrading to 7.6 is mostly painless (except for CAS, see below).  However you get a  number of significant improvements pretty useful for new development .  You can see here and here  the release notes document for 7.6 and 7.5, but in this post I am trying to better explain what they really means.

Upgrading to 11g probably  is the better choice, as I discussed in this blog post, however it somewhat changes the editorial team experience. In this post instead I explain the technical reasons for upgrading to at least to 7.6.

CSDT

Number one reason to switch to 7.6 is CSDT. While I was critical of CSDT in the past (because I do not like the eclipse plugin - I still prefer either Fatclipse or my homegrown alternative fatproject) there is a feature in CSDT (that is similar to my own FatProject code) that is actually working well and it is a much complete solution than FatProject : the import/export feature.

CSDT lets you export an entire web site in XML format, including configurations and content model, and then reimport it in another instance.

Anyone working with Fatwire knows the pain having of multiple developers working on the same server, using ContentServer Explorer to edit pages, and how limited as a version control system revision tracking is. Modern agile development prescribes a continuos integration server. Furthermore, publishing is a tool for deploying content, but it is not great to deploy code.

Just to make a simple example, code has relations (a piece of code to work may require a specific version of another piece of code), but  publishing just doesn't capture this relation, while version control systems does. So publishing template by template is very error prone and lead to inconsistencies between environments. Furthermore code is usually dependent on a specific content model, so it must be kept together.

CSDT gives finally developers freedom from those constraints. Since you can import and export a whole site, you can export it from a shared development environment then import in a JumpStart and use it for development. Furthermore, you can revision control the csdt export , sharing and merging it with other developers. And finally deploy it to the final, production server.

So definitely, CSDT (Content Server Development Tool) is the definitive tool to make Fatwire Development acceptable for a professional developers, used to work in their machine for development,  accustomed to perform merging of others work, revision control the code as a whole, creating automated builds and running tests against the builds.

AssetCache

 Asset Cache has been introduced in 7.6,  it is only vaguely mentioned in the release notes but it addresses a very important problem: improve performances of uncacheable templates caching the assets instead.
Let's define the problem: your site is dynamic enough that many templates cannot be cached. Before version 7.5, Fatwire cache was based on the idea of caching the pagelets, the snippets of html generated by template execution.
This works well as long as the snippets you generate are not too many. But think to a search page, for example: you  may generate way too many different renderings to cache them, so unless you want to fill the cache without any performance gain, you need to leave the search page uncached. And this can be pretty slow.
What it is really needed then it is the ability to cache the Java "pojos", the underlying objects that are created when you render a templates. To better explain what this means, consider the standard call <asset:load name="asset" ...>  used to load an asset in memory for extracting the content.
The "traditional" Fatwire way is to load the asset in a pojo in memory, use it to generate a snippet of html (the pagelet), then throw it away and cache the pagelet. This works well for cacheable template, but uncached templates were a "don't do it" before Asset Cache...
Now, using AssetCache the underlying pojo is no more thrown away: instead it is cached, as it happens in many other  java applications (like those based on Hibernate for example).
This feature lets developers to write uncacheable templates acceptable .... and save their butt when the performance of the site are unacceptable because templates are all uncached (somethings that happens too much often unfortunately) and cannot be cached for many reasons (complex logic, too many parameters, messy design and so on).
So if your site is now unacceptably slow, and you have just discovered that the templates cannot be cached because you passed 20 different arguments including the browser agent and the current date and time, you can still keep your job just recommending to upgrade to Fatwire 7.6 and then enable Asset Cache (and InCache,  see below)... Actually  AssetCache  requires InCache, let's focus on it.

Incache

Incache was introduced with Fatwire 7.5. What is InCache? It is basically just ehcache, the underlying cache used with Hibernate and many other project around. It improves the traditional fatwire cache offering a number of interesting features. From the release notes, InCache, as ehcache, is:

  • Distributed
  • Scalable and High performance
  • No single node needs a complete view of cache
  • Communication via dependencies
  • No shared disk
It is basically a better cache that works distributing the load within different nodes. More nodes can be added when required so it is not limited by the speed of a shared disk and can be scaled up adding more servers. You can learn more here.

Rest API

Fatwire 7.5 introduces also a new API that replaces the obsolete SOAP bases web services API. This means... a lot. This Rest API is pretty verbose, but is it finally allows interaction with the server in XML and JSON, and not only through Form POST.. Using the rest API your web site can be written not only as a static site, but also as an HTML5 fronted calling backend  restful webservices, a design becoming increasingly common. I would say that is the current state of the art since all the new sites includes (and uses) jQuery...

So, if you plan to advance your web site to implement some ajax call using jQuery or similar, of better you want to have code that can also update some assets and not only read them, definitely having the Rest API deployed is a must.

Single Sign On (CAS)

Well, I am not sure if the Single Sign On component (that is actually the open source project CAS) is an advantage... or a liability. It was introduced together with the RestAPI both to protect restful resources and allows multiple applications to be plugged as extension to Fatwire (like Community Server and Gadget Server).
It is required since the Rest API is based on it, and since CSDT uses the RestAPI you cannot get rid of it if you want CSDT. You can skip the installation but you will lose RestAPI... and CSDT. Not recommended. However, it IS a major source of pain for upgrader, since it works using a double redirect.
When you access to a protected resource,  or just log into Fatwire, CAS redirects to its server, generate a ticket and then redirect back. This requires a that DNS is properly configured (and a broken DNS is not uncommon in many intranets). This requires  also that all the proxy servers in the middle can  proxy the fixed URL and not a generic ip based URL.
CAS can make also impossible to log into ContentServer when you try to access using a tunnel and you are trying to do an emergency intervention to a customer that cannot quickly open you the firewall, so you trying to log into the the server through multiple ssh to the host server...
It is also a source of problems in publishing. Since it is used also by the publishing system, a misconfiguration can cause the publishing to start to fail after the upgrade... when it was previously working perfectly.

Last but not least

I am aware at least of one important security hole still present in 7.5 that has been fixed in 7.6. I prefer not to tell the details in a public blog post, but I strongly suggest to check release notes of 7.6... or just upgrade...

Conclusion

If you want

  • develop in a healthy, isolated, version controlled development environment
  • need caching options for complex uncached templates
  • need to scale your cache up to the infinity
  • leverage ajax using jquery
  • fix some security bugs
  • AND you are NOT SCARED of fixing DSN and PROXY configuration because of the introduction of CAS

then definitely go and upgrade .

 

Posted by msciab
22Sep2012