Web-services granularity with SAP project?

Question

In a project that comes as a third-app on top of SAP to extent its functionality thru SOAP web-services, I am wondering how should be defined the web-services themselves ; should we implement dozen of web-services that achieve simple & atomic actions, or very few web-services that take a bunch of parameters and does all the thing.

I am interested in feedback & suggestions considering :

• workload on the SAP NetWeaver layer (amount of concurrent web-services)
• third app maintenance
• SAP web-services maintenance
• network load (considering SOAP envelopes & HTTP requests)
• any other consideration I may not have thought of

Thanks

OB.

Answer 1

Generalising away from SAP, my first thought when defining a Web Service interface is that coarse-grained services tend to be more appropriate than busy fine-grained services.

This is firstly because the overhead of each call is comparatively large, so fewer round-trips tend to be preferable. (Eg. GetName, GetAddress, GetPhoneNumber versus GetPersonInfo)

Second, if there is logic we want the service to own it. We don't want each client to need to know the order in which to call fine-grained methods. Otherwise we end up duplicating logic in each client.

I have an article here which elaborates on issues such as this.