Name: Anonymous 2015-05-08 18:13
With SOAP, the typical workflow is something like this.
First, you write a class that represents your API, and you use decorators to indicate which methods to expose as SOAP calls. The magical SOAP library then takes this information and exposes the class as a SOAP web service, and part of that is a WSDL, an XML document that describes the service and its methods, and links to a schema that describes the types that are involved in these methods. On the client, you then import the WSDL and use it to generate a "proxy" class, which mirrors the methods on the server, but forwards them all through the magic SOAP library and has it call into the server. So pretty close to the "single source of truth" approach, but more convoluted, and with the server unilaterally acting as the authority over the types - if the server changes, the client becomes invalid without further ado and stops working. This change management part is one of the reasons why people started dropping SOAP the instant JSON made its appearance.
First, you write a class that represents your API, and you use decorators to indicate which methods to expose as SOAP calls. The magical SOAP library then takes this information and exposes the class as a SOAP web service, and part of that is a WSDL, an XML document that describes the service and its methods, and links to a schema that describes the types that are involved in these methods. On the client, you then import the WSDL and use it to generate a "proxy" class, which mirrors the methods on the server, but forwards them all through the magic SOAP library and has it call into the server. So pretty close to the "single source of truth" approach, but more convoluted, and with the server unilaterally acting as the authority over the types - if the server changes, the client becomes invalid without further ado and stops working. This change management part is one of the reasons why people started dropping SOAP the instant JSON made its appearance.