I believe a SOAP package should be in the cross hairs of those responsible for the future development of OpenACS. The package would provide a RPC gateway to public functionality available in other packages. This type functionality could be classified as Published functionality. The package should do at least the following:

1. Generate, cache, and deliver WSDL documents that expose published methods for various packages.
2. Bridge the execution of a package's published functions to the SOAP RPC specification

In my opinion, the usefulness of SOAP in OpenACS far exceeds the notion that it would a cool feature; it would provide needed programmatic access to the functionality and data that is encapsulated in the OpenACS product as a whole. For example, data maintained and manipulated in the ecommerce package could link to existing business applications. Without the RPC mechanism, what mechanism would a developer utilize? Performing FORM POST operations programmatically is not a good option. Direct access to the db data is also less than ideal.

Packages that wish to scale to enterprise solutions would publish methods designed to facilitate the type of connectivity required by existing systems. Consider the burden of payment processing performed by the payment gateways that accompany OpenACS. Would it not be beneficial to have a passive payment processing paradigm on the OpenACS side requiring an external payment processing mechanism to accumulate and execute pending payments? Another example would be the synchronization of a product line maintained in a retail application to the products listed in an ecommerce application.

I wish I had the time and expertise with OpenACS to develop a SOAP package. Unfortunately, I'm still on the outside looking in hoping to improve my OpenACS skills each day I uncover another nuance of its being. Perhaps a coordinated effort by a few experts may yield a suitable package that would provide some basic SOAP gateway functionality. We use SOAP extensively in proprietary solutions and we don't require all facets of things associated with SOAP such as UDDI. On the other hand, we conform to the WSDL spec even though that's not completely necessary if stubs are manually crafted.

I don't know...
... what do you think.

William,

• Thank you for stating the obvious,
• and repeating whats already bounced around these bboards numerous time....
• oh and thanks for *not* offering to do anything about it!

Don't worry, I'm only kidding ;)

But seriously folks, we can all give a list as long as your arm of things we'd *like*, however what *I'd* like is a bit more in the way of volunteers, effort and commitment....

A bet the time it took to write this posting could have been spent fixing a bug.. ;)

Cross Reference

Yes, thats part of my thinking too... the time and effort could certainly be spent on SOAP (and I can see the PR benefits for OpenACS) but....

What does anyone want to do with it?

I've been mailed privately on this same point by people concerned I might push effort and resources in a better direction, so yes, I think some concrete examples of need have to be supplied to...

Otherwise (as I've been reminded) there are other tasks we might more usefully contribute to

Google's APIs might be a good starting point if someone were going to
work on this.  Anyone else know some good things to look at?

I'm not disagreeing with you Dan, what I meant was if I do have time and resources spare is this the best thing to commit them to?

You tell me who decides? Buggered if I know.. it normally seems to be someone posts up something controversial, everyone argues for a week and then something else entirely gets done. As far as I can tell 'what' gets done usually comes down to who's prepared to shout the loudest about it or post up contentious replies until everyone gives up the ghost :)

People during testing and colleagues/clients have 'mentioned' the fact that maybe there's better things to concentrate on first, like fixing the bugs, weaknesses and undesirable behaviours we have in existing packages.

I'm not as yet persuaded either way, thats why I'm asking

My only personal concern is that no customer of mine has ever asked for it. I can see the value, I can't as easily see the need if that makes sense?

I don't/haven't (who knows if I will) use SOAP and as far as I can tell in the UK the fervour for 'web-services' hasn't really caught the imagination. I just want to be working on things people really need, things that other companies and individuals actually have to have to do their job better or sell/develop more successfuly. What I don't want (and no disrespect is intended) is to waste time on anything thats largely an academic/hobbyist exercise.

I was trying to see if the was any commercial need for this. If not I'd rather spend my spare time down the pub ;)

So, following on from your question, I'll ask again, Is there this need? I can see you have plenty of ideas, but is that reflective of peoples requirements.

Does that make sense? I seem to be struggling to explain myself today, must be knackered.. *chuckle*

There's always plenty of other things that can be done, but I wonder if your clients are asking for you to those things instead?

;o) Nothing quite so sinister. (or maybe you meant are they 'really', in which case yes to a degree) Blimey, postings are so open to ambiguity :ob

But yes, I do freely admit I have my own commercial considerations playing a part in it. Naturally, as we use OpenACS for commercial purposes that makes sense. I am quite open about it, I make no apologies for making a living out of much of the excellent work thats done here, and I hope people who contribute take that as the genuine compliment to their abilities that it is.

In return, as a company I hope we do what we can to pitch in also.

I really just like to make my 'angle' clear in these discussions. As a commercial company we have a responsibility to spend our time/cash frugally and in the best interests of the employees. That means I do have to evaluate anything before I can commit.

(What I do personally, when their separable) is of course entirely different.... although its question of competing with beer then ;o).

I like to be pretty communciative with customers, so I think I may 'survey' a couple of them and get a little input on this one. That might give me (and us) a better idea.

I'm certainly persuaded we can think of valuable things to do with SOAP. So if there are other commercial outfits here who can confirm their interest in it, I'd say it was go-er, cos that will help ensure the right level of committed development.

Ok, I think someone already offered to produce an initial semi-formal spec, so I'd be interested in seeing that quite soon.

I for my part will get some input from some of our bigger clients about their feelings on the matter and see if that injects some thrust/ideas into the mix, and see how it goes from there.

(Mind you I still think maybe a re-development of the request processor as an AOLServer C module wouldbe a good move. I forget who mentioned that a while ago, but yes I'm keen to see that too)

We made a considerable time investment into axis in a project unrelated to OpenACS. We eventually discovered the overhead in using it was too high. In particular, we were unsuccessful in getting SOAP stubs to work from within applets without modifying the user's security settings (something related to the log4j integration). We ended up building light weight stubs using dom4j. It's a smaller jar deployment and we have complete control over the SOAP implementation. These client side issues ofcourse are unrelated to the server side SOAP components axis provides.

My interest in SOAP support for OpenACS is to bind RPC method invocation to package functionality on a limited scale. I intend to spec (and perhaps provide a light weight pseudo implementation) using existing components that accompany a typical OpenACS install. On the other hand, axis integration would yield a more robust and compliant alternative.