Forum OpenACS Development: Forget about Apache support

Well, not really. But now that I have your attention, I want to point out that there is apparently a relatively easy way to get a huge amount of integration mojo and buzz (both steak and sizzle) that may be lower hanging fruit than any of the Apache strategies that have been bandied about.

While reading up on the SOAP progress, I ran across Nick's idea for a tool that converts service contracts into SOAP web services. Now, not being a programmer, I had no idea what kind of stuff that would expose. So Nick was kind enough to send me a list of the service contracts running on his apparently not-particularly-loaded-up dotLRN instance.

What I saw got me very excited. IMS Enterprise. WebDAV. Workflow. I can only imagine what else is available from a fully loaded installation. If I'm understanding the situation correctly, then a good chunk of the rich, sprawling set of functionality that is OACS can be exposed as web services with just a few weeks of work to build Nick's sc2ws thingie. Again, if I'm really getting what this means, then it would blow away any mod_proxy or mod_whatever integration with Apache. Instead of just providing buzz value, it would actually provide ways for developers of other systems to add real and substantial functionality to their apps through SOAP integration with OACS, whether those apps run on AOLServer or Apache, or are written in TCL, Java, PHP, or Eiffel. As a bonus, it clarifies the proper roles of AOLServer and OACS in the application stack by removing the HTTP server from the conversation.

I dunno. Am I missing something?

Here's the thing:

Back in the day, the original ACS was the ultimate web site erector set. Nothing else came close for building rich web applications quickly. That's still true in some ways, but (from a marketing perspective) the message is muted because there are a lot more solutions out there that are at least adequate and use more standard (i.e., familiar) technologies.

Once again, if I'm understanding the situation correctly, sc2ws could change all of that with one stroke. If there's a platform out there that provides more than 20% of the erector set functionality that the OACS service contracts provide, I'm not aware of it. And by making that functionality automatically available through SOAP, OACS could essentially be run as a black box from the developer's perspective. They only need to know enough about the underlying technologies to keep OACS running.

sc2ws could by the flux capacitor for OACS and take us back to the future. It just seems so good that I feel like I must be missing something.

(And it's good to be back, Carl....)

I am not sure exposing the service contracts that exist right now really would get us a huge advantage. I guess that depends on which bits of OpenACS need to interoperate.

For example, service contracts in WebDAV really shouldn't be exposed. Its just an API to map WebDAV methods to objects. If you had a need to connect externally to WebDAV, you would just use the WebDAV protocol.

I think it would be a great idea to figure out what sort of functionality it makes sense to offer as a web service and find a way to implement that. I know that acs service contracts were designed originally based partly on WDSL for web services.

Lately we have found that the actualy _use_ of service contracts inside OpenACS really lends itself more to the recently added callback system. Service contracts might be a good idea for web services, but for inter-package communication the callback feature is simpler and easier to work with, while still providing all the functionaly we have been using.

As a general rule of thumb, I think everything we store in include files would make sense to be exposed as a webservice.

What I found useful in the eLink System was the ability to store a query in the eLink System and query it using the tSOAP. Therefore a general system that exposes the .XQL file based queries using SOAP could be interesting for interoperability.

I could think of an index.vuh in the tsoap package, that gets a soap request with the fullquery name and the bind variables as parameters. It would be called like /tsoap/< mountpoint_for_my_weblog_package>/blog. We need this method (instead of saying: /tsoap/weblogger/www/blog) due to the fact that most queries depend on the package_id to limit the results in a sensible way.

Last but not least, everything we provide as a portlet should be available to the outside world. Finding a general way there would bring us miles ahead. Sadly I'm not sure a standard exists for including portal content (sure, we could send back the full HTML code, but what would happen with the links?).

Oh, and the standard for portlet content that seems to be the best to look at is WSRP. I am not sure if there are any competing standards we should look at.

Three questions:

1. Nick has proposed a general mechanism for converting service contracts to web services without per-service programming. Can that general mechanism be extended to cover all the include files?
2. Assuming that such a mechanism were built, could OACS be legitimately said to have a special advantage as a platform for building new web services easily?
3. Would somebody volunteer to create a quick-and-dirty list of these include files and post them in a new thread so that we could evaluate them as a group in terms of their value for web services?

Jade,

It would be much cleaner if this was done through service contracts than through ad_proc. Service contracts were based on WSDL, so it makes sense to use service contracts. Also if you take a look at /acs-service-contracts of your openacs installation you'll find a list of registered service contracts. These service contracts can already be registered and unregistered, so it wouldn't take much effort to deploy/undeploy web services in much the same way.

I have already got a UI completed for this little project, but I have left the guts of it till later on in the year. I first need to get dotfolio developed and released by June. Then I will work on sc2ws, as my next task would be to integrate dotLRN and dotTeach with dotFOLIO.