Boundaries are explicit – A service with well defined boundaries should provide no visibility to the internal implementation of the service. This allows a services implementation to be versioned without breaking external systems. It will also allow Global Bank to outsource provisioning of certain services at a later point in time, as the services interface makes no assumptions about its internal implementation.

Some guidelines for ensuring boundaries are explicit include:
* Selection of functionality to be represented as a service should be based upon generalizable logic that can be reused independently of geography, trust authorities or particular execution environments.
* Service boundaries should not require platform dependent context such as would be necessary for a service to participate in a 2 phase commit.
* Service implementation details such as internal database row identifiers commonly found within a dataset should not leak outside the boundary of the service.


Please insert remarks / discussion here:

Q: I have been working on creating an enterprise wide application role based service for internal consumption and have found it very hard to communicate these tenants to my fellow programmers. Is there a white paper or practices page that outlines interface boundary best practices that I can point others to? -- KirkViehland
A: Yes - Check out Principles of Service Design: Service Patterns and Anti-Patterns -- RonJacobs

Back To: GlobalBankWiki
Back To: ServiceOrientedArchitecture