Forum OpenACS Development: Web Services Package

Collapse
Posted by Nick Carroll on
Hi,

I've just completed stage 1 of my research project.  It took a little longer than expected, but I can now focus on the next stage.  I am looking at integrating Web services into OpenACS.  I know there is a SOAP-gateway package, and tclSOAP.  I also know that none of these use tDOM as the XML parser.  I wish to write my own SOAP interface using tDOM.  Before venturing into the project I would like to hear from those that are interested in Web services, and have their own vision of Web services integration in OpenACS.

OpenACS has already moved from ns_xml to tDOM.  Can anyone guarantee that we won't move to another XML parser?  Would it be best to provide an interface to the XML parser, so that if we do change XML parsers we won't need to change a lot of code, just the interface bindings to the XML parser?

My end goal is to have a Web services package that sits on top of acs-service-contracts.  This will allow a developer to export functionality through Web services by selecting specific service-contracts.  I don't believe the existing SOAP-gateway package does this.  The big picture that I have in mind is to use Web services as a way for dotLRN to comply to OKI.  However the Web services package should be generic enough to export any registered acs-service-contract.

I'm working on a specifications document for this, and would like some feedback on this proposed project.

Regards,
Nick.

Collapse
2: Re: Web Services Package (response to 1)
Posted by Talli Somekh on
Nick, I doubt the community will be leaving tDOM any time soon. I think there's a pretty strong tDOM fetish out there that is contagious.

Also, I received assurances from AOL that they will be releasing their XMLRPC module Real Soon Now (within a month or so). This is built on tDOM as well.

talli

Collapse
3: Re: Web Services Package (response to 1)
Posted by Dave Bauer on
Nick,

Check out the xml-rpc package in CVS. It uses the xml abstraction procedures in acs-tcl/tcl/30-xml-util-procs.tcl.

It implements xml-rpc server and client.

Collapse
4: Re: Web Services Package (response to 1)
Posted by Claudio Pasolini on
Regarding the xml parser go for tDOM!

Perhaps I'm missing something, but what is the point of using service-contracts? I personally find publishing and accessing web services much more simple using soap-gateway, even if it is somewhat experimental.

Going a step forward am I completely wrong thinking that the web services could (should) substitute service-contracts?

Collapse
5: Re: Web Services Package (response to 1)
Posted by Don Baccus on
Why would we want to push all of our internal plug-in facilities through a web-services paradigm?

Service contracts allow us to implement plug-ins in a standard way, nothing more.

Collapse
6: Re: Web Services Package (response to 5)
Posted by Nick Carroll on
Don, I'm not suggesting we expose all of OpenACS service contracts through Web services.  The package I'll be working on will produce a list of all registered service contracts, and you can select which contracts you would like to expose as a web service.  A tool can take these service contract definitions and create a WSDL file that describes bindings to these service contracts as end points for Web services.

Service contracts allow OpenACS packages to implement plug-ins in a standard way, but we can leverage this with Web services to plug OpenACS into other systems.  In the dotLRN space, courseware or learning objects can be shared between systems.  In the project management space we can have a service contract for importing data from other packages, but can expose this as a web service to also import data from 3rd Party project management applications.

Instead of having to rewrite code to publish a web service, which is currently being done, we can use existing interfaces such as service contracts which clearly specify an interface of how a package should be used.

Collapse
7: Re: Web Services Package (response to 6)
Posted by Nick Carroll on
So I'm not trying to replace service contracts, just reuse a well-defined interface for Web services.  It could be a package that sits between service contracts and the SOAP-gateway package.
Collapse
8: Re: Web Services Package (response to 1)
Posted by Don Baccus on
I didn't imagine you were, Nick, I was responding to Claudio's post where he raised the question as to whether or not this might replace service contracts ...

Claudio among other things web services are exposed to the outside world and not only are service contracts simple and fullfill an abstraction need, they communicate strictly internally so there's none of the security issues that are raised by web services.

Collapse
10: Re: Web Services Package (response to 8)
Posted by Nick Carroll on
Sorry Don, I thought you were asking me a question... kind of wish the postings are threaded.

I will be writing up a document on what I want to do with Web services, and making it available for the community.  I also hope to complete it before next month, as my supervisor Rafael Calvo will be heading to Heidelberg for the Spring meeting to present what our group is doing down in Sydney.

Collapse
11: Re: Web Services Package (response to 10)
Posted by Nick Carroll on
I meant "postings are hierarchical and not flat" and not "postings are threaded".
Collapse
9: Re: Web Services Package (response to 1)
Posted by Don Baccus on
BTW I like the approach you're outlining ... will you publish some design info for the middle layer soon?