Forum OpenACS Development: Response to <b>OpenMSG will develop a SOAP interface if......</b>
Posted by
William Byrne
on 10/17/02 05:37 AM
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:
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:
- Configuration/Admin pages that designate which packages are nominated for SOAP connectivity.
Upon initialization, the SOAP-package would:
- Version check the nominated packages against WSDL files it previously generated.
- Create new WSDL documents for new packages or rev'd packages.
- WSDLs are returned to a client app via a SOAP-package site. For example:
http://my.server.com/SOAP/ecommerce.xml - 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.
- 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.
- 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/
- 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.
- 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.
- 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':
- Authentication is an interesting component.
- 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.
- 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.
