Forum OpenACS Development: Clean solutions using SOAP
- Generate, cache, and deliver WSDL documents that expose published methods for various packages.
- Bridge the execution of a package's published functions to the SOAP RPC specification
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.
- 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.. ;)
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.
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
These are, for example, the requirements established by the Italian government for the upcoming e-government projects.
work on this. Anyone else know some good things to look at?
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.
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*
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 :).
;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)
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.
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.