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 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.