I’ll also be giving a presentation at YOW Nights on July 5th. Information here.

I’ve also decided to give a condensed version of my 3-day Enterprise Development with NServiceBus course while I’m there. This “NServiceBus Kickstart” event will be on Saturday July 9th and will give you everything you need to know to get started with NServiceBus.

Joining me in leading this event will be Simon Segal and Mark Harris – two of the earliest adopters of NServiceBus in the world. They’ve built a very impressive product with NServiceBus that has been in production with the Australian Federal Government for over 12 months now and will be sharing from their experiences.

Register here.

Domain Models & Composite Applications

Enjoy!

Missed and Pissed

A couple of weeks ago I received an email from a company in Austin Texas asking me if I was planning on providing any training there. They were a bit dismayed (to say the least) to learn that I had only recently given a public training course and that they’d missed it.

Last week I received a similar email from a company in Melbourne, with similar dismay to having missed the course there.

It turns out that in my efforts to keep the blog “clean” of this kind of marketing, I was actually doing a great disservice to my readers. So, first off, please accept my apologies if this has affected you. From now on I’ll be putting out posts about upcoming courses and conferences that I’ll be speaking at and I’d be happy to see you there.

Feedback about courses

Many people have been raving about my 5-day course. Here are what some of the attendees from Australia had to say:

Rhys Campbell: “Seriously though, the course was incredible, I think the overwhelming majority learnt more in those 5 days about designing large scale scalable enterprise architectures than they had over the 5 years of their career… well go on the course, its freaking awesome…”

Michael Nye: “Aside from having a sore brain, I now have an entirely new point of view for building systems. For those that are lucky enough to have the chance, I cannot recommend enough to try to get along to one of the courses. You will literally be blown away by it.”

For more opinions see: Paul Batum, Mark Harris, and Simon Segal who’s actually done the course 3 times!

Upcoming Course Locations

Next week! Hurry so that you don’t miss this one: Feb 15-19 London UK. Register here

April 12-16 Philadelpha USA (5 seats left) Register here

And for companies that are looking at sending many people, there is the option for on-site training as well.

I’ll put up a separate post with upcoming conferences soon.

Hope to see you at one of these events.

Good judgement comes from experience,

and experience comes from bad judgement – if you survive it.

[Source]

Done it again, the analysts have.

Dreamt up a (not) new acronym around SOA, they have.

Written up a useless 53 page report on it, they have.

The grizzled veterans over at the SOA yahoo group have already weighed in.

Back in the beginning of 2006 I called it out as a Common SOA Pitfall. Later on in mid 2007, InfoQ quoted me on this same theme for Astoria – now ADO.NET Data Services.

“Stopped they must be; on this all depends.”

Thank you.

In brief, you can’t provide business value if you can’t ship. Shipping software means more than having some features passing some automated tests, although most of the discussions I’ve been hearing in the Agile circles seems to say that that is enough. Are you really going to be putting credit card numbers into that system before you’ve done any security testing? I hope not. Same thing goes for usability, scalability, etc.

So do you really have to be able to release software every two weeks, or month?

Bottom line, understand the terms and conditions of every release, and plan accordingly – both in development effort as well as in testing scope and amount. Also, sponsor-driven constraints like trade-shows will affect what you need to test and when.

So, viewing testing outside the context of hands-on project management is ineffective.

Why do we have that independent QA department again?

At the age of 84, Saba Eli, father to two, grandfather of 4, great-grandfather of 4, passed away at 8:43 pm, Thursday April 26th, 2007.

I am sad.

I’ve defined a custom channel on Google AdSense for every category on the site (except “uncategorized”) so that advertisers can focus in on exactly the content they want. This is a step forward for directed advertising on blogs, but I don’t see many other site owners doing the drudge-work that I just went through. We really need some higher-level way of setting something like this up.

Anyway, this post is more for the advertisers than our regular readers, but I do hope that the products suggested in the ads you see will help you in some way.

I want to thank Clemens for helping me break out of my “I’m tired, I’ll just blog tomorrow” rut by tagging me.

So, here are 5 things you don’t know about me:

1. I was born in Israel, but grew up in Canada. After finishing high school I came back to Israel. This accounts for my native accent when speaking English and is often quite a surprise to people when I’m speaking at conferences, mostly in Europe. People in the states don’t give it much thought usually.

2. I’m a blue belt in Judo and have 3 city championships and 2 regional gold medals to my name. I never was really willing to commit to doing it seriously, since that required spending an entire summer at a training camp in Japan.

3. I’m a classically trained pianist going through the whole Conservatorium thing. Chopin is my favorite with Beethoven a close second.

4. I started programming at the age of 8 when my dad first brought home a computer from the university where he worked. I asked him if we could get any games for the computer and he answered that the only games that would get on the computer would be those that I wrote. After going to the library and taking out some books on GWBasic I was GOTO-ing with the best of them in no time. Looping and control flow came soon after but I bored with it quickly until I got to Pascal, my first programming love. I’ve never stopped enjoying the act of programming, even the debugging.

5. My path to speaking at conferences started during my military service. After attending numerous user group meetings and hearing various speakers talking about all sorts of technological topics, I said to myself, “I can do that, and I probably won’t be worse than him”. I approached the user group leader (Nimrod Luria) and asked him to give me a chance, which he did. My internal sense of perfection wouldn’t leave me alone until I had integrated blogs and books on public speaking and Presentation Zen into my routine. That, and lots of practice have helped me get to where I am today and keep improving. Actually, the one thing that came as a precursor to all this was the blogging which Roy unwittingly pushed me into. Without the blogging, I don’t think I ever would have gotten into the speaking.

So, those are my 5 things. And the tags go to Roy, Arnon, Harry, Natan, Johanna. You’re IT.

If there was one thing that I’d add to his solution is to use some kind of notification mechanism (publish) that would let all subscribers know that the data in the XML file had changed. This would be preferable to having each subscriber polling for changes. You could use Web Services to implement such a mechanism, but shucks, the WS-Eventing spec is only now getting nailed down and it might take some time for the implementations to get out, not to mention the kinks worked out of them. I’ll bet you could use some other, simple notification mechanism instead.

So, the question isn’t really XML vs. Web Services, but rather today’s stable, already in use techniques vs. tomorrow’s hyped up, not yet stable technologies. If you had to build a mission critical system, what would you bet your job on?

However, in cases where we are performing “highly asynchronous work”, like sending a request to another machine, where that request will be processed, and a result eventually sent back over the network, this kind of API could make it clear that we are NOT performing in-process multi-threading, and that the expectation of execution time should not hold.

And the code that enables this API (note: this is from memory):

public delegate void CompletionCallback(int errorCode);

public interface ICallbackRegistrar
{
event CompletionCallback Completed;
}

public class CallbackRegistrar : ICallbackRegistrar
{
private RegisterCallbackDelegate toCall;

public CallbackRegistrar(Delegate toCall)
{
this.toCall = toCall;
}

public event CompletionCallback Completed
{
add
{
this.toCall.DynamicInvoke(value);
}
remove { }
}
}

public ICompletionRegistrar SendMessageToServer(Message m)
{
// do work
return new CompletionRegistrar(
new delegate(CompletionCallback toCall)
{
this.messageIdToCallbackLookup[m.Id] = toCall;
}
);
}

public void HandleMessageReceivedFromServer(Message m)
{
if (m.CorrelationId != null)
{
CompletionCallback toCall;
this.messageIdToCallbackLookup.TryGetValue(m.CorrelationId, toCall);
if (toCall != null)
{
toCall(m.ErrorCode);
this.messageIdToCallbackLookup.Remove(m.CorrelationId);
}
}
}

Enjoy.

This does NOT mean that response times don’t matter. This is where SLAs come in. I can offer a service under various SLAs. If you’re willing to pay me $X per message, then I’ll be willing to offer you an SLA entailing the fact that your message will be processed and you will receive a result in under 2 seconds with 95% certainty. If you’re not willing to pay anything, then I may offer a default SLA with much lower levels of certainty. It’s all about the business demands and expected returns that influence these SLAs.

I’m not a historian so I don’t think I can comment about SOA’s newness. However, I do find that if we treat the autonomy tenet as one that includes the meaning that one service will not be “actively waiting” for a response from a different service, that is, that the initiating service can be handling other requests until a response comes back, then the design of the service will be quite different from many of the designs common today.

Why do I think that this meaning of autonomy is valuable? Because, if a number of services on which our initiating service depends are “experiencing technical difficulty”, their response times go through the roof, then the “active waiting” which entails holding resources open per request will bring about a self-inflicted denial of service. This would be the exact opposite of autonomy, in my opinion.

A service’s availability should not be affected by the services on which it depends.

This would directly affect the way a service handles state. In fact, it makes the message-processing workflow into explicit state that needs to be managed.

Therefore, by viewing state as one of the pillars of architecture, we can say that service orientation does impact our choice of architecture. Would I say that this is “special” about SOA? Well, yes, in so far as it separates SOA from other architectural approaches and the steps taken to get to them.

This month’s presentation, by our own Udi Dahan, will be about user interfaces, and the changes that have been occurring there, with the increased amounts of data that need to be handled, the problematic connectivity to data sources, as well as the ability to display events happening in real time. The specific focus will be on how to use multi-threading techniques to achieve higher quality user interfaces, as well as what kinds of problems arise, and how to solve them.

Udi Dahan is a Microsoft Israel recognized .Net development expert and head of .Net development at KorenTec. Udi leads the Israel Agile Practitioners Community and speaks regularly at user groups throughout the country on advanced .NET topics. His experience spans technologies related to Command & Control systems, Real Time applications, and high-availability Internet services using C#/.Net and MS SQL Server databases.

As always, we’ll have our special “Hatzilu” session at our meeting. So please come prepared to discuss your most frustrating problems (or at least some of them!) and to share some of your own techniques and solutions that you have found useful in your applications.

Please remember that it is important for me to know as accurately as possible how many people will be attending each meeting, so that I can arrange for the right amount of food and the proper setup of the chairs. Please confirm your attendance.

See you there !!

The March meeting of the Israel Visual Basic User Group
http://www.renaissance.co.il/ivbug:

March 2, 2005

Location:

Microsoft Israel

2 Hapnina St,
Ra’anana

(09) 7625-100

Floor 0 , Dekel Room

It is the new building across from Amdocs.

After the first traffic circle, there is an area for parking on the right.

17:30 – 18:00 Assembly
18:00 – 18:10 Introduction
18:10 – 19:30 “Multi-Threaded User Interfaces – Part 1″

Udi Dahan, KorenTec

19:30 – 19:45 Break
19:45 – 20:00 “Hatzilu !”
Open session, with questions and answers/ideas from everyone
20:00 – 21:00 “Multi-Threaded User Interfaces – Part 2″
Udi Dahan, KorenTec

=========================================
Object-Oriented Design
: (pages 15 and 16)

Actually, this is a trick question, because the right answer
is that both views are important: the algorithmic view highlights the
ordering of events, and the object-oriented view emphasizes the
agents that either cause action or are the subjects upon which these
operations act.` However, the fact remains that we cannot construct a
complex system in both ways simultaneously, for they are completely
orthogonal views. We must start decomposing a system either by
algorithms or by objects, and then use the resulting structure as the
framework for expressing the other perspective.

Our experience leads us to apply the object-oriented view first
because this approach is better at helping us organize the inherent
complexity of software systems, just as it helped us to describe the
organized complexity of complex systems
Object-oriented decomposition yields smaller systems through the
reuse of common mechanisms, thus providing an important economy of
expression. Object-oriented systems are also more resilient to change
and thus better able to evolve over time, because their design is
based upon stable intermediate forms. Indeed, object-oriented
decomposition greatly reduces the risk of building complex software
systems, because they are designed to evolve incrementally from
smaller systems in which we already have confidence. Furthermore,
object-oriented decomposition directly addresses the inherent
complexity of software by helping us make intelligent decisions
regarding the separation of concerns in a large state space.
=========================================

Now I’ve published many of my thoughts about OO before, but there is one thing that hasn’t got much attention, and that’s the OO analysis process when done with the client/domain expert. OOA is not a new thing and many developers do actually do it, however, for the most part, its an activity that is performed by the development team with little input from the client. XP avoids this by having a client on-site.

So, what’s the added value of having a client/domain expert when doing OOA?

The real deal is about getting to the “unwritten” requirements.

You see, when doing a task/process analysis you get to a comfortable 80% understanding pretty quickly. The problem is that you can’t really leverage that towards getting to the requirements that are locked up in the clients head. These are the things that the client doesn’t even pay attention to, but have become just a part of doing business.

When mapping out the objects in the system and discussing their relationships with the client, you begin to infer certain relationships as your understanding of the problem domain grows. As you infer, you ask questions to verify, which makes the client remember (all of a sudden) that in “special” cases there are orders whose order items need to be shipped to different addresses (for whatever reason). Only by doing OOA together, can you hope to get close to nailing down the last 20% of the system.

Please note that this discussion pertains to the analysis of the requirements of the system and not so much as to the design of how the system will be developed. When it comes time to develop, you really want to be as sure as possible that you understand the requirements of the system – especially those edge cases which end up making life so difficult late in the game.

So, while I don’t disagree with Grady Booch’s statements, I feel that the OO zealots out there may be too quickly dismissing other complementary approaches when it comes time to develop. Just because there’s value in OOA, does not mean to forsake process/task based analysis. Comparatively, OOP is a good tool, but not the only tool.

What I mean by “in practice” is that although most developers have separate “layers” for the Logic and the UI, there are so many cases that I run into where the logic is still coupled to the UI. The most obvious case is where an object in the logic layer has a reference to an object in the UI layer. I can’t stress this enough – make the logic independent of the UI! If you can’t compile your logic layer “project” without the UI project, that’s a sign that you’re in trouble.

Anyway, once you get past this point, that when things can get really interesting. I won’t expound on it here because Martin Fowler does such an awsome job on his site. “Organizing Presentation Logic” is a must read! You won’t ever look at your UI the same again.

After listing to the latest DotNetRocks show, one thing really struck a chord with me. I don’t remember who exactly it was that said it, Don Kiely I think, but the statement made was that there are those who are too busy actually working with the stuff, and doing the cutting-edge development with the current technology, to go speak about it, and that that’s a shame. (Well, he (or somebody else) said something somewhat like that, before I paraphrased it to death)

Now, not to sound like I’m tooting my own horn here, but this is exactly why I couldn’t make it to TechEd. I try to keep speaking now and then at the local .Net user groups, but nowadays, I barely have the time to read blogs! In fact, I entirely forgot about a user group meeting I wanted to go to today (.Net Software Architects), and by the time I got home from work, well, the meeting was already over.

Before you all start weeping at my sad story, I just want to say that I’m actually quite happy with what I’m doing – just that I wish that there were a few more hours left in the day after my job and my family.

Apparently my post on reporting – “Data, Report.” – Picard wasn’t the first to point out that using a separate reporting database was a good idea. It turns out that Martin Fowler posted on the exact same topic about a week earlier “Reporting Database”.

Although it kind of sucks not being first, I still think that coming in second to The Man is alright.

This just sort of popped up onto my radar after reading Roy’s post on creating group projects under a single solution. Roy states the advantages of this from a TDD perspective as follows: “For example, usually I’ll have a pair of projects for each Application tier, one for unit tests and another for the tier implementation (“Dal“,“Dal.Tests“). Using such a folder scheme as mentioned above I’d have a folder under my solution called “Dal” under which these two projects will reside.”

While I agree that the group project idea is great, the one thing that bothers me is the example. More specifically, the namespaces there. Anyone see it ? It’s right there, “Dal”, and “Dal.Tests”. No takers ?

The problem with this arrangement is that all classes in Dal.Tests will be a part of the namespace Dal as well. What this means is that any internal classes to Dal, which you obviously didn’t want anyone to know about outside the Dal project, are suddenly accessible in Dal.Tests !

Now, if you are the only developer working on both Dal and Dal.Tests, you’d probably remember not to make any use of InternalDalClass or any other internal classes. But, in many cases you’re not the only developer. And in almost all cases, you’re not going to be the only one maintaining the code over time. So, some other developer when writing a test class in Dal.Tests would see just another class he could use to test the functionality of Dal.

This is OK if you intend on doing white box testing. However, I think that it is generally agreed that black box testing be done outside the project (Dal) while white box testing be done within. ( If it’s not generally agreed, well, sorry, but I’ve seen it done a lot, and the logic behind it makes more sense than all the alternative approaches I’ve seen. )

So, for black box testing, instead of “Dal.Tests”, just call it “DalTests” and voila, a separate namespace where the internal classes of Dal are not accessible.

_______________________________________________

Update: The above is WRONG ! Well, except the part about white/black box testing. See the comments for the reasons why.