Architecture changes for Alfresco Content Services version 6.0 and beyond

[resplin]

** Please note while the general direction of this post is still valid some specific items may not have been actioned yet and some may still be subject to change. In particular, while we have deprecated certain Share functionality in order to encourage users to move to using the ADF, we have a large number of customers still using these features in Share and have no intention to leave these customers unsupported. **

Following the successful release of Alfresco Content Services in 2017, we have been planning our next round of innovation. In this blog post, we share some of our plans so that you can prepare for the next release and provide feedback. At the end you will find a table summarizing the actions you should take.

Even though we refer to Alfresco Content Services, most of this information also applies to Alfresco Community Edition.

There are three overriding architectural goals for upcoming releases of Alfresco Content Services (ACS):

• Improve integration across the Alfresco Digital Business Platform - encompassing products such as Alfresco Process Services and the Alfresco Application Development Framework. One of these planned improvements is a shared authentication system that supports additional modern protocols such as OpenID Connect. This improved integration will make it easier for Alfresco Content Services customers to benefit from the power of Alfresco Process Services when their use case requires it.

• Provide a containerized deployment option that can be hosted on a range of infrastructure, both on-premises and by cloud providers such as AWS. These containers will also be portable between deployment environments such as dev, test, and production.

• Further enhance the REST API to allow advanced customizations to be completed outside of the repository Java process, including APIs for batching requests and subscribing to system events. Integrations using the REST APIs are easier to maintain and upgrade than customizations within the repository.

These goals will require some significant architectural changes to the Content Repository, and so we expect the next release to be a major version, Alfresco Content Services 6.0, which we plan to release in 2018. You will see these changes begin to enter Alfresco Community Edition immediately.

In order to make these improvements, we need to change some features of the product that you might be using. Specifically, we want to make sure you are aware of the following plans:

• Installation Bundles: Customers have asked us to reduce the amount of effort necessary to deploy Alfresco Content Services (ACS) in a production configuration. The ACS installers will be replaced with Docker containers, using Kubernetes and Helm. This deployment technology allows us to better define a standard production configuration while giving greater flexibility to our customers as they deploy into their environments.

• Web Application Servers: As part of providing a containerized cloud-ready deployment, we will be removing the need to manage a separate web application container. Instead, configuration will be injected into the Docker container, reducing the effort required to setup, secure, and manage the application. In the next release, we will no longer support Alfresco Content Services deployed within J2EE web application servers such as JBoss, WebSphere, and WebLogic. Over the long term, we are considering embedding the web application server within the repository and making the content repository directly executable. As a result, it is likely that support for deploying into a separate Tomcat web container will be dropped in a future release.

• Solaris and DB2: As we focus on the most widely used deployment platforms, we will be dropping support for the Solaris operating system and IBM’s DB2 database.

• CIFS an NTLMv1: Due to security vulnerabilities in the protocols, we will be removing the ability to access Alfresco Content Services as a shared network drive using CIFS / SMBv1 and the ability to authenticate using NTLMv1. We recommend that customers needing shared network drive access use our AOS WebDAV when using Windows clients and our standards-compliant WebDAV when using non-Windows clients. Customers should also use Kerberos instead of NTLMv1 for SSO. We will continue to improve our implementations of WebDAV and Kerberos.

• Legacy Solr: ACS 6.0 will leverage the advanced capabilities of Solr 6. Previous versions of Solr will no longer be used—Solr 1 will be removed from the product, and Solr 4 will be deprecated and remain in the product only to support upgrades. No functionality will be lost upgrading to Solr 6, but there are some different defaults affecting the way locale is handled that will require minor adjustments in customizations.

In addition, we plan to remove the following capabilities:

• Alfresco Process Services Share Connector: Advanced content and process applications can be built with superior user experiences using process and content components from the Application Development Framework.

• Repository Multi-Tenancy: The multi-tenant capability of the Content Repository will only be supported as part of an OEM agreement and we are likely to remove multi-tenancy from Alfresco Community Edition. The support of multi-tenancy in Alfresco Process Services remains unchanged.

• Encrypted Node Properties: This capability provides a label for properties that are managed by client code and is used internally in modules provided by Alfresco. With the release of Alfresco Content Services 6.0, it will be considered part of the private API. Custom clients can achieve the same capability by using a Blob or Base64 String property and managing the encryption of the content within those properties.

• CIFS Shortcuts: Alfresco Content Services’ CIFS implementation provided Windows Explorer shortcuts for ECM tasks. These will be removed along with support for CIFS shared network drives. We do not currently plan to move them to the WebDAV implementation.

• Meeting Workspace and Document Workspace: These Share site types are not supported by recent releases of Microsoft Office, and so will be removed.

With the release of Alfresco Content Services version 6.0, the following features will continue to be available but are deprecated, and you should expect them to be removed in a future version:

• Some Share Features: We will gradually simplify Share to focus on the most commonly used capabilities by removing the following lesser-used site components and dashlets: site blogs, site calendars, site data lists, site links, and site discussion forums. These use cases are better met with dedicated interfaces, either through integration with third party applications or through custom development.

• Web Quick Start: Web Quick Start provides an add-on to Alfresco Share that demonstrates how to build a website on top of Alfresco Content Services. Though customers are welcome to continue using Web Quick Start, we will not be enhancing this product. There are many ways to use the Alfresco Digital Business Platform to deliver content to the Web, and we would be happy to discuss your specific needs with you or point you to a partner.

• Alfresco in the Cloud: As the market for content collaboration technologies has evolved, we are evaluating replacements for Alfresco in the Cloud (my.alfresco.com). We will offer different synchronization solutions to supersede Alfresco Cloud Sync to my.alfresco.com. As a result, we are no longer adding new functionality to that service. As our new products mature, we will reach out to the customers who are using Alfresco in the Cloud to outline the replacements and possible timelines.

We also make the following recommendations to help those building applications on top of Alfresco Content Services to prepare for future releases:

• The versioned REST API for ACS covers a wide range of use cases, and is preferred over in-process APIs for extending Alfresco Content Services. Integrations and customizations that use the REST API are easier to integrate into your own development processes and are easier to maintain when upgrading ACS.

• In order to make it easier to design, deploy, and maintain custom workflows, in a future release we will be providing a platform-wide workflow service using Alfresco Process Services (powered by Activiti). This will replace the use of embedded Activiti for custom workflows. Future custom workflows will be implemented external to the Content Repository and will leverage the REST APIs of Alfresco Content Services. To be easily upgradable, new custom workflows should make local REST API calls in order to avoid using the in-process APIs.

• ACS workflows are intended to automate the management of content items within the Content Repository and APIs for custom workflows will continue to be available with subscriptions to Alfresco Content Services. A subscription to Alfresco Process Services (APS) is required for advanced process management use cases which is used for collecting, disseminating, integrating and coordinating information across an organization.

• Though we continue to improve and maintain Share, we recommend that custom applications be built with the Application Development Framework (ADF). ADF components make it easier to assemble and maintain custom applications.

Thank you for the feedback you have previously given on our products which have informed these changes. We think you will appreciate how these changes will allow us to evolve Alfresco Content Services to meet the needs of your organization both now and in the future. If you are a customer, and have any questions, please reach out to your Customer Success Manager. If you are using one of our open source products and want to engage in the discussion, feel free to comment on this post. We look forward to continuing the conversation with you.

Regards,

The Alfresco Team

Table Summarizing Changes and Guidance

Architecture Change	Guidance	Timing
Improved REST APIs	Use the REST APIs instead of the in-process APIs.	Immediately
An eventual move to a platform workflow service	Custom ACS workflows should use REST calls to the Content Repository when possible. Use APS for process management across the organization.	Immediately Immediately
Simplify the Share UI	Integrate with 3rd party applications or develop custom interfaces.	Immediately
Containerized deployment	Transition your deployment from the installers toward container technology.	6.0 release
Executable content repository	Move away from separate web application servers.	6.0 release
No support for Solaris	Migrate to a supported different OS.	6.0 release
No support for DB2	Migrate to a supported database.	6.0 release
No support for CIFS or CIFS shortcuts.	Use WebDAV.	6.0 release
No support for NTLMv1	Use Kerberos.	6.0 release
Replace Solr 1 and Solr 4	Upgrade to Alfresco Search Services powered by Solr 6.	6.0 release
Discontinue the APS Share Connector	Leverage the Alfresco Development Framework.	6.0 release
Repository Multi-Tenancy only for OEMs	If you need multi-tenancy, talk to your Customer Care Representative about your use case.	6.0 release
Encrypted Node Properties	Use a Blob or Base64 String property.	6.0 release
Removal of Meeting Workspace and Document Workspace site types	Use standard collaboration sites in Share.	6.0 release
Removal of some Share features: site blogs, site calendars, site data lists, site links, and site discussion forums	Develop a dedicated interface or use one provided by a third-party.	Post 6.0
Phasing out of Web Quick Start	Transition to another web delivery platform.	Post 6.0
Phasing out of Alfresco in the Cloud	No action needed at this time. We will contact you when there is a timeline you should be aware of.	Post 6.0

[afaust]

To be easily upgradable, new custom workflows should make local REST API calls in order to avoid using the in-process APIs.

I hope Alfresco comes forward at some point to tell users / customers how this should be achieved in a transactionally safe way. The workflow will run in its transaction and make a non transaction-bound REST call locally - how can users / customers ensure some failure and rollback in the workflow transaction (potentially outside the scope of the process engine) will properly roll back changes made via those REST calls? Are all APIs that currently exist in the Script API (including actions such as mail sending) already exposed via REST APIs? I doubt it.

Also, what about content policies, rules and actions that need to trigger logic in those workflows? Will Alfresco 6.0 provide REST APIs for its "still" in-process workflow engine matching Alfresco Process Services so such functionality can be "easily upgradeable" when the switch needs to be made? How do you expect people to "immediately" use ReST APIs for logic from within ACS workflows when those have only been available since 5.2 and there are none yet matching APS REST APIs for calls from ACS to ACS workflows?

I hope the documentation team is already busy updating all the documentation on ACS workflows "immediately" so people can read up on how they should "immediately" change how they develop workflows.

[...] in a future release we will be providing a platform-wide workflow service using Alfresco Process Services (powered by Activiti). This will replace the use of embedded Activiti for custom workflows.

ACS workflows are intended to automate the management of content items within the Content Repository and APIs for custom workflows will continue to be available with subscriptions to Alfresco Content Services. A subscription to Alfresco Process Services (APS) is required for advanced process management use cases which is used for collecting, disseminating, integrating and coordinating information across an organization.

So, is there going to be a usable, community-edition / open source / LGPL (or Apache License) Alfresco Process Services (powered by Activiti)? You only state that a subscription to APS will be required for "advanced process management use cases", so simple ACS workflows must be "free" in some way. But APS currently does not exist as a free product - there is only the Activiti webapp, or is this going to be rebranded in some way?. Where do you draw the line functionality-speaking between ACS workflows and "advanced process management use cases", because "automating the management of content items within the Content Repository" may very well involve steps considered as "collecting, disseminating, integrating and coordinating information across an organization". I mean, as soon as an ACS workflow involves more than one user/person (potentially different departments/teams), is it already considered to be a workflow "across an organization"?

At some time it would be nice to get clear and comprehensive information on that. Heck, this kind of strategic, architectural change should be worth several Tech Talk Live and DevCon sessions, but I see none on any event schedule so far. If community folks can't use this allegedly planned "plattform workflow service" for the same kind of use cases they are currently handling, I don't think people are going to "appreciate how these changes" will force them to look for alternatives to keep clear of these new product differentiations ("How you doin', Flowable?").

[resplin]

Background

As usual Axel, thank you for engaging in discussion about these topics. Your post has a lot to respond to.

It will help people to understand that this announcement tries to balance competing desires in our user base:

• People want to get information as soon as possible so that they can make the necessary implementation adjustments on their own schedules. This encourages us to share information early.
• People want to have all the answers to their questions. This encourages us to wait to share information until the projects are very mature.

We need to manage this tension while keeping the post brief enough that people will actually read it.

There is a similar tension as we collaborate with our open source contributors who want to be informed early enough to influence our direction, but still want detailed answers. That is why it is so useful that you pursue conversations like this one.

We decided in this case to share our technical direction early. As the implementation of this vision progresses, we will be able to share additional details and answer more questions. That is why this post sets a direction for Alfresco Content Services 6.0, but makes clear that these changes will be delivered over a series of releases. Similarly, we try to be clear which items will stop being supported in Alfresco Content Services 6.0, and which items will continue to be supported in the product but will eventually be replaced. Our goal is to provide options and avoid surprises.

Workflow and REST APIs

We are confident that moving away from the embedded Activiti is the right decision to leverage the improvements we are making in that product and to make it easier for customers to scale up their implementations over time. We also recognize that moving away from the embedded Activiti engine will require a re-implementation of custom workflows. By leveraging the REST APIs when they are adequate for your use case, you can reduce the effort required for future upgrades.

We add more capabilities to the REST API in every release. Content Policies, Rules, and Actions are all on the short-term roadmap, and we are working on a method for batching REST API requests to meet the use cases currently covered by the transactional Java API. We will not be removing the embedded Activiti until we have an adequate replacement for workflow use cases. 

We recognize that these changes will require significant updates to our documentation and training, which we will do over time. Our immediate goal is to spur a change in our developer ecosystem so that contributors like you can help in developing best practices that follow this vision.

Workflow versus Advanced Process Management

This blog post is also intended to help people evaluate when the embedded Activiti is sufficient for their use case, versus when they should deploy Alfresco Process Services. Key things to note:

• The Activiti engine will continue to be run as a separate open source project from the content repository in Alfresco Community Engine. That project is upstream to Alfresco Process Services, which is our commercial offering built on that engine.
• Even after removing the embedded Activiti, Alfresco Community Edition will continue to include a workflow capability. We expect this to be provided by an Activiti service deployed alongside the Content Repository, rather than embedded within it.
• Even after removing the embedded Activiti, Alfresco Content Services will continue to include a workflow service that will not require a subscription to Alfresco Process Services. We have not yet defined whether that will be provided by a service based on Activiti or based on a reduced version of Alfresco Process Services.
• We recognize that we will need to be more specific in what use cases will count as workflow, and what will only be supported as part of Alfresco Process Services. We have been doing research with customers to gauge the impact of this distinction, and we find that fewer customers have used the embedded Activiti for advanced process management than we had expected.
• In order to help people make the right implementation choices, we will need to make clear which Activiti APIs will be considered part of a workflow offering, and which will require a subscription to Alfresco Process Services in order for us to provide a supported solution. We are still working on how to do that.
• You can expect Tech Talk Live sessions, DevCon sessions, and blog posts as we implement this change over the next few releases.

We look forward to continuing the discussion.