Skip to Content

In his blog Web Services Overhead Dan compared Web Services to good old RFC by looking at the execution speed. It was no surprise: Web Services are much much slower. But what are reasons?

  • At the caller’s side RFC API seems to be faster.
  • The size the response packages seems to be slower but this shouldn’t have much impact.
  • The Internet Connection Manager needs some time to process requests.
  • We have the SOAP runtime an ABAP side that processes incoming SOAP messages and create outgoing documents.

In this instalment I will compare two stateless web services: an simple ABAP web service generated form a function module and a REST-like web service made by a BSP application and Simple Transformation that generates the SOAP output. In both cases I return only the values of the centraldataperson structure. It will turn out that the REST-like web service is nearly twice as fast. 

For the REST-like web service I created a BSP application with a page result.htm with flow logic. There is an OnRequest event handler that uses an AUTO page attribute BUPA of TYPE STRING that contains a business partner. This parameter is appended at the URL when we call the service: ?BUPA=123456789. So we don’t have to parse an incoming SOAP document.

The SOAP response is generated by a ST program because it’s the fastest way to cope with XML in ABAP:

The Result

The table BUT000 contains more than 1.000.000 entries. I repeated the access 1000 times in both cases and looked at the runtime analysis (transaction SE30). In fact repetition was quite important because the access gets faster because at the first calls lots of data of the soap runtime is written into buffers. To calculate the average runtime I copied the report SAPRSAT1 in the customer namespace and changed it a bit to for my calculation.

In average the ABAP web services needs about 33.000 microseconds each time where the REST-like service needs only about 17.000. It is not surprising that in the REST-like service the BAPI BAPI_BUPA_CENTRAL_GETDETAIL needs 56% of the execution time compared to 21% in the other case.

In fact this is no surprise because the SOAP runtime has a lot of overhead. To be honest  I expected that the overhead would be much bigger. That’s why I looked at the ABAP package SOAP_CORE and learned that the SOAP runtime is quite generic but optimized by using kernel calls like XRfcConverter to access the SOAP header and body.

In fact this was a very simple web service – in other cases ABAP runtime will dominate the SOAP overhead. This is one reason why I don’t think we should migrate ABAP web services to BSP. On the other hand I think there may be potential to improve the performance of the generic ABAP SOAP runtime using generated code and simple transformations.

Epilogue: REST Web Services

I chose to call the non-SOAP web service “REST-like” because passing parameters using HTTP GET is characteristic for REST (represential state transfer) web services. The current SOAP specification 1.2 learned from REST so we can use HTTP GET as well: http://www.w3.org/TR/2003/REC-soap12-part0-20030624/#L10309 .

The BSP web service is a web service because it doesn’t use UDDI, it is stateless and we could return any XML or HTML document. But the REST paradigm goes further:

  • Resources (think of business entities like business partners) are identified by URIs, for example http://www.mycompany.com/businesspartners/123456789
  • We use (HTTP-like) operations like GET, POST, PUT and DELETE as operations for business entities compared to SQL statements SELECT, INSERT, UPDATE, DELETE.
  • The result of an operation is an arbitrary document (XML, PDF HTML and so on). For structured content XML is appropriate – we can use XSLT or XQuery to process them.

REST web services are very close to XML and semantic web technologies. And they are in fact a “web” technology because of HTTP and URI usage. But this doesn’t mean that they are faster because they don’t use the SOAP runtime. Usually REST web services will transfer a complete representations of an objects which can be very resource consuming.

Le me come to the point: The question “SOAP or REST” is a philosophical question about software architecture –  every approach has its strengths and weaknesses.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Anton Wenzelhuemer
    Hi Tobias,

    a view things that immediately come to my mind

    • what happens if I call your service with ?-(/$5THHGHGJGHKJNGH%-/(4556
    • how do you validate the input both on client and server side?
    • how do you supply a service contract (analogue to the WSDL in the SOAP case)to the wanna-be client?
    • are HTTP GET parameters encrypted when using SSL?

    I think it is not correct to make the overhead appear to be a completly useless one. Of course there is always potential to improve performance.

    Of course, if you design completely dedicated, never-to-be-reused, point-to-point connections it makes sense (and one is free) to use an optimized (proprietary) protocol.

    But SOAP & XML is about standardizing and reuse. I think that if you advance any REST-like service pattern to the standardization level that SOAP & XML has today, you’ll end up with the same ‘overhead’.

    Regarding JSON, IMHO the beauty of XML lies in it’s expressivenenss. In contrary to what many believe, HTTP is only one possible transport binding. Actually, you can also bind a SOAP message to snail (i.e. print it, put it into an envelope and send it per mail). The nice thing is that the non computer literate recepient of that message were able to make sense of it (with a little effort though 🙂 ) while he wouldn’t understand a JSON message sent that way.

    thanks for your contemplation anyway,
    anton

    (0) 
      1. Tobias Trapp Post author
        Hi Anton,

        I agree with you. That’s why I wrote the sentence “This is one reason why I don’t think we should migrate ABAP web services to BSP”.

        And I agree, too, that the SOAP overhead if far from being useless. I came to the conclusion the implementation in the ABAP stack is far from being bad: “To be honest I expected that the overhead would be much bigger.”

        In fact I didn’t decide to program a pure REST service – if you look at the Simple Transformation I decided to give out a SOAP message which would be a little bit weird in the REST universe.

        But I’m asking the question whether the SOAP runtime could be made a little bit faster with the techniques I suggested. And if there should be a way to call a stadnard ABAP web service using HTTP GET I’ll be trying it immediately.

        Regards
        Tobias

        (0) 
      2. Anonymous
        Hi, Anton.

        I think you were replying to my post regarding JSON, XML, etc…

        Regarding SOAP transport neutrality, actually we’re experimenting in the manufacturing team with binary web service formats over TCP – creating interop between the Microsoft .NET infrastructure (WCF, formerly known as Indigo) and the Java world.

        I think there are use cases for “all of the above”.  My view of the world is that you have an “intimacy stack” that starts at an API level, for tightly bound, locally connected applications, providing the highest level of performance.  As you move up the stack, you might still have remote transports (RFC, RPC, REST/binary), but light and fast, moving all the way up to clunky, self-describing, loosely coupled, and slow SOAP/WSDL.

        In truth, RFC’s were really a special kind of web services, weren’t they (particularly when invoked over TCP/IP)?  Or, more correctly, RFC’s were a powerful RPC mechanism (self-describing, sync or async, transactional or not, etc) – and remember that SOAP’s original intent was as an RPC mechanism.

        Anyway, this is an interesting discussion, and I hope we collectively change the definition of services, so that we aren’t cursed with the weight of SOAP as our only option(s)…

        – Rick

        (0) 

Leave a Reply