Category Archives: Services

Related to Software as a Service (SaaS), Service-oriented Architecture (SOA), Service Orientation (SO), etc.

Understanding LiveCycle ES2′s application model

Posted on by
3

Note: If you’re visiting this blog from the Adobe LiveCycle Developer Center or from the Adobe LiveCycle Blog, welcome to my musings. You’re invited to tell me what you want to know about LiveCycle via a comment. Thanks in advance! :-)

This longer-than-usual post is intended to help customers understand why the new application model exists in LiveCycle ES2 and understand how to migrate LiveCycle ES assets into ES2 assets, based on business value into doing so. It is meant to complement, not reiterate, other content already published concerning the application model (e.g. the section on migration process, below, is just an example meant to whet the reader’s appetite for more detailed demonstration/conversation elsewhere).

So, without further ado…

Table of contents:

  1. Introduction
  2. Application model principles
  3. Conclusion
  4. Additional resources

Introduction

When Adobe LiveCycle ES2 released, major advancements and changes occurred in several areas of application development. The purpose of this white paper is to explain these advances specifically in the context of migrating existing LiveCycle assets into the new ES2 application model. However, before the migration process is described step by step, it’s important to understand the new model, why it is exists and when it should be leveraged.

The most notable changes to application development in LiveCycle ES2 are as follows:

  • LiveCycle Applications
  • Versioning
  • Far and Near References

All new development work in LiveCycle ES2 occurs in LiveCycle Applications.[1] A new Applications view replaces the Processes and Resources views in LiveCycle Workbench ES2 as the primary view for application development. Both Processes and Resources views remain to support upgraded LiveCycle assets that have not yet been migrated to LiveCycle Applications.

LiveCycle Applications contain processes, forms, guides, data models, events, fragments, images, DDX files (Assembler document service), DSC’s, etc.[2] A LiveCycle Application is a container of design-time assets. When a LiveCycle Application is deployed, services are delivered into the runtime, and at this point a particular service’s implementation becomes hidden from the consumer (e.g. there is no “File | New -> Service” that emits a service object in LiveCycle). Consumers continue to discover services via the LiveCycle Service Registry.

It is important to understand that from now on when you do something in Workbench the first thing you do is “File | New -> LiveCycle Application” and that the Application is the container for all your application assets.

A LiveCycle Application is the basis for a hardened, discrete versioning model in LiveCycle ES2. That is, application assets do not have versions of their own; they inherit the version of their parent LiveCycle Application. These version numbers are immutable, meaning that they do not change even when the application is deployed on different LiveCycle systems. In LiveCycle ES an edit/save gesture on an application assert could result in the creation of a new version of that asset; however, in LiveCycle ES2 such gestures will not–version is defined solely by the hosting application.

A LiveCycle Application is the context for how asset references are maintained. An asset referring to another asset in the same LiveCycle Application uses a relative near reference. When an asset refers to an asset in a different LiveCycle Application then it is a far reference. Far references are required to state LiveCycle Application name and version (e.g. repository:///Applications/NewCustomers/1.0/Loan/Forms/request.xdp).

Applications, assets and references
Figure 1. Applications, Assets and References

In the above figure, there are two applications (i.e. App1 and App2) and a total of three application assets (i.e. A, B and C). The line between A and B represents a near reference (i.e. wholly contained by App1). The line between A and C represents a far reference (i.e. a reference that spans from one application to another application–specific version).

In the above figure, App1 and App2 can be versioned (i.e. 1.0, 1.1, 2.0, etc.); however, A, B and C cannot be versioned apart from their containing LiveCycle Application.

Application Model Principles

So, why did LiveCycle ES2 usher in a new application model, and why should you want to upgrade to leveraging it?

In LiveCycle ES, there were services/processes, events, forms and Document Service Components (DSCs). Each object had distinct user interface with different semantics for how the object could be edited, locked, activated, secured, versioned and exported. Conceptual information that the user acquired while using one subsystem was not transferable to the other subsystems. One of the design goals of the LiveCycle ES2 application model was to normalize these behaviors and provide a consistent user model across the managed objects.

The LiveCycle ES2 application model provides hooks at strategic points in an asset’s runtime. The ability to transactionally deploy a collection of assets and the ability to intercept the runtime lookup of a named asset both represent key indirection points that can be leveraged in future versions of LiveCycle.

The LiveCycle ES2 application model enforces a consistent persistence model for the design-time assets. This, in turn, provides the foundation for supporting disconnected mode (offline or occasional connectivity), SCM integration and intuitive experience in Workbench (e.g. login/logout, open/save).

Your confidence during migration is of utmost importance. The LiveCycle ES2 application model addresses migration confidence by enabling existing investments to continue running in a “bug compatible” manner. Maintenance of existing systems can involve evolving an existing system on an as-needed basis.

The application model in ES2 supports two types of changes: semantic and non-semantic. Given that an application is a composition of assets, change can refer to the set of assets in the application and/or to the assets themselves—both their content and their associated metadata.

A non-semantic change represents an update that does not provide any new functionality over prior versions but rather represents an incremental refinement. Bug fixes and patches are good examples for a non-semantic change. A non-semantic change never requires consumers to be aware of the change. Non-semantic changes can be imposed by the producer on all of its consumers without requiring the participation of the consumer.

A semantic change represents an update that will introduce new capability above what is available in pre-existing versions. It is possible that a semantic change will necessitate that the consumers adjust the way that they interact with the objects. A semantic change must be explicitly requested by consumers, it is never implicitly forced upon them by the producer.

Example migration to ES2 application model

So, now that you have a better understanding of a LiveCycle Application and the new application model in LiveCycle ES2, let’s walk through the process of migrating a LiveCycle ES (8.x) process to a LiveCycle ES2 (9.x) process:

  1. Deploy the LiveCycle ES LCA as LiveCycle Archives (8.x) (Compatibility mode).
    • The LiveCycle ES processes will run as-is on LiveCycle ES2 as LiveCycle is backward-compatible. If your goal is to simply move the running content to an ES2-based server (without taking advantage of any new capabilities) you are done.
    • If you want to leverage native ES2 functionality, you will need to follow the rest of these migration steps in order to convert the LiveCycle ES process to LiveCycle ES2 process. Converting the process will result in a service name change since the LiveCycle Application name (namespace), version, etc. become part of the service name in LiveCycle ES2.
    • Best practice: If you are adding new resources to the application the recommendation would be to do a full migration and import all assets into the new application, resetting the deployment identifiers. Mixing and matching legacy ES resources and the new ES2 application model is not recommended.
  2. In Workbench, create a new application (e.g. MyApplication).
    • Application name forms a namespace for assets therein.
    • You can optionally create folders within the application to specialize this namespace further.
    • For example, your development team may have particular standards for organization (e.g. based on asset type, based along functional lines, etc.).
    • In this particular migration, we’ll create a “processes” folder to receive the imported ES process assets.
  3. In Workbench, right-click on MyApplication/1.0/processes and select Import. In the dialog shown, select Process and click Next. In the next screen, select the LiveCycle ES process from its LiveCycle ES category. Click Finish.
  4. The LiveCycle ES process will be added to the LiveCycle Application (i.e. MyApplication). Please note that this is a copy of the original process.
    • The service name of original process is the process name itself; however, the service name of the new process is ApplicationName/processes/ProcessName.
    • Assets in ES lived apart from a namespace (i.e. unqualified services at runtime). ES assets in ES2 operate in a global service namespace (implied) at runtime. Native ES2 assets operate in application-scoped namespaces.
  5. If the original LiveCycle ES process has dependencies on other LiveCycle ES sub-processes, the new LiveCycle ES2 process will also have the same dependencies (i.e. LiveCycle ES2 process depending on LiveCycle ES processes). Therefore, in order to create a self-sufficient LiveCycle ES2 LCA containing processes with the same functionality, we need to identify and reset these dependencies. That means finding each dependency, visiting it and pointing it to something new.
    • In order to point a dependency at something new, the desired dependency target must exist in the application.
    • Best practice: create self-contained applications.
  6. To remove dependencies from other LiveCycle ES processes, we’ll have to repeat steps #3 to #4 and import all those processes under the same LiveCycle Application (e.g. ApplicationName/processes/SubprocessName).
  7. After importing all processes under the LiveCycle Application, we’ll have to edit all the processes individually in order to replace all the sub-process activity with the new processes.
    • Consider the following example: Process A uses process B (LiveCycle ES).
      • Both ES processes are imported into the LiveCycle Application, which results in processes A’ and B’ (LiveCycle ES2).
      • However, process A’ (LiveCycle ES2) still uses process B (LiveCycle ES).
      • We edit A’ and replace activity B with B’, using the same input/output parameters.
    • This step requires manual editing of all processes using sub-processes, which is time-consuming and can be error-prone without sufficient attention to detail.

This example is simply focused on process asset migration, but, as previously noted, there are several other application asset types that may be migrated.

Conclusion

Hopefully this paper has been helpful to your understanding of why there is a new application model in LiveCycle ES2 and how to take advantage of this capability with your LiveCycle ES investments in mind.

The LiveCycle team continues to work on enhancing migration support for its customers (e.g. increased automation), and it appreciates your feedback.

Additional Resources

For a more detailed dive into the process of migrating LiveCycle ES applications and assets to LiveCycle ES2, please consider the following content:

Footnotes

  1. LiveCycle Application should not be confused with LCA, which stands for LiveCycle Archive. LiveCycle Archives continue to provide the ability to export an application along with its assets (i.e. variables, images, documents, etc. since ES, service endpoint configuration and security since ES Update 1, etc.). Asides: (a) legacy LCA’s are still supported in ES2 (i.e. it’s possible to create/import them), and (b) there are two kinds of native ES2 LCA’s: patch (a specifically selected set of assets) and full (one or more applications where all content from the application is involved–no need to explicitly enumerate assets).
  2. These contained objects are called assets (i.e. application assets).

EMC Documentum Developer Edition

Posted on by

Today we launched a new EMC Documentum developer-oriented community within the EMC Community Network. Front and center is the new developer edition of the EMC Documentum ECM Platform.

So, what does this developer edition include? We believe it includes a lot of goodness for the development of content-enabled applications.

  • First of all, free software for developers
  • A new one-click installation process for the core of the EMC Documentum ECM Platform
  • xDB and new XML components – please visit the just-launched XML Technology Developer Community for more details about our native XML database and other technologies
  • Integration between the resulting development environment and online community resources and support mechanisms – think of this as a starting point and means to the ends you want to pursue, not an end in itself

Essentially, we’re trying to provide a low-touch, DIY experience. That being said, by integrating your local installation to an online community, the developer edition enables you to reach out to fellow developers and EMC employees as your pursuit your content management development interests grows. For example, you’ll find a range of white papers, documents and videos, as well as sample code in, for example, Java and C# (.NET). Topical tutorials available online are drawn from our Education Services library.

So, what is the process to obtain the free developer edition? We hope that it’s straightforward.

  1. Browse here and login into ECN/EDN
  2. Navigate here and complete a short (less than 30 seconds) registration form. Click the “Continue” button to proceed to the download site. (You may need to add ecn_communications@emc.com to your email safe senders list so as not to miss messages from that address (i.e. have them interpreted by Outlook as junk).)
  3. Navigate the EMC SubscribeNet links to arrive at the FTP download (or HTTPS-based download, if you prefer). Note that the download is a bit more than 1.73 GB and represents a Zip archive, which means that you should ensure adequate disk space to extract, deploy, etc.
  4. Commence your download.

In a follow-up post, I’ll walk you through the installation experience and how to leverage the version of DFS that comes with the developer edition. BTW, if you’re too anxious to dive in and can’t wait for my post, go for it! There is an online getting started guide as well as an online tutorial for building your first application.

Cheers! :-)

Update 5/20/2009: Well, I’m about to take a much needed vacation, and I have yet to follow-up with a walk-thru post. So, I wanted to at least provide some details here as to what this software requires system-wise. System requirements are as follows (and are displayed in the initial installer screen):

  • No Microsoft SQL Server or SQL Server Express installed [1]
  • No other Documentum software installed [2]
  • Microsoft .NET 2.0 or higher [3]
  • Browser with Sun JRE 5.0 update 16 or higher [4]
  • Minimum of 3 GB RAM (4 GB RAM is recommended)
  • 5 GB of free disk space [5]
  • Intel x86 CPU
  • Operating system–again 32-bit only for this release–is one of the following: Windows XP SP3, Windows Server 2003 SP2 or Windows Server 2003 R2 SP2
  • You must be logged in as a member of the Windows Administrators group, but not necessarily as Administrator

Notes:
[1] Be aware that if you already have Visual Studio (e.g. 2005 or 2008) installed on your target machine, you may need to first uninstall the version of SQL Server that may have been installed with the IDE. If you are running Windows SharePoint Services or UDDI on your target (Windows Server 2003) machine, you may also need to see what embedded database is supporting these services before proceeding with this developer edition installation.
[2] Be sure to understand where you may still have Documentum-related configuration files on disk (e.g. dfc.properties, C:\Documentum, etc.).
[3] Microsoft .NET Framework 3.0 is required for WCF-based consumption of DFS endpoints; so, I recommend .NET 3.0, which includes (requires as its foundation) .NET 2.0. .NET 3.5 is also supported by DFS, if you prefer to leverage WCF “v2.”
[4] This is supported by Webtop and DA.
[5] Keep in mind that, as I noted above, the Zip archive download is a bit more than 1.73 GB. The total size of its extracted contents is not that much larger, but you’re also starting to approach 4 GB; so, I recommend that you have 10 GB free disk space in order to complete the installation with room to spare before cleaning up the extracted bits and the original archive to reclaim that 4 GB.

…and, welcome, CMS Watch readers! :-)

Update 7/16/2009: Be sure to run Windows Update after installing DevEd. Typically, you’ll need to apply SQL Server 2005 SP3. Note that if you upgrade a DevEd environment from 6.5 SP1 to 6.5 SP2 (via uninstall-reboot-install) that you should still run Windows Update after your upgrade, and you may need to re-apply SQL Server 2005 SP3.

When upgrading a DevEd environment from 6.5 SP1 to 6.5 SP2, I also recommend that following the uninstall and reboot, that you confirm C:\Documentum and C:\Program Files\Documentum are empty before you proceed to install the newer DevEd.

Finally, if you’re reading this blog but not the installation guide, please note that you should uninstall DevEd via Start | Programs | Documentum | Uninstall, not via Add/Remove Programs under Control Panel.

Content-enabled applications empathized

Posted on by
Reply

Laurence Hart was kind enough to pick-up my previous post on content-enabled applications and add his thoughts to the subject, especially concerning the role CMIS can play.

From my first post: Content-enabled applications should facilitate the convergence of content, collaboration, interaction, and process.

I agree with Laurence (aka JaneDoePie) that content is an enabler, not the center. All content-enabled applications “should be shaped to work with and enhance the process the users use to perform their work.”

Laurence offers case management as his favorite, generic content-enabled application in order to further ground the point that success is determined by the combination of content, user experience (interaction, more than just UI, IMHO) and process (e.g. collaborative workflow).

I’m in the middle of reading Subject To Change, and already I’ve found its message highly relevant to the subject of content-enabled applications. For example, the book focuses on experience strategy and how to develop organizational empathy where the target users of your products or services are concerned. Specifically, in the case of case management, the book would argue that you, as case management application architect/designer, need to actually observe case workers in their native setting to appreciate how case management really works (or doesn’t). Go beyond theory and someone else’s analysis. Experience business activity firsthand in order to model reality into your solution.

Recently as part of the Case Management Solution Framework xCelerated Composition Platform (xCP) released for D6.5 SP1, a sample application for grants management was shipped that illustrates how Process Suite components can be used to build case-based, content-enabled applications. You can download this package from Powerlink (authentication required). The easiest way to run this sample application is to install it using the express installer, which will install all the right components (with their compatible versions) and the DAR file. You can also download the express installer from Powerlink (authentication required).Please see the update below for the correct link.

A goal of a solution framework is to make it easier to build content-enabled applications such as those for case management. A solution framework should allow you to invest more time in becoming empathic in order to ship solutions that resonate well with your users and drive more efficient business as a result.

In this response, I wanted to focus on empathy’s role. Separately, I plan to pick up the CMIS angle raised by Laurence. Thanks in advance for joining our discussion online…

Update 5/1/2009: A PM colleague pointed out to me that the link to the “one click” installer that takes one from state “zero” (i.e. Windows but not database) to state “ready for proof of concept” is as follows: https://emc.subscribenet.com/control/dctm/download?element=2193203 (authentication required). Cheers!

Addressing MaxReceivedMessageSize issues

Posted on by
2

If you’re a .NET-based consumer of Enterprise Content Services (e.g. those offered via Documentum Foundation Services) and you experience a Windows Communication Foundation CommunicationException having to do with MaxReceivedMessageSize, you may be interested in the details of this post. This post applies both to direct-to-WSDL consumers and also to consumers that leverage the DFS productivity layer for .NET. Guidance herein has more to do with WCF in general; however, it will be offered in a ECS/DFS context.

Depending on the size of incoming messages from services to your application, you may discover the need to increase the maximum received message size. For example, your application experiences the following exception raised by WCF:

System.ServiceModel.CommunicationException : The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element.

An example of exceeding quota could be application requests that result in data package-based responses with a large number of data objects and/or a set of data objects with significant metadata and/or content (e.g. ObjectService.get).

If you implement a direct-to-WSDL consumer of this service using Visual Studio and WCF’s Add Service Reference designer, you will by default introduce a per service binding application configuration file into the overall solution. Therefore, to declaratively increase the maximum received message size, you will edit app.config by focusing on increasing the value of the MaxReceivedMessageSize attribute on the appropriate (named) binding element from the default value in configuration as follows:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding name="ObjectServicePortBinding" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536" messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true">
          <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
          <security mode="None">
            <transport clientCredentialType="None" proxyCredentialType="None" realm="" />
            <message clientCredentialType="UserName" algorithmSuite="Default" />
          </security>
        </binding>
        . . .
      </basicHttpBinding>
    </bindings>
    . . .
  </system.serviceModel>
  . . .
</configuration>

As in the case of a direct-to-WSDL consumer, a productivity layer-based consumer of the DFS Object service may also need to declaratively increase the value of MaxReceivedMessageSize more compatible with actual runtime requirements.

In the etc\config directory path of your local DFS SDK you should find an example App.config file. Please note that this app.config file is oriented toward productivity layer consumers, not direct-to-WSDL consumers via WCF. That being said, the same binding attributes apply to a solution here, too. The difference is how the bindings are declared in app.config.

The productivity layer oriented declaration names a single binding, DfsDefaultService, to act as the binding for all DFS services, except for DFS runtime services, which have separate, named bindings declared. So, Object service gets its (WCF- based) binding configuration from the “DfsDefaultService” binding…and so does, for example, Query service.

To declaratively increase the maximum received message size in productivity layer oriented app.config, you will most likely edit the MaxReceivedMessageSize attribute on the “DfsDefaultService” binding element from the default value in configuration as follows:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  . . .
  <system.serviceModel>
    <bindings>
      <basicHttpBinding>
        . . .
        <binding name="DfsDefaultService" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferSize="1000000" maxBufferPoolSize="10000000" maxReceivedMessageSize="1000000" messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true">
          <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
          <security mode="None">
            <transport clientCredentialType="None" proxyCredentialType="None" realm="" />
            <message clientCredentialType="UserName" algorithmSuite="Default" />
          </security>
        </binding>
      </basicHttpBinding>
    </bindings>
  </system.serviceModel>
</configuration>

You may notice that the DFS SDK-based app.config binding element attribute values differ from direct-from-WCF defaults (i.e. maxBufferSize–1000000 versus 65536, maxBufferPoolSize–1000000 versus 524288, and maxReceivedMessageSize–1000000 versus 65536). This is simply a change to lessen the likelihood of encountering WCF CommunicationExceptions having to do with MaxReceivedMessageSize values.

One technique you can employ to determine what a reasonable MaxReceivedMessageSize value should be for your application is to set the value of your binding attribute/property to the absolute maximum in order to profile actual runtime message size using a web debugging proxy like Charles or Fiddler. That is, temporarily set MaxReceivedMessageSize to 2147483648 (i.e. Int32.MaxValue), pass your SOAP messages through, for example, Charles via port forwarding, review response message content length values, and reset your default runtime MaxReceivedMessageSize value accordingly.

If you prefer to take a declarative approach to WCF binding configuration for your application but you’re concerned about a user setting the value too low, you can always interrogate values at runtime in order to ensure that they’re sufficient.

For example, a productivity layer-based client could do as follows:

System.Reflection.FieldInfo appConfigInfo = typeof(ContextFactory).GetField("appConfig", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);
System.Reflection.FieldInfo agentServiceBindingInfo = typeof(AppConfig).GetField("m_agentServiceBinding", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);
System.Reflection.FieldInfo contextRegistryServiceBindingInfo = typeof(AppConfig).GetField("m_contextRegistryServiceBinding", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);
System.Reflection.FieldInfo defaultServiceBindingInfo = typeof(AppConfig).GetField("m_defaultServiceBinding", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);
BasicHttpBinding binding = new BasicHttpBinding();
binding.MaxReceivedMessageSize = 0x7fffffffL;
binding.MaxBufferSize = 0x7fffffffL;
agentServiceBindingInfo.SetValue(appConfigInfo.GetValue(contextFactory), binding);
contextRegistryServiceBindingInfo.SetValue(appConfigInfo.GetValue(contextFactory), binding);
defaultServiceBindingInfo.SetValue(appConfigInfo.GetValue(contextFactory), binding);

Of course, in a production app, I’d ensure that there is a log (auditable event) of such programmatic override activity. I might also consider presenting the user with a suggestion, requesting that the software be given the opportunity to auto-correct the value (e.g. updating the effective application configuration file).

Building content-enabled applications

Posted on by
7

Both Pie and Marko have blogged about content-enabled applications, or what Gartner calls CEVAs (content-enabled vertical applications).

As it so happens, I’ll be presenting there will be a session on this subject next month at EMC World 2009.

Based on my research of what folks label a content-enabled application, two things rise to the top: process (surrounding content) and subject matter expertise (individual or group surrounding process), and context. OK, three things.

For example, Forrester defines content-centric applications as “solutions that put the business’ content to use, and add context along the way–to support line-of-business needs.” Example solutions include customer self-service, claims processing, proposal management, contract management, and case management.

Other CEVA vendors argue that content-enabled applications are process-oriented, not content-centric. I tend to prefer this viewpoint. A claim is valueless in itself. Only once is claim is processed is value realized, including taking a future liability off the books.

Content-enabled applications should facilitate the convergence of content, collaboration, interaction, and process.

Before you leverage your content in an application to generate value, ask yourself few questions:

  • Who uses the content? Why? How?
  • What processes does the content support?
  • If I’m not a subject matter expert for this type of content, who can I involve to design a better application experience?
  • What processes does it support?
  • What context is involved, either centrally or peripherally?

Start with something familiar to just about anyone these days: email (or IM, micro-blogging, etc.). Answer the questions. See how applications, for example, around email have evolved. Think about where current email applications may have untapped potential. Etc.

So, where have all the CEVAs gone (as Marko asks)?

  • I think that we in the content management business do ourselves a disservice by overly complicating concepts (e.g. behind TLAs or FLAs). Although fine as a conceptual catalyst, CEVA is self-defeating, IMHO, as a rallying label.
  • I agree that CMIS has great potential to increase the availability of content-enabled applications, if for no other reason, because application development that consumes the proposed standard should have a greater return on investment by being applicable to multiple content repositories. (ECM vendor partners are you listening?)
  • In the end, it’s the application, not the content or the process or the people. That is, if you’re just adding a document and perhaps a workflow to some code, you may have an app…but it won’t be used. Focus on user experience (i.e. the meaningful, intuitive presentation of content, context and process together).

Back to EMC World…          Orlando, FL - May17-21

I’ll miss interacting with ‘Zilla at the conference. It was at EMC World in 2007 (also held in Orlando, FL) that I first met Mark in person.

If you are able to make the conference and consider yourself to be a “2.0 type,” you may be interested in Len’s advert. Looks like there is even a LinkedIn event established for the conference.

I plan to tweet the conference and otherwise engage with the community. In the meantime, if you plan to attend my session (as presented by others), please feel free to comment (here or ECN) on your thoughts about content-enabled applications and what you’d like discussed or demoed. Thanks in advance.