SOAP frustrations
Graham Dumpleton
grahamd at dscpl.com.au
Wed Oct 16 06:19:38 EDT 2002
More information about the Python-list mailing list
Wed Oct 16 06:19:38 EDT 2002
- Previous message (by thread): SOAP frustrations
- Next message (by thread): SOAP frustrations
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Derek Thomson <derek at wedgetail.com> wrote in message news:<tS7r9.452$i84.53205 at news.optus.net.au>... > Andrew Dalke wrote: > > > > It's such that the more CS-y people at my client's site believe that > > web services in Python are still very immature and want to switch the > > project over to Java and WebLogic(!). (I did point out that developing > > the library I did was still less time than setting that up, but there > > are other factors in the mix as well.) > > I think most CS-y people believe that web-services themselves are very > immature, and are likely to remain so for a while yet. As far as the Internet goes I would probably agree on that point. After all, there aren't exactly many (any?) web services of any great significance which are generally available over the Internet through only a SOAP or XML-RPC interface. Where such SOAP or XML-RPC interfaces exist, they in general merely add something on top of what is an existing browser based service. The problem in the Internet arena is that you are asking too much in putting up a web service on the Internet, publishing your WSDL and expecting people to write their own clients. Yes it may work for very simple stuff like Google searching or stock quote services, but not for anything too much more complicated than that. Where web services make more sense at this point is on company Intranets where the application developers can also build and deploy the clients which might make use of such systems in a meaningful way. Even in this setting I still don't see services relying purely on XML-RPC or SOAP type protocols for communications. What is a better mix is to use more traditional frameworks for interprocess communications and/or messaging and have these web based protocols more as a convenience for accessing a restricted set of interfaces of a system as a whole. In such an approach, having such interfaces can be especially good as providing a way of monitoring or controlling the application. Even using such interfaces merely for the task of getting information out of an application during debugging and testing or even after it is deployed, can be enormously useful and save a lot of time and effort. The trick of course in all of this, is having a framework where providing such interfaces isn't an undue burden. Preferably it shouldn't require any extra work at all over the minimum you have to do to get your work done in the first place. :-)
- Previous message (by thread): SOAP frustrations
- Next message (by thread): SOAP frustrations
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list