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.