2009/1/30 Rob Eamon <[email protected]>: > It would seem then that the statement "...batch processing can be > better handled as a service..." may be a bit off. Batch appears to be > a characteristic of the interface/operation rather than the main > focus of the service.
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. 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, i.e. every line in the 2nd case calls the first case. 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). So I'd say that there is a bit of interface operation and a bit of behaviour. > > In other words, I think it is better to think of "batch interface" > rather than "batch service." The focus of the service is defining > what "submit customer" does and then providing the interfaces needed > by consumers, batch or otherwise. 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). > > Does that seem to be a reasonable view? I think its a reasonable view, but I'm not sure its completely right. Steve > > -Rob > > --- In [email protected], Steve Jones > <jones.ste...@...> wrote: >> >> Batch processing itself (IMO) isn't a service that is just the >> technical implementation. >> >> As an example I did a system in 2000 where there were two batch >> interactions, one was for the customer information the other for the >> product information, we received these each night from the mainframe >> and updated the local system. Now the main service was >> CustomerManagement but "inside" this service (i.e. Customer >> Management was at Level 1) there was another service called >> CustomerSubmissionService which was only accessible to Customer >> Management and could only access customer management. This >> Submission Service was the batch processing engine which received >> the, rather large, update files over MQ and then did the database >> update. >> >> Implementation wise we used MQ round-robin for failover for >> resilience and a tiny bit of load-balancing. >> >> So batch processing wasn't a service it was the _implementation_ of >> a business service (CustomerSubmission) which from a domain >> perspective was wholly contained within an overall business service >> (CustomerManagement). This meant the folks dealing with customer >> had responsibility for all of customer work (including the batch >> job). >> >> The same model was used for Product. >> >> Steve > >
