Unfortunately, what you've run into are interoperability problems, possibly because different vendors are interpreting the standards differently. The WS-I organization was set up to iron out these wrinkles in interoperability and the result to date is the WS-I Basic Profile which outlines how to properly interpret the standards (you can find it at http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0a.html). Generally, if your services conform to WS-I Basic Profile, they will interoperate with most of the existing implementations. Unfortunately, vendors have not yet made their SOAP implementations WS-I compliant out-of-the-box for services you build with them. If you want interoperability today, sadly, the burden falls on you to make your service WS-I Basic Profile compliant (through careful definition of your service and use of the platform it's built on). Luckily, there are tools which can help you test if your service is compliant (and diagnose why they might not be). An example of this type of tool is SOAPScope.
A guideline I like to follow (beyond the Basic Profile) when I design services are to keep the datatypes simple. I don't mean that you should avoid large data structures, but that you should try not to depend on very specific semantics of programming language data types. For example, don't depend on the fact that numerical data types can have null values -- even though SOAP fully supports this, not all programming languages (and thus consumers) support this. The set of data types I generally limit my services to are non-nullable integral types, non-nullable floating point types, timezone-less date/time, string, enumerations, array-like types, and "structs" (ones that are almost purely data structures with no methods other than "helpers" used to read/write the fields of the data structure) -- of course, the structs can contain any of the data types in this list (including other structs). All of these data types map cleaning into most programming languages that will be service consumers. Other data types rarely map so cleanly or easily.
Dig Deeper on Development implications of microservices architecture
Related Q&A from Daniel Foody
Daniel Foody defines end-to-end security and discusses the different parts of security to consider. Continue Reading
Dan Foody discusses the capability of using Web services for ASP applications. Continue Reading
Daniel Foody discusses the "find-bind-execute" paradigm and secure service directories. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.