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.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access