--- In [email protected], Steve Jones <jones.ste...@...> wrote: > > In the case on the project I outline below there were specific > services to handle batch, its not just about the interface its about > the behaviours and the SLA. The batch processing service was in > effect only operational for certain hours (we could hot-switch it if > we wanted to) and would take a huge amount of CPU when processing > it. This means it goes beyond the interface as its fundamentally > about the contract and behaviour of the service rather than simply > being a "scaled up" interface that happens to accept lots of pieces > of information at once.
A service defined specifically for batch. I don't know why that strikes me as off. It seems to be a technically driven reason. > What I mean by this is that if it was just the interface then the > "updateCustomer" method that takes a single record and the > updateCustomer that takes a batch would be behaviourly the same, Yes. > i.e. every line in the 2nd case calls the first case. Not necessarily. That's an implementation detail. > With batch processing this often isn't the case as you have to make > sure that the whole batch is valid (or it all fails). Sure. 1 or none. 10,000 or none. > So I'd say that there is a bit of interface operation and a bit of > behaviour. Implementation behavior? Or business function behavior? Regardless of a consumer submitting 1 or 150,000, the intent is the same--submit customers. Why would the non-technical behavior differ if the consumer passes 1 or 100? > See above though, the characteristics of submit customer in a batch > are liable to be different, certainly from an SLA perspective (so > its at least interface + policy) and arguably from a behaviour > perspective (in the case of batch integrity). The SLA of the service could indicate how the number submitted at once are to scale up. E.g. 1 item, <1 sec. 2-1000, < 5 sec. etc. The atomic nature of the interaction could be controlled via the interface itself--an input indicating "on error continue" or "on error, fail all". > I think its a reasonable view, but I'm not sure its completely > right. Right is in the eye of the beholder, no? :-) Creating a service specifically to handle batch (and presumably nothing else) seems misplaced to me. How is this a "service" and not a classic import program found in traditional integration efforts? -Rob
