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

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!

When creating a solution, much of thinking goes into the creation of functional chunks, database tables and generation of reports. Basically, the definition is made part by parts, and then it is all glued together.

Now, how do you glue it? At architectural level, it is important (and often overlooked) to define a flow strategy. What is that? Well, all the functional elements will have to execute at some time, and the execution may have at least start and one end. But before and after that what happens? How do you get to that start, and what do you after the end?

At one particular moment, the application may be doing several things, all coordinated. At the next moment some things will continue, other will stop and other will start. That “movement” is the flow, which is important. Think two applications with the exact same elements, but with different flows: they will behave differently, and even produce different things!

So, which flow strategies are there? Of course, your actual application does have one, maybe you don’t it yet but there it is, just like an undocumented architecture. Let’s review some of the strategies:

-> The Script. In this strategy, there is one script, like in the movies, where all is described: from the start, the time when one actor cries and the way another actor jumps out of the window. And there is a director, who is in charge of telling the actors what to do. Notice that the actors (architectural element, components, or even plain objects) know what to do and they do it, but the time when they must act, and the decision of who is next, is the director’s job. And this can be hierarchical, where one higher director will control other directors, which in turn control the actors.
Another important thing is the director may know all. That is, there is a continuum manager (the director or a helper). Meaning the state, persisted or not, is taken care of by the directional staff, and not by the actors.
This is perfect for concurrent processing, with highly pluggable and independent pieces of code.

-> The Production Line. If you center the flow on the processed entity, then you can have a production line. Here, the entity goes from one station to the next one, following one sequence (with forks in some parts and sub-roads). You recall the Pipes-and-filters here. The flow is actually very static, predefined. There are decision in the way too. The state in this case is managed by the actual entity, and in some cases you may need to avoid state at all.

-> Democratic Control (Chained, Distributed). This is a very common setting: the flow is in the actual executed code. That is, one piece of code not only executes its task, but also knows which other piece is called next. Of course, this means coupling and a bad separation of concerns. A change in the flow will require changes in the business code. Despite this, it is commonly used by developers (without much thinking in the strategy).
It may be use in very simple cases, with a very static flow, where the construction of a more complex flow strategy may not be worth it.

-> Workflow (or control container). Usually it uses orchestrators (I prefer to call them directors) in an engine, which will parse and interpret the flow. It seems similar to the Script, but here the engine is a generic orchestrator that executes a flow, instead of a functional element programmed with the flow itself. It is more flexible as a change to the flow may require simple adjusting the flow definition. The engine will not suffer modifications.
This is the regular workflow solutions out there, like WFF and the tools using BPEL.
The problem with this is that you require a control container, an engine to execute the flow.

-> Reactive (Event Driven). The other strategy is similar to the democratic control, as the control is associated to the functional pieces. Here, the pieces are no chained, and the control may be an aspect. Each piece is passive but listening to the environment, until something happens. Then, some pieces may decide to act, and perform something. That performance may be also detected by others, and so on. These are event driven systems, where there is an event engine and the pieces are the ones that act upon messages or events. Note the control here is in the pieces, not the engine.

So, now: which flow strategy do you use?

From many talks, blogs, case studies and reviews, I have collected a list of conceptions of what people think SOA is.

Yes, Service Oriented Architecture may mean different things for different people. I’m not talking about definitions, since those are more academic-theoretical things. Conceptions are more like the practical being of the concept.

Most conceptions differences are subtle, but enough to be important.

Let’s star by saying I conceptualize a SOA (yes, an instance of a SOA) as an architecture whose elements, in majority, represent (or are) services. SOA is an architectural style.

That said, here is the list:

SOA as an Acronym. Yes, SOA is just a name created by composing the first letter from Service Oriented Architecture. Thus, SOA is taken as yet another acronym that may be compared to other named technologies. Just another one of the bunch.

Academic SOA. In trying to explain the concept, many academics find several similarities with other concepts they had known from long time ago. Are they simple exposed objects? Are services similar to Complex Systems? What is the difference between a Service and an Intelligent Agent? Of course, there are differences. Services were never meant to be exposed objects or components (although implementation made that happen). Complex systems have evolution, self organization, chaos is involved and emergence (clearly, services are far much simpler). And of course, an agent is something that is not only autonomous, social (talk to other agents) and react and pro-act, but also have intelligence. Services do not.

SOA as an Indirection Layer. Now this one is more on the earth of implementations. SOA is seen just as a layer that receives commands or requests, and passes them down to the real working objects (that ones with the business rules). So, SOA is just a way to add indirection to the requests, encapsulating and hiding the actual how-to. Of course, this conception is wrong by a great deal. SOA is not a layer to begin with. Being an architecture, it should be an organization of elements, the majority of them representing services. As implementation, we may think of services as the layer before the actual implementation, but the service is really the complete thing: the service contract, interface and inner implementation.

SOA as a Wrap. This is very similar to the above. SOA is seen just as a decoration for already made business logic. Usually presented as a salvation for legacy code, SOA is depicted in the diagrams as a layer that wraps the old in-use code, and made it usable for the new generations. (Careful with that picture, it is not as easy to expose old functionality with new interfaces, old code may not be designed to handle new load or business flow). Of course, SOA cannot be a wrap. You can create a wrap that uses services, but then your architecture will have new elements on top, services in the middle and old code down below. That is a sandwich, not really an architecture oriented to services.

Pages: 1 · 2

This was the first day of OMG's technical meeting, here at Costa Rica.
I attended the Architecture-Driven Modernization (ADM) – Case Studies Information Day hosted by William Ulrich and Philip Newcomb.

First of all, William did a great introduction to ADM, that I can summarize as a process to update software system solutions (legacy ones) to newer (modern) languages and architectural best practices.

Now, the actual focus was about synching the business architecture to the IT (technical) architecture. This idea I had talked about in several other places: there is a trend to create IT solutions that require the business architecture to be adjusted to the IT decisions, and not all the way around. And they seem to move independently.

The presentation was good, but, based on the cases that were presented, the whole ideal was not actually implemented as it was described (maybe I missed something). Two cases were about translating the solution from ancient languages to new ones (Modernization of the EuroCAT Air Traffic Management System (EATMS) and Model-driven Reverse Engineering of Cobol-based applications). The other case was a different approach, using a SOA wrap of the legacy modules and building improvements upon it (SOA and BPM enabling an Agile Enterprise Architecture that, btw, didn't mention much of BPM).

So, my questions went around the ideal presentation of using architecture as a driven force to modernization, still the cases were more on language translation (so far no architecture look up). Also, the language translation was achieved using tools that were to automate the process. In this regard, I'm not sure about the capabilities of those tools to pass from a pure procedural language to an object oriented one (I know you can use Java for procedural programming, but to use it as OO requires modeling that cannot be automated). Still the answer Phil gave me was that I made an assertion, not a question, and that my assertion was wrong. I blame my english.

OMG has two standards, KDM (now an standard) and ASMT (in final stages). The first is to model knowledge, used to obtain a model of working solution. The other one is to model language, so I can pass from a written program into ASMT, do refactoring there (language agnostic) and then save using another language. That way I get language modernization (refactoring since there is no functional change). I think that is great.

Still, I was expecting more discussion about architectural visualization of legacy systems, architectural refactoring and evaluation of legacy solutions.

I will read a little bit more and write another post about that.

Will see tomorrow on the SOA and BPM day.\

William Martinez Pomares.