Here are some more details about the portal I made using the soap-gateway package:
- My client is the "City of Mantova" (the local government authority of the city of Mantova)
- The portal will provide services about all the local taxes managed by the "City of Mantova", the main of wich being the "Imposta Comunale sugli Immobili (ICI)" (i.e. a tax on real estate property)
- Registered users will be able to
- perform several queries about their fiscal declarations and payments
- calculate the amount due for a given fiscal year with regard to their real estate properties
- submit their fiscal declarations and (in the next release) pay the amount due
The portal is made up with two packages.
The first (soap-gateway augmented with the procs implementing the web services) talks to a back-end server (OpenACS 3.4 + PostgreSQL) used by the "City of Mantova" in his intranet to manage local taxes. AFAIK Postgresql is not able to generate directly XML and so I've used tDOM to create XML from the result sets.
The second package interacts with the soap-gateway via XML/SOAP and manages the presentation of the services.
The presentation layer stores (if necessary) in the file system the XML received in order to minimize the interactions with the back-end and uses tDOM to parse the XML
I've not yet tested the system under heavy load, but the performances seems very good
The soap-gateway installed without any problem on my OpenACS 4.6, but I had to:
- create a soap client proc hacking a piece of code originally written by Philg (I've uploaded the soap client procs plus some wrapper procs around tDOM in openacs.org/storage/miscellaneous)
- modify the way the WSDL are automatically built
The lesson learned is that it works and can provide a powerful way to bring any legacy code to the web with all the advantages of OpenACS, the only problem being the availability of legacy db drivers within Aolserver.
Hope this helps
