Options for composing the components of a service orientated application

I work for a polygot organisation where we code in multiple different languages and architectural styles.

I have been writing Service Orientated Application's for around two years now, and have gotten comfortable with the way I do things, and that's the problem.

At the Big SOA level we all agree on how to use SOA principles to connect different pieces of the solution/enterprise.

At the component level we all differ slightly;

Currently I take the every high level component as a service approach to SOA, favouring capability driven interfaces and softeware fortresses. Be the implemenation beans or wcf services the pattern remains unchanged.

Like so, SOA Design Pattern

Others in my organisation opt for the rich domain mo开发者_JAVA技巧del of standard classes underneath a facade. Architectural styles like SOAP, REST have both been used at this level.

We also differ in the style of method call, command style messages vs more activity descriptive messages.

I have used both and am happy with either, my question are there other methods are other engineers using to compose their SOA.

I am interesed in new ideas, how ever wacky, to stimulate new ways of thinking around the topic of building a SOA.

---

I spent awhile building up a components-based approach to SOA called SoaKit that might be helpful. See http://bradjcox.blogspot.com for rationale.

The basic idea is to avoid tools-based approaches (JAX-WS) in favor of a suite of pre-built components (provided by SoaKit) that each do commonly-needed functions and can be snapped together easily to do the whole job. Example components: add SAML signed header, decrypt/encrypt message parts, XSLT/XQUERY transforms, and so forth and so on, with each such component independently configurable.

If an enterprise is a city, a service is a house in that city, and SoaKit components are bricks for building houses. The blog has articles that contrast that with the mud-brick approach commonly used today. The analogy is to evoke the impact Roman brick architecture brought to building construction, seeking to bring the same impact to software.

Hope the notion is helpful. Shelved the idea because the world seemed bent on monolithic magic push-button approaches (JAX-WS) that are nearly impossible to control or understand. That's been my experience with JAX-WS/Metro and WSO2 at least.