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