SOA Patterns

The study of SOA from a Pattern view can reveal interesting insights not least of which is the fact that it is based on several Patterns that have been around for a long time. According to Miko Matsumura VP of WebMethods, three sets of patterns underlie SOA - the consumer pattern, the provider pattern and governance patterns. consumer patterns of runtime and design governance. Consumer patterns are the simple "give me my stuff" paradigm where the consumer gets a service without worrying about underlying compexities. Provider patterns get a little more complicated - providers may have to do complex processing across different ownership domains , then register5 the service and finally provide the service when requested. Governance patterns are both runtime and design time (validate services before they are registered)

Relationships between SOA and EA

Today, I reviewed some basic concepts of traditional Enterprse Architecture . Also explored the space between and overlaps of traditional EA and SOA. which I believe will help provide bacground context in my exploration of SOA Frameworks.

CSC's SOA Views

In preparation for my next step - which is to look at some of the leading vendors in the SOA space, I began digging into the "blueprint" - the thing I will be able to map to vendor technologies . This blueprint is CSC's SOA Thought Leaders Technology Architecure Framework.

SEI's approach to SOA - contd.

SOA has many promised benefits - Today, I examinde the space where SOA intersects with Legacy Systems, specifically looking into the newer and revised approaches being proposed by SEI to help organizations with legacy systems modernize move to SOA.

What is and What is not SOA

What is SOA
• This is how Eric Marks and Mike Bell define SOA and Services:
“SOA” is a conceptual business architecture where business functionality,or application logic, is made available to SOA users, or consumers,
as shared, reusable services on an IT network.

“Services” are modules of business or application functionality with exposed interfaces, and are invoked by messages.”
What is NOT SOA
• SOA is not a product.
• SOA is not a solution.
• SOA is not a technology.
• SOA cannot be reduced to vendors’ software products,
• SOA is not a quick fix for the IT
• complexity that has accumulated over 30-plus years.
• SOA does not address every IT challenge today. There are some scenarios when SOA is not appropriate
What is SOA
• SOA is not a silver bullet . It needs careful consideration planning and execution but in the end, if executed correctly WILL deliver compelling business value and benefits to any organizaiton
Elements of SOA
• Conceptual SOA vision
• Services
• Enabling technology
• SOA governance and policies
• SOA metrics
• Organizational and behavioral model
A note on Technology
Even though the Technology gets the most press and it’s a valuable element of SOA it is also perhaps the easier part of an SOA and the other elements should not be forgotten








Why SOA – The Solution
Why SOA – What’s different
Why SOA – What’s different
Why SOA – What’s it trying to solve
Why SOA – What’s it trying to solve
SOA Benefits for IT

SOA Benefits for Business
SOA Benefits for Business
Busienss can launch new products and services 30% faster than your competitors because you have reduced or eliminated friction within your enterprise.

Better collaboration between your suppliers and your
design engineers as well as better collaboration with your channel partners.

SOA Governance

Here's a 5 minute "essentials of SOA Governance" capsule extracted from my couple of hours worth of digging -

SOA Governance has two components . It controls how Services are:
(a) Designed & Developed ( Development Governance)
(b) Deployed and Operated (Runtime Governance)

(a) Development Governance - Use Registries and Repositories to govern development. Registries (for example UDDI) can help re-use of service - a directory of what's available and how to use/re-use it - Contains information about the service, its interface, versioning and security contracts. Because of its use of standards - allows interoperability and true discovery & re-use. Repositories contain all the info needed to implement the service - the implementation code, configuraiton, dependencies and infrastructue specific deployment profiles.

(b) Runtime Governance - Ensures that your SOA is operating smoothly and delivering the value that you think it should be . Ensures that you have consistent policy Management (i.e. Security, Logging , Auditng, SLA ). Uses standards like WS-Policy, WS-Security, WS-Reliability.

Service Policies can be separated from development. Developers can focus on developing services to meet business needs and then at the time of deployment the policy makers can define the policies.

Service Design

Continued Review of Eric Marks and Mike Bells work . Focused on Service Design and Realization.


Five Main Steps:
1.Examine the state of business services- composition, business processes and associations.
2.Design business services granularity maps. Rank and position services on a granularity scale
3.Build demarcation maps. Find business commonalities and discover business service associations and affinities.
4. Apply design operations on the services
5. Realize and expose physical solution services.


I find their dual approach of "Bottom-Up" and "Top-Down" compelling .

Bottom up approach consists of six steps:
1. Study business problems / concerns.
2. Analyze business requirements / processes.
3. Construct granular entities based on software library design
4. Establish source code modules which are founded on business context
5. Design and construct software components.
6. Group components into physical solution services.



Both are needed.

Top Down ignores the technology constratints

Bottom up lacks conceptual and analytical approach

Used in combination – a very powerful toolset