Handling WCF binary SOAP requests

Hi,

Is it possible to use Gatling when testing a service that takes requests of type application/soap+msbin1?

When I have run the recorder I have the binary request files in the request-bodies folder and the request body is filled using RawFileBody. The problem is that I need to change some parameters in the request using session variables.

Anyone has an idea or has some experience working with soap+msbin1 requests?

BR,
Gustav

Hi,

I don’t know anything about Microsoft specific formats.
Is this format text or binary?

If it’s text, with Gatling 2, you can use ELFileBody instead of RawFileBody and use Gatling EL syntax.

Cheers,

Stéphane

It is a binary format unfortunately.

BR,
Gustav

“application/soap+msbin1” is a MS specific format (so much for WS interop, reminds me of JAX-RPC…).
I seriously doubt you’ll be able to find an open-source, JVM implementation of this encoding, so I’m afraid you’re stuck with VisualStudio…

If you were to find such an implementation, please feel free to ping.

Regards,

Stéphane

WAPT load tool (pro version) claims to have full support for this special MSBin1 binary format, used for instance by Silverlight apps. The free version does not support this special plugin though.
http://www.loadtestingtool.com/silverlight-testing.shtml

LoadUIWeb load tool seems to offer some support as well?

“LoadUIWeb can decode .NET Binary XML (Binary XML and Binary SOAP). This means that with LoadUIWeb, you can perform load testing of applications that use these formats to communicate with web servers…”
http://loaduiweb.org/docs/generalinformation/supportedapps/ria/protocols/support-for-binary-xml-format.html

How can WAPT and LoadUIWeb manage this if msbin1 is Microsoft proprietary?

rgds Juha

Sorry, the term proprietary is maybe inappropriate. I don’t know if the format is under close license so you have to pay MS if you want to write an implementation, or if the specification is public.

In any case, all the implementations you mentioned are neither open source nor free.
And that makes sense:

  • enterprisey
  • not widespread non-interoperable protocol
  • no open-source concurrent Java implementation
  • implementation costs: MS licenses + learing curve for people with a Java/Linux background
    Generally speaking, this is the typical drawback of using very specific protocols: very hard to test and generate lots of hidden/non anticipated costs.

For example, in my company, we have some Flex applications that used AMF (testing hell), and we migrated everything so the services now expose JSON (migration cost…).

IMHO, using this MS specific binary format was a bad idea to begin with :wink: