Forum OpenACS Development: SOA needs to talk to Tcl App Server API, not just the Database
We've come up with the idea that OpenACS is really just a database [...]
The problem is that although the above is a useful metaphor and guideline, it is nowhere near 100% true of OpenACS in practice - nor should it be!
For example, look at how user creation is handled. Last time I checked, the Tcl user creation procs call a whole bunch of different helper procedures, in an entirely non-obvious fashion. There is an underlying simple-looking PL/SQL object-like API, but in fact it is not sufficent, it only does part of the work. Correctly creating a new OpenACS user is totally dependent on calling the correct Tcl proc. Now, that particular example could probably be alleviated by refactoring the existing OpenACS use creation code. But there must be many other examples. E.g., cacheing. Sooner or later, your XML-RPC SOA stuff is going to need some way to say, "Change X, and then please also flush the corresponding cache Y."
Non-trivial real-world integration with remote systems is going to require access to the OpenACS Tcl API in some fashion. Access to merely the PL/SQL (or plpgsql) API is not sufficient.
Moreever, it would probably be a bad idea to make the PL/SQL API sufficient! At least arguably, the gratuitous over-dependence on PL/SQL introduced in ACS 4.0 is one of OpenACS's core weaknesses - and OpenACS hackers much more expert than me seem to think so too.
Ideally, going forward I would like to see a complete, well-factored Tcl API running in AOLserver, which uses PL/SQL only where specifically useful, with no attempt to give the PL/SQL API full coverage. (I suspect Gustaf has some thoughts and has done some work along those lines, perhaps from a relatively XoTcl-centric angle.)
SOA-style programmtic control would then logically hook into this clean and comprehensive Tcl API. However, there's no reason you have to implement one before the other, you could build in some sort of general SOA Tcl interface now, use that to write whatever ad-hoc SOA functionality you really need right now, and then only later revisit a refactoring of the underlying OpenACS APIs. Indeed, getting SOA to work out in the wild, on real-world projects, would probably give you a lot of ideas about where and how you'd like to improve the OpenACS APIs in the future.
Also, above I repeatedly say "Tcl API" because that happens to be what OpenACS uses, but in this context Tcl is largely incidental - what I'm really talking about here is OpenACS's "application server API", and for better understanding, that's probably the term that should be used when talking to outsiders.
If OpenACS actually needed to support another in-process programming language, defining bindings for it to the canonical Tcl-based app server API would be pretty straightforward. But of course, such multi-language support is much harder and messier if you don't have a really good and clean canonical API - which is basically the current de facto situation in OpenACS.
Note, semi-related, the zipfile of the old code I posted back March 2005 to allow a client AOLserver to login under SSL to a remote OpenACS server is still available on my website.