- Service Interaction Patterns
- Service Access
- Access Control
- Service Request Routing
- Service Composition
- Locating Services
- Enterprise Architecture for Services
- Summary
- Key Service Utilization Questions
- Suggested Reading
Enterprise Architecture for Services
Except in the most unusual of circumstances, you will not be constructing your SOA in one mammoth project. Instead, your enterprise will evolve its existing architecture in a series of projects. However, to reap the benefits of SOA, you must make sure that design decisions are made consistently from project to project. The role of maintaining this consistency is typically given to the enterprise architecture group. With respect to services, this group's responsibilities are:
- Selecting the service interface standards to be followed and selecting the supporting infrastructure to be used
- Defining service interaction patterns and their preferred technology implementations
- Defining the criteria to be used in determining when standardized data representations (common data models) should be employed in operation interfaces
- Defining the selection criteria for proposed services and the procedures for validating their appropriateness
- Defining the preferred architectural styles for implementing services and the criteria to be used in selecting a style
- Defining the service mediation architecture and selecting the supporting infrastructure to be used
- Establishing the preferred design patterns for content-based routing and the criteria to be used in selecting a pattern
- Establishing the capacity planning procedures for services and ensuring that these procedures are followed
As an enterprise architect, you should be aware that it is difficult to formulate an efficient and practical set of guidelines without a bit of trial and error. You must make every effort to observe the guidelines and procedures you have defined being put into practice. Are the guidelines easy to follow, or do they constantly require interpretation? Interpretation opens the door for variation and therefore inconsistency from project to project. Such variation may work against your SOA objectives. Observe the level of effort required for project teams to comply with the guidelines and weigh this effort against the benefit you expect from the guideline. Is the effort justified? Be particularly vigilant for signs of excessive administrative complexity, making records that are never used or whose accuracy is never validated. Such complexity not only increases the level of effort, but it can also be a significant source of error.