Interoperability remains a problem essentially because of developer choices and a focus on what's needed to develop...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
If you search the Web for the old SOAPBuilder results, for example, you can clearly see that the fewer the data types, the greater the interoperability level, especially when working with complex and structured data types. These advanced data types may give the developer a lot of power and flexibility and result in more compact code, but they interfere with interoperability since different languages do not support the same collection of data types, especially not the same set of complex data types. Web services attempts to resolve this problem by mapping individual language data types to XML data types, but the mapping is never 100% and never guaranteed to be automatic.
Performance is an issue with respect to interoperability, so if you have the luxury to stay in the same environment, such as Java EE or .NET, you are better off using a native communication protocol, such as RMI for Java EE and the Microsoft RPC for .NET. If you need to interoperate across Java EE and .NET programs, however, Web services is pretty much the only solution. In that case it's necessary to trade the hit in performance for the ability to communicate programmatically.
Another place to look for means to achieve interoperability is in the area of asynchronous messaging protocols, such as JMS or AMQP. REST/HTTP fits this area as well, at least conceptually (although not in execution— more about that later). The main concept for achieving interoperability this way is that you can avoid using an interface with data types. Instead, you can just put all the data into a big semi-structured message then pass it around like a file (which it is, basically). The program on the sending side is responsible for packing the data into the message, and the program on the receiving side is responsible for unpacking the data and doing something with it, such as accessing a database. This provides a great deal more flexibility in dealing with data type issues but comes at the expense of more complexity.
REST/HTTP is a special case of this because REST/HTTP defines a fixed interface and allows for content type negotiation. The design center is based more on generating and consuming the representations of resources than it is on defining and packing/unpacking messages per se (although conceptually something very similar is happening).
Related Q&A from Eric Newcomer
ACID is used to summarize the basic properties of a transaction in the database sense of the word, not the logical "business" transaction sense. On ...continue reading
Overall it has the feeling of a large set of enhancements to a variety of products in response to various customer requests. Oracle can finally say ...continue reading
What divides mainframe level transaction processing from Java or .NET server level transaction proce
OSGi expert Eric Newcomber discuesses what divides main-frame level transaction processing from Java or .NET server level transaction processing.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.