Willy's SOA Manifesto

Yep, my own. Although it may have some shared ideas, this is not a group agreement, nor the savior of what is now known as SOA (which is what is being done so far), nor something made for others to follow. It is just what I believe, what I follow, and what I teach each time I can.

So, here it is.

SOA MANIFESTO

1. Commons.
a. SOA is an acronym composed of the words Service Oriented Architecture, which relates to an architectural style that is based on the rules of the service metaphor.
b. A Metaphor is an application of the figure of speech concept to the IT design discipline. Using metaphors in architectural design actually refers to observing the rules of behavior of a particular entity in the business domain, and mimic them with an architectural element.
c. A Service is conceived as a cohesive (and coherent) business functionality, technologically neutral, offered through a uniform interface. A Service is a plain, homonymous metaphor of a business service.
d. For an architecture, Orientation describes the guidelines, principles and decisions that are based on the rules that govern the metaphor behavior.
e. The Architecture refers to an actual style that defines the architectural constrains, suitability and consequences of using it.

From (a) to (e) :

SOA is an architectural style whose components, constrains and principles
are driven by the service metaphor.

2. Delta
By definition, and in contra-position from some usual implementation, SOA IS NOT:
a. An Indirection Layer for interoperability.
b. A Decoration Wrap for legacy code accessibility.
c. A Component from a whole that represents one architecture instance
d. A Service Group or container of services
e. A Business Process Container.
f. A Modernization Agent
g. An Object Distribution Technology
h. An Antagonist of REST
i. A ROI salvation
j. A Way of Life, A Philosophy of Doing or a Trend (It is an architecture style!)

Corollary of (j): SOA cannot be killed, it cannot just die.
It can be suitable for a problem or not.

By definition, and in contra-position from some usual implementation, Services ARE NOT:
a. Necessarily Web Services as defined in the WSA.
b. Ways to implement RPC nor RMI.
c. Exposed Methods or Objects.
d. Defined by the process they execute
e. Necessarily Stateless (YES, they should not necessarily be Stateless).

3. Principles.
Whenever there is the opportunity when working with SOA, people should
a. Favor Business Value exposed in the business domain OVER Business Value exposed with IT domain.
b. Favor Composability OVER Integration through Interoperability, AND favor Integration through Interoperability INSTEAD of Distribution.
c. Favor Metaphor rules INSTEAD of Tool rules
d. Favor Pure Document Style INSTEAD of RPC/RMI style. (NO WRAP TRICKS ALLOWED)
e. Favor Messaging OVER Other communication options.
f. Favor Business needs OVER specific IT practices (like optimization or flexibility)
g. Favor Entity documents OVER commanding documents
h. Favor Versionable documents OVER Structurally static documents.

So it is written.

William Martinez Pomares

Notes on SOA Manifesto

In a recent discussion at InfoQ about the news of the upcoming SOA Manifesto, I had discussion with great people, including Jean-Jacques Dubray and Steve Ross-Talbot both renowned guys in the SOA world. We all talk the same, maybe at different levels or on different realms. Still, I promised Steve to put my two cents about SOA. Well, here I have a couple of ideas about it, too high level, but trying to clarify at least the three words that conform the acronym.

Well, here they go.

1. Many people talk about SOA and Services, but I’ve found in presentations, articles, case studies, working with tools vendors and looking at real implementations, that not everyone understands the concepts quite right. So, I have a couple of posts (here, and here) and a short video in the Architecture Journal (SOA Myths), explaining the types of perceptions people have about the concepts, and why I think they are wrong. I assure you it is a good list, interesting to read. So, that would be my first contribution.
2. Now, let’s check on the Service concept. As I mention in the posts, to me a service is a cohesive (and coherent) business functionality offered through a uniform interface. And it is technologically neutral. What does that mean? Well, a service is a plain, homonymous metaphor of a business service, just like the loan service in a bank, or a delivery service of you mail office. As a metaphor, it is driven by the rules of common services, with contracts, processes, protocols, controls and evolutions. Its actual implementation may be whatever, but it should not surface the definition, meaning users of a service do not have to know how the service was implemented to use it, and should not have to learn anything else apart from the rules and protocols of regular business services interactions.
3. Now, Orientation. For an architecture, orientation describes the guidelines, principles and decisions that are based on the rules that govern the metaphor behavior. That is, the service one.
4. Architecture refers to an actual style that defines the architectural constrains, suitability and consequences of using it.
5. So, SOA is an architectural styles whose components, constrains and principles are driven by the service metaphor.
6. Service implementation is out of scope. Service metaphor implies business domain. The implementation domain should not surface into the business view, not affect the rules of the metaphor. This is something almost all of implementation fails to accomplish: to use a service you usually must know implementation details, and those are the ones that actually avoid flexibility and change.
7. The service contract requires a semantic agreement (standard shared business semantics are a must), functional specification, pre and post conditions and the description of side effects. All that is technologically neutral.
8. Lastly, and just for the records: to me, reuse is not a business concept, but an IT one. So, Services should not have as a goal the reusable property. In business, the property is composability. The key is to be able to create higher-level services from composing lower level ones. Reuse is a side effect, and should not be the base for ROI, because it will never make it!

Hope this is clear.

William Martinez Pomares

Styles, Pattern and Idioms

From a recent discussion with Duncan Cragg, related to his proposed FOREST, a get-only-rest-integration-pattern I came to think that it was good to create a little post to explain the difference between an Architecture Style and a Design Pattern. So, let’s do it.

It was Christopher Alexander, in his book A Pattern Language: Towns, Buildings, Construction. (Oxford University Press, 1977) that coined the Pattern term to denote ideas or solutions that were proven to be successful and widely used.

Well, that book was about buildings, and Alexander was an architect, of the building class. When mapped to the IT field, we have three levels at what we develop: Strategic, Tactical and Operational, or Architectural, Design, Implementation. So, we have those “ideas or solutions” in all those three levels. For Architectural level, we have Architectural Styles. For Design level, we have Design Patterns (or just plain patterns) and for Implementation level we have Idioms. You can read the definitions in POSA1 (Pattern-Oriented Software Architecture:A System of Patterns from Buschmann et al, Wiley 1996).

The style name is discussed by Roy T. Fielding in his dissertation about REST. He actually dislikes a little the name since he says it represents more a particular way of doing things (that singer’s style) rather than a general way of doing things. Coming from the art world myself, I can say it has that other meaning: a style is a way someone follows, and thus “followable”. Given someone is so original that creates a new style that others follow, does not take away that followable quality, only makes it richer.


So, as you know, the architecture of a system is the organization of its elements and their relationships, guided by principles. When defining a style, you define what types of elements would you use, what do they do, the relationships, and principles to guide their construction. A Simple example is the Client Server style. It identifies two architectural elements, the client and the server, indicates what each one does and who will the interact. Not this is a global solution: the whole system works Following this style.


BTW, Roy defines the Styles more like a set of constrains, coordinated, that define the elements and relationships. Actually, REST is defined that way in this dissertation.


When defining a Pattern, you work closer to implementation. There, you define a solution in the domain context, identifying actors and processes, relationships and results, aimed to solve a localized problem. The example here is the Factory. To solve the problem of needing different but similar objects depending on some parameter, the factory proposes the creation of the right type of object. Note this is in an object oriented context, and the solution is given in terms of objects, and it is to solve a particular problem in the whole system, not to define the whole system. Finally, note this is an idea that can be implemented in any OO language, and particularly in Java you can do it using inheritance or interfaces, meaning the pattern does not impose an specific implementation.

The Idioms are little patterns related to languages. These are proven ideas of how to accomplish things in one particular language. Say, to use StringBuffer in Java to concatenate strings.

As you can see, in general, patterns are good things, but quite different depending on the development level you are using. Now, to define a pattern, you need to provide at least five things, per Nick Rozanski and Eoin Woods, in Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives (Addison Wesley 2005).:

1. A name
   
2. A context where the problem and solution may be presented.
3. A problem to solve
4. The actual solution, given at the appropriate level
5. The consequences of applying that solution.

So, it is important to check all that before defining a new pattern, or before applying it. This last part is very important, since you may end up using a pattern that is not suitable for the context, for the problem or that has unwanted consequences.

Hope this helps clarify the concepts!