DZone recently published an interview with me on my  SOA Pattterns book. Along with the interview you can also download chapter 2 of the book (I think you need to be a DZone member to actually download it).

Chapter 2 includes  the Edge Component , Service Host , Active Service , Transactional Service and the Workflodize patterns. Additional downloads related to the book include

• Chapter 1 which you can downlaod directly from Manning
• The Service Firewall Pattern which I published on InfoQ
• The Saga Pattern
• The Gridable Service Pattern

Lastly, you can ownload the first version of chapter 1, which I mention in the interview and the slides of a presentation on few of the patterns from Dr. Dobb's Architecture and Design World last year

 

CrossTalk, the journal of defense software just published its Aug. 2008 issue. Which, incidentally is its 20th anniversary issue.
This issue includes a couple of very interesting articles one is called "Good Old Advice" by Alistair Cockburn and the other is called "What Have 20 Years Accomplished and What Is Left to Accomplish in the Next 20 Years?" by Gerry Weinberg.
Cockburn explains very eloquently something I also wrote about a year ago that the ideas and lessons expressed in literature of yore are not just valid today but they drive home the points of the "coolest" ideas we have today. Alistair does that by demonstrating how the principles behind the agile manifesto builds on the works of Fred Brooks, Barry Boehm, TomDemarko, Gerry Weinberg and many others.
We have known for decades that is is all about people , users, communications between them. Alistair summarize his article as follows (emphasis mine):

"

I derived the four values of the Agile Manifesto from much older, recognized, and highly reliable articles. The point I wish to make is that the authors of the Agile Manifesto did not throw out all previous experience as they wrote it. On the contrary, what they did was cherry-pick four of the most important issues from among hundreds. The appropriateness of their selection is seconded by decades of prior experience and data, as evidenced by the numerous articles referenced in this article.

For decades, we have learned, documented – and ignored – the same lessons:

• Attend to the individuals and their interactions.
• Put the mercilessness of running software to good use – write, and learn from the writing.
• Get inside the heads of your users and customers, and get them on your side.
• Plan coarse-grained long term and fine-grained short term, and find a way to replan quickly – because you’ll have to.

And, finally:

• Do not believe in any single process or methodology because each works only in a particular and limited context.

Those who do not learn from history are doomed to repeat it. Let’s stop pretending we don’t know everything and let’s stop repeating painful history by following this good, old advice."

Weinberg writes a short retrospective of the last 20 years. Here are some interesting quotes (again emphasis mine):

Individual managers, however, have certainly improved. The good news is that we now have many more excellent managers who can mentor new managers. The bad news is that because the field has grown so much, there simply are not enough experienced managers to go around. We still see people abused or poorly used by their managers. All of this in spite of the fact that we have much more information about how to work with people in software development – information that, sadly, is frequently ignored. Too many managers have failed to learn that the world will not end due to a late delivery or a defect in production. Nor have they learned to relax, breathe, learn from their mistakes, and try again.

and

The idea of certification is only one of the management myths that has not changed in a generation. We still have an excess of heroic environments, often leading to death march projects. Many managers still maintain the fallacious perception that quality can be tested into slapdash software. Some still try to develop software without being bothered by potential users of that software. And some still believe that process models are the answer to all of our problems.

These are the things I notice on my pessimistic days. On my optimistic days, I notice more managers realizing that it is the people who make a difference, that they can hire talent, but then must also build the relationships to build a team. Quite a few organizations are now using process models successfully, but as only one of the tools providing information for informed cultural changes to their software community.

Though looking from different angles, both articles somehow hash the same ideas like 'work iteratively", "b e wary of magic or single processes" etc. I do believe that what underlines both these articles and, indeed, software development itself is that at the end of the day software is developed by the people and for the people and we should not allow ourselves to forget it.

---

*with pardon to Abe for the misqoute
 

Every Thursday we have this "happy hour", you know beers, snack etc. Every other week or so we also try to make it educational and after socializing for a while hear a presentation  or a webcast.

I used this week's slot to present the REST architectue style. I think the presentation turned out pretty well so I thought I'd share it online (note it is a 6M ppt)

 

My friend Gunnar Peterson asked about my opinion on SOA and security concerns. Here's what I wrote him:

In a paper I wrote a couple of years ago I examined the relevancy of the “fallacies of distributed computing” defined by Peter Deutsch almost 20 years ago. Writing about the “Network is Secure” fallacy I wrote that after all these years you would think that the fact you cannot assume the network is secure would be a no-brainer. Alas it still it happens all the time - and that's for "regular" distributed systems.

 In my opinion, assuming the network is secure for an SOA is not only naïve but negligence pure and simple. The whole premise of moving an organization to SOA is connectedness and integration. So, unless your SOA will fail it will be connected to other systems. Whether you  are building RESTful systems, WS-* SOAs, EDAs or any combination of these architectural styles, If you won’t treat the services boundary as a border and secure it – you will be sorry…

Security in SOA should be considered at the "grand-scheme" level with issues like authertication, authorization but also at the single service level, looking at issues like DDOS, SQL injection, elevation of privilige and what not. A trivial thing like exposing a transaction beyond service boundaries can translate to an attacker denying services in your system simply by locking out your database. Again, this is just a simple example.

The other thing about Security is that you have to consider it early. patching security "later on" can have devestating effects on a system's capabilites esp. in areas related to performance. I have seen even military systems that had to go through serious rework, just  because Security was added as an afterthought instead of handled early on

 

The .NET community is generally criticized (and rightfully in many cases) that it lacks innovation, with a lot of developers relying either on Microsoft or porting Java stuff* (Junit - > Nunit, log4j -> log4net, Hibernate -> NHibernate, Spring -> Spring.net and the list goes on).
Amidst all this, it is nice to see, that a lot of .NET original ideas are generated here in Israel**.

Few examples that come to mind are

• Rhino Mocks by Ayende Rahien (a.k.a. Oren)
• nServiceBus by Udi Dahan
• Regulator by Roy Osherove

The reason for this post is a new open source project coming from here. This one is from Sasha Goldshtein and Alon Fliess and it is a Non Paged CLR host which offers

"This custom CLR host ensures that all memory given out to the CLR is locked into physical memory if possible, thus eliminating paging completely."

Which can be very useful in performance intensive applications. Cool :)

---

* This is not to say that sometimes, the port is better than the original (NUnit 2.0 is a prime example for that in my opinion)
**Naturally there's also original stuff happening outside of israel :) e.g. Ninject by Nate Kohari or StoryTeller by Jeremy D. Miller
 

As I was going through my RSS list (which I publish as a linkblog) I noticed Reginald Braithwaite's post on the metaobject protocol. Reginald says

The bottom line: Languages like Java give you an object protocol: There is one way to do things with objects and classes and interfaces, period. Anything else, like adding generics or annotations, must be done outside of the language, it must be done by the creators of the language.

Languages like Common Lisp and Smalltalk give you a meta object protocol: You can decide for yourself how to do things with objects, classes, interfaces, generic functions, whatever you want. You don’t need to wait for a committee to try something different.

What's nice is that a couple of posts later I noticed a link by Harry Pierson to an attempt by Jeff Moser to port OMeta to the .NET world and to enable the very "meta object protocol" Reginald mentios. Here are the opening bits from Jeff's post (go read the rest):

What if programming language implementations were object-oriented? What if you wanted to change one itty-bitty part of your favorite language? Say you wanted to add an exponentiation operator (^^). How hard would it be?

Wouldn't it be nice if you could "subclass" a language like C# and then add 5 lines of code to make it work and then use it? What if you could add Ruby-like method_missing support in 20 lines?

What if you could conceive of a new language and start experimenting with it in production code in an hour? What if it leveraged your knowledge of existing frameworks like .NET?

Also check out the code Jeff posted so far (on CodePlex)