A simple tutorial on Java and. NET SOA Interoperability

In this article, we're going to show you how to use simple technology plus a document-centric approach to bringing valuable business services without having to use proprietary middleware or the complexity of Web service stacks. Our inspiration comes from the architectural style of rest and the ability to move XML over the HTTP protocol.

How Web services are

The best way to introduce our approach is to compare it to a simple Web service example. Suppose there is a simple weather service that exposes a Web method called "Weatherquery", which returns an object that contains temperature and barometric values. In general, people take ready-made code, use tools to expose methods, and generate WSDL.

If you believe in this scam, all you have to do is find a WSDL equivalent tool in Java and generate stub code.

Unfortunately, things are not that simple, WSDL is a generalization of the standard, and in fact the scope to allow people to interpret freely. In our case, we find that. NET enforces a document-based approach, while the Java tool uses the opposite RPC method. In addition, we have found problems with namespace obfuscation, schema inclusion, and tools splitting the WSDL into separate parts. In short, this technology has begun to focus on the practical problems we are trying to solve.

In addition to these issues, we have found inconsistencies between the tools of Web services. For example, for a WSDL document that is automatically published, there are different versions of the Internet Information Server and Web Services enhancements, as well as their Java equivalent products, which are only partially compatible with each other.

Some things are patchwork to work today, but tomorrow, if a later version of the service requires more sophisticated Web methods, it will break down. These things are really annoying to us.

A more restful style.

There are two key assumptions in the above method: first, exposing only one existing method call is enough to give us a meaningful service, and secondly, using tools makes it a piece of cake to work with Web services to access the service.

Instead of considering the requested parameter and the type of return, we can think of the request as a document that contains the requested type and the corresponding parameter. Consider this document as a description of the contract in the business process that you are trying to model. If we use the same Weatherquery method as an example, using common XML to describe it, we can get something like the following-