IF YOU BUILD IT

... Will they Come?

May 2007

Last month we saw Ajax making a move to the desktop with the aid of Adobe Apollo. Earlier this month I talked about it again when Sun announced JavaFX, and Microsoft officially announced Silverlight.

I guess it was inevitable that Google would also join the fun of blurring the lines between desktop applications and web applications. And indeed I just read that Google released a beta of Google Gears.

What does Google Gears do? Well, in essence it lets you develop occasionally disconnected web applications by providing an API to store application resources and data locally as well as Workerpools that let you run tasks in the background (sort of like a collection of processes that host javascripts and can communicate by messages).

What all these means is that it wouldn't be too long before the the architectural choice between web clients or desktop clients will not be that important it will be more about making a technology choice on the preferred development environment and tooling as well as designing robust occasionally disconnected applications regardless of that technology. Just look at the architectural guidance Google provides for utilizing Google gear. You'd see that the components that they identify are very similar to the high-level components you are likely to design with any occasionally disconnected desktop application....

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

Udi Dahan writes that ".NET/Java Interop is not a reason for SOA".

Udi says that companies that need to integrate two technologies turn to Web services and that:

The only problem is that in order for things to work right, they really must have a chatty interface, and flow transaction context between these “services”, and all the other things I describe as anti-patterns.

Udi is right in that if you don't rethink and remodel your systems, you will (probably) not have an SOA as you are likely to find your self implementing anti-patterns like those he mentions.

However, using Web services does not automatically mean that you are doing an SOA. If you don't think about moving to SOA, you can still opt to use Web services as a remoting or RPC technology to connect two systems. The advantage over the other proprietary products Udi mentions is that Web services are a standard technology. This will work well or fail if orthogonal to the technology choice. It depends on the architectures of the systems you integrate. If you need to flow transaction between the systems you'd also need that even if you cross-compile one of the applications in the other environment.

Another thing I don't agree with is the word must Udi uses. First, while it is likely that older systems have chatty interfaces, it is not mandatory. The designers of the legacy system may have thought about the consequences of distribution without regard to SOA. Also you can still wrap an existing system with a service contract (using Web services or any other technology) and not get to chatty interfaces, etc. However that means that the wrapper should have some substance or business logic inside it to mask the old system's behavior this is especially important if you are thinking about moving to SOA and you take into consideration that the business will not just halt and wait there until you are done. You have to think about interim solutions, such interim solutions can include wrapping a legacy system with an Edge Component and a SOA facade (a pattern I call "Legacy Bridge") while you move in the grader direction of a full-blown SOA.

Posted by Arnon Rotem-Gal-Oz at 04:42 AM  Permalink |

Back in November 2006, I talked about the Saga pattern which, if you recall, led Udi and I to argue on the use of queues and databases. Now, I've finally completed a draft of this pattern.

The Saga pattern deals with manging complex interactions between services without the use of atomic transactions, which as I've mentioned are not a good idea (see "Transactions Between Services? No, No, No!" and " Some More Thoughts on Cross-service Transactions").

You can download the draft for the Saga pattern here. I'll also add a link to it from the SOA Patterns book section (where you can also download the other pattern drafts I published).

By the way, I am not happy with the current sketch (the pattern illustration) in this pattern, so it will probably change in later drafts. I would be happy to hear any suggestions you have for improving it.

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

I just read Shy Cohen's (via Nick Malik) article in Microsoft's Architecture Journal entitled Ontology and Taxonomy of Services in a Service-Oriented Architecture.

Shy provides a list of what he calls "service types". He identifies two major types bus services and application. He then continues to sub-divide them, the bus services are divided into communication and utility services, and the application services are divided into entity, capability, activity, and process services.
I have to say it was quite alarming to see this coming from someone who had deep involvement in defining Windows Communication Foundation Indigo.

Where do I start?

Well, for one, the article completely fails to make the distinction between services as in "Service-Oriented Architecture" and services as in "capabilities or features an infrastructure provide". The "communication services" are for the most part capabilities that a service infrastructure (such as an ESB) provides. Not services you would define in an SOA initiative

And then there's the matter of service granularity and the difference between remote objects and SOA. For instance, the example Shy gives for a "method" (his word) on a customer service (entity service):

An example of a domain-specific operation is a customers service that exposes a method called FindCustomerByLocation that can locate a customer's ID given the customer's address.

Why would a service return a customer ID? This is the kind of call you would make on an object you hold a reference to not some remote "Something" that also want to authorize your call and may reside in a different company. This kind of thinking is what made remote objects fail. Gregor Hohpe explained that nicely in a paper called Developing software in a Service Oriented World:

The Transparency Illusion. Distributed components promised to hide remote communication from the developer by making the remoteness "transparent". While the basic syntactic interaction between remote components can be wrapped inside a proxy object, it turned out that dealing with partial failures, latency, and remote exceptions could not be hidden from the developer. It turned out that 90% transparency was actually worse than no transparency because it gave developers a false sense of comfort.

As an aside, Gregor recently gave a presentation that covers this paper at JavaZone which you can watch online at InfoQ .

Returning to Shy's article, let's take a look at another quote:

Capability Service may flow an atomic transaction in which it is included to the Entity Services that it uses. Capability Services are also used to implement a Reservation Pattern over Entity Services that do not support that pattern, and to a much lesser extent over other Capability Services that do not support that pattern.

I already explained why cross-service transactions and especially flowing transactions is not a good idea in SOA so I won't do it again here -- but you can read about it both here ("Transactions between Services? No, No, No!") and here ("Cross-Service Transactions").

Also I hope Shy didn't mean .NET data sets when he said "In some cases, typically for convenience reasons, Entity Service implementers choose to expose the underlying data as data sets rather than strongly-schematized XML data. Even though data sets are not entities in the strict sense, those services are still considered Entity Services for classification purposes."

In any event the whole decomposition of services into fine grained "capability", "activity", and "process" takes no account of the fact the SOA is a distributed architecture...maybe Microsoft is not affected by the Fallacies of Distributed Computing ?

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

In writing about "letting go of BDUF"(Big Design Up Front), Johanna Rothman says that you can't predict what the architecture needs to be. I don't with this, since many times you do know something about the project and you do have prior expereice that can give you enough confidence to lay some ground rules. I called this Just Enough Design Up Front (JEDUF).

Another statement Johanna made -- and which I wholeheartedly agree with -- is that you should let the architecture evolve. Evolving an architecture sounds very compelling, but it is not a simple feat. Architectural decisions tend to have system wide implications which means that changing one too late in the game you'd get a lot of rewrite and/or refactoring to do.

My strategy to solve that conflict is to:

• Set the first one or two iterations as architectural ones. Some of the work in these iterations is to spike technological and architectural risk. Nevertheless most of architectural iterations are still about delivering business value and user stories. The difference is that the prioritization of the requirements is also done based on technical risks and not just business ones. By the way, when you write quality attribute requirements as scenarios makes them usable as user stories helps customers understand their business value.
• Try to think about prior experience to produce the baseline architecture.
• One of the quality attributes that you should bring into the table is flexibility -- but be weary of putting too much effort into building this flexibility in.
• Don't try to implement architectural components thoroughly. It is enough to run a thin thread through them and expand then when the need arise. Sometimes it is even enough just to identify them as possible future extensions.
• Try to postpone architectural decisions to the last responsible moment. However, when that moment comes, make the decision. Try to validate the architectural decisions by spiking them out before you introduce them into the project

These steps don't promise that the initial architecture sticks, but in my experience it makes it possible to minimize the number of architectural decisions but still have a relatively solid foundation to base your project on.

Posted by Arnon Rotem-Gal-Oz at 05:42 PM  Permalink |

Last month I briefly mentioned Ajax moving to the desktop (with Adobe Apollo) and the whole Rich Internet Application (RIA) movement.

Now that Microsoft WPF/E Silverlight has been announced, we see that Sun is also jumping on the RIA bandwagon (or was that Reo Speedwagon :) ) by announcing JavaFX. JavaFX is a new Java scripting language which aims to take over JavaScript, Flex, Groovy and Silverlight by building on Java popularity. One thing that is going for it is that JavaFX is open source while Silverlight and Flex aren't (Thanks J E Fritz for pointing that Javascript has at least one opensource implementation (Mozilla) and reminding me that Groovy is also Open source).

Generally speaking, more options is a good thing, but as always it also comes with a price (see, for example what Otaku Cedric has to say about it).

Anyway, as I said in the previous post we are going around in circles and resolving problems we already solved with Rich Client. The good news is that at least the cycles are shorter and it seems we are getting decent development environments faster.

Also as it seems the boundaries between rich clients and web client are getting thinner we can hope that in a few years it will really be a non-issues. But then, we'll probably think of something new.

Posted by Arnon Rotem-Gal-Oz at 04:41 PM  Permalink |

Architects are like jugglers. No, that's not because we operate in a circus (although some projects seem to be marginal in that sense). Architect's are like jugglers because in the same way jugglers try to keep several balls up in the air at once, we have to keep all those quality attributes -- performance, security, flexibility, etc.-- without letting any of them fall.

If you are a good architect, you might be able to keep five balls up in the air in the same time and maybe throw in a couple of Torches for good measure. If you are a great architect, maybe you can handle 10 or 15. In any event, there's a limit to the number of quality attributes you can balance in the same time and that's were we should really shine -- in the tradeoffs.

What I am going to do over the next few posts is to take a look at quality attributes (and their sub-categories) as well as look at some of the forces and common trade-offs.

I am currently planning on having posts on:

• Performance
• Security
• Availability
• Scalability
• Manageability
• Testability
• Flexibility
• Reliability
• and maybe a few more

Let me know if there are any quality attributes you want me to address which aren't on this list.

Posted by Arnon Rotem-Gal-Oz at 12:49 PM  Permalink |

Back in December/January, I wrote a few posts on Business Intelligence and Service-Oriented Architectures and how you can make them work together (for example, see this one).

Recently I took these thoughts, polished them a bit, and turned them into an article. You can read this article on line in the MSDN architecture section.

I think it provides a good reading even if you read my original posts since the article is a little more organized and adds some new information that wasn't in the posts (like a sample CEP query, illustrations etc.)

Posted by Arnon Rotem-Gal-Oz at 04:31 AM  Permalink |