Forum OpenACS Development: Best-in-class interoperability?

Collapse
Posted by Michael Feldstein on

A while back I got excited about Nick's proposal to make it possible to turn any OACS service contract into a web service by simply toggling a switch. (I'm still excited about that, btw.) This, combined with the general support for SOAP and XML-RPC, provide the foundation for marketing OACS as a best-in-class tool for building a service-oriented architecture. And as such, OACS can act as a black box, dramatically reducing the historic objection to Tcl and AOLServer by potential adoptees. (It also would make OACS more attractive to companies whose business models involve offering web services to their customers.)

Recently, there have been a few more developments that might make this possibility even more attainable. First, JSR-223, a specification for making it easier for Java to interoperate with scripting languages, is about to be finalized. Obviously, improved Java interoperability is not the same as web services; but if it makes it easier for straight Java developers to call OACS functions without having to get down and dirty with Tcl then it achieves similar ends for marketing purposes. Second, OKI, which has been adopted by IMS, has just released tools designed to make it easier to move OKI out of a Java-specific implementation. I can't find anything on the web site about it yet, but here's an excerpt from an email I just received:

(Cambridge, MA) - The Open Knowledge Initiative (O.K.I.(tm)) announced today the release of its XOSID representations of the Open Service Interface Definitions (OSIDs). XOSIDs provide a language neutral XML representation of the OSIDs, which until now were only available as Java APIs.

"We are very excited about this release," said Jeff Merriman, Project Director of O.K.I. "It has always been our intention for the OSIDs to be applied to various technologies, and not be tied to any one particular programming language. The XOSID representation of the specifications finally allows us to do this."

The XOSIDs are the master OSID reference from which programming language specific bindings can be generated through XSL transformations. The currently available Java language OSIDs are an example of such a binding. The XOSIDs provide a mechanism to describe services generally, without reflecting the details of any particular technology. In addition to the Java binding, work is currently underway to port the OSIDs to PHP, Objective-C and C#.

Honestly, the true ramifications of these specific technical developments are beyond my non-technical brain. I don't know what they would really mean, if anything, for OACS and dotLRN. But at any rate, they struck me as possible examples of ways in which the OACS/dotLRN community could extend its competitive edge in web services and, in doing so, mitigate the liability of the relatively unknown technology stack.

Does this make any sense?

Collapse
Posted by Nick Carroll on
Damn... I've been so busy that this totally slipped my mind. I could have got one of Rafael's undergraduate thesis students to work on it. It might not be too late... will see if there are any takers.
Collapse
Posted by Dave Bauer on
OKI and IMS, wires and sockets revisited http://www.cetis.ac.uk/content2/20050606013433

A little more detail on what OSID might mean.

Collapse
Posted by Andrew Grumet on
they struck me as possible examples of ways in which the
OACS/dotLRN community could extend its competitive edge
in web services and, in doing so, mitigate the liability
of the relatively unknown technology stack.

I can't speak to the JSR, but historically OKI has taken a dim view of XML over HTTP. I've sat in meetings with the architects of the OSIDs in which they're referred to Web Services as an "implementation detail". Again, historically, they've very calculatedly specified things at the level of the technology stack. Here's the test: if you have a method call that returns and object that itself has method calls, and that is opaque (i.e. can't be expressed in terms of simple strings, numbers, booleans, etc) then the spec will not lend itself well to cross-platform interoperability.

The XOSIDs are interesting because now lots of different technology-stack-dependent implementations can be built. From the article Dave B. linked to...

"Note that implementing an OSID in such a language doesn't mean that it will then be interoperable with OSID adapters that have been written in other languages."

That is, you can now build an island of compatibility for each stack. The best comparison may be drawn to something we have already: our ACS Service Contracts paradigm, and the set of contracts that have been defined and their implementations.

But...the linked article also hints...

"Which of course raises the older question of how OSIDs relate to Web Services in practice. Part of the answer will be demonstrated at alt-i-lab in Sheffield..."

Maybe they've found an interesting way to transform the XOSIDs to WSDL. Doing this would would be expensive and something of a "dirty trick" for a number of reasons (would require DCOM-like architecture, which the SOAP guys were pointedly trying to get away from), but it would be interesting if they did it this way and were able to pull it off.

Of course all this isn't to say that better interoperability through XML and HTTP isn't a good thing. The best opportunties seem to be in places with well specc'ed XML formats and protocols that are truly cross-platform, such as IMS CP (lors*) and IMS Enterprise (user sync) and RSS and XMLRPC. I'll believe it when I see it, but everything I've seen in three years of brushing up against OKI is that they are pretty deeply Web Services unfriendly.

Collapse
Posted by Michael Feldstein on
Again, I'm somewhat out of my league here, but I wonder if the JSR and XOSIDs *combined* will do the trick without the need for "dirty tricks." If you've got Tcl OSID bindings, and if JSR-223 (or some other method) makes Tcl-Java translation more straightforward, rather than using XML as the mediator, could that allow at least Tcl<->Java OSID cross-compatibility in a reasonable way?