Data Related SOA Design Patterns
Get flash to fully experience Pearltrees
Co-existent application of Enterprise Service Bus, Decoupled Contract, Contract Centralization, and Canonical Schema. Listen to the podcasts that accompany this site Data-Related SOA Design Patterns Three Specialized SOA Design Pattern While Enterprise Service Bus provides a range of messaging-centric functions that help establish connectivity between different services and between services and resources they are required to encapsulate, it does not inherently enforce or advocate standardization. Building upon the platform established by Enterprise Service Bus, this pattern positions entry points into the logic, data, and functions offered via the service bus environment as independently standardized service contracts. Canonical Schema Bus is comprised of the co-existent application of Canonical Schema , Contract Centralization , Decoupled Contract , Enterprise Service Bus
How can services be designed to avoid data model transformation? Problem Services with disparate models for similar data impose transformation requirements that increase development effort, design complexity, and runtime performance overhead.
How can direct consumer-to-implementation coupling be avoided? Problem Consumer programs can be designed to access underlying service resources using different entry points, resulting in different forms of implementation dependencies that inhibit the service from evolving in response to change.
How can a service express its capabilities independently of its implementation? Problem For a service to be positioned as an effective enterprise resource, it must be equipped with a technical contract that exists independently from its implementation yet still in alignment with other services. Solution
An enterprise service bus represents an environment designed to foster sophisticated interconnectivity between services. It establishes an intermediate layer of processing that can help overcome common problems associated with reliability, scalability, and communications disparity. Listen to the podcasts that accompany this site The ESB and Related Messaging Patterns Versioning in SOA Enterprise Service Bus is fundamentally comprised of the co-existent application of Asynchronous Queuing , Event-Driven Messaging , Intermediate Routing , Policy Centralization , Reliable Messaging , Rules Centralization , Service Broker .
I am designing several applications to work together through Messaging . Each application has its own internal data format. How can you minimize dependencies when integrating applications that use different data formats? Therefore, design a Canonical Data Model that is independent from any specific application. Require each application to produce and consume messages in this common format.
How can service contracts be designed to avoid redundant data representation? Problem Different service contracts often need to express capabilities that process similar business documents or data sets, resulting in redundant schema content that is difficult to govern. Solution Select schemas that exist as physically separate parts of the service contract are shared across multiple contracts.