[UPDATED: To remove my comment about the absence of workflow config in Share, which Martin does cover. Sorry about that, Martin]
Packt Publishing sent me a copy of Martin Bergljung’s new book, Alfresco 3 Business Solutions. I just finished reading it, so I thought I’d write a quick review.
Overall, I think it is a good book with a lot of useful information across a variety of topics. The preface says the book is for “systems administrators and business owners”. Inclusion of “business owners” is a stretch–they’d have to be pretty technical to get something out of this book. I think the intent of including “business” in the title and the target audience is to set up the book as more of a solution-oriented look at Alfresco and less of an exhaustive technical how-to.
Bergljung attempts to organize the book around “business solution” focused chapters. For example, if your main concern is letting your users access the repository through file protocols, then Chapter 5, File System Access Solutions, is for you. If you are doing a content migration to Alfresco, Chapter 8, Document Migration Solutions outlines the different approach available for doing that. I think this is a good approach for the stated audience and most of the chapters fit the approach.
The book starts out with an overview of the Alfresco platform and various repository concepts. Although there are places that risk going into too much detail too early, that first chapter would be a good read for anyone new to Alfresco. The chapters on authentication and synchronization (Chapter 4) and CIFS/WebDAV (Chapter 5) are very thorough and provide some of the best coverage of those topics I’ve seen in any of the Alfresco books. The vigor with which Bergljung attacked those topics makes me think those areas are a particular passion for him. If you are strict about the target audience, Chapters 4 & 5 are definitely the strongest in the book.
However, at various points, the book strays from its intended audience and starts to go into developer topics. Don’t get me wrong, that’s the most interesting stuff to me, but I think it is potentially confusing (or, at best, superfluous) to system administrators. For example, the end of Chapter 1 covers the underlying database schema. Maybe it is a good idea to discuss what the tables are and how they are used so that a DBA gets a feel for the schema and can tune the database appropriately. But Alfresco’s schema is not public and shouldn’t be accessed directly unless you know what you’re doing and if you are willing to sign up for the inevitable maintenance down the road when the schema changes without warning. Bergljung gives a soft warning to this effect at the start of the section but the negative effects could have been emphasized more.
There are a few other developer-centric concepts in the book that I just simply don’t agree with. The first is about AMPs. In a couple of places, Bergljung implies that the Java Foundation API and AMPs are somehow dependent on each other. The statement, “The Foundation API is only used when deploying extensions as an AMP,” is just not true. Later, another statement compounds the problem by saying, “AMP extensions require Java instead of JavaScript”, which, again is not accurate. For some reason, the author is trying to link an API (Java, JavaScript) with a deployment approach (AMPs) which are not related or dependent on each other at all.
Another piece I don’t agree with is about $TOMCAT_SHARED. To be fair, I’ve seen this in other places and have heard certain Alfresco Engineers encouraging the use of $TOMCAT_SHARED for things I think belong in the web app instead. Regardless of where it comes from, I think it’s really bad advice to tell people to use $TOMCAT_SHARED for anything other than alfresco-global.properties and server- or environment-specific settings. Proponents of $TOMCAT_SHARED will say they like deploying their customizations there for two reasons. First, when Alfresco and Share are deployed in the same Tomcat instance, you can deploy your extensions as one package and both web apps will use it. Second, your extensions go into an extension directory external to the Alfresco WAR, which keep them well away from Alfresco’s code. In my option, both of these are actually reasons NOT to use $TOMCAT_SHARED. Why? As to the Alfresco/Share sharing bullet point, why unnecessarily couple those two web apps together? The Alfresco and Share WAR are built to run on completely separate nodes which is helpful. We shouldn’t ruin that by making them both rely on the same shared directory.
As for the “keep your extensions away from Alfresco’s” reason, that’s what the extension directory is for. I can keep my customizations separate and still have them reside in Alfresco’s WAR. In fact, most clients I’ve dealt with prefer that because they have IT Operations teams that only want to deal with self-contained WARs. Being a “special case” is not how you win the hearts and minds of your infrastructure team.
Now, with these picked nits out of the way, I should say that there are some developer-oriented topics that were very good. Bergljung has some good Java Foundation API and JavaScript API examples in Chapter 2 covering Node Service and other commonly-used services. And I like the section in Chapter 3 that talks about setting up Apache Hudson for continuous integration. Chapters 9 through 11 provide good coverage of Advanced Workflows, from designing workflows with swimlane diagrams to a lengthy example showing super states, sub-processes, and custom workflow management dashlets.
In keeping with the “solutions” approach, I think I would have combined the portlet chapter and the mobile app/Grails chapter into a single “integration solutions” chapter and talked less about the specific implementation details and more about the touch points: options for integration (Web Services, CMIS, custom web scripts), single sign-on approaches, what’s available out-of-the-box, caveats, etc. Most of this is covered one way or another between the two chapters. It just seems like a common thing people think through is “What’s the best approach for doing X on top of Alfresco” where X is a portal like Liferay, a community platform like Drupal, a mobile app, and so on.
So, if you’re a “business owner” and by that you mean “non-technical end-user”, you’d probably be better off with Munwar’s book, which is definitely end-user focused. If you are a “system administrator” or someone who needs to know the capabilities of Alfresco and how to integrate Alfresco with various touch points (LDAP, Active Directory, portals), it’s definitely worth a read, particularly if you need to deal with external authentication sources or you are responsible for getting CIFS working. Developers will benefit from the API examples and the chapters on Alfresco’s embedded jBPM engine.
Congrats to Martin and Packt. It’s good to see another title (I think we’re up to 8 or 9 now) added to the Alfresco bookshelf.
Hi Jeff,
Thanks for taking the time to review my book.
Just a couple of points:
Target Audience:
———————–
The target audience for the book is anybody that wants to build CMS solutions with Alfresco.
I think that there are useful information for Developers, Architects, and System Administrators.
I agree with you that business owners and business analyst probably will have problems following
the chapters in detail as they are quite developer oriented.
About AMPs:
———————–
I tried to locate the following 2 statements in the book but cannot find them.
If you let me know what page they are on then I can comment based on the context:
“The Foundation API is only used when deploying extensions as an AMP,”
“AMP extensions require Java instead of JavaScript”
I would be really surprised if I actually wrote any of these statements
as they are not correct and I am sure they would have been picked up by reviewers.
If I indeed wrote them then I would have to apologise to the readers for
supplying incorrect information.
$TOMCAT_SHARED:
———————–
I am of the same opinion as you here, tomcat/shared should be used for
alfresco-global.properties and server- or environment-specific settings.
I do refer to tomcat/shared when talking about configuring authentication and
synchronization and this falls in under server- or environment-specific settings
I think. I also talk about configuring values in the alfresco-global.properties file
under tomcat/shared in a couple of places, which is okay I think.
I do not talk about putting any other customizations under tomcat/shared.
If you can elaborate on this I would be happy to respond.
Coupling Alfresco.war and Share.war
———————–
I do not talk about coupling them anywhere. In fact the build project that I present in the book
builds either AMP extensions for the alfresco.war, JAR extensions for the share.war, or both.
What directories to use for extensions
———————–
Both the AMP extension and the JAR extension follow best practices recommended by Alfresco for extending the product.
Delivering WARs instead of AMPs and JARs
———————–
Agree that some IT Operations team prefer WARs. Then I just run the AMP against the WAR and then deliver the custom WAR.
I prefer to have the extensions separate from the Alfresco source code. That way it is easier to see what extensions
that have been done and it is no problem to upgrade to newer Alfresco versions. It is also easier to version the
extension file.
Workflow in Share (“I thought it was kind of weird that it didn’t address user interface customization for Share”)
—————————
I do, see chapter 10 and the last 7-8 pages, which go through exactly how to configure
support in Alfresco Share for Advanced workflows.
Martin,
Thanks for responding. I’m happy to provide clarification on my post…
Regarding the target audience, the preface on page 3 says, “This book is designed for system administrators and business owners…” I think some people will read that and use it to make a decision about whether or not the book is applicable to them. If they do, it could lead to missed expectations, because, as you point out, there are many developer-oriented topics.
On the AMPs topic, I should have explicitly said that I was paraphrasing, or, even better, used the exact quotes instead. When I said, “AMP extensions require Java instead of JavaScript,” I was paraphrasing the following, which is on page 39, “When you implement Java extensions delivered in the form of an Application Module Package (AMP), you would mostly use the so-called Foundation Service API, but when you implement Web Scripts and Business Rules it is more convenient to use the JavaScript API.” I think this could just be re-worded to address the issue, which is that AMPs have nothing to do with the Foundation Service API. The API you use, and whether or not you are using Web Scripts, Java, or JavaScript, is completely independent of how you choose to deploy your customizations.
This linkage is repeated again on page 59 in the section on the Java Foundation Services API, “[The Java Foundation Services API] is used only when you develop extensions that are merged with the Alfresco web application archive (WAR) via an AMP,” which I paraphrased as “The Foundation API is only used when deploying extensions as an AMP.”.
On $TOMCAT_SHARED, I think what raised the flag were these sentences from page 49, “The shared directory is where you will do all Alfresco configuration that should live over deployments and Alfresco upgrades. Basically, try and always do the configuration here because then you know it is not going to be overwritten when somebody installs a new AMP or does an upgrade.” It sounds from your comments that you agree that not all configuration should be done in the shared directory.
On coupling the two WARs, I agree that you didn’t say anything in the book that couples these to together. In my post I was referring to advice I’ve seen elsewhere about using the shared directory and that, in my opinion, it couples the two together. Same for the directories to use for extensions.
I’m glad that you agree that some IT Operations teams prefer WARs and I agree that when that is the case, AMP-ing the WAR and giving that to them is a good way to go. I agree with the reasons you list above as to the benefits of AMPs, although one of the drawbacks is that it significantly affects the development cycle because the merge/explode steps take much longer than simply unzipping customizations into the exploded WAR. This is either something developers live with or they create multiple ant targets.
On configuring advanced workflow in Share, you are absolutely correct. You do cover that in Chapter 10. I blew right past it and then didn’t find anything in the index on the topic later when I thought I hadn’t seen the topic covered. I’ll update my post to remove that comment.
Thanks again for replying with your thoughts on the post and congrats on publishing the book. I know what a huge project that was.
Jeff
Just adding a personal opinion about this book 🙂
I don’t know for sure for who this book is intended to. but one thing for sure, as a project manager, this book give many useful insights for me.
Some chapter give clear and simple understanding, but yes, I admit in other chapters, the way the topic presented is not too clear. But overall, it’s a very good book, and worth to buy.
It is a very detailed book, especially for CIFS, LDAP configuration. And it really helps us a lot. There is no WIKI and forum discussion or blog post or other books that cover this topic as complete as Alfresco 3 Business Solutions.
One thing that impress me, it give an honest view about the system (Alfresco). Martin covers some issues that will occur when doing real implementation and he suggest some alternative for that issue.
Plus (cmiiw) currently it’s the only books that covers the SHARE customization.