The Alterian Content Manager's (ACM) application architecture combines an enterprise strength, reliable and scalable server with SQL Server or Oracle for the repository, Internet Exporer and Firefox browsers with AJAX technology as well as Microsoft Smart Client desktop technology for client application usability and responsiveness, and a choice of ASP.NET or JSP to develop your web applications.
Content Application Server (CAS)
The hub of the content management server is the repository and the CAS, which provides the programmatic interface used by both the delivery engine and the client applications.
This interface is exposed to the outside world through C#, Java and SOAP APIs for the application developer and the Smart Client, and through ASP.NET web parts and JSP custom tags for the template developer.
Web Application Development
Platform technology choice has always generated heated debate. Should it be Java? Or should it be the Microsoft technology stack of the moment? For content delivery templates, we leave you free to choose either Microsoft ASP.NET or JSP depending on your technology requirements.
We fully support both, in the native way you want to use those technologies – by providing the development building blocks you expect. For our Microsoft development community we don’t just offer our Java API with C# scribbled on it in crayon – instead we use master pages, we provide a data provider, custom controls and an example site. For the Java guys it’s the API and JSP Tags – or we support whatever development methodology you want to use.
ACM Smart Client
We call our desktop client the “Smart” Client as it was built against the Smart Client standards the Microsoft defined in 2003, the first commercially available Content Management System that took advantage of the (at the time) emerging .Net platform standard.
ACM Web Client
With the Web Client, we felt that it was important not to mandate a single browser, or to somehow "degrade" the user experience when running on something other than Internet Explorer. For that reason, we worked hard to make the Web Client look and work identically in both Internet Explorer and Firefox, to open up the Web Client to as many client platforms as possible.
The Web Client is built on the powerful Dojo AJAX libraries and the Tapestry framework – requiring nothing more than a simple servlet container to run (we supply Tomcat on the CD as a suggestion).
Content Model
Content is defined by type, each type having a series of fields which can include a binary part, such as multimedia, and a set of relationships to other types. We can handle over a hundred and forty different binary types.
Types also have a workflow, which defines the stages that an item of that type passes through in the publishing process. Version and revision control is available at the level of individual content items, with a full audit trail. As part of workflow, you can specify how many previous versions to keep for each item of a specified type, and the points in the workflow at which new versions are made.
Access controls determine who has access to which items, at which stages in the workflow, and with which presentation. You can restrict where items of a particular type are located on a site and you can control access at a branch level.
Content Deployment
ACM uses a hub-and-spoke deployment model. A single, central staging or "editorial" server repository holds all content at all stages of its workflow. Your content and site development teams work against this server, usually located inside your firewall on your company network.
Content is delivered to the end consumer from one or more live servers, which connect to read-only slave content repositories. A module on the staging server, the Distribution Server, ensures that content is replicated automatically from the staging to the live server.
Integration
The ACM interface is exposed to the user through several routes. The first of these is the client-side Java API, a set of public classes that provide the lowest level of access to the server facilities, bridged to a C# API for the Microsoft developer. Communication is over RMI/IIOP except in the case of classes that deal with binary objects which use HTTP streaming. The CAS is also exposed through a Web Services SOAP interface.
Further Extensibility
The CAS is able to load and execute "jobs" - Java classes written to a published interface - according to a schedule defined in an XML document. Since they execute in the context of the content engine, these jobs have high-performance access to a local copy of the Java API. In addition, the Gateway module supports a JMS adapter. This enables the developer to publish content workflow events (create, update, sign-off, soft delete and hard delete) to a message topic.
If you’d like to know more, please contact us .