For TurboZSI, you start with a WSDL file (that you make yourself) and then it generates some python stubs for the service. With TGWebServices, you define everything in Python and your WSDL is generated from that.
TurboZSI hands you request and response objects rather than letting your Python methods look like normal Python. TGWebServices uses type annotations on your methods for generating appropriate WSDL and converting incoming parameters. TurboZSI only does SOAP. TGWebServices spits out XML or JSON for plain HTTP requests. If you're only targeting SOAP and want to be able to do more of what SOAP can do, I believe that TurboZSI may be more flexible. (If you're writing the WSDL and responses yourself, you can be a lot more flexible in how your output looks...) Kevin On 2/12/07, Ken Kuhlman <[EMAIL PROTECTED]> wrote: > > What are the strengths/weakness of this as opposed to TurboZSI, which > has a simular mission? > > http://sda.iu.edu/turbozsi/ > > On Feb 9, 3:19 pm, "Kevin Dangoor" <[EMAIL PROTECTED]> wrote: > > I'm pleased to announce the release of TGWebServices 1.0: > > multiprotocol web services for TurboGears. > > > > http://tgwebservices.python-hosting.com/ > > > > More info: > > > > TurboGears gives you a plain HTTP with JSON return values API for your > > application for free. This isn't always what you want, though. Sometimes, > > you don't want to expose all of the data to the web that you need to > > render your templates. Maybe you need to support a protocol that names the > > function it's calling as part of what it POSTs such as SOAP or XML-RPC. > > > > TGWebServices provides a super simple API for creating web services that > > are available via SOAP, HTTP->XML, and HTTP->JSON. The SOAP API generates > > WSDL automatically for your Python and even generates enough type > > information for statically typed languages (Java and C#, for example) to > > generate good client code on their end. > > > > How easy is it? > > > > :: > > > > class Multiplier(WebServicesRoot): > > > > @wsexpose(int) > > @wsvalidate(int, int) > > def multiply(self, num1, num2): > > return num1 * num2 > > > > With this at the root, SOAP clients can find the WSDL file at > > /soap/api.wsdl and POST SOAP requests to /soap/. HTTP requests to > > /multiply?num1=5&num2=20 will return an XML document with the result of > > 100. Add ?tg_format=json (or an HTTP Accept: text/javascript header) and > > you'll get JSON back. > > > > The great thing about this is that the code above looks like a '''normal > > Python function''' and doesn't know a thing about web services. > > > > Features > > -------- > > > > * Easiest way to expose a web services API > > * Supports SOAP, HTTP+XML, HTTP+JSON > > * Outputs wrapped document/literal SOAP, which is the most widely > > compatible format > > * Provides enough type information for statically typed languages to > > generate conveniently usable interfaces > > * Can output instances of your own classes > > * Works with TurboGears 1.0 > > * MIT license allows for unrestricted use > > > > -- > > Kevin Dangoor > > TurboGears / Zesty News > > > > email: [EMAIL PROTECTED] > > company:http://www.BlazingThings.com > > blog:http://www.BlueSkyOnMars.com > > > > > -- Kevin Dangoor TurboGears / Zesty News email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
