I just wanted to announce that we (]project-open[) are going to publish very soon a generic XML-RPC bridge for the database API. Please find the details below and let us know what you think. We've are still in an advanced planning phase, so there is still some room to influence our design. The package will be licensed under GPL V2.0.
There is an incredible hype around this little acronyme ("Service Oriented Architecture") these days. Both SAP and Oracle are rewriting (or at least pretending to...) their applications to support this concept.
To me SOA means a kind of "component architecture" for web services (WS). You have "components" (WS) and you've got "glue code" (scripts, XML routers, Workflows, MS-BizTalk, ...) that connects the different WSs amongst each other and impose a certain business logic and some sequencing.
So given this definition (please let me know if you think I got it wrong), we'd propose nothing less then a complete "SOAization" of OpenACS / ]project-open[. Using this interface, any external application with the right credentials would be able to integrate with and "remote-control" an OpenACS instance.
SOA might imply SOAP as a communication protocol (Does it? It's become just such a fuzzy term), so somebody might argue that our XML-RPC-based approach isn't really SOA compatible. However, we could easily create a SOAP-version of our generic interface in the future. Any opinions?
During some recent customer surveys it turned out that "integratability" was #1 inhibitor for our potential ]project-open[ customers. Our customers frequently have legacy systems written in MS-Access etc. that need to read from and write to ]po[. So they are preoccupied by the integrated approach of ]po[ and need to be reassured that there applications will continue to be supported.
On the other hand there is usually very little budget available while most of our customers are not very "IT-sophisticated". So the integration needs to be easy and transparent (easy to debug).
Interface Generic Architecture:
Normally we'd need hunderts of different XML-RPC calls in order to access and modify the hundereds of object types in OpenACS / ]project-open[. However, after some discussions we've come up with the idea that OpenACS is really just a database (objects "live" in the DB, instead of "living" in the memory). So we'd only need four different API calls to access any type of object:
- "LOGIN": Authenticate and generate a session key
- "SELECT": Retreive the fields of an object from the database
- "UPDATE": Modify the fields of an object
- "PLPGSQL": Execute a object__new() or object__delete() procedure to create and delete objects
The integration with our "DynFields" (formerly known as "FlexBase") metadata model allows us additionally to access fields in "extension tables". For example we've got a table "im_employees" in ]project-open[ that contains payroll information for users of type "employee". Fields in this table are automatically selected and updated with the XML-RPC calls.
Interface Communication Protocol:
We've been looking at all three options for the interface. We have finally decided to go with XML-RPC, because it is the _easiest_. Here are the details:
- XML-RPC is the oldest XML-based interface standard. It's been kind of deprecated with respect to SOAP in the last years. However, it's much easier to use then full-blown SOAP.
- SOAP is the standard today for XML-based communication. In particular there is the cool WSDL feature that allows yout to meta-describe your communication protocol in XML, so that the usual tools (MS, IBM, ...) can automatically create proxies/interface objects for the SOAP messages.
- REST is a cool newcomer these days. The main difference to SOAP is that related objects are _reference_ (included as URIs in the XML text) instead of _embedded_ (included inside the XML document as subobjects). In REST every object (user, forum item, ...) has its on URI (a slightly generalized type of URL).
We're sticking with HTTP over SSL ("HTTPS") for security. For authentication we're probably going to use a session key that is generated using the "LOGIN" message.
Dependencies with ]project-open[:
We'll try to keep the XML-RCP-Bridge free from dependencies to ]po[.
The main issues is the "DynFields" SQL Metadata system which hasn't been included in OpenACS yet. However, we've mainly going to use the table "acs_attributes" to extract information about "extension tables" and dynamic attributes, so you could edit the contents of this table manually without DynFields.
As said in the into, we've already taken some decisions (XML-RPC and the generic interface idea), but everything else is still flexible.