IF YOU BUILD IT

... Will they Come?

October 2006

Okay, I know it is a bit of shameless promotion--but it is also related to this blog's subject matter.

The draft for the first chapter of my book SOA Patterns is available on-line from Manning Publications Co.

The first chapter talks about software architecture and the inputs architects can/should use to design an architecture (emphasizing Quality Attributes). It explains the challenges of distributed systems and takes a look at the SOA from an architectural perspective.

You can freely download the chapter here

Any comments are welcome and appreciated. (You can also leave comments at soa@rgoarchitects.com.)

Posted by Arnon Rotem-Gal-Oz at 02:15 PM  Permalink |

While on the subject of architecture evaluation.... There are two tools that can help you evaluate the structural quality of your architecutre and design. Note that this is not the same type of evaluation I talked about in the last post.

The structure evaluation needs the architecture to be implemented (at least at a skeletal level). Also it is mainly based on depenency and complexity evaluation and not on how well the quality attributes are addressed (this is why it is "structural evaluation"). Nevertheless, these tools are important and can help you maintain the integrity of the design.

The first tool is Lattix LDM. To actually understand how it works, you can read an evaluation of .NET Framework using this tool.

The other tool is Stucture101. In addition to tracking dependencies (as Lattrix does), it also tries to evaluate the complexity of packages. Again you can get an idea of how it works by looking at an evaluation of a framework--this time it is Spring.

These tools do not absolve you from evaluating how the architecture fits the requirements or how one architectural option is better than another in fufilling a quality attribute while not contradicting another. They "just" help you with balancing the structure of the architecture and design once you decide what you want to build. This "just" can save you a lot of troubles as your architecture and design evolves.

Posted by Arnon Rotem-Gal-Oz at 06:23 AM  Permalink |

I saw the following question on one of the forums I monitor:

Most often you would have come across a situation when you need to design a solution which is esoteric in nature and technically perfect, but ultimately undoable by the team you have (for development) or undoable due to unknown reasons.

What have you done in that scenario?

Have you designed applications that are doable today rather than tomorrow? Or have you designed applications that are technically perfect but doable only tomorrow and are bound to be a failure when developed by handicapped teams?

Which approach do you prefer as a Software Architect? Building perfect designs or building doable designs?

I think the answer is obvious -- I would go with doable architecture anytime. What I answered this guy was:

There is no use for a "undoable" design.it is just a waste of time and money.

The architect's role is to find a pragmatic solution that will satisfy as many as possible of the system's quality attributes (performance, availability etc.) required by the system. As an architect you need to strike a balance between these requirements the budget and time constraints and the capabilities of the team who will develop the solution.

If you have (or worse, you are or part part of ) an architect or architecture team that makes such decisions challenge them to evaluate their architecture early either on paper or better yet in code .I think there is no place for ivory tower architect in modern software development. Architects should be involved.

Posted by Arnon Rotem-Gal-Oz at 06:09 AM  Permalink |

I recently read a post by Nicholas Allen about "avoiding OneWay deadlocks" (using Indigo, ah, Windows Communication Foundation). The article explains some of the technical issues behind OneWay messages. What's more interesting, however, is the issue of deadlock and services.

If you architect/design a SOA solution where you get deadlocks between services, well, you shouldn't be designing SOA solutions in the first place. Alternatively , if you are just using "web-services" technology to implement plain old RPC, while thinking web services will absolve you from your RPC pains (such as worrying about deadlocks), then it serves you right.

In my eyes, one of THE anti-patterns for SOA is extending transactions over a call outside the service. For one, you can't assume an external service will be willing to participate in your transaction. More importantly, you cannot afford to do so. The service boundary is a trust boundary. services on the outside do not care about you. performing a distributed transaction from one service to another is giving up on service autonomy.

Even if you don't try to have a remote service participate in your transaction and just want to wait for the other service to return within an internal transaction you still have bad design. This is opening your service to deadlocks as your service now holds a resource locked for the duration of the call, which, mind you, is a remote one over the wire one. (Remember the Fallacies of Distributed Computing.)

A better approach is have the data cached locally when your service needs it. you can do that either by actively going and fetching data by implementing a patterns I call "Active Service" (a service with an active thread that can talk to other services on a scheduled basis) or have other services publish their state continuously (a pattern I call "Inversion of Communications"). This way when the service needs external data it just checks out the local cache which makes the service more autonomous, robust and "deadlock" free.

Posted by Arnon Rotem-Gal-Oz at 07:25 AM  Permalink |

Udi Dahan commented (in his blog) on my last post.

Udi mostly agreed with what I said but commented on the SQL 2005 Service broker features I described: "You can add readers to empty queues faster, and lock all related messages that are read by one of the readers (so you won't have a situation where one reader reads the order and another reads the same order's order-line before the first even updated the order into the database)".

What Udi said to that was:

And here's the kicker. Modeling your messages in such a way is a rather poor design. Why on earth would you take an Aggregate Root like an Order, and split it up into multiple messages -- orderlines and the order itself separate?

It cracks me up time and time again. Some new fangled product bends over backwards trying to support some really hard feature, which is then touted as a key strength, which, in turn, makes more developers work that way. If you design your messages properly, you won't have any problem adding "readers" even without using Service Broker.

First, Udi is right in that the example I used was lame; I was merely trying to explain the feature by a simple example. Nevertheless, since service consumers are sometimes humans and not just other services, you might have a situation where this would occur; e.g., someone submits an order, then has a "duh" moment and adds another line (you can argue that it is better to repost the whole order in this case, but what if bandwidth is very low; e.g., GPRS). Okay, so this is an extreme example. Another (much more common) situation is what is known as a "Saga" -- a series of messages that goes back and forth between two (or more) services in a long running session. There is an advantage of using an infrastructure that gives you message correlation out of the box.

So yes, you need to try to tell a "complete story" for each message. You may still have situations where you need two or more related messages to paint a coherent and complete picture (just try not to make that the norm...)

Posted by Arnon Rotem-Gal-Oz at 11:25 AM  Permalink |

On a meeting I had with a few fellow architects a couple of days ago, (courtesy of Eliaz Tobias from Microsoft Israel), someone brought up an old (1995) thesis by Jim Gray called Queues Are Databases. In this paper, Jim argues that queue systems are just a private case of a database, so they might as well be implemented on top of a database.

In retrospect, this paper was probably one of the initiators to what we know today as "SQL Server 2005 Service Broker". The fact that Service Broker is built on a database gives it a few niceties which are harder to implement on other messaging platforms. For example, in Service Broker messages are delivered only once and in order. You can add readers to empty queues faster, and lock all related messages that are read by one of the readers (so you won't have a situation where one reader reads the order and another reads the same order's order-line before the first even updated the order into the database) etc.

One (minor) issue is that queues need a lot of insert/delete operations, where usually tables show fewer deletes and many updates.

Another issue is that databases have relatively heavy installation, while messaging middleware has a much lighter footprint.

The main and real problem is that Queues Are Databases only when you need reliable messages. Messaging middlewares support few other types of messages express or uncertified message, like multi-cast messages (using protocols like Pragmatic General Multi-cast (PGM)) and publish/subscribe semantics all of which are not very database-like. (Imagine you create an application that sends out stock tickers to hundreds on users on your LAN you don't want to do a transactional uni-cast to each and everyone of them, now do you?)

To sum up: Queues are not databases. They can be implemented on top of a database for scenarios where
transactional messages are important. I would still stick to non-databased queues for most scenarios.

By the way, as a side-effect of having Service Broker in the DB, you can now perform asynchronous invocations (have a reader stored proc listen on a queue) and other nifty tricks like a derived transactions (having one transaction trigger another transaction which is not in the scope of the first one -- i.e if the second fails it will not the fail the first one)

Posted by Arnon Rotem-Gal-Oz at 09:14 PM  Permalink |

I received a note from Pete who thought that sample/anecdote I presented in Part V last week suggested that I consider every non-technical reason to be irrational or at least irrelevant.

This was not my intention. There are plenty non-technical reasons that can be valid and relevant for a technical discussion (and the most obvious/common ones have to do with budget and time constraints). My point was that people often have interests that are not related to the problem, project, or company goals. As an Architect you need to be aware of that situation and learn to navigate these waters; e.g., the comment left by Wayne who suggested making people think the idea you have was actually their's. Note that this would help if the person is driven by his/her ego -- but will not work if the interest is self preservation (e.g., the person was the one who made the decision you now try to reverse), or if the person owes a favor to someone else, or the person you are trying to convince just dislikes you or your boss or has another hidden agenda.

Again, my point of the post was to raise the awareness of knowing who the stakeholders are, understand that they may rbe motivated and driven by interests which are not directly (and sometimes not even remotely) related to the problem.

Lastly, it is important to note that the situation is not that bleak (well, in most organization) and many decisions are made based on valid reasons. Politics is just one of the forces (a powerful one I admit) that shape decisions, but not the only one.

Posted by Arnon Rotem-Gal-Oz at 07:10 AM  Permalink |

Working on my SOA patterns book, I thought of this rule for contract versioning which my shameless ego wanted to dub "Arnon's Contract Versioning Principle." I was happy playing with this thought, until I realized that there isn't some profound new understanding here -- this is just an application of LSP for service contracts.

Liskov Substitution Principle (LSP), which I recently blogged about here as part of a series of blogs on Object-Oriented Principles, basically states that a subclass should be usable instead of it parent class. To put this in other words, you could say that a subclass should meet the expectations that users of the parent class have come to expect from the parent class's observable behavior.

So LSP applied to SOA would state that:

When changing the internal behavior of a service, you don't need to create a new version of the contract if for each operation defined in the contract the preconditions are the same or weaker and the postconditions (i.e. the outcome of the request) are the same or stronger or in other words the to retain the same contract version, the new version of the service should meet the expectations that consumers of the service have come to expect from the old version's observable behavior.

For example, let's say you have a customer service and the contract lets you get a customer's VIP status. If you changed the way the VIP status is calculated (e.g. in the old version the customer had to have $1 million in her account, but now she must have $10 million) there's no need to create a new contract version. However if you introduced a new level of VIP status (e.g. 1 Million = Gold, 10 Million = Platinum) you do need a new version for the contract.

Posted by Arnon Rotem-Gal-Oz at 02:40 PM  Permalink |

Martin Fowler writes about "Designe Inheritance". Designed Inheritance means that you (as a class developer) design upfront which parts of your class can be overridden and extended by subclass and which methods/structures cannot (are sealed for extension).

Martin says he favors open inheritance (i.e. not restricting overrides etc.). I think going for open inheritance is something you should do if you either know exactly who your users (developers that inherit your class) and you know that they are good enough, or you don't care who your users will be.

The problem is that someone who inherits your class can very easily commit Liskov Substitution Principle violations and cause problems with other parts of your application/framework/library that rely on the inherited class.

If you want to go with open inheritance and mitigate the LSP violation risk, I suggest sending the class a long with a suite of tests that verify the invariants on the classes interface.

There are, in fact, tools like RSPEC, JBehave, or nBehave which allow you to specify how a class should behave. These tools are based on a notion called BDD or Behavior Driven Design. BDD is wider in scope that what is needed here -- which is only making sure the post conditions, preconditions, and invariants are kept and not necessarily defining all the behavior of the class (which can also be beneficial ).

By the way, Dan North (who invented BDD) defined the difference between the xSpec and xBehave efforts as follows:

• xspec uses the vocabulary of "specification" where xBehave talks about "behaviours".
• xspec is exclusively looking at BDD-as-evolution-of-TDD, whereas xBehave is also about automating stories and scenarios.
• xspec extends the language to add DSL-type verification, so it is well-suited to dynamic languages (Ruby and Smalltalk are the current target platforms). xBehave uses Joe Walnes's constraints-based approach.

To sum up this post. The good thing about designed inheritance is that it saves class users the effort of learning all the details and risks involved in overriding the behavior of the class they are extending. If you opt for open inheritance, it is recommended to back that up with code (tests) that will help those inheriting the class from falling into traps and LSP violations that will result in odd bugs when they'll actually try to use their inherited class.

Posted by Arnon Rotem-Gal-Oz at 05:02 AM  Permalink |

This is my fifth post on the architect's soft skills. The previous post talked about how the architect should understand where the organization is going. This post talks about how you as an architect should understand how the organization is working so that you can make things happen.

Udi Dahan and I co-architected a system awhile ago. One of the key elements of that systems was a servicebus component which we wanted to base on a commercial messaging middleware. Although we both explained why choosing messaging was the best choice for the project very thoroughly to the project leader, another solution based on a proprietary (and fundamentally flawed) distributed objects middleware was constantly suggested and eventually made a constraint (it took four iterations (and a lot of rework later) to convince that a messaging middle-ware is the (much) better solution for that project). What happened here?

Decision making, especially technical decision making, seems like such a logical process. You just look at the alternatives, analyze the merits vs. the problem at hand, and may the best option win. This works out well if you are the king (or work alone which makes you the king by default) -- otherwise there are other people and they won't necessarily agree with you. One reason for that may be they really have another solid opinion, in which case you need negotiate with them , but that has to do with the leadership skill (which I talked about here) or communications skill (which I'll discuss in part VI). The other reason for people to disagree, which is the focus of this post, is that they may have other interests, which run much deeper than the positions the externalize (i.e. their disagreement with you).

Organizations (and the larger they are, the more complex they get) tend to get to decisions by employing a system of rules which encompasses a lot of these interests on top of the rational reasons to agree or disagree. In a sense understanding Organizational Politics is understanding this non-rational influence on the decision making processes. Acquiring the the skill of Organizational Politics means learning to navigate this restless sea.

To return to the anecdote above, it didn't take us too long to understand the real motivation there. It turns out both the project leader boss and a few others recommended buying that component which cost a small fortune, now that it was there (for another project) it had to justify itself by being used everywhere. In this particular case the only way we found to reverse the decision was to prove that it was flawed and to minimize its infiltration into the project (so it will be relatively easy to remove it later). in other cases there might be more cost effective ways to do achieve the desired result.

To be able to do that the first thing to do is understand where you are. This is one of the reasons the first step in the SPAMMED framework is to understand the stakeholders. If you manage to uncover the agendas and interests of the different stakeholders as well as the influence they may have on your project will at least help you pin-point your problems. The complicated part in knowing to navigate and influence the organization . you need interpersonal skills, networking capabilities, schmoozing, and you also need excellent communication skills (which is what I'll talk about in the next part).

The point I am trying to make here is that even though technical people tend to regard organizational politics as dirty you cannot disregard it. Organizational politics can have a severe influence on your project and actions. I didn't talk a lot about how to become more judicious political animal, I am probably not qualified enough to do that (you may want to check some of the resources below though)

More resources:

• David Ing mentions this in his "overly long guide to being a Software Architect"
• Ruth Malan and Dana Bredemeyer talked about it as well (see for example their paper on the architect's role or their competency card on organizational politics).
• David Dikel, David Kane and James Wilson cover some related organizational patterns in their "Software Architecture: Organizational Principles and Patterns"
• Mark Maier and Eberhardt Rechtin have a chapter on politics in their "Art of System Architecting, Second Edition"
• and probably a few others I don't know about.

Posted by Arnon Rotem-Gal-Oz at 03:00 PM  Permalink |

Doing some research for the SOA patterns book I working on, I've read on the Open SOA* web site about a "standard" for SOA they released called Service Data Objects

What are SDOs you ask? Here is what they have to say about it :

SDO is based on the concept of disconnected data graphs. A data graph is a collection of tree-structured or graph-structured data objects. Under the disconnected data graphs architecture, a client retrieves a data graph from a data source, mutates the data graph, and can then apply the data graph changes back to the data source. The task of connecting applications to data sources is performed by data mediator services. Client applications query a data mediator service and get a data graph in response. Client applications send an updated data graph to a data mediator service to have the updates applied to the original data source. This architecture allows applications to deal principally with data graphs and data objects.

SDO enables both a static (or strongly typed) programming model and a dynamic (or loosely typed) programming model. This enables a simple programming model without sacrificing the dynamic model needed by tools and frameworks.

SDO also provides a metadata API, which allows applications, tools, and frameworks to introspect the data model for a data graph. The SDO metadata API unifies data-source-specific metadata APIs to enable applications to handle data from heterogeneous data sources in a uniform way.

or in other words ADO.NET disconnected datasets reloaded.

The only question I have to them is "What where you thinking?" How does exposing internal data structure of a service helps promote loose coupling? How does binding to a data type help promote interoperability? How does defining small insignificant services (mediators) helps promote business alignments? How does this pertains to SOA?!?

* OSOA is an "informal alliance" of technology companies (IBM, Oracle, BEA, Sun and a few others) with an intention to define SOA concepts (to help them sell us more of their technologies, might I add. :) )

Posted by Arnon Rotem-Gal-Oz at 06:23 PM  Permalink |

Back in August, David Chappell posted his opinion on SOA and reuse (and comments on the response he received). David said that reusing services is next to impossible.

David Ing commented on that, saying that in order to do any reuse of services you should focus on data and on exposing it. Harry Pierson said that Object/Component reuse has been partially successful for non-business aspects (sting classes, UI widgets etc.) but when you introduce context (as in business context) reuse becomes more complicated. Harry commented on reuse again (after attending a workshop by Thomas Erl) that he doesn't really see how reuse is going to happen.

I agree with all of them. However, I do see some potential for reuse in SOA--not the kind of "write once, integrate everywhere" but rather in don't throw everything when you need to make changes to the business. This is something that is done even on the initial stages of SOA when, instead of writing everything from scratch, SOA developers use what I call "Legacy Bridge" and expose existing business application in their SOAs.

Also as David Ing said that since the data doesn't change as much as business rules and processes so as the service evolve you can reuse these parts of the service.

Another aspect of reuse can be in the "non-contextual" aspect; that is, reusing the software infrastructure you build for one service to build the other ones (i.e. the stuff that deals with security, auditing, monitoring etc.).

Nevertheless at the end of the day I agree with Udi Dahan who said "Bottom line, do SOA for the value, or don't do it at all."

Posted by Arnon Rotem-Gal-Oz at 07:10 AM  Permalink |