SOA Design Patterns

According to an article about SOA design patterns, they are patterns that relate to other patterns. What that means is that "in order to apply one pattern, you may be required to apply (or have already applied) another."(PCWORLD)

What these SOA patterns do, aside from relate to one another is to provide a framework for real world applications. For example:" a pattern called Logic Centralization essentially establishes a rule whereby, for any given reusable body of solution logic, only one official service can exist. This reduces the risk of redundancy and maximizes reuse potential among services within a given domain." Here this pattern is applied: "imagine a service that encapsulates several databases and a legacy system. Even if we centralize the logic represented by the service, we are still not doing anything to prevent all of these underlying resources from being accessed directly via traditional-style integration channels. This is where Contract Centralization enters the picture.
The Contract Centralization design pattern limits external access to a service to its published technical contract (or interface or API), which means that the underlying resources cannot be touched by outside programs or applications (which we can refer to as service consumers), because the sole point of entry is the service contract.


As you can see this is quite involved but below is the link to the article for further reading.


http://www.pcworld.com/businesscenter/article/150569/working_with_soa_pattern_relationships.html