Book Review - SOA Patterns (First 5 Chapters)
I'll cut straight to the chase, I definitely recommend SOA Patterns to anyone interested in SOA.
Even though its currently only available in MEAP, and is a bit rough and ready, and isn't complete, it's still great stuff and well worth your time.
Now I've said that I'll give a quick run through. Essentially the author, Arnon Rotem-Gal-Oz, has decided to focus on the practical aspects of SOA and in particular with a focus on the software architecture aspects of SOA. It thus doesn't cover the business aspects of SOA, which is fine with me as those topics are covered elsewhere.
With that tight focus in mind Arnon has already managed to pack in a range of very interesting and valuable patterns. Each pattern includes the problem, solution, technology mapping and quality attributes. There is already the feeling of a pattern language about it which I think will evolve as later chapters are added, this should allow you to describe a complex system with just a few high level patterns or to dig into more detail by discussing the lower level patterns they compose.
You can actually read a few of the patterns online, see the linked PDFs and also the Blogjecting Watchdog pattern, and the anti-pattern called The Knot is also worth a read.
In addition Jan has posted a review of the book.
My reaction to patterns like "Blogjecting Watchdog" is sort of "URRRRRRRRRRRRRRGH".
ReplyDeleteI've never heard of the term Blogject before. I guess that makes me a spooky oldtimer, since this meme was coined in 2006. Either way, "blogject" just makes me angry.
Some of these portmanteaus are out-of-control.
Bottom line: there is a lot of needless terminology here, and it basically demands that programmer's learn this vocabulary to communicate.
Why do I have to "report to edges". What happened to the layman phrase "status"? Also, why on earth would a "watchdog" be self-healing? "Watchdog" is just a NIH way to say "Observer". Here is a note to the author: Watchdogs Bark, They Aren't The Police.
The moment a Watchdog does more than bark, you introduce all kinds of design problems. What happens when there are circumstances where you want to respond differently to the same bark? You're best off barking at a management system that knows how to handle the bark. Maybe the watchdog is barking because a mission-critical system just went down and automatic action (like restart) is potentially the worst thing to do. You really, really want human intervention.
Also, I feel the author thinks self-healing somehow implies no separation of concerns, whatsoever.
All-in-all, these patterns strike me as solutions derived by a "software architect" instead of a "network architect". While I don't mean to create such perverted stereotypes, it is a useful psychological profile.
"The moment a Watchdog does more than bark, you introduce all kinds of design problems. What happens when there are circumstances where you want to respond differently to the same bark? You're best off barking at a management system that knows how to handle the bark. Maybe the watchdog is barking because a mission-critical system just went down and automatic action (like restart) is potentially the worst thing to do. You really, really want human intervention."
ReplyDeleteThere is actually a seperate service monitor pattern that you'd want to read for this, like I say the best bit about the book is its beginning to form a little pattern language where one pattern builds on another.
From the sample material, it looks like the author prefers namedropping technologies instead of guiding the reader to bottom-up results-oriented implementation.
ReplyDeleteIn Blogjecting Watchdog, the author seriously advocates SNMP traps. If that isn't a red alert that the author doesn't have a network administrator's mentality, I don't know what is. In case you are unfamiliar, this is what an SNMP trap looks like: http://www.adventnet.com/products/mysql_agent/images/hp-openview-trap.jpg
Bottom line: books are not supposed to impress me with how many technologies the author knows, which is what those blogs and whitepapers seem to be attempting. All I care about is a convenient book that distills what I already know, so I can recommend it to a junior programmer.
Moreover, the lack of caution in using SNMP Traps is questionable. The author doesn't seem interested in pointing out to the reader that SNMP traps are as useful as system log messages, but several orders of magnitude more expensive to implement. I guess if you work for a company with "Fortune 100" style controls, you can impress people, but if you ask a general system administrator off the street, they will not be impressed by this decision.
Overall, it's not just the writing style that fails to get the job done.
@zman - few comments, if I may
ReplyDelete"Watchdog bark" - the term watchdog I am using comes from embedded systems where watchdogs (usually implemented in hardware) reset the system if the dog isn't "kicked". basically a counter counts to zero and live system should reset it before it does. So watchdogs act and don't report - which is why I added the "blogjecting" part to also report.
You're assuming that an external management system will know better about a service than a component which is part of the service - I beg to differ. For instance in my current system when there's a problem servicing a mobile video call we use an applicative call recovery component to try to route the calls to other available services
re "Name dropping technologies" - The point of the patterns in the book is that they are architectural ones and not design ones. This means that they are in a higher level of abstractions and there are many possible solutions. Some map to existing tools, components, libraries and some can be custom development. The technology mapping section points out to few possible leads.
an SMTP alert is an option it is not the only solution (see previous point). It can be useful if that's what's supported by your management system
re naming - I've read a lot of pattern books (Enterprise integration pattern, design patterns, patterns of software architecture, anti-patterns etc. - they all formalize solutions to problems and name the solution. How would you do that differently ?
Lastly, the patterns I present are based on actual solutions I used repeatedly in actual projects. I found that these ideas served me well. your millage may differ.
if you want something that distills your knowledge then by all means go a head and write your own book. In any event I don't try to trick anyone to buy my book. There are several patterns (and more will be published) which are available for free on the internet so you can form your opinion (good or bad) without investing the 30$ or so a book costs which I think is fair enough
Arnon
Higher levels of abstraction are supposed to simplify things, not make them seem more complicated.
ReplyDeleteI am highlighting some pretty hard hitting issues with your current patterns. Yes, you provide this for free, which is fair. Yet, you seem to be defensive rather than looking at this as an opportunity to restructure your explanations.
Also, higher level or not, it is pragmatic and justified to say something like, "Setting up SNMP traps is a lot of work just to effectively add a status code to a syslog message, and, guess what, you don't even know where that status code will be (just look at the RFC)!" Just because SNMP traps are structured doesn't mean they're standardized, and so structured only does a fraction of the work required to implement this stuff. On top of that, there are lots of log analysis tools available at the fraction of the cost of mainstream SNMP products, and the log correlation provided is as good as the structure provided with SNMP. You know, Martin Fowler discusses things at a high level, but he's good at sticking in pragmatic stuff like that into his prose (IMHO).
Its immensely valuable. For one, it gives the reader the sense that the author has "Been there, thought about it, done it, evaluated the results". I want to get the sense from reading something that the author has given some care and consideration to things. Otherwise, it just feels like commandments from up high that the simpletons are expected to "get done, yesterday".
The phrase "watchdog" from embedded systems also really doesn't need to be brought over to the SOA community, and I'm not sure why you want to cross-pollinate a poorly chosen word.
It's hard for any writer to look at his/her article and think of ways to better structure it, but my feedback might just be a useful kick into reconsidering what to say and emphasize.
P.S., there is a reason why I am posting anonymously. I've learned over the years that people dislike heavy criticism from people they don't know, so putting my name on it is pointless.
zman, I am open to hearing constructive criticism but that doesn't mean I have to agree with every criticism nor do I feel your criticism is expressed in a constructive way (not saying you didn't mean it as such - just that I don't read it as such)
ReplyDeleteOn the subject of naming - I currently feel pretty good about it. Nevertheless the book is still a work in progress and it will be reviewed and edited before it would be finalized so it may still change.
On the matter of technical detail. I think that patterns I describe provide structured ideas to solve problem I encountered while implementing SOAs. I made a conscious choice not to provide detailed implementation for each pattern as it will make the book overly long and , I think, will make it hard to readers to see the forest for the trees. Also many times a better solution is to use something which already exists rather than go and roll an implementaion .
As for Martin Fowler - I never claimed to be as good. I do hope that I what I write is good enough , at least there is something to aspire to :)
As for you staying anonymous - that's your choice. I didn't say or hint anything about it
Arnon
I always feel there is a right mixture of high-level and low-level "you better get this part right" details for any pattern to be implemented properly.
ReplyDeleteFor instance, Template Method is often an abused GoF design pattern.
As for your naming of things, don't feel too much pressure to change. These are your ideas and you can call them whatever you like. However, a couple of concerns:
In blogjecting watchdog, you associate the watchdog with the timer itself - you don't kick the dog! (That would be animal abuse.) This is questionable if not incorrect design (or hazy explanation). Again, the watchdog simply barks. You might physically couple barking and handcuffing actions together, for performance reasons, but in an OO embedded systems sense they are separate responsibilities.
To revise what I said above, I don't mind reusing phrases from embedded systems, but you are using them and changing their meaning slightly (and significantly). Technically, you seem to be discussing a "Blogjecting Watchdog Timer". (And yes, I am in disbelief I just casually used the phrase blogjecting. ;-))
Maybe you are right and the technology doesn't matter whatsoever. But a quick look at the fact there is a mailing list *dedicated* to log analysis (the "loganalysis" mailing list) shows people take this seriously and don't feel it is a trivial subject, implementation-wise.
In particular, open source monitoring software has come a long way in recent years. Everyone I know raves about Nagios 3.0. You could say that is transient, but what is *it* that makes system administrators like it so much? It's probably not a random chance.
On that matter, Redhat's system administrator tools people are the best team in the industry, as far as I'm concerned, in establishing best practices in all forms of software and hardware management.
Maybe you don't find that kind of question interesting (at least in this context), and maybe your readers won't either (at least in this context). *shrugs*
Hi zman
ReplyDeleteI don't think that technology doesn't matter - it matters a lot since if you mismatch a technology to an architectural choice you'd constantly pay with hard work and quirky bugs.
I think your point about log analysis and Nagios are good addition to another pattern - monitoring.
The point of the blogjecting watchdog is to go beyond just listening and reporting (which is what monitoring agents do) with the idea that business services can be more autonomous and fix themselves (to an extent). You still need a monitoring system to complement that. Also it isn't always the appropriate approach. I can tell you, however, that I've implemented this in several systems and got a lot of benefit
Arnon
Your purpose for blogjecting watchdog doesn't change the fact you are cross-pollinating vocabulary from embedded systems and co-opting it.
ReplyDeleteAs nerds, we have a hard enough time talking to each other without slaying the meaning of our own technical jargon.
Bottom line: Watchdogs do not fix problems, they report them! This is true even in embedded systems. In the embedded world, watchdogs watch the "watchdog timer" (or something similar) and then delegate to a Fault Handler pattern (typically). The Fault Handler pattern in turn understands concepts such as "re-booting the system into a Fail-Safe State."
I think the _real_ implementation things that can be mostly ignored is stuff like physically coupling the watchdog and fault handler together, for performance reasons. In fact, if you are writing a model-driven compiler to compose SELF-* systems, then you can trivially physically couple these two together, because it is a linker/loader issue, not a model issue. The models should still be logically separate but cohesive.
Also, as a "computer scientist observation", I think the connection between embedded systems (using OOA and MDA) and SOA makes sense -- if you don't co-opt meanings.
ReplyDeleteThere is a good reason why!
It is because you can describe much of both using Finite State Automata. The real challenge then becomes getting FSAs to play together; this is a "click-in modularity" challenge.
さあ、今夏も新たな出会いを経験してみませんか？当サイトは円助交際の逆、つまり女性が男性を円助する『逆円助交際』を提供します。逆円交際を未経験の方でも気軽に遊べる大人のマッチングシステムです。年齢上限・容姿・経験一切問いません。男性の方は無料で登録して頂けます。貴方も新たな出会いを経験してみませんか
ReplyDeleteみんなの精神年齢を測定できる、メンタル年齢チェッカーで秘められた年齢がズバリわかっちゃう！かわいいあの子も実は精神年齢オバサンということも…合コンや話のネタに一度チャレンジしてみよう
ReplyDelete最近仕事ばかりで毎日退屈してます。そろそろ恋人欲しいです☆もう夏だし海とか行きたいな♪ k.c.0720@docomo.ne.jp 連絡待ってるよ☆
ReplyDelete最近TVや雑誌で紹介されている家出掲示板では、全国各地のネットカフェ等を泊り歩いている家出娘のメッセージが多数書き込みされています。彼女たちはお金がないので掲示板で知り合った男性の家にでもすぐに泊まりに行くようです。あなたも書き込みに返事を返してみませんか
ReplyDeleteあなたの性格を、動物に例えて占っちゃいます。もしかしたらこんな動物かも！？動物占いをうまく使って、楽しい人間関係を築いてください
ReplyDelete家出中の女性や泊まる所が無い女性達がネットカフェなどで、飲み放題のドリンクで空腹を満たす生活を送っています。当サイトはそんな女性達をサポートしたいという人たちと困っている女性たちの為のサイトです
ReplyDeleteセレブ女性との割り切りお付き合いで大金を稼いでみませんか？女性に癒しと快楽、男性に謝礼とお互い満たしあえる当サイト、セレブラブはあなたの登録をお待ちしております。
ReplyDelete夏フェス一緒に行ってくれる人募集！！夏の思い出一緒につくろぉ☆ megumi-0830@docomo.ne.jp 連絡してね♪
ReplyDeleteあなたのゲーマー度を無料ゲーム感覚で測定します。１５個の質問に答えるだけの簡単測定で一度遊んでみませんか？ゲームが得意な人もそうでない人もぜひどうぞ。
ReplyDeleteHな女性たちは素人ホストを自宅やホテルに呼び、ひとときの癒しを求めていらっしゃいます。当サイトでは男性ホスト様の人員が不足しており、一日3～4人の女性の相手をするホストもおられます。興味を持たれた方は当サイトにぜひお越しください
ReplyDelete実は出会い系には…関係者用入り口があるのを知っていますか？広告主やスポンサー用に用意されたIDではサクラや業者が立ち入ることが出来ないようになっているのです。当サイトでは極秘に入手した関係者用URLが公開されています
ReplyDeleteホムペ完成記念！私の事みんなに知ってもらいたくて頑張りましたぁ。色々とご感想をお待ちしているので思った事を意見してください。メアドはほむぺにのせてありますぅ！★ fan.jna@docomo.ne.jp
ReplyDelete夏休みで気軽に家出する女子○生が急増しています。しかし家出したはいいものの泊る所やお金が無い彼女たちは、掲示板などで泊めてくれる男性を探す子も多いようです。当掲示板にも夏休みに入ってから通常の3倍以上のメッセージが寄せられています
ReplyDelete今最もアツイバイトは人妻とのセフレ契約です。当サイトではお金を払ってでもセフレがほしい人妻が集まり、男性会員様との逆援生活を待っています。当サイトで欲求不満の女性との出会いをしてみませんか
ReplyDelete素人ホストでは、男性のテクニック次第で女性会員様から高額な謝礼がもらえます。欲求不満な人妻や、男性と出会いが無い女性達が当サイトで男性を求めていらっしゃいます。興味のある方はTOPページからどうぞ
ReplyDelete少し魅惑な自分をネットだから公開してみました。普段言えない事など、思い切って告白しているプロフなので興味ある方はぜひ除いてみてください連絡待ってまぁす。 hinyaaaaa@docomo.ne.jp
ReplyDelete