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 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. Does that seem to be a reasonable view? -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
