Tag Archives: LiveCycle

Upcoming speaking engagements

Conferences have always been about networking and when you have the privilege to speak at a conference it’s about engaging with your audience, listening to feedback and sharing ideas.

In the next several weeks, I’ve been given the opportunity to speak at two different venues: Adobe's annual MAX conference and Day Software's Ignite conference. This will be my first time speaking at either venue, and I’m really looking forward to the experiences.

So, if you’re in Chicago, Los Angeles or Berlin and want to learn more about Adobe’s focus on customer experience, I encourage you to take advantage of the following opportunities:

  1. When Content Meets Applications, October 14, 2010, Day Ignite Chicago 2010
         Come hear how the combination of Adobe and Day will help you realize greater customer experiences through contextually agile content and applications that have been previously managed separately.
         Speakers: Alex Choy, VP of Engineering and Technical Marketing, LiveCycle, & Craig Randall, Principal Scientist, Adobe
  2. Realizing Great Customer Experiences with LiveCycle ES Next, October 25, 2010, Adobe MAX 2010 (repeated on 10/27/2010)
         Hear how focusing on user experience can improve the value of the enterprise applications you deliver. Also learn about architectural changes in the next release of Adobe LiveCycle Enterprise Suite as well as new features in servers, client runtimes, and tools that will allow you to build, deploy, and measure excellent customer experiences.
         Speaker: Craig Randall, Principal Scientist, Adobe
  3. Strengthening Adobe’s Enterprise Platform with Day Software and Open Development, October 25, 2010, Adobe MAX 2010
         Learn how the combination of Day’s leading web solutions and Adobe’s enterprise portfolio provides a unique opportunity to developers: a unified web content and application delivery platform. By introducing web content management, digital asset management, and social collaboration to Adobe’s product portfolio, the combination offers developers an impressive set of capabilities to create, manage, distribute, and monetize content while delivering the best experience possible. Learn why open development is the cornerstone of Day’s R&D strategy for web content management and how it can help software development organizations design more adaptive systems and leverage the power of virtual communities.
         Speakers: David Nuescheler, CTO, Day Software, Roy Fielding, Chief Scientist, Day Software, & Craig Randall, Principal Scientist, Adobe
  4. When Content Meets Applications, November 3, 2010, Day Ignite Berlin 2010
         Come hear how the combination of Adobe and Day will help you realize greater customer experiences through contextually agile content and applications that have been previously managed separately.
         Speakers: Alex Choy, VP of Engineering and Technical Marketing, LiveCycle & Craig Randall, Principal Scientist, Adobe

See you there! Otherwise, check back later for updates online. Cheers.

Update on 10/14/2010: The presentation for #1, above, is now available here.

Update on 10/27/2010: The presentation for #2, above, is now available here.

Update on 10/29/2010: The presentation for #3, above, is now available here.

Update on 11/3/2010: The presentation for #4, above, is now available here.

Understanding LiveCycle ES2’s application model

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).

Rich Internet Applications

During the MAX 2009 conference, Duane Nickull was interviewed by DZone on the subject of RIA architectures. As an architect, I appreciated Duane’s comments about the responsibility of architects, versus developers, where RIAs are concerned (e.g. focusing on and valuing interaction design and user experience, distilling key business requirements by working closely with those the RIA will serve, being mindful of the framing process-oriented context, etc.).

In particular, don’t frustrate users resonates with me (e.g. it’s a non-technical answer to “what is an RIA?” (or “reeyah”). Duane’s Revenue Canada example (or not “getting” this) is a good one. It just so happens that I encountered my own today…

First, two exhibits off Twitter:

Don’t get me wrong, more vendors need to be reaching out and engaging with their communities in deep and meaningful ways. So, I’m not suggesting that creating a forum for community discussion is bad. However…

What if, instead, the forum was seeded (pre-launch) by a reasonable distillation of those who’ve already voiced their concerns, like Pie? The Web is there to be culled–“listened to” if you will–you just need to mine it.

As Duane and his co-authors talk about in Web 2.0 Architectures, more and more of us are living declaratively. Certainly this is true when it comes to providing candid feedback and standing behind things we believe in (e.g. vendors we want to succeed…and those we don’t).

So, an alternative forum post could have listed Pie’s identity management feedback alongside the feedback of others–fully annotated with community profiles, source links, etc. Of course, those supporting the forum could proactively reach out to folks like Pie to confirm that discovered feedback is appropriate for syndication and could enable contributors to easily follow the conversation moving forward–ideally in the medium of their choice (e.g. email, feed, etc.).

Update 12/29/2009: Of course, Pie, being the strong advocate he is, reached out again and updated the forum post himself. :-)

Adobe LiveCycle ES2

If you’re at the Adobe MAX conference this week, then you already know: Adobe LiveCycle Enterprise Suite 2 has launched.

And judging by the attendance at the pre-conference session on LiveCycle, there’s significant interest in building user-centric applications in the enterprise–exactly what LiveCycle ES2 is designed to unleash!

As you will see on the main LiveCycle site, ES2 is all about:

Given my work on smart client architectures, I have to say that I’m particularly excited about the potential in LiveCycle Mosaic.

Mosaic provides a compelling framework that brings together aspects of business and collaboration to drive richer context pivoting. The task (goal) at hand is more richly represented at all times, allowing the user to pivot more effectively and efficiently and leading to better outcomes more rapidly.

Mosaic is not merely about aggregation as is portal technology. Rather, Mosaic is about intuitive, contextual composition that puts the focus back on the user’s task rather than all the supporting systems underneath. Users can access their mosaics either in their browser or on the desktop (via AIR support). Catalogs of mosaic application assets like tiles can be shared to encourage reuse and to simplify future composition.

LiveCycle Mosaic should be a boon for user-centric, content-enabled applications development.

By the way, if you’re not at MAX (like me), you can still participate online. For example, view the top three sessions from each day at MAX on demand. (Today’s keynote stream was five-by-five at my desk!) Check out the MAX Companion, too, while you’re there. October 11 will see all the MAX content posted online, too!

Cheers! :-)

Update 11/25/2009: Please read the “what’s new in ES2” document. I also recommend that newly revised LiveCycle Developer Center (aka DevNet site).