How does fleXdoc fit in a service oriented architecture (SOA)?
The heart of fleXdoc is the API (application programming interface): it merges data (supplied as XML) with a document template. But an API cannot be easily shared with other projects: they can get their own copy, but those are very hard to maintain: new versions
of the API need to be distributed to all projects, templates are not stored in a central location, etc.
To overcome such problems, fleXdoc also comes with a webservice. A single installation of the webservice can be used by all project. There's only one template-store and the stateless-design of the webservice allows for load-balancing scenario's, so
SLA's can always be met.
The figure below shows the overall architecture. The webservice itself only handles the loading of templates and internally uses the fleXdoc API to do the actual document generation.
The generation process
The generation process consists of several steps:
- An in-memory copy of the template is created
- For all parts of the template (headers, footers and the main document) the following steps are executed:
- Perform an XSLT-transformation to merge the XML-data with the part's contents (which is also XML)
- Execute this entire generation proces for each included/imported templates and include/import the results