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

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.

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.

Simon, I tested forums for you.  Please don't ever post html tags in
your subject again.

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 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.

I think someone is going to have to pry ... the ... period

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

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

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

This is good. I'll produce a spec for OpenACS's consideration in about a week or two.