Some additional thoughts.
What's really nice about the contract-first approach is that except for some
of the web service handling specifics - parsing the XML in the SOAP
envelope, generating the SOAP envelope, and of course the associated WSDL,
web services look like just any other web app. So you can use the existing
web app infrastructure out there that's much more mature and feature rich
(like Django) than most of the tooling available out there that's web
It also won't break if you try to deploy on different containers, even
different versions from the same vendor. And since web services generally
are in the context of integration, usually they break somewhere along those
Lastly, creating RESTful versions will be much easier, since you can readily
reuse the same logic.
The challenge that you will face is that there's very little information out
there on how to do even contract first, never mind in the context of Python.
Probably one of the better books out there using the contract-first approach
is this one,
it's of course just in terms of Oracle SOA Suite. (The authors recently
updated this book btw.)
On Mon, Sep 27, 2010 at 10:06 PM, Jim Baker <jbaker@...> wrote:
> soaplib now requires lxml, which is not supported at this time on Jython.
> Maybe an earlier release of soaplib would work.
> Tools like soaplib are code-first in their orientation. You get some
> control over the generated WSDL, but it's not terribly stable as the code
> changes. And it's hard to get it right when you're mixing different
> languages. In general, I think the better practice is to use contract-first,
> writing the WSDL with a good XSD, in conjunction with the document/literal
> wrapped style (
> I have not implemented this strategy in Jython, just Java, but it should
> work well in Jython. Something like the following makes sense:
> 1. Use your favorite web app framework like Django or Pylons, running
> on WSGI/modjy, to define web service endpoints (these are just URLs).
> Provide also a service point for getting WSDL docs, properly bound against
> your actual host. You need this binding so tools like soapUI properly work.
> 2. Parse incoming XML requests with javax.xml.xpath. This package
> provides the same namespace awareness for which soaplib leverages lxml, for
> the obvious reason that you need NS support to do any real web service work.
> An alternative is to use ElementTree, but it's pretty slow on Jython right
> now. This is definitely a case where I would recommend using Java libraries
> instead of the available Python libraries. (Better yet would be good Jython
> wrappers of these Java libraries, so porting lxml to Jython is the right
> 3. Use your choice of templating, like Django, Freemarker, Mako, etc,
> to output XML documents. Just make certain you appropriately escape any
> content (any good template system supports that without CDATA hacks!).
> 4. Test, test, test. I like soapUI. I also worked with
> javax.xml.validation to validate soap docs against the WSDL.
> - Jim
> On Mon, Sep 27, 2010 at 12:03 PM, Mark Santcroos <mark@...:
>> I would like to build a web service written in python, but because of
>> our other services I would like to deploy it in our tomcat container.
>> My current plan is using modjy as a wsgi server for soaplib, but I'm
>> open to other suggestions.
>> Are there people who have done similar things and want to share their
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> Jython-users mailing list