Reputation: 868
I am not sure if it's a right word, but in my enterprise we have two types of services: aggregate service & elementary service.
Aggregate service are identified from their interfaces where input is List of Request objects and similarly the Response is a list. The service is supposed to process the List of Requests in mutually exclusive manner i.e. if processing for one Request object, the service must still continue to process next Request object. The usual reason offered is improving performance - instead of consumer calling service in loop, it simply creates list of Request object and call service only once. The other so called benefit is you can group unrelated requests into one request.
Does anyone also use similar kind of aggregate services? if so, can you please provide more information/ or benefits of this approach.
Upvotes: 2
Views: 1959
Reputation: 1400
This is a common practice in service design, idea is that whenever you cross a service boundary, you are inuring a cost. Remember that SOA is about passing messages between services, not references to objects, the price for this decoupled goodness is cross the boundary.
So when you do cross a boundary you should try to squeeze as much out as you can.
In the scenario above, for performance reasons it seems that you are processing items in a concurrent manner, just make sure that if any transaction resource is being used that your locking strategy is in line with your concurrent processing approach.
Here are some links to nice resources about some other SOA service design ideas.
I would suggest you read articles by Thomas Erl and Roger Sessions, this will give you a firm handle on what SOA is all about.
Why your SOA should be like a VW Beetle
Upvotes: 5