Our company has a pretty wide mix of systems Windows mostly VB & .Net and Solaris Java & C++.
Standards without standards.
Our company’s standard for interoperability is web services, however that’s more or less where standardisation stopped. The protocols and general design of the web services is down to the individual teams. On the whole the java guys produce XML schemas for there messages, then use this to generate web service stubs using various toolkits, the .Net guys tend to just create a load of objects and let .net serialise them as it sees fit. The Visual Basic code is legacy, and there are some interesting home made web interfaces thrown over some of this code.
Although all these teams work within the Web Service standards, the resulting interfaces can me more or less proprietary.
.Net & Web Services
The web service interfaces that result from .Net using the [WebMethod] attribute in .Net can lead to some quirky WSDL, as the .Net serialiser can add additional mark-up within the embedded XSD, in order to describe classes like Lists etc. This can make life very difficult for non .Net applications to consume.
The flip side of this is that when you try to reference a Web Service built around a complex XML schema (like those sometimes created within java applications), the .Net web method wrapper (the thing run behind the scenes when you add a web reference) can produce some interesting objects, or fail all together.
Java & Web Services
Its more difficult to generalise with java as there are many web service toolkits, but typically as the starting point for a web service is quite often an XML Schema, more thought goes into the messages, and they are typically of a higher standard. This can lead to problems when some of the more exotic devises within the XSD standard are used (Substitution Groups, odd forms of type restriction etc), which can trip up the proxy generation tools (both on the java tools and the .Net ones).
On the flip side, the java proxy generation tools are typically better than there .Net counterparts, and while you can end up with some ugly looking objects, they tend to cope with more complex schemas.
Conclusions when designing a web service.
If interoperability is something that would be valuable to your project now or in the future, then think about the interface. Ultimately this is expressed as an XSD embedded within your WSDL. If its structured correctly, from the outset your life will be much simpler.
Tips for examining your web services structure.
Visualising the Web Service
The XSD describing your Web Service is embedded within your WSDL. Looking at the XSD code in its raw from, can be pretty off putting, so its best to use a tool that will allow you to view it as diagram. We’ve been using Liquid XML studios XML schema viewer for this.
Visualising the request/response from the Web Service.
Ultimately it all comes down to an XML request and response. These are structured according to the XSD within the WSDL. You can easily build sample request, and see the web service output using Liquid XML Studios web service call composer. This allows you to call a web service without having to write an application. It constructs a sample request that you can change to add in more appropriate values, then shows the results.
