Home
The Toolkit for Online Communities
17607 Community Members, 0 members online, 2633 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Q&A : Status of SOAP Support

Forum OpenACS Q&A: Status of SOAP Support

Icon of envelope Request notifications

Collapse
Posted by Simon at TCB on
Hi,

I'm a little out-of-step with the OACS at the moment and wondered if anyone can give me a heads up on the status of SOAP within the project.

Specifically....

-I recall a module, SOAP-Gateway. Is this still in existence, is it a preferred method and where's the latest version?

-I do recall discussions around tclSOAP. Is this usbale with AOLServer (3 not 4 as I beleive i'll need SSL support also)? If so should this be the way to go?

-Was there also an xml-rpc module knocking around? Again, where is the latest version of that?

Many thanks in advance.

Collapse
2: Re: Status of SOAP Support (response to 1)
Posted by Claudio Pasolini on
I'm not sure if soap-gateway is the preferred method, but I like it and succesfully used it. There has been some talk recently and perhaps the package will be checked in, meanwhile you can find it at http://www.byrnelitho.com/SOAP-Gateway-0.1d.apm

The next version will make use of tdom instead of nsxml and support both SOAP 1.1 and SOAP 1.2.

Collapse
3: Re: Status of SOAP Support (response to 1)
Posted by Nick Carroll on
I'm in the process of working out how to commit the revised soap-gateway package that uses tDOM instead of ns_xml.  It is a straight port of the original soap-gateway package.

I am further developing "service contract to web service" (sc2ws) support.  Which means you are able to deploy a service contract implementation as a web service through a web interface.

The current method of deploying web services requires writing some procs in a library and importing it into soap-gateway.  The sc2ws approach on the other hand means you don't have to write code if you want to interact with a package through web services.  You just click a few check boxes, hit submit and a service contract implementation is then deployed as a web service.

An example of usage would be if you wanted to share your Learning objects in the LORSM package.  sc2ws would allow you to deploy the "export learning objects" service contract implementation as a web service.  This will allow LORSM to share learning objects with third party systems that also supports IMS standards.  Well this is the vision I have for it.

As a result of this I have found that the soap-gateway package doesn't handle multiple return values very well, which is the case for the majority of service contracts.  Also arrays aren't supported very well either.  These are issues that I will be working on.

Collapse
4: Re: Status of SOAP Support (response to 3)
Posted by Nick Carroll on
A tarball will be made available (temporarily) on my website untill I can commit it to CVS.

Cheers,
Nick

Collapse
5: Re: Status of SOAP Support (response to 4)
Posted by Orzenil Silva Junior on
HI Nick,

Thanks for made soap-gateway available now. I am very curious about implementing services using soap to access existing instructional resources from digital libraries (as you said in your vision statement).

Your tarball installs fine in my dotlrn-2-1a2 (with pgsql 7.3.5 and aolserver4) but I had error when trying to import unpublished services - interop and workspace - under maintenance section ( soap/admin ).

I think they are only typo errors but could prevent us to appreciate the package. Because there is no soap-gateway in bug-tracker could you evaluate this changes i made? Thank you.

--- /tmp/soap-gateway/tcl/soap-server-lib-procs.tcl    Thu Sep 30 00:40:00 2004
+++ soap-gateway/tcl/soap-server-lib-procs.tcl  Thu Oct 14 10:54:33 2004
@@ -615,10 +615,10 @@
            }
        } elseif { $force } {
            # update
-          error "[soap::server::lib::method_update $mid $method $idl $idl_style $proc $note"]
+          error "[soap::server::lib::method_update $mid $method $idl $idl_style $proc $note]"
        }
    }

    # return namespace id
    return $nid
-}
\ No newline at end of file
+}
--- /tmp/soap-gateway/sql/postgresql/soap-gateway-create.sql    Thu Sep 30 00:41:40 2004
+++ soap-gateway/sql/postgresql/soap-gateway-create.sql Thu Oct 14 11:11:45 2004
@@ -322,9 +322,9 @@
        v_method_id = null;

        -- get namespace count for id
-      select into v_method_id method_id
+      select namespace_id into v_method_id
        from sg_namespaces
-      where namespace_id = p_namespace_id and lower(method) = lower(p_method);
+      where namespace_id = p_namespace_id and lower(service) = lower(p_method);

        -- fix up
        if v_method_id is null then

Collapse
7: Re: Status of SOAP Support (response to 5)
Posted by Nick Carroll on
Thanks for that Orzenil, I will apply those fixes now.  I'm still waiting on a CVS account.  Might have to ask somebody else, as Don must be busy.
Collapse
8: Re: Status of SOAP Support (response to 7)
Posted by Nick Carroll on
Orzenil, I have already made those fixes in my own cvs repository.  The tarball you downloaded must contain an older version.  I will check out a more recent version and make that tarball available.
Collapse
Posted by Andrew Piskorski on
There are at least a half dozendifferent XML-RPC and/or SOAP implementations for AOLserver and/or OpenACS, all in various states of completeness and quality. AFAIK no one has yet reviewed them all and put together a description of what the heck they each do and why you would want to use one or the other.
Collapse
6: Re: Status of SOAP Support (response to 1)
Posted by Talli Somekh on
There's also Bart's XML-RPC code that uses AOLserver4 and tDOM.

talli

Collapse
9: sc2ws update? (response to 1)
Posted by Michael Feldstein on
Nick, now that the improved SOAP support has come out, what are your plans for the service-contract-to-web-service package?
Collapse
Posted by Nick Carroll on
Are people still interested in that work? I had put that work on the back-burner for the time being, as I am now focusing on the eportfolio package. I had a user interface developed, but the logic required to deploy the service contract as a web service was left unfinished.

I thought that work would be a neat way of managing web services within openacs. I'll try and work it into my work load. Otherwise I can talk to Rafael about getting one of his undergraduate thesis students to work on it.

Collapse
Posted by Michael Feldstein on
Well, as somebody who is not a current OACS user, I'm not sure how heavily you should weight my vote in terms of adjusting your workload. That said, I do think that having a quick way to convert the rich set of functionality that OACS already provides via service contracts into web services would be pretty significant.

Out of curiousity, just how much work is involved?

Collapse
Posted by Nick Carroll on
I wouldn't expect much work to be done. Just need to develop some procs that can generate a WSDL file based on a selection of service contract implementations. Plus some admin features that keep track of deployed/undeployed service contracts.

I will be working on this later on in the year once I've got the eportfolio package (dotfolio) underway. I'll be needing this feature for interoperability between dotlrn and dotfolio.

Collapse
Posted by Torben Brosten on
I stumbled on http://shibboleth.internet2.edu/ which seems to be useful for standardizing the various external permissions solutions available with openacs/dotlrn. Maybe influences eportfolio, too?

Implementing it might give dotLRN a competitive edge.

Collapse
Posted by Michael Feldstein on
While I don't really have a sense of how urgent federated permissions needs to be, the list of "committed participants" is interesting from a dotLRN perspective--EBSCO, Elsevier, Fedora, etc. Still, I'd put WSRP ahead of Shibboleth, at least at first blush.
Collapse
Posted by Malte Sussdorff on
Andrew, the reason for the tsoap package was simple:

- There was no SOAP package for OpenACS available, that works with a pure SOAP gateway (not XML-RPC).
- We needed an implementation of the SOAP package to work with tDOM instead of TclDOM, due to the fact that OpenACS relies on tDOM.
- The goal is to create SOAP request in your own procedures (look at babblefish.tcl) and parse the result automatically.
- It should be easy to work around character set conversion problems as well as BASE64 decoding, that occured with the out of the box parsing.

So, the reason is stated above and the goal is to have a general SOAP parser and request generator for integration of other webservices using OpenACS as a client. Obviously, if we define a standard API on how to access our objects (similar to the /o approach in 5.2), it would be very easy to provide our objects to the outside world. For more complex web services we'd have to see where the demand goes. It should be a piece of cake to offer the add/edit/display/delete interface of the CR using SOAP calls and maybe even XML-RPC. Once we stumble upon a project that requires more thorough SOAP integration in this way, we will definitely include this in one way or another with OpenACS.

Collapse
Posted by Dave Bauer on
Malte,

At one point TclSOAP supported acessing the same APIs thorugh SOAP or XMLRPC. Do you know if this is still true?