LiveCycle ES2’s application model best practice – Modularity

In LiveCycle ES2 the development model has changed from the repository centric approach that was used in previous versions. The new development model is application centric rather than relying on loose assets in the repository. When developing applications it is critical that proper modular design patterns are used. There are 3 primary factors that should be considered:

  • Number of processes in the application
  • Physical size of the application (the number of bytes)
  • Actions executed by the application’s process during deployment

There is no set limit for the number of assets within an application; however larger applications could lead to issues during deployment due to transactional constraints.  LiveCycle was tested with significantly sized applications, however, a point will be reached where deployments will suffer from performance issues if applications become too large or complex. In addition, it should be noted that manageability and maintenance of an application will become more difficult as the number of assets in an application grow. Also note that the use of slow performing systems and network latency will exacerbate deployment problems with large applications.

Modularity should be a primary development objective when designing applications.  Putting all assets into a single monolithic application does not take advantage of the application model and the modularity that it allows.  Modular development will allow for greater control over versioning, better performance, and much more flexibility in application design.  Modularity does mean breaking up application assets simply to reduce the number of items in an application.  Assets should be grouped so they target a specific use case, area of functionality, or so they are grouped because they are maintained in a similar way or by a similar group of developers.

Consider the case of Java and creating applications; it is possible to put all of your Java classes into one jar file.  You could even take third party libraries, unjar them, and then rejar them into your applications jar file.  If you took this approach you would quickly reach a point where your application is unmaintainable.  Application development in LiveCycle should be thought of in a similar fashion, taking advantage of the capabilities that are present to provide modularity.

How to separate existing applications will depend on the interrelationship of assets held inside the application.  In most cases, when an asset is moved to another application the other assets that depend on it will need to be modified to reflect the new location of the asset.  For example, a process that uses a form would need to be modified to use the new form asset in its new location.

Ultimately, as there are no set guidelines for actual modularity of any given application, the developer will need to exercise reasonable common sense when developing in the ES2 application model. Having said that, if one begins to see dozens of process or assets accumulating in an application, this should be a signal to review the application’s modularity. Another warning sign is if an application deployment begins to take prolonged times (over a few minutes) or actually timeout.

For more information on the LiveCycle ES2 application model, please see:

Craig Randall’s blog post on the subject:

http://craigrandall.net/archives/2010/05/livecycle-es2-app-model/

 

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)

About Darren Melanson

Darren is a development manager working on the ADEP product in Adobe Systems.
This entry was posted in Adobe LiveCycle ES, Adobe LiveCycle ES2 (9.0.x). Bookmark the permalink.

2 Responses to LiveCycle ES2’s application model best practice – Modularity

  1. nep says:

    Hello,

    First, thank you for this helpful information.

    Can you tell me what is the runtime isolation between different applications deployed to the server, or can you point me to some tutorials talking about this? (both in ES and ES2.0)

    I would like to understand how they are independent or shared related to heaps and stuff like that, and how I can share data between different deployed applications.

    thank you!

    • Darren Melanson says:

      Hi Nep,

      LiveCycle applications are not the same thing as Java applications, so the concept of isolation isn’t the same. Think of you building a Java application with a bunch of classes and methods, you as the designer can determine who can see what method or class based on leveraging language semantics such as private, protected or public. The same thing applies in LiveCycle, if you build a business process, it’s up to you to determine who can run it (via securing invocation endpoints). So, its very difficult to answer your questions given that there is no direct relationship to how a LiveCycle applications share things like memory or data since it’s all just running as a Java application in the hosted container.