- 1 Vapor IO Brings OpenDCRE to General Availability
- 2 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 3 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 4 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 5 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
Apache SOAP 2.2 Overview Page 15
Performance and Future Implementation Development
CORBA, DCOM, and RMI use binary coding for message exchanges. This process requires both parties to know the exchange language. This mode of transmission is very effective but makes it difficult to tweak the application that processes the messages, and while each system uses its own binary mode, these systems do not interoperate easily.
Given that SOAP uses XML coding, it is easier to process the messages at each stage of invocation, which requires a significant degree of flexibility in the development of the SOAP application.
Clearly, reading and interpreting XML messages is intrinsically slower than processing binary messages, because of the coding-decoding time for SOAP messages.
Nonetheless it is possible, in a closed environment such as an intranet, to optimize the processing of SOAP messages using the same client/server implementation. For example, a SOAP client could easily add an additional tag to the HTTP header to indicate that it supports a particular optimization. If the server also accepts it, this optimization could be set up for subsequent transmissions.
The Apache SOAP architecture is fairly slow in comparison to other implementations. Indeed, communication between two Java applications on the same machine works at around 30 round-trips per second, while other implementations can work at up to 700 round-trips per second (see http://www.extreme.indiana.edu/soap/sc00/paper/node13.html#observations).