I have read some good articles concerning SOA, especially James Avery's articles back in January starting with Adventures in SOA, Part 1, 2, 3, 4, 5, 6 and related comments (especially by Udi Dahan and his later article I'll see you when you get there), but there are a couple of things that haven't yet solidified.
When building a Service Oriented Architecture... the theory is to divide the application up into a number of services. On the one hand the idea is to have as many distinct services as possible (for maintenance and extensibility) while on the hand remembering to keep the number down to a minimum for performance reasons.
So for example, let's say I have 2 simple services: UserManagerService and CustomerManagerService.
UserManagerService has the following methods: GetUserByUsername(username), AddUser(user), UpdateUser(user), DeleteUser(user), IsUserOlderThan(age)
CustomerManagerService has the following methods: GetCustomerByName(customerName), AddCustomer(customer), UpdateCustomer(customer), DeleteCustomer(customer)
where parameters are XML defined by schema
NOW the question --> I want to relate Users to Customers. What to do...
Do I need to build a higer level service which offers additional interfaces (methods) like:
AddUserToCustomer(user, customer), DeleteUserFromCustomer(user, customer), GetCustomerUsers(customer) and this service in turn calls UserManagerService and CustomerManagerService?
Or is it okay to let CustomerManagerService know a little about Users, say just the UserID and add the following methods to CustomerManagerService: AddUserToCustomer(userID, customer)?
Fabrice Marguerie writes about "Factorization" in his article Getting a little closer to SOA and this would seem to suggest that services should not know anything about their peers unless they themselves are consumers of those peers.
Marcus