As already mentioned in a different place: sounds interesting.
Some thoughts of mine on this:
I'd prefer a REST service over a SOAP service. Ideally, this would work
with plain JAX-RS so it is independent of the implementation but since
such a service would certainly require multipart support that seems
impossible. A real pity that hasn't been standardized, yet.
We already have basic (demo) servlets in Apache FOP but they are not
suitable for real-life scenarios. The problem with that one is mainly
that the caller needs to know the location of the stylesheets and give
them as local file names which is totally against the idea of a servlet.
Furthermore, there's also no guard against DoS attacks which are easy
with a CPU- and sometimes memory-hungry FOP. Just throw a handful of
jobs at it simultaneously and see what happens.
If I had to come up with a set of requirements, it would look like this:
- Ability to set up a config file.
- Ability to set up a URIResolver that can be used to access the
stylesheets, fonts, images etc. without the requirement to know where
exactly these resources are (file-system, CMS, website etc.)
- Caching of stylesheets (Templates instance)
- Ability to configure pre-defined processing scenarios, identified by a
name, that include stylesheet(s) and other resources. [1]
- HTTP POST payloads can be XML files or URIs identifying XML content
lying elsewhere (configured URIResolver must be able to resolve that).
- Semaphore for limiting concurrency.
[1] Basically, I would want to just HTTP POST an XML file with a
Scenario header entry and get back my PDF (or whatever MIME type I
specify in the Accept header).
I must say that I have all that (and more) already for myself as part of
a larger solution. I recently threw out Apache CXF in favor of Jersey to
take Spring out of the equation which in an OSGi environment constantly
caused grieve in production (Spring OSGi services simply don't come up
reliably for me). So, you can guess by now that even though I find this
an interesting topic and a useful addition to FOP, I wouldn't need that
myself. But I'm pretty sure that there are people who could profit from
that since they don't have to integrate FOP into such a service
themselves. But it would have to be easy to set up.
Generally, CXF seems extremely heavy-weight for something like this.
Most of my requirements above have nothing to do with the REST service
itself. The tricky thing on the service-side is just the multipart
support. So basically outfitting a servlet with multipart support and
covering the requirements above would already solve the whole problem. I
don't think that CXF (or any other JAX-RS implementation) would make the
whole task that much easier.
On 10.03.2011 00:01:18 Benson Margulies wrote:
It occurred to me that some might find it congenial to be able to
download a .WAR file that drops into Tomcat or Jetty and provides a
REST (or, perhaps, SOAP?) web service that runs FOP. Using Apache CXF,
this would be a rather straightforward exercise. This would make it
easier to set up FOP once, with whatever configuration appeals to you,
and then use it on your network.
I could bang such a thing together using Apache CXF if you all, who
have a much better sense of how FOP gets used than I do, think it's
worthwhile.
It would be an independent build from the main fop tree, and, warning,
it would get built with Maven.
Jeremias Maerki
