Forum OpenACS Development: Clean solutions using SOAP

Posted by William Byrne on
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.
Posted by Claudio Pasolini on
Here my vote to include SOAP in the todo list of a future release of OpenACS.
Posted by defunct defunct on

  • 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.. ;)

Posted by William Byrne on
Oh, pardon me while I wipe this side-splitting grin off my face<g>. I'm being sincere in raising the point once again. I'd be willing to collaborate and invest time in a SOAP package; however, I hesitate to commence on something that may already be underway. Perhaps I could have been brief and requested a list of willing participants for the production of a SOAP package. Or, test an existing implementation. Maybe a specification/plan would be in order?
Posted by David Walker on
Cross Reference
Posted by Jeff Davis on
Could someone point out some concrete service we could use or provide
more broadly if we implement SOAP.  I am not trying to make some point
here, I just find it easier to think about (and work on) something that
has an immediate benefit.
Posted by defunct defunct on
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

Posted by Claudio Pasolini on
I have not yet thinked about wich OpenACS package could be conveniently exposed as a Web Service, but I know that to make OpenAcs eligible as a suitable framework to build a portal we need the capability to call Web Services provided by other parties.

These are, for example, the requirements established by the Italian government for the upcoming e-government projects.

Posted by Jeff Davis on
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?
Posted by Dan Wickstrom on
I've tried the google api (using nsjava), and it works well for searching, and something similiar could be added to openacs.  In addition, web services could be used for the following items: importing/exporting/xfering content items, ecommerce payment gateways and inventory control, channels to other sites for education and intranet integration with portal sites, interfaces for single sign-on control for a group of sites on a campus or within a company intranet.  That's just a few ideas, and I don't think there is any shortage of applications for web-services within openacs.

Simon, who are these people that are deciding what's important within the openacs community?  It seems to me that adding support for web-services is as important as anything else that could or is being done currently.

Posted by defunct defunct on
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*

Posted by Dan Wickstrom on
This thread doesn't seem too contentious - quite calm in comparison to
other threads that we've had lately.

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?

The linux-journal article on OpenACS seemed to be right on the mark
when it stated that openacs is unfinished in many respects.  Thinking
about it though, alot of potential clients probably don't care about
the things in openacs that are unfinished.

Probably, people don't yet see the value in web-services, but if it
were available and you offered it as a superior method to solve some
of your customer's problems, then demand for it would probably grow.
If your decision is purely a business decision predicated on
short-term benefit to you and your company, then implementing
web-services now is probably not a good bet, especially in light of the
fact that none of your customers are asking for it.  I think it's
useful, and I think it could be applied to solving alot of problems
that folks in this community are trying to address, but I'm not a
customer, so my opinion probably doesn't matter in your decision

In spite of that, I have to admit that I was quite impressed with google's
implementation of web-services.  This type of service really shines
when it comes to integrating services from source outside of your own
web-server.  For instance, in the google case, the web-service
interface gives you complete control over how the data is received,
and it let's you present the received data in whatever format you
choose. It seems to be a really good fit for dotLRN, since there will
be a demand for tying dotLRN in with legacy systems, and web-services
are good for that type of problem.

The thing is, once your customers start realizing they need something
like SOAP, there probably won't be enough time to quickly throw
something together.  Wouldn't it be better to already have it
available?  There's always the chance that your customers will never
ask for it, so it is a gamble to undertake the work, if you're expecting
a future payoff.

Spending your spare time at the pub, is probably a better bet :).

Posted by defunct defunct on
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)

Posted by Dan Wickstrom on
I don't have a clean solution using SOAP, but I do have a slightly dirty one, since it is contaminated with java. I have a basic integration of the apache axis soap implementation working with aolserver and nsjava. It has support for deploying soap 1.1 compliant web-services.

I need to clean it up some and make it easier to setup and configure with the framework of aolserver, and after I do that I intend to turn this in to an openacs package, and I will make it available for download if anyone is interested.

Posted by William Byrne on
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.