- Overview
- Design Patterns (alphabetical)
- Overview
-
Agnostic Capability
-
Agnostic Context
-
Agnostic Sub-Controller
-
Asynchronous Queuing
-
Atomic Service Transaction
-
Augmented Protocols
-
Brokered Authentication
-
Canonical Expression
-
Canonical Protocol
-
Canonical Resources
-
Canonical Schema
-
Canonical Versioning
-
Capability Composition
-
Capability Recomposition
-
Compatible Change
-
Compensating Service Transaction
-
Composition Autonomy
-
Concurrent Contracts
-
Containerization
-
Content Negotiation
-
Contract Centralization
-
Contract Denormalization
-
Cross-Domain Utility Layer
-
Data Confidentiality
-
Data Format Transformation
-
Data Model Transformation
-
Data Origin Authentication
-
Decomposed Capability
-
Decoupled Contract
-
Direct Authentication
-
Distributed Capability
-
Domain Inventory
-
Dual Protocols
-
Endpoint Redirection
-
Enterprise Inventory
-
Entity Abstraction
-
Entity Linking
-
Event-Driven Messaging
-
Exception Shielding
-
File Gateway
-
Functional Decomposition
-
Idempotent Capability
-
Intermediate Routing
-
Inventory Endpoint
-
Legacy Wrapper
-
Lightweight Endpoint
-
Logic Centralization
-
Message Screening
-
Messaging Metadata
-
Metadata Centralization
-
Micro Task Abstraction
-
Microservice Deployment
-
Multi-Channel Endpoint
-
Non-Agnostic Context
-
Partial State Deferral
-
Partial Validation
-
Policy Centralization
-
Process Abstraction
-
Process Centralization
-
Protocol Bridging
-
Proxy Capability
-
Redundant Implementation
-
Reference Data Centralization
-
Reliable Messaging
-
Reusable Contract
-
Rules Centralization
-
Schema Centralization
-
Service Agent
-
Service Callback
-
Service Data Replication
-
Service Decomposition
-
Service Encapsulation
-
Service Façade
-
Service Grid
-
Service Instance Routing
-
Service Layers
-
Service Messaging
-
Service Normalization
-
Service Perimeter Guard
-
Service Refactoring
-
State Messaging
-
State Repository
-
Stateful Services
-
Termination Notification
-
Trusted Subsystem
-
UI Mediator
-
Utility Abstraction
-
Validation Abstraction
-
Version Identification
- Design Patterns (by category)
- Foundational Inventory Patterns
- Logical Inventory Layer Patterns
- Inventory Centralization Patterns
- Inventory Implementation Patterns
- Inventory Governance Patterns
- Foundational Service Patterns
- Service Implementation Patterns
- Service Security Patterns
- Service Contract Design Patterns
- Legacy Encapsulation Patterns
- Service Governance Patterns
- Capability Composition Patterns
- Service Messaging Patterns
- Composition Implementation Patterns
- Service Interaction Security Patterns
- Transformation Patterns
- REST-inspired Patterns
- Compound Patterns
- Microservice Patterns
- Big Data Patterns
- Cloud Computing Patterns
- SOACP
SOA Patterns and Application Technologies
It is important to view and position SOA as an architectural model that is neutral to any one technology platform and service-orientation as a paradigm that is neutral to any distributed implementation medium. By doing so, you have the freedom to continually pursue the strategic goals associated with SOA and service-orientation by leveraging on-going technology advancements.
For example, a service can be built and implemented as a component, a SOAP-based Web service, or a REST service. Essentially, any implementation technology that can be used to create a distributed system may be suitable for service-orientation. Many of the design patterns in this catalog are not specific to any one of these three implementation mediums, but some are. Several examples are based on the use of SOAP-based Web services because this service implementation medium has been historically the most popular. This does not preclude you from applying the patterns with other suitable technologies. Some patterns in particular can be carried out with vendor-specific products and technologies that rely on alternative communication protocols and APIs that are not based on industry standards.
When deciding on what technologies to use for a given pattern, it can be helpful to take some of the standards-related patterns into account, such as Canonical Protocol, Dual Protocols, Canonical Resources, and Canonical Schema. These types of patterns can provide regulatory guidance to help you establish some baseline criteria for technology selection.