The relationship between the SOAP Web Services and the other APIs

1 minute read time.

A customer asked me whether the SOAP Web Services were an extension of the .Net API or a separate API built on top of the COM API.

Below is a diagram that is frequently used to explain the Sage CRM Architecture.

This diagram represents the hybrid architecture of Sage CRM pretty well. It shows both the eWare.dll and the Java-based part which delivers behaviour through the use of Apache Tomcat web apps. This includes the SData RESTful web services.

But it doesn't make mention of the SOAP web services interface.

We know that the eWare.dll APIs, whether for ASP pages, Self Service or indeed the .NET API are dependent on a common COM based core that provides the mechanism to interact with the eWare.dll.

So where does SOAP web services fit in?

The SOAP web services communicate with the eWare.dll. We can see this in the use of the endpoint that provides the WSDL

[http://[servername]/[instancename]/eware.dll/webservices/webservice.wsdl]http://[servername]/[instancename]/eware.dll/webservices/webservice.wsdl

or the endpoint to which requests are directed

[http://[servername]/[instancename]/eware.dll/WebServices/SOAP]http://[servername]/[instancename]/eware.dll/WebServices/SOAP

But the SOAP web services are a separate interface and not an abstraction of the COM APIs.

There will be some common pathways and reuse of behaviour within the eWare.dll, especially around database interaction (low-level CRUD) and the triggering of table level scripts. But the web service methods (described by the WSDL) that are invoked by the requests trigger different internal mechanisms than the COM based behaviour.