Content Integration Vs Content Migration

Few days back Fatwire Software announced the launch of the Fatwire Rescue Program for Vignette and Interwoven WCM customers.
The program will enable customers of Interwoven and Vignette to upgrade to FatWire’s WCM solutions at no license cost. However, this holds good only if they engage Fatwire’s supported or so-called ‘proven’ migration tools and services.
Vamosa and Kapow. I hope this move will hold well for Fatwire in WCM market space.

If you remember Fatwire already has a Content Integration Platform(CIP), which is a “web-services-based” content sharing tool. In this Fatwire CMS user can access content stored across the enterprise without leaving the Fatwire CMS interface (CS-Direct). CIP offers connectors to access content from Documentum, SharePoint, and Windows and Unix file systems.

So why this rescue package from Fatwire when they already have a solution in place? Here are my insights on the demarcation between the two offerings and the differences in the approach –

1. In Content Integration Platform, the source WCM/ECM sever must be up and running in order to serve the content. The only difference will be accessing the content using Fatwire console (dash/advance/insite interfaces).
[Access + Connector = Integration]

2. Fatwire rescue program is based on the expertise and past experiences of Content Migration service providers (Vamosa and Kapow). Server Instances of Teamsite or Vignette will not be required after full content migration.
[Entire data movement (Assets/Content/Templates/Workflows/Roles/Security/Users/Publishing Events) = Content Migration ]

Since there is no Fatwire connector for Vignette and Teamsite as of now, I believe this is another way of attracting the customers to move completely into Fatwire at lower cost (No license cost + No Running Instances of Teamsite or Vignette required).

Content Migration is a very risky, customers are advised that there is no fully automatic or a neat way of doing it. Manual intervention and tweaking of trusted scripts, XMLs and non-java based templates is very much required in order to do the migration. Evaluate and request for case studies or a proof of concept from the product vendor before you make a decision.

I am glad that in the midst of acquisitions in the WCM space, Fatwire is the one of the niche player who is moving a step forward by collaborating with content migration service providers like Vamosa and Kapow. I hope this move will hold well for Fatwire in WCM market space.

Content Integration Platform and Content Interoperability

Few days back Fatwire Introduced Microsoft SharePoint Connector as part of its Content integration platform. This new connector enables Fatwire CMS users to seamlessly access SharePoint content to use on the web. The Content Integration platform provides web-services-based, peer-to-peer content sharing capabilities that gives CMS users access to content stored across the enterprise without ever leaving the Content Server interface, and publish it to their public sites, intranets and extranets.

Enterprise content which are spread and stored in various content management systems and across platforms, the integration and seamless access of the content is still a challenge. Efforts are being made to overcome to manage content across multi-vendor, multi-repository content management environments. Recently talked CMIS is another such effort which defines a set of protocols, exposed via REST and Web Services definitions, for platform-independent interchange of content.

“…….Using CMIS-defined HTTP calls, you will be able to do standard CRUD operations (create, read, update, delete) against any compliant repository, regardless of the underlying repository architecture “

Though there are couple of valid questions which still need to be answered around the concurrent operations across content repositories, but it seems like that various CMS vendors or specification authorities are going to use “common web services” as their technology to move forward.We will definitely look forward for the success of content integration platforms or CMIS as it’s hard to find projects that were successful where vendors took JCR170 as their selling point, nevermind you still find sales guys talking about JSR 283 in their product presentations 🙂

JAX India 2007: Web2.0: What you should do?

Craig McClanahan talked on the Web2.0 at JAX India 2007.You can find more detilas about what he covered in Shishank’s post. Here’s a bit of elaboration of those 10 points what Craig suggested to make the web right :-
10 – Expose Data/Logic as services
* Content is more important than presentation.
* Use REST based Services when you “Can”
* Use SOAP based Services when you “must”
9 – Incorporate External Content
* No single application or database can contain everything
* Combine available content from multiple sources
8 – Seek QOS (Quality of Service) deals from Sources
* Authentication guarantee
* Performance provisioning
* API and format compatibility
7 – Give QOS Deals to users
* External consumer will also become dependent upon your content
6 – Adopt Agile Processes
* Continuous iterative improvement model
* Incremental release every 7-14 days
5 – Test Driven Development
* Reduce release testing
* Do aggressive unit /functional testing
4 – Architect for Scalability
* Separate view, logic and persistence
* Break into layers that can be independently scaled
* Add resource as needed for bottlenecks
3 – Embrace Heterogeneity
* Data and logic as “service” insulates layers both internally and externally
* Agile Technology benefits in for fast UI fixes
2 – Reach out to Mobile Clients
* UI for Mobile devices can share existing service
1 – Enable User Provided Content
* Participating in “mashups” counts
* User like to participate not just “view”

The suggestion that Craig has provided, gives a clear perspective on how Web2.0 should be incorporated gradually within your organizations portal, CMS or website.If you read the above points again I feel that some of them directly or indirectly take you to the SOA space where we re-architect our implementations so that our applications can be “loosely coupled” and “interoperable” when used as “services”.

Enterprise Portal and Service Oriented Architecture (SOA)

Service-oriented architecture (SOA) is the talk of the enterprise fraternity. Not only the business is getting benefited but the potential of SOA is affecting the speed of application development process.

This buzzword strikes Portal technology as well. These days organizations are in the process of migrating from traditional client/server, monolithic or disparate n-tier architecture to a more loosely coupled and interoperable environment, this process is then better termed as Service-Oriented Architecture (SOA).Most of us are aware of SOA and its benefits, I wont be repeating those here but will discuss that how Portal can be used to leverage SOA.

When we talk about the underlying components of SOA i.e. Interoperability, Scalability, and
Integration, the best suite that does and support all these is an Enterprise Portal Implementation.

A Portal based on standard like JSR168 and WSRP can be the most eligible candidate for SOA. When we look at the Portal’s Infrastructure, we find that it comprises of nuts and bolts of Service Oriented Architecture.

So the next thought that comes to mind is how Portal fits in SOA?

Portlets are reusable web components which forms the core of a Portal Desktop, providing relevant and customized information.SOA’s Interoperability is achieved by deploying JSR 168 Portlet to any JSR 168 compliant Portal server. Also, a portlet can be reused in different Portal pages as well as in different containers which proves reusability aspect of SOA.

Web Services, one of the main building blocks of SOA, fits nicely with Portal as WSRP based portlets. WSRP enabled portlets, which adhere to Web services standard such as SOAP and WSDL, enables portal to easily include services from a third party into a portal page. This eases and reduces the development process and makes use of already available enabled services. WSRP provides much support for the basic pillars of SOA like SSO, Reusability, Access management, service integration with loose coupling (here I mean to say that different processes should be integrated but without the processes being dependent on each other ).

Lastly, Role based content delivery model in Collaborative Portals makes a value addition for role based SOA Implementation.

The above information perfectly fits with the Gartner’s conclusion that

The portal can be a logical and appropriate first step toward SOA implementation because its fundamental nature lends itself to SOA approaches”

Open Ajax and Collaboration the big guys finally collaborate to push AJAX in the opensource community. IBM, BEA Systems Inc., Borland International Inc., Novell Inc., Oracle Corp. and Red Hat
Inc., have formed a group to contribute code and work together to promote use of AJAX., they will call it Open Ajax. This group will promote the use of Ajax tools with which developers can build rich Internet applications. The tools essentially eliminate the need to refresh a Web page every time a user enters or receives new data.

IBM is to propose its Ajax Toolkit Framework , that framework supports multiple Ajax runtime tools and can be used to develop and debug applications.

Since in the portal front the world is going collaborative and AJAXed 🙂 ,its good to see that even the top notch vendors are implementing or moving a part of their technology to opensource.

Blog at

Up ↑