The purpose of the PDF forms contest is to create a public library of sample Forms and LiveCycle Designer templates that other PDF creators can use. The contest is open to qualified participants in any industry. You can even use a free 30-day trial copy of Acrobat 8 Professional to create your entries.

There are two entry categories:

Category: Fillable Forms

Show sophisticated and visually interesting fillable PDF Forms created using the forms toolbar in Acrobat 8 Professional, and may include interactive form elements, auto-formatting, calculations and Javascripting.

Category: LiveCycle Designer Templates

Develope form templates that can be used in LiveCycle Designer 8, and may include graphics, interactive form elements, library elements, auto-formatting, calculations and Javascripting. (LiveCycle Designer is included with every copy of Acrobat 8 Professional for Windows)

Notable entries will appear in the PDF Forms gallery. Entries may also qualify to win Adobe software, video cams and t-shirts.

The contest runs from Mar 10, 2008 until Apr 30, 2008.

Full details at http://www.acrobatusers.com/contests/forms/

Before talking about process serving and composite application development, we should spend a little time talking about architecture. Don't worry - I won't get into a long winded discussion about architecture and design patterns... That's what Duane Nickull is for :) In his post about the new SOA Whitepaper, Duane talks about Web 2.0 as a common set of architecture and design patterns. The bottom line is that Web 2.0 applications are made up of a Service Oriented Architecture which is accessed by a Service Oriented Client.

In this diagram, we quickly recognize the Resource Tier and the Service Tier. This is where IT professionals have spent a vast amount of time and resources ensuring that backend resources are available and accessible. Web Services have been created, Java Beans developed, services were born. So, what's the problem? The problem is that the needs of the business often outpace the bandwidth of the IT department. New requirements flood the IT shop, new services are born to meet the demand. Seems harmless enough... right? Turns out, not so much. All of a sudden, specialized services are invading the once clean and sterile SOA scene. The reality is, service multiplication causes maintenance nightmares.

Concept: Process Serving

What books like Secrets of SOA are telling us is that we need to take a step back and re-evaluate SOA approaches and implement what we have learned. One of those key lessons learned is that we need the ability to "string" multiple generic services together in order to create specific composite services. This is what Terry Borden and Bill Mitlehner refer to as process serving. Process serving is the ability to link two or more services together, the execution path of these links are driven by business rules specific to the implementation, and deployed as a new "composite" service with the same availability and accessibility as the atomic services themselves.

Theory: Service Container

For process serving to occur, you need to have an extremely flexible environment that would be able to expose a "workflow" like process engine that could invoke generic services synchronously or asynchronously while maintaining complete control over execution flow and state. Among other things, this service container would require:

• Registry/Repository where all execution assets and state information can be stored.
• Sophisticated foundation would be required to manage common tasks like logging, file system access
• Job management to handle the various requests 
• Invocation layer that would be able to dynamically register endpoints for new composite services
• Granular security model
• Design tools to facilitate process definition and deployment

Reality: LiveCycle ES

This is exactly what Adobe LiveCycle ES provides. Sure, we talk about PDF documents and document services, that is our bread and butter. But when you take a serious look at what the LiveCycle ES platform delivers... you get process serving. LiveCycle ES implements a service container on top of the J2EE stack (Weblogic, WebSphere, JBoss) with a dynamic invocation layer which automatically exposes multiple endpoints for each new service or composite service. A sophisticated foundation with common services and integration points. A security model (User Manager) which leverages existing user registries. A service registry/repository to store and maintain service execution and state. Of course, LiveCycle ES comes with a complete set of design tools built on Eclipse (Workbench).

A good friend of mine, Greg Wilson, has recently posted several interesting articles around LiveCycle ES.  His latest post is particularly of interest since it is directly related to what I have begun to cover here. I highly recommend that you take 15 minutes and watch his introduction to LiveCycle ES video. Also, take the time to have a look around the LiveCycle Developer Center... Read some of the great content posted there and download a trial copy. The download is quite large, if you would like to receive a DVD shipped to you, please drop me an email with your shipping information.

In the next article, I will introduce LiveCycle Workbench ES and how it is used to create composite services that can be deployed to the service container.

Make sure that you sign up for the pre-release program by visiting the LiveCycle Developer Center.

"The ultimate value of SOA is the ability to combine automated business services to create new market offerings that may reduce time-to-market and development costs."

This statement was made by Terry Borden and Bill Mitlehner in chapter 4 of the Secrets of SOA. I find this statement very interesting since this is exactly was Adobe LiveCycle ES offers.  This new release has been completely re-designed to enable you to visually "string" document services together to match your requirements. Now, I say document services because that's what we are in the business of selling. But don't let that fool you. The LiveCycle ES architecture is built on SOA principals which enable extensibility and flexibility beyond just documents. Mike Hodgson wrote up an excellent article on Adobe DevNet on how to deploy your own POJOs in LC ES 

Everything LiveCycle sits on what we have dubbed the Foundation. The foundation is powered by a service container which exposes two types of services:

• Packaged POJO (Plain Old Java Objects) classes: Java class accompanied by a component.xml file which describes which methods, inputs and outputs are supported by the class.
• Orchestrated services: Using Workbench (Eclipse based graphical editor), a designer drags the above mentioned packaged POJO classes onto a canvas and links them together based on business rules and/or application requirements.

In each case, once the service is activated, it is registered in the invocation layer which automatically creates invocation methods (endpoints) for that service. The default endpoints are: Web Service, Flex Remoting and EJB. Additional available endpoints (configured manually) are: Watched Folder, Email and Task Manager (only used in conjunction with LC Workspace ES).

The latter type of service (Orchestrated Service) is exactly what Terry and Bill are describing in their chapter. LiveCycle ES provides developers and business analysts with the ability to build processes in a graphical environment, set service properties using property pages and link services together based on their requirements. The key here is that the second that "process" is activated, it is deployed within the service container and from that moment on, is available just like any other service. Of course, there are security constraints that are applied, etc. The point is that very few people understand the power and flexibility that LiveCycle ES provides. With this introduction, I will post several examples in the next few weeks that illustrate my point.

Get the LiveCycle ES Trial now

Regardless of the vertical that you are in, one of the most challenging obstacles to overcome is connecting mobile agents to back office processes. Once that agent leaves the connected world and begins his/her day interacting with customers, suppliers or citizens - something bad happens... All that investment in technology in the back office to increase efficiencies and save money falls apart.

Those field agents are collecting valuable information that needs to be processed as soon as possible - but how does that information make it back into the SAPs of the world? OK, maybe I am going a little over-board here... Many organizations have built custom solutions to bridge that gap or have found some specialized application that does most of what is required. Hmmm, how do we get this application installed on all of the mobile devices the field agents use? And what happens when Fred (good old Fred who built the custom application) leaves the company or gets a promotion? Who is going to maintain that app?

OK, that was a long-winded intro for someone who hasn't posted on his blog for a while... I guess I have too much to say, and not enough time. But wouldn't it be cool if you could have an application that runs on a free runtime provided by a trusted vendor? And you could use this runtime to easily push new applications out to those laptops? And what if that application could automatically detect if it has connectivity to the network or not? And what if it could seamlessly continue to function as if it were connected and automatically store all of your work and automatically submit that work as soon as network connectivity is detected? Now that would be cool!

Well let me introduce you to a sample application I created to demonstrate all of that craziness. This application was built using Flex Builder 3 Beta 2 and runs on AIR Beta 2 . The goal of this sample application is to demonstrate how AIR can help you easily build Rich Internet Applications with the power of off-line and PDF integration.

I called this sample application the Equipment Requestor because I wanted a simple use case that would not overshadow the base message here. The idea is that you are a field agent that may or may not be connected to the network. Each request that is completed and submitted kicks off a business process within the back office. Of course, I am using LiveCycle ES as the process engine (more to come on that - I have lots to say about ES - believe me). The business process in this case is pretty lame - accept data in XML format, merge it with a form template to generate a PDF document. Then, apply Reader Extension rights to that document so that the user can digitally sign the document, etc.

Now, this sample app needs some way to store the information collected by the agent. Not to mention the submission data while off-line and the PDF documents that get returned by LC ES. Since beta 2, AIR provides an embedded database engine - SQLLite. Sounds like a plan to me! When the sample app loads, it looks to see if a local database exists; if it doesn't - it creates one, if it does - it loads what's there. When the users enters data into the request module of the app and clicks submit,  then we need to know if we are on-line of off-line. Well AIR to the rescue again. A NetworkMonitor API is provided that allows you to easily detect network availability. In the sample app, I indicate availability with a traffic light located in the bottom right corner. If there is network connectivity, then the submission is executed in real-time. LC ES is called, the form is rendered and rights are applied. The result is a PDF document send back to the app. That PDF document is then stored in the local database for later viewing.

Oh yeah, AIR does PDF too. So the PDF is stored in the database and we need to enable the end-user to view that document. Well, we use the HTMLControl included with AIR and tell it to display the PDF. The HTMLControl uses the Reader plugin (just like any other browser) to display the PDF. The user can interact with that PDF - digitally sign it, add comments, etc

.

Get the application here.

Get the source here.

For more details on the AIR features I mentioned, Mike Chambers authored an excellent article here.

We have been heads-down working on the LiveCycle ES launch. Might seem like no big deal, but the LC ES architecture is such a dramatic change from it's predecessors that the amount of work required to get our field organization trained and ready has been monumental.

With Adobe announcing AIR and releasing LC ES, there is so much to talk about. Within the last year we have gone from LiveCycle being a collection of server products to be re-architected to fit the SOA reference model and AIR being announced - the ultimate Service Oriented Client.

More to come soon...

To view the results of the conversion, get the free trial version of Adobe Designer here.

The xForm Converter will be part of the Adobe Designer 8.1 release scheduled for later this spring. At that point, it will no longer be a standalone utility. The coverter will be invoked when using the File/Open... menu option and selecting the xForm option in the file type dropdown.

Christoph, much like myself, has a strong focus on LiveCycle and was introduced to Flex and Coldfusion when Adobe acquired Macromedia. If you happen to be hanging out in Antwerp (Belgium) the week of December 11th, you can meet him at Javapolis. He will be hosting a couple of Flex sessions and one of those will focus on Spring and Hibernate.  

Welcome Christoph, we all look forward to your contribution to LiveCycle and Flex communities.

The LiveCycle Productivity Kit is an open-source project. The source is also posted in subversion, so feel free to download, update and extend :)

I will be posting some Flex and CF samples using the kit in the near future. I am working on a Flex sample right now that uses the LiveCycle Productivity Kit to communicate with LiveCycle Workflow. The potential for enterprise applications is impressive!

4.1 Define the non-modal window: Since we have walked though the Hibernate code previously, I will not repeat myself here. Let's create the AddEmployeePopUp.mxml file. Copy and paste the following MXML into a new file in your application called AddEmployeePopUp.mxml.

Take time to look at the AddEmployee() function in the above MXML. This function demonstrates how to add a new entry in the database.

4.2 Make the non-modal window appear: Now that we have defined our popup window, we need to call it so it will be displayed. To do this, we will add a new function to the Main.mxml application called showAddEmployeeWindow(). This function will use the PopUpManager to display our add employee window. Copy and paste this code in the script block of your Main.mxml file:

NOTE: You only need to copy the function highlighted in bold. All of the other functions are already in your Main.mxml file.

So now we have a function that will displat the popup window, we need to add a button to our control bar which will display the window to add an employee. Locate the ApplicationControlBar in the Main.mxml file and add a new button:

<mx:Button label="Add New Employee" id="button1" click="showAddEmployeeWindow()"/>

That's it! Our application now has the ability to add new records in the database.