If you’ve read my recent post on the threading issues I’ve been dealing with in Smart Client Applications, then you’re probably beginning to get the picture that its fairly complex. To tell you the truth, it is. And up until this point I haven’t been able to find anything that’ll help – and that includes the CAB/SCSF. But yesterday I had my epiphany. The answer was in AOP.

You see, the main problem that I hadn’t been able to solve was that in order for the code to be thread-safe, you had to make sure that no code in the views would/could change entity data. One solution is not to use data-binding, which sucks, but isn’t enough to be sure. Another solution is to have all supervising-controllers clone an entity before they give it to a view. Even if you could possibly code review every line of those classes, the new guy (or old guy who forgot) will, by accident, write one new line of code that could pass an entity to a view without cloning it first. That’s not a very sustainable solution.

This thing has been bothering me for a couple of months now and I hadn’t found a way around it. Until yesterday, like I said. I was talking to somebody about threading stuff, and somehow my unconscience lobbed me this thought about AOP. Now I’m not the sharpest pencil in the pack, but I know to listen when my unconscience “speaks”.

So I set about going over what I knew about AOP – interceptors, advisors, advice, introductions, etc, etc. And then it dawned on me. I could intercept all calls to any object that implemented IView, check the parameters of those calls, and if they implemented IEntity, to clone them before passing them through.

<Homer-style WOOHOO />

The great thing is that developers don’t need to remember to clone entities – it happens automatically. The even greater thing is that this will lead developers to writing the correct kind of interaction between their views and supervising controllers.

Together with nServiceBus, this is going to make the extremely difficult problem of writing thread-safe smart clients possible.

I’ve never made use of AOP in a framework before so I’d like to get the broader community’s feedback on this before incorporating this in production. I’ve spoken with some serious AOP folks who have allayed most of my uncertainties, but I’d like to hear more. Anyway, here’s the proof of concept (that makes use of Spring).

If this turns out to be a viable solution, I think we’ll have a solid environment for building a software factory on top of. That is something that I’m really excited about. In this multi-core future (present) that is upon us, multi-threading on the client is pretty much a necessity. We need a way to get things safe and stable by default without requiring a member of the CLR team to hold our hand.

Anybody who’s interested in helping, drop a comment below.

I’ve been getting more and more requests for tutorials and “getting started” stuff for nServiceBus so the first one is now up on the Sourceforge site.

The sample can be found under /test/RequestResponse and demonstrates the following flow:

Client subscribes to CustomerUpdatedMessage.
Client sends the Server an UpdateCustomerMessage, and passes a CompletionCallback with it.
On the Server side, the UpdateCustomerMessageHandler is activated and passed the message.
On the Server side, the above handler randomly decides upon success or failure of the action:
    Success: Bus.Return((int)ErrorCode.None); // return success code
    Success: Bus.Publish(new CustomerUpdatedMessage());
    —
    Fail: Bus.Return((int)ErrorCode.Fail); // return fail code
On the client side, when the error message containing the error code arrives, the bus dispatches the error code to the CompletionCallback passed originally by the client
On the client side, when (if) the CustomerUpdatedMessage arrives, the bus dispatches it to the CustomerUpdatedMessageHandler.

Some things to note – this is a simplified form of request/response. What we’re doing here is Command/ErrorCode.

The next sample that will be coming up is a full request/response implementation. Let me know if you have any things that you’d specifically like to see done using nServiceBus.

Last week I was at a client in their test lab and saw a strange bit of behavior. The system could be described as something like an air traffic control system, showing things moving around on a map. For just a second, a fraction of a second, one of the “planes” disappeared from the map and then reappeared again.

When I asked if anybody else saw it, one of the developers said, “Yeah, that happens sometimes – but it fixes itself right after that.”

“What if the user sends a command to the server making use of that location?”, the PM asked. “Could that cause them to collide?”

You could hear a pin drop.

After everyone got passed the preliminary shock, we got down to work. I asked if I could look at the logs, but after more than an hour, I found nothing. No reason to explain the strange behavior. I suggested doing some more instrumentation so that whenever a location changed on the client-side entities, we’d write that to the log.

After that, we ran the system again in the lab under the expected load (several hundred things moving every second, and the user doing the expected activity) and didn’t notice anything. An intern “volunteered” to keep working the system while the rest of us went to lunch. When we came back, he told us that everything seemed to be working OK.

These Heisenbugs are the things that keep me up at night.

“Watching the system changes its behavior”, one of the older devs nodded his head sagely.

Just as we were about to leave the lab another one of the developers gave a shout, “It did it again!”. We quickly stopped the system. Opened the (rather huge) log files and looked for the latest entries.

There it was.

A context switch between setting the latitude and longitude of an entity.

That should not have happened. Not that context switches don’t happen, but rather that it should have been impossible by design. We had made use of synchronization domains and the appropriate patterns so that two threads could never concurrently be working on the same instance of an entity. The synchronization features baked in to nServiceBus had taken care of everything up to that point.

Before getting into the threading solution, I want to address a specific alternate patch that was deployed in the meantime:

The solution for the long/lat problem was simple – just make Location a value object and use a single setter for it rather than one for Latitide and another for Longitude. We were still worried about other bits of data that were correllated in the domain – things that couldn’t be solved the same way.

After getting 3 grizzled C++ veterans in the room, we did a code walkthrough of the threading model of nServiceBus. We went through the nitty gritty details of synchronization domains, how the Bus object was outside of the domain, why that was important for user experience, how the message handlers couldn’t be ContextBoundObjects because of the performance impact of creating and destroying them at a high rate, why they couldn’t just be singletons, why they still had to run in the synchronization domain, so that the UI thread couldn’t work on the same (or related) objects at the same time, etc, etc.

And then it hit me.

The bus was communicated directly with the message handlers.

After the Object Builder created the message handler, the bus dispatched the message to the handler directly. And since the bus was outside the synchronization domain, then the thread calling into the handler wouldn’t have locked the domain, leaving the UI thread open to go in and touch those very same objects.

They say that really understanding the problem is 90% of the solution. I’m hoping to meet them some day, because they’re really smart.

All that we needed to do was have the Object Builder dispatch the message to the handler instead of the bus – since the builder was configured to be in the synchronization domain (on the client side). Something as simple as just adding the method:

So, instead of the bus using this code:

It would do:

[Just FYI, this is now up on the sourceforge site]

We redeployed the system to the lab, ran all the functional, stress, load, etc tests and everything appeared to be stable. The system has been under scrutiny for the past 4 days by batteries of testers instructed specifically to look for those strage kinds of behavior. Other developers are running scripts on the log files looking for other kinds of context switches that may have been missed by the testers. I am happy to report that they haven’t found anything.

Not that this means that the problem isn’t there. We really can’t be sure. However, the PM has decided that we are stable enough to go into pilot mode – deploying into production beside the current system; having users work on both systems at the same time. I’m optimistic.

I’m personally involved in two more production-projects that are making use of nServiceBus in similarly high-end situations and we’ve never had these threading problems – now two years running.

That was an interesting week.

In this podcast we’ll be discussing certain methodologies for migrating an architecture from N-Tier to SOA. We’ll see what parts can be used almost unchanged, and which N-Tier concepts have no place in this new, service-oriented world.

Ketan asks:

Hello Udi,

I am Ketan, working as Analyst Programmer in India. I want some information regarding SOA Architecture. I have visited several blogs and sites and I do have enough knowledge regarding technical terms of SOA. I have worked a lot in 3-tier mechanism a lot and now want to switch on SOA Architecture in Visual Studio 2005.

I read your blog post How to migrate to SOA and liked the contents and am interested in doing it. Can you please be more precise about how to migrate from 3-tier to SOA? Actually, I have read whole content of above link and you have explained enough. But, still I want you to keep me out from dark. You have described it functionally, but I want some technical description of this process. Please help me in this.

If you can provide me some example/application (in which SOA Architecture has been implemented), then it will be very helpful to me.

Thanks in advance. Waiting for your favorable reply.

Ketan

Download

Download directly here.

Additional References

• Blog post on migrating from layers to services
• Podcast on “Does SOA mean the end of OO”?

Want more?

Check out the “Ask Udi” archives.

Got a question?

Send Udi your question to answer on the show.

4 years ago I had just started this blog and had a handful of subscribers. Now you all number over 1200. I am just totally blown away, and thankful for your support. I’ve been thinking to myself over the past few weeks that I should be doing more for you, but was wondering exactly what.

I have been trying to keep busy besides “just” the blog.

I finally set nServiceBus free. And am probably more pleased with myself than I should be 🙂

The Ask Udi podcast does a bit towards getting some feedback from you, but I’m pretty sure that you feel (as do I) that it’s too “fire-and-forget” since it can take a month or more for my answer to come online. I do want to give a quick shout out to Bill who has been extremely patient with me and keeps sending me nice meaty questions. Thanks Bill!

Just recently I’ve floated a new endeavour called ArchiTips, hoping to get some of you to share your tips with the rest of the community because, let’s face it, I talk way too much as it is already. Even if you don’t have a big write-up for your tip, just fire me an email with a sentence or two and I’ll find the way to package it for mass consumption.

Finally, I’ve recently started doing some remote consulting with a couple of my blog’s readers, one in Florida, the other in Ireland. I must say that it’s working quite a bit better than I would have imagined and that they’re getting value from it. Both are in the initial phases of a serious web system upgrade and are looking at their architecture again with an eye on scalability and simplicity (my two favorite ‘S’ words). For me, it was great really getting to know them and I’d like to do more of this.

So here’s what I had in mind (bonus for you for reading this far!)

I want to give away 10 remote consulting sessions, each of them half-an-hour long. I know that it’s not enough for everybody but I want to see if this will work at all before trying to scale it up. Leave a comment below if you’re interested – or an email if you really need the privacy. Tell me a bit about yourself, what kind of work you’re doing, and how you think I could help. Also, let me know if you’d be willing to have yourself recorded so that we can put our conversation up as a podcast for others to benefit from – you’ll always have the right to veto this should you regret you’re initial decision later.

I’m hoping this lower latency communication will help turn things up a notch, and I’m looking forward to hearing from you.

BTW, I won’t necessarily be choosing the first 10 that I receive. I’ll try to get an even split between those who agree to have their conversation come online and those who require more privacy. Believe me, I’ve worked at some places who were pretty over-the-top when it came to confidentiality and IP and all that – I know what you guys have to deal with.

So, umm, let’s go.

(Gosh, I hope the comments won’t stay empty. Wouldn’t I look dumb.)

In this podcast we’ll look at the issues around versioning and SOA and how the asynchronous nature of messaging obviates the need for previously accepted interface-based versioning practices.

Jarrod asks:

Hi Udi,

I have some questions around versioning and SOA:

Over the years I’ve been fairly adamant about the practice of versioning interfaces should a method change be needed.

Hence, IDog and IDog2

Generally I would also say that a method addition would need a new interface as much as a change to an existing method or property (sometimes requiring completely deprecating the old interface).

With SOA being used more and contract first designs coming down the pipe…an addition of a method or operation to a contract in SOA does not mean its a breaking change.

So, do you continue to create a new interface and version the name within an SOA environment? Even if its just one method that is being added?

A service contract, in general…with just a single method in my opinion is a bad design. Sure, there are exceptions to that but I can just see changes made to the service contracts over the course of a few years with many 1-2 method interfaces.

Day 1 : 12 methods on interface IDog

6 months later : 1 new method, create IDog2 which implements IDog

15 months later : 2 new methods, create IDog3 which implements IDog2

Some can argue that if you’re having to add methods like this, the original design was flawed. That may be…or you could just be in a volatile business environment in which SOA must adapt.

So my main questions are:

1) Do you think its the best practice to continue to version interfaces for non-breaking method additions in an SOA environment in which you also have control of the consumers (internal consumers)?

2) Do you think its the best practice to continue to version interfaces for non-breaking method additions in an SOA environment in which you do not have control of the consumers (external consumers)?

3) If the answer to the above is yes, is a single method on a new interface acceptable?

4) If you know of a problem in an existing interface on a method and have control of the consumers – do you “fix” the method and redeploy to the consumers? Or do you deprecate the entire interface and begin anew?

I’m interested in seeing your responses 🙂

Jarrod

Download

Download via the Dr. Dobb’s site

Or download directly here

Additional References

• Podcast on Autonomous Services and Pub/Sub
• Blog post on “The Perils of WSDL first”

Want more?

Check out the “Ask Udi” archives.

Got a question?

Send Udi your question to answer on the show.

I’ve taken the next step in making NServiceBus truly open source. You can now find it on SourceForge here:

http://sourceforge.net/projects/nservicebus/

Having never run an open source project before, I’d appreciate it if one of my trusted friends would step up and help me run the logistical aspects of it – to whom to give developer access, manage the writing of documentation, etc.

It’s kind of weird, really. I’ve managed the development of much larger code bases with many, many developers but just can’t seem to get my head around this open source philosophy. The one thing that I am sure about is that NServiceBus needs to be open source. So, please bear with me while I figure out this brave new world. If I do happen to slight anyone, believe me that it is entirely out of ignorance of the accepted decorums and manners, so I offer this apology a-priori.

Now that that’s out of the way, here are some things people have been interested in putting into NServiceBus:

• Support for ActiveMQ
• Port to VS 2008
• Documentation!

Any other ideas? Send them my way either via the comments here, or on the SourceForge project site.

Welcome to the first instalment of ArchiTips. I’m Udi Dahan, The Software Simplist and together with IASA we’re going to be providing you with quick titbits of information designed for architects.

This week is going to be the opening of a new series of tips about presentation skills.

As architects, many of us have grown from highly technical positions where our success derived mainly from our ability to talk with machines. However, in the role of architect much of our communication is now done with our fellow human beings. Moreover, our use of machines now focuses on creating content for human consumption.

As much as we wish it weren’t so, the “rightness” of our guidance won’t necessarily make developers or managers accept it. And, truth be told, an architect whose guidance is consistently not followed may need those same communication skills in the interviews coming his way 🙂

Although many books can be written on the topic (and, indeed, many have), this week I wanted to call out one simple, practical, easy to employ tip that will increase the effectiveness of your presentations.

If you’re in any situation where you’re talking to more than one person about your guidance, stand up.

This may be a formal design review, or an informal discussion over some diagrams, it doesn’t matter. Especially if everyone else is sitting down, standing up automatically communicates authority and self confidence. You’ll also notice that once you stand, you’ll start making more
use of your hands and other body language. When speaking to groups of 10 or more people, standing up will also ensure you can make eye contact with everybody. These two factors account for 55% of communication.

What this means is that if you’ve been using the perfect words, pitch, speed, volume, and tone of voice, you’ll more than double your effectiveness.

I can only imagine what this little tip could have done for my career when I was just starting out, so I’d like to hear from those of you who are using this tip and how its working for you. Also, if you have any tips of your own that you think will help other architects, send it in! You also can check out my blog for more information for architects.

A while ago I put up a jobs network thing on the right bar of my blog but didn’t give it much thought. The other day I thought I’d take a look around and see if there’s anything of value there, or if I should just take it down. I must say that I found some interesting stuff – interesting enough to warrant its own post. Here are some of them:

Senior Technology Architect
Are you a rock star architect? A programming champion? An expert in enterprise architecture and high-performance, event-driven systems? An authority on software development process and methodologies? Are you challenged by understanding the business problem and mapping out a clear path to solving it? Does leading a team to meet big obstacles head on excite you? If so, Bridgewater Associates wants you to help us revolutionize our mission-critical technologies.

—

Architect/Technical Lead at ThoughtWorks
If you would like to…

• Architect, and subsequently help develop, Enterprise-scale Applications and Systems from the ground up.
• Guide a team to consistency and creativity throughout the software development lifecycle
• Take a technical leadership role and help shape the “big picture” on projects
• Collaborate on architecture and design decisions with a team of exceptionally talented developers in an non-hierarchical environment
• Help ThoughtWorks to continue to build robust, technically leading edge systems for clients, across a variety of domains that continually raise the bar in delivering business value.

We want to hear from you!

—

The full job listing can be found here, and you can also subscribe for the RSS feed. If you’re looking to recruit the kind of people who read my blog and others like it, take a look here.

I’d also be happy to hear about anyone who found a job through this network and hear about their experiences.

I think that covers the topic.

Apparently, I didn’t screw up my talk last year at TechEd so they’re having me back. Here’s hoping this esoteric topic doesn’t scare too many people away:

ARC401 Designing High Performance, Persistent Domain Models Discover how denormalizing your OLTP database schemas and your object models can improve your systems performance – even for complex business logic scenarios. We’ll be touching on tips and tricks that Amazon and EBay employ to improve throughput. This session will show you when to use lazy loading, eager fetching, and other high-performance persistence techniques as well as how to encapsulate this complexity keeping client code loosely coupled. Thu Nov 8 13:30 – 14:45 Room 117

You can find the slides I’m going to be presenting here in zipped PDF form.

I recently presented this session to the Jerusalem user group and they seemed to like it, so all that’s left to do is take that 2 and a half hour presentation and make it just as good in half the time. I’m optimistic. Really.

Stop reading.

You’re ruining my optimism.

I mean it.