2009/1/30 Rob Eamon <[email protected]>: > --- 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.
The overall business service (CustomerManagement) was what the rest of the world saw remember. The point about the Submission services was that that was how the backend of the businesses worked, 5 countries and all had mainframe type backends and could give us a dump once a day. > >> 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. There is a big difference between the contracts on those two. > >> 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? Take the Product information, if it was wrong then it had some very sensitive information in it (the sort of people might die type of information) if you do a single update the assumption was that it was a valid edit. With the product file update however you had to do some x-ref pieces on the received information to validate its integrity as a whole before doing the replacement. Its partly technical (and I do say that you can have support services which are technical) but it was also due to the specific business domain (regulated) in which it operated. > >> 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". The difference is that it wasn't a fail due to a specific line, it could be a fail due to an overall x-ref in the received information (i.e. the x-refs didn't have to be linear, so a new line could refer to something that didn't exist) with the single line this wasn't a problem (you just bounced it) but with the batch it was critical. It was related to the complexity of the business data. > >> I think its a reasonable view, but I'm not sure its completely >> right. > > Right is in the eye of the beholder, no? :-) I subscribe to the Brian Clough school ;) > > 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? Firstly its about the management of it, the management of customer batch was done by the customer management team, not by an old school ETL group, the Product Management team dealt with the product batch. Secondly you do need support services (I mention it in the book ;) part of the reason that these were not externally visible services was that I didn't see them as primary business services but as managed support services. Thirdly the mentality and challenges of batch handling are different, this means it makes sense to separate out the coding of that sort of implementation, but within the context of an overall business service. So from the perception of 95% of the project the Batch was hidden behind the business service, but for the teams that cared about it there was a very real difference between the "normal" business service and the submission service. Steve > > -Rob > >
