Paul Hammant wrote: > > It still won't help in your communication with Coocoon using RMI. > Cocoon is not a block in it's own right *yet*. I guess if it was it > would also solve your problem. I've talked to Berin about this and he > thinks that it could, in the future, be a block as well as a WAR file > deployable app.
This mail may be a bit off-topic, but perhaps it can help thinking along different lines for communicating with Cocoon. I use SOAP (via a self-written Cocoon taglib) to communicate with Cocoon. The taglib is downloadable from my homepage http://ulim.cocoonhost.com/ (however, it only supports Cocoon1). In any event the taglib is a generic SOAP client that acts as a HTTP interface on top of SOAP services. That means the clients do not have to speak SOAP, they just have to speak HTTP. So you can write clients in Perl or whatever language suits you - after all, why should programmatic clients require a particular platform (language/library/runtime), when interactive clients (webbrowsers) don't? I believe that programmatic clients should enjoy the same freedom as interactive clients and therefore speak HTTP. The server-side SOAP services need to have the SOAP libraries available (I use Apache SOAP), but no special code is needed - so you can take any of your programs and let it run as a SOAP service without changing the code. I have a fairly elaborate installation of SOAP services and programmatic clients, who use them. The SOAP services can run on a server different from the machine Cocoon runs on, as can obviously the clients. The whole shebang has been in production for about a year or so and proved to be maintainable and reliable. I will eventually convert these SOAP services into Avalon blocks, since Avalon is obviously a more robust and feature-rich platform than my quick hack. But there's a couple of functionalities that I need for that: - a SOAP communication layer for Avalon/Phoenix - an HTTP layer on top of the SOAP layer, so my programmatic clients only need to know HTTP - JMX or another management concept, so I can see how that ties in with the SOAP stuff - XML services like those in Cocoon, but more modularized As we're running a production system under Avalon/Phoenix, I'm not too keen on changing the basic architecture too frequently, so I'll wait for a clearer picture on the above issues and meanwhile let my SOAP installation do its thing. Ulrich -- Ulrich Mayring DENIC eG, Systementwicklung --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
