The enterprise architecture team is responsible for exposing core functionality in ways that support the application teams. But how is that best done?
I would like to propose a combination of 3 approaches:
* Registration al la COM+
* Enterprise components made available to inherit from
* Callable API's
Clearly there isn't a one size fits all solution. My experience with a generalized enterprise environment has been: data --> exposed by components --> which are called directly by large grain business components or activities wrapped by message based services.
I am growing more and more fond of registration, both persistent and transient. It provides an opportunity to initialize the conversation between consumer and provider. I get loose binding via mechanisms such as reflection and publish/subscribe but tight bounding after the initial conversation with each participant now possessing real knowledge of the other. I am particularly drawn to this for low level services such as component life cycle support, clustering, security and location transparency.
My object side would likes to see the major entities of the enterprise provided to the applications as facade objects which are already integrated into the enterprise plumbing. For example a binary representing a customer would be inherited by all applications. The customer would expose stateless methods as well as methods which return a complete instance of customer. In either case the caller would be unaware of the under-lying complexity working on context (rules, security, location, and time).
The major activities of the enterprise would be similarly exposed as callable API's. That is intentionally plural. Exactly how the API's are structured is domain specific, but it is likely to have some bounded by security requirements and others grouped by interface type (synchronous v. asynchronous) or possibly a combination of the two.