在定义Web服务接口时，我的第一个想法是，粗粒度的服务往往比忙碌的细粒度服务更合适。
这首先是因为每个调用的开销相对较大，因此较少的往返往往是优选的。（例如GetName、GetAddress、GetPhoneNumber与GetPersonInfo）
其次，如果有逻辑，我们希望服务拥有它。我们不希望每个客户端都需要知道调用细粒度方法的顺序。否则，我们最终会在每个客户端中复制逻辑。
我有一篇文章here详细阐述了这样的问题。

我会沿着SAP铺好的路走：从创建类似细粒度服务的CRUD开始。当您浏览SAP Enterprise Services Wiki时，您会发现SAP提供的大多数服务都是细粒度的。
假设您目前处于服务API的第一次迭代中，可以肯定的是，您不会在第一次尝试时就获得正确的高级API，而是必须在将来扩展它以用于越来越多的特殊情况。因此，为什么不从细粒度的API开始，然后根据真实的经验提供更高级别的API--同样像SAP对组合服务所做的那样。
当然，性能是一个考虑因素，但如上所述：企业服务基础设施是经过时间考验的ABAP引擎的 shell ，而且这个引擎速度很快。

至于SAP网络层上的工作负载，这是一个问题。不应该这样sap abap应用服务器是一个成熟的平台。它的伸缩性很好，可以承受任何负载，只要它在cpu中有一些东西（他有效地使用了cpu）。
因此，问题更多的是网络开销和维护。像djna我相信粗粒度是要走的路。但没有什么特别的sap'y关于它。