A brief form server history

I was reading a posting recently on FlexLive.net about how Live Cycle has yet to cross the technology chasm. This got me thinking about Live Cycle Forms and in particular its form server component. Did you know that this core piece of LiveCycle Forms is now seven years old?

The form server began as a research project back in 1999 in order to leverage the power of another fledgling technology called XFA. The idea was that with form templates being defined in XML one could dynamically generate forms for a variety of clients. The form server was first released as ReachForm and marketed as the easy way “for people to access and submit forms online using the Internet”. The major feature of ReachForm then was its ability to generate form content for any browser from a single XFA definition. One could even generate multi-page HTML applications complete with client and server side scripting!

The form server was originally a Windows only COM-based solution written in Visual Basic. As a result it was a Windows only solution but could also be accessed by non-Windows platforms using SOAP.  Over the next four major releases new transformation formats were added (including PDF!) as well as digital signature support and higher performance.

Today, COM is long gone and has been replaced by Java and J2EE. Some old features have been dropped but new ones have been added as well. Even still, while its implementation is vastly different the underlying architecture and core capabilities of the form server has largely remained the same.

My point here is that while LiveCycle does indeed have a chasm to cross the chasm itself keeps moving.  What makes a good technology great is its ability not only to cross the chasm-of-the-day but also manage to keep up with change. Technology is liquid and any great software must be able to mold and transform itself in order to meet the demands of technology. The form server has proven itself over the past seven years that its core architecture is able to keep up with the pace of changing technology in the enterprise and still deliver the same great results.

The form server technology that is now part of Adobe LiveCycle Forms has stood the test of time and will continue to be innovative well into the future.

technorati tags:, ,

Blogged with Flock

Share on Facebook

6 Responses to A brief form server history

  1. Oliver Merk says:

    This is good stuff. I’m just in the process of becoming an instructor for LiveCycle and this fills in some of the historical gaps.

  2. Kevin Matassa says:

    Way to go Anthony. Providing history context is really need in the case of Forms — an often misunderstood product.

  3. A.PETROPOULAKIS says:

    I try to invoke a pdf form using SoapClient. My application runs on Oracle Application Server 10g and LiveCycle on JBoss.I cannot render the form. My application is running on localhost:80 (Oracle Application Server) andLiveCycle on localhost:8080 (JBoss).(It just returns a blank page).Do you have any idea? (I made a request at forums at LiveCycle Forms – Subject:SOAPClient at Oracle Application Server cannot Render a PDF from LiveCycle running at JBoss)

  4. nep says:

    Hello,Just to give you some more historical information: in the time or reachform, formserver was in fact not necessary if you would use just the xml format (without the need to produce PDF, that in that time was non-interactive and static; and without the need to converto to html, which in that time procude not very good html). I´m saying formserver was not needed because all the stuff (merge data and xfa template) was done by the client (an activex component)!. The only thing formserver was prepare to do was to gzip and base64 encode the streams (data and template).When Adobe bought the solution they add the PDf vision to accelio solution (reachform). Doing that, and because the new activeX was actually Acrobat Reader (free to everyone), formserver should be more necessary (so Adobe could make some money:) ). So, since that time, Acrobat Reader can´t read xfa directly (at least we think it can´t).

  5. nep says:

    Hello,Just to give you some more historical information: in the time or reachform, formserver was in fact not necessary if you would use just the xml format (without the need to produce PDF, that in that time was non-interactive and static; and without the need to converto to html, which in that time procude not very good html). I´m saying formserver was not needed because all the stuff (merge data and xfa template) was done by the client (an activex component)!. The only thing formserver was prepare to do was to gzip and base64 encode the streams (data and template).When Adobe bought the solution they add the PDf vision to accelio solution (reachform). Doing that, and because the new activeX was actually Acrobat Reader (free to everyone), formserver should be more necessary (so Adobe could make some money:) ). So, since that time, Acrobat Reader can´t read xfa directly (at least we think it can´t).

  6. Halesha says:

    Hi,I need some information regading first server used in the organisations could you please do it..Thanks..