Building a service-oriented architecture implies the understanding of the business and the use of patterns - because SOA is really about architecting for reuse.
Reusability consisted originally of component-based development. We were concerned with reusable building blocks such as:
- Normalized Data Entities (defined information architecture)
- Data-type Domain Rules and Valid Value Sets
- Elemental Processes (Normalized)
- Reusable Screens and Navigation
- Main Event Rules
- Location Type Rules
- Actor Role Rules
- Warehouse Dimensions/Facts
Reusable utility service components came next and they included:
- Naming and Location Services
- Directory Services
- Server Management and Instrumentation Services, including instrumentation for monitoring, traceability, performance statistics, throughput, etc.
- Server management functions including startup, shutdown, health-check
- Logging of errors including business events and issues with
- Security Services, such as authorization, authentication, and encryption/decryption
Most service-based architectures implement some type of design pattern. These patterns are simply listed here. Discussions, tutorials and sample implementations abound on the Internet.
- Layers – basic pattern design
- Façade – provides a simpler interface to an existing application
- Adapter – makes one interface look like another
- Half Sync, Half Async – describes a processing mechanism where some interactions are synchronous (calls that block) and some are asynchronous (non-blocking). This is practically the norm when there is a separate business process layer.
Patterns that we first used when building SOA’s included the following naming conventions (there were none previously, so we had to make them up):
- ADO – Adaptive data object or data abstraction layering
- Half-Sync, Half-Async
- Domain Objects
- Wrapper Façade
- Observer / Mediator
- Abstract Factory
- Composite / Composition
Today, there has been a growth in use of highly engineered or deterministic patterns including:
- Composite patterns - Combine business patterns and integration patterns to create complex global solution.
- Business patterns - Describe the interaction between the participants in an e-business solution. They highlight the most commonly observed interactions between users, businesses and data.
- Integration patterns - By combining multiple business patterns together they describe how to create complex e-business solutions. Integration patterns are the glue between Business patterns.
- Application patterns - Describe how the application logic and data are partitioned and how they interact. They define an overall architecture style (classification) for the application.
- Runtime patterns - Uses nodes to group functional requirements. The nodes are interconnected to solve a business problem. The choice of application pattern will typically lead to an underpinning runtime pattern.
- Consider that when implementing an SOA, one must engineer a solution that both meets the needs of the business today as well as supports future growth of the organization.