Tell me more ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.
up vote 0 down vote favorite

I'm on a project that exposes SAP ABAP functionality as a web service via Netweaver / Java (7.01 SP3 I think). We consume it on an .NET 4 UI tier. We are dealing with some large message structures (12MB serialized XML) that are taking too many seconds to shuttle between the various tiers.

We're tackling this performance on a number of fronts:

  • Disk, network, CPU and memory are fine and nowhere near saturated.
  • We're working to trial WCF Streaming mode
  • We may try gzip compression on the web service's server
  • And lastly, the point of this question: is there a way to enable binary serialization that's interoperable?
share|improve this question
If you can change the Java side end-point, you can use Ice for proxies and messages or protobuf for messages only. – Karel Frajtak Aug 14 '12 at 8:34
That's an idea worth considering, something like ICE or Zero MQ as the messaging transport. – Travis Pettijohn Aug 15 '12 at 0:22

1 Answer

up vote 0 down vote

Assuming that you already tried everything to get the payload size down and to split it into smaller pieces (12 MB XML, seriously!), I'd say that depends on the kind of XML processing you need on the ABAP side. You could try to implement your own ICF HTTP handlers and go for some REST-style interface. This is especially interesting if you really want to transfer binary data (for example, some document you retrieve from an archive system) because you can then transfer the document via HTTP without the XML-binary-ugliness. Even if you have to use fill WSDL-y web services, you could try to refactor the binary parts out of that interface, just send some (GU)ID through the web service and have the client fetch the binary part from your custom ICF handler.

share|improve this answer
We have to get the whole data set from SAP+Java to the .NET UI somehow. Another approach we're investigating is breaking the request into small chunks and loading either in sequence or in parallel. We turned on Gzip compression and got the 12MB size down to under 200KB. No joke :) – Travis Pettijohn Aug 15 '12 at 8:12

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.