CODEWITHSUNDEEP
web-servicessoapnetweaver
Olivier BOISSIN
Olivier BOISSIN

Reputation: 208

Web-services granularity with SAP project?

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 :

Thanks

OB.

Upvotes: 3

Views: 422

Answers (3)

Frank Bechmann
Frank Bechmann

Reputation: 81

I would just follow the road, that SAP paved: starting with creating CRUD like fine grained services. When you browse the SAP Enterprise Services Wiki, you will find that most services provided by SAP are fine grained.

Assuming that you are currently in the first iteration of your service API, it's about sure, that you won't get a high-level API correct on the first try, but instead would have to extend it for more and more special cases in the future anyway. So why not start with a fine grained API and provide a higher-level API based on real world experience later - again as SAP did with the composition services.

Sure, performance is a consideration, but as written above: the enterprise services infrastructure is a shell for the time-tested ABAP engine and this one is quick.

Upvotes: 1

Igal Serban
Igal Serban

Reputation: 10684

As far as the workload on the SAP netweaver layer is a concern. It shouldn't be. The sap abap application server is as mature platform as you will encounter. It scales wonderfully and can take any load, as long as it got something in the cpu's ( which he uses efficiently).

So the question is more of network overhead and maintenance. Like djna I to believe that coarse-grained is the way to go. But there is nothing specifically sap'y about it.

Upvotes: 0

djna
djna

Reputation: 55957

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.

Upvotes: 2

Related Questions