SOA Implies Understanding Patterns

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.