Forum OpenACS Development: OpenMSG will develop a SOAP interface if......

... anyone knows a decent existing open source offering thats already out there that we could use a template/exemplar..

We don't really use SOAP much and I just don't have the time to piss about being clever and designing it from scratch.

But i'm happy to put in the effort to get an initial offering going that people can then build on...

Anyone got an suggestions of a good existing set of code that would serve?

TclSOAP

http://tclsoap.sf.net

It supports SOAP and XMLRPC.

It allows for plug in transports and has a CGI mode. So there must be a way to work it into using the AOL HTTP facilities.

It was on my list of things to do. I hacked a way to make it work. It requires nsexpat and nstcldom packages, which I believe you can get from the AOLserver sourceforge site. If not I have copies here somewhere that work.

My goal was to write an XML layer to allow TclSOAP to work unmodified with tDOM xml parser running inside AOLserver so that we wouldn't have 2 or 3 XML parsers running for OPenACS. Another option is to fix the minimal XML parsing in OpenACS to use nstcldom.

You can get nstcldom from the CVS repository of the nssoap project - http://sourceforge.net/cvs/?group_id=34784  I would suggest asking Scott G. to import it into the AOLserver project tree.  (Assuming Dave's version doesn't have any special modifications.)  nsexpat is available from both repositories, but it looks like the version in the AOLserver repo is newer.
For the love of everything which doesn't suck and isn't lame, please stop using tags in your posts' subject. They are not meant to be there. They are ugly. Your post is important, but so is everybody else's. Please, please, please.

Note: this is not a personal attack of any kind or sort, and no offense is meant with this post. This is just a simple request from a fellow bboard reader/poster.

Happy to comply.... however its not just a question of importance, more variety is the spice of life and all that :)

But I shall grant you this small favour .... :o)

Of course if you wanted to volunteer to test a package for me in return..????

Simon, I tested forums for you.  Please don't ever post html tags in
your subject again.
Collapse
7: Why no tags (response to 1)
Posted by Lamar Owen on
If no tags in the subject, then bboard should strip the tags out of the subject. If bboard doesn't strip them out, then.... well, bboard doesn't strip them out.
Is this OpenACS or OpenPMS?

I would give serious consideration to utilizing a "C" level parser that would ingest the FORM content payload. The namespace for the SOAP method could map to a package, the method and args would follow. However, the mechanism for parsing the Envelope isn't as important as spec'ing out a SOAP implementation a level above the coding details. I envision the following:
  1. Configuration/Admin pages that designate which packages are nominated for SOAP connectivity. Upon initialization, the SOAP-package would:
    1. Version check the nominated packages against WSDL files it previously generated.
    2. Create new WSDL documents for new packages or rev'd packages.
    3. WSDLs are returned to a client app via a SOAP-package site. For example:
          http://my.server.com/SOAP/ecommerce.xml
    4. First round implementation for WSDL generation should account for common XML primitives. In my view, the primitive constraints of Tcl help to define the minimum primitive types to be supported.
  2. Once the WSDL Service Contracts are published, a RPC gateway is required to fulfill client requests. Equally exciting as producing a WSDL generator is the process of marshalling incoming XML RPC to packaged methods.
    1. It's specified that a WSDL document describe the namespace a method lives in. The namespace would best serve a marshalling process if it were to include the method's package somewhere in its URI. It may be helpful to include application/site info as well. For example, the following namespace would refer to the ecommerce package installed at a subsite called 'shop':
          http://ecommerce.openacs.org/shop
      A service could be qualified without a site as:
          http://calculator.openacs.org/
    2. Once the package/site info is parsed from the namespace, the method and its args are evaluated. There are varying degrees of implementation quality when extracting the arguments parked within a SOAP envelope. A basic SOAP parsing implementation can get you pretty far and I don't think it necessary to have an "all or nothing" approach to the envelopes parser implementation. The WSDL documents generated above would limit the level of complexity of incoming SOAP envelopes. Basically, we publish only those things we're willing to parse.
    3. Next the Tcl invokes and returns a result. This stage of execution is merely a sprintf into one of a series of preformatted return envelopes. Sure, I'm over simplifying this part; however, it's pretty basic.
  3. Authentication is an interesting component.
    1. New client activity would typically be confronted with authentication request. Since OpenACS uses FORM based authentication and maintains user profiles, it may be a good idea to publish a WSDL for basic user activity. The WSDL would include methods for authentication, favorite foods, old flames, etc.
    2. The authentication and profiles methods would be hard wired into the SOAP package in contrast to the gateway process utilized to invoke methods in other packages.
Perhaps we can formalize a spec for a SOAP implementation. I'd be happy to regurgitate the above in a formal spec. It would be somewhat superficial since I'd would need to defer architectural/design remedies to OpenACS experts. Is there a mechanism for such a process at OpenACS?
There isn't really a mechanism but a formal-ish spec might be useful!
There isn't but in part that's because much of what's being added to the toolkit comes from client-driven projects.  In that space, of course, clients and vendors often negotiate a spec, for the purposes of putting together a contract if for no other reason.

SOAP integration is important enough that I think we should have a target to poke at so we're all in agreement as to how this is implemented.  If you want to write up a spec for folks to comment on, that would be great.

We do want to switch to tclDOM and standardize on that as our XML parser.  Doing so requires minor work in the toolkit (which currently uses libxml in a few places), work that needs doing for 4.7.  This has nothing to do with SOAP integration specifically - we want to switch for other reasons.

Roberto - can you post status on this?  I know you had Neophytos's tarball and that we've been waiting for Zoran to release the AOLserver module.  Has he done so?  Can we take this first step in the CVS HEAD soon?

Oh ... stop with the bloody HTML tags in your subject lines, mate.

Collapse
11: HTML in responses (response to 1)
Posted by defunct defunct on
:o( *Sniff*, *Sniff*

Is there anyone else who want to slap-my-wrists for using html tags?

:o( *Sniff*...

;).. I've stopped, I'm cured... I shall never again try to bring some joy and colour into your lives....

Good Bye Cruel World......

Of course perhaps a 'I don't like to receive HTML option' might be an idea???

I take it no-ones interested in my 'mood icons' for the BBoard package then...? I dunno, have a heart folks, half the time I only get to play with SMS, 160 characters and noooo formatting at all.... why this bboard was my only release ;)

Collapse
Posted by Jeff Davis on
I think someone is going to have to pry ... the ... period

................ key

off ... your keyboard...though :)

My, but you folks are a demanding audience.

Oh well, sod the prose, bums on seats laddie, bums on seats!

Don,

why would you make tclDom the standard and not tDom?  tDOM is a C implementation of the DOM level 1 core using expat  and tclexpat  for parsing. tDOM also includes C implementations of XPath and parts of XPointer. tDOM is written to be accessed from tcl. The performance of tDOM is very good and the the current beta version 0.7.5 can be compiled as an AOLServer library. Sure tDOM requires a few minor changes in the acompanying Tcl files but nothing that couldn't be worked out. And these changes won't affect tDOM for non AOLServer use.

/Bart

Bart, I'm sure Don meant tDOM. At least that is the tarball, I have sent to Roberto.

cvs -d:pserver:anonymous@www.archiware.com:/usr/local/pubcvs co tdom
This is good. I'll produce a spec for OpenACS's consideration in about a week or two.