The issue of concurrency is one of particular interest to me. I’m not sure if it’s because I have seen too many projects get into serious trouble around it, or that I’m just weird that way. After these last few days at Arosa at the Software Architecture Workshop, I’m beginning to understand that there’s a pretty good chance that I’m just weird. I mean, it turns out that I do quite a few things different from most other people. So, after reading Matts’ great post on “Realistic Concurrency”, even though it was after midnight, I had to get my head around his thinking.
 

After framing the issue as a business-level update of information in a multi-user system, we drilled into the specifics. First of all, we agreed that pessimistic locking in business terms meant treating that part of the system as single user for when the user had acquired the lock. The pattern that is often used in that case is what I call the “Make it so” pattern, after Picard from Star Trek, The Next Generation. In this case, the user sets up the data the way he wants and tells the system to “make it so”. From a software perspective, that data snapshot can be sent to the server without very much fanfare since no other user could work on the data in the meantime. It has been my experience that projects usually get these parts right.
 

Before going into the optimistic concurrency topic, I just wanted to mention that the way the system enables the user to acquire a pessimistic lock itself involves optimistic locking, since there is no way to prevent multiple users from attempting to acquire the same lock at the same time. I consider that somewhat ironic as I’ve seen numerous projects work under the premise that they could do only pessimistic locking and ignore optimistic concurrency.
 

Well, the main thing that I wanted to hear from Matts after reading his article was how was it that I had never run into the problems that he had described. After going back and forth about it a little, Matts proclaimed that the way that I was working was not usual. Maybe I am a bit quirky, but I find nothing special about this rather generic way of working:
 

1. Server gets a message
   
2. Service layer opens a transaction
   
3. Service layer requests the relevant object (often by ID)
   
4. Service layer calls a method on that object
   
5. If no exception is thrown, commit the transaction, otherwise rollback
   

Matts put me to task by asking exactly what kind of method would I call for a generic update. I have to admit that that was not something I was prepared for. A generic update? In a business-level optimistic concurrency scenario? I don’t have any of those. Its all specific – change customer address, cancel order, authorize payment, etc. This specific information is passed as a part of the message, including the relevant data, which in turn get passed to the specific method. The transactional scope makes sure that if two concurrent actions are received for the same instance, they will be performed serially. If there’s any validation to do, it’s done as a part of the specific method.
 

And then I saw Matts eyes light up; “you’re doing exactly what I’m suggesting! Before going to update the data, you refresh it.”
 

Apparently I was missing something; “I didn’t know there was any other way to do it. Its always just get the object, call a method. For example, canceling an order: you have to check if the order hasn’t been shipped yet. How could you possibly do that if you didn’t get the current state of the object? I don’t think I understand the alternative.”
 

Weird, dense, or tired, but Matts got me to understand in the end. The underlying premise that I had was that the UI was task based for all things where multiple users could be working on the same data. After I understood that not all systems were like that, quite often editing data in a grid, I began to realize the root causes he was talking about. Matts had a much broader perspective than I in these matters because he wrote, and supports an object-relational mapper. He interacts with a much larger and more diverse type of projects and was trying to help solve problems in the general case. My suggestion was that this specific problem could be better solved by redesigning the UI. Users like tasks based interfaces – they correspond very well to the environment in which they operate. When a customer talks to a call-center worker, they don’t talk in terms of “I want to generically update my information”, but rather in terms of specific tasks: “I want to change my address, and cancel an order.”
 

This isn’t so much of a big deal in call center apps, since that user won’t often be doing similar tasks online concurrently with their conversation, but collaboration type systems are much more susceptible. Document management type systems are one example.
 

Well, by the time we were done yapping, it was already after 2 am but we had made some progress. We had recognized that no system could be entirely based on pessimistic locking, and the different patterns for each scenario. I was practically passed out at that point, but that was definitely a productive night, rounding out an amazing day.

Published in the IBM Portal of DevX.

Summary: Udi’s developer therapy group wrangles over the real advantages and tradeoffs in developing using SOA in the real world—especially compared to past practices.

Continue reading.

I’ve began rethinking certain assumptions about how I use message passing in my distributed systems after reading things like “SBA & EDA Lessons Learned” from the excellent “Panic from Fuzzy” blog. Since I was only familiar with the Tuple Space theory but have never employed space technologies like JavaSpaces, I did the only thing I could do – I convened a session on it at the Software Architecture Workshop so as to benefit from the knowledge and experience of those frightfully smart guys.
 The functional issue that attracted me to spaces was its ability to do very dynamic like content-based filtering. By subscribing to notifications based on a template, I could replace a broad and deep topic hierarchy and handle some other interesting scenarios as well. For instance, when a given user is working on a certain set of data – a tree of specific instances, I would like that machine to only get updates on that data, which could be quite a substantial savings in terms of network load. Another case is where the user is only allowed to see certain instances of the same type.
 

About three quarters of the way through the session, when I was still thinking that I could put entities in the space, someone called my attention to the fact that I would have to give up the cross-entity transactional semantics that I was so used to. For instance, in order to implement a business rule when an order is cancelled the customer may also need to be updated to a non-preferred status. This calls for a transactional scope around both of these updates – on the business level. If the entities were in the space, the naïve solution would be to Take the order, change its status to cancelled, Put it back in the space, Take the customer, updates its status, and Put it back in the space. By not being able to perform all this work transactionally, failure cases would need to be handled by compensating transactions – a significant jump in complexity.
 Needless to say I left that session quite a bit cooler on Space-Based Architectures than I was going in, but later on in the day, over a beer with one of the guys, he suggested that maybe spaces could be used as an alternative way to do message passing. Instead of Taking and Putting entities, we could do the same for messages – since the business-type of transactions would by-and-large correlate to a single message. We could benefit from the dynamic subscription behavior and possibly do away with a deep, and sometimes fragile, topic hierarchy. Once again my enamourment was on the rise.
 

But as do all fickle loves, this too was not destined to last. After doing some more thinking I remembered about handling failure cases in terms of message passing. When dealing with reliable messages, the receipt of a message, its handling, and the subsequent sending of new messages is at times required to be all transactional. I was once again required to perform a Take operation as well as multiple Put operations in a single transaction.
 I hardly believe that this is the end of the story for me and spaces. I’m still getting my head around using spaces as a technology choice in my current architectures and examining new architectural possibilities around it as well. We are definitely living in interesting times.

Update

After reading “What about Usability”, Jeremy’s latest installment of his “Better Software Development” series (my words, not his) I got flooded with a bunch of thoughts. Mostly things that I’ve wanted to blog about before but didn’t. So please pardon the disjointed nature of the following notes.
 

Since I’m writing this while on the plane to the Software Architecture Workshop in Switzerland, I’m reminded of a discussion I had with Arjen Poutsma at this same workshop last year. I think that the original topic had to do with Web Services, but it meandered around quite a bit. I think it started by me saying that services should not expose CRUD style operations. Arjen countered by mentioning that most user interfaces in line-of-business applications exposed the same model to the user by having them fill out data in grids. My retort to that was that while humans can get used to almost anything as long as its consistent, that doesn’t mean that it is a good solution. In the systems that I work on there is usually an HCI (human-computer interaction) person on the project who designs the UI, mostly around the tasks they perform. These tasks often corresponded very well to the coarse-grained messages we employed in terms of SOA. We finally agreed that the successor of SOA would be TOA (Task-Oriented Architecture) in its aggregation of client-side aspects to the already server-centric principles of SOA.
 

A different topic that came up in a recent meeting in one of the projects I’m consulting was how long users expect to wait for a response from the system. What made the HCI person rethink his design was my suggestion that certain algorithms could be deployed client-side and since their performance for the kinds of work the user would do most of the time was on the order of a couple of hundered millis, we could run them “interactively” – as in, on every mouse-click. This input eventually brought about a greatly simplified and much more interactive experience for these expert users. I’m no HCI expert, but I’ve learned a thing or two over the years, and one of the important ones was the need for synergy between architecture and HCI design.
 

Finally, code that supports highly interactive user interfaces is non-trivial to say the least. Jeremy brought this point up and suggested using design patterns like MVP with a healthy dose of unit tests. I couldn’t agree more, well, yes I could. Even if you use the next generation patterns of Passive View and Supervising Controller, the Dependency Injection development style, and the Command Object pattern, it will not be enough! I’m seeing, in real time, what happens to a project that utilizes all the appropriate patterns, manage their dependencies well, decouple fervently with events, and keep their code clean at all times but doesn’t require/encourage developers to write unit tests. It is a stability nightmare. If you have a complex system to build with intricate logic as to what can be activated when, or any long list of detailed requirements in terms of user interaction, ignore unit tests at your peril. Having a testable design is a great first step, but if you don’t go and test, you’ve negated quite a lot of its benefits.
 

I hope that that didn’t amount to just a bunch of over-tired, jet-lagged, incoherent babbling, but I’ve been waiting to get it off my chest and now seemed like just the time to do so.

More information:

Usability is Timeless, and things that are still broken with usability today.

After all contestants presented their solutions in the Iron Architect contest at TechEd Developers in Barcelona, and the judges left the room to deliberate, I put a question to them:

“When can you have your solution in production and how much would it cost?”

You could see the shock on their faces. Architects weren’t supposed to answer these kinds of questions, were they? That’s what project managers are for, right? Eventually, they settled on one month for the schedule question, with only one developer. That’s one month in terms of calendar time. I was shocked by that.

Unless you’re Superman, in the span of one month you cannot learn an existing system, figure out all the new requirements, design, develop, test, and deploy, debug, etc, etc, and keep stakeholders happy and in the loop throughout the whole process. And it doesn’t matter how many developers you have.

And on that point, like you’re really going to be able to find a developer who’s any good at the drop of a hat, get them to leave whatever they’re doing for a month, for a short term project like that.

This topic came up in the speaker dinner when I was talking to Pooya and Jurgen (one of the judges). Architects need to be the glue that connect everything together – business, management, technical, test, operations, etc. They need to fully understand project lifecycle issues. When business comes along with a new requirement, the architect is the one who says if it can be just slipped in or needs to be separately budgeted – not the PM. The PM may have the final call, but the architect is the one who provides the information about the ramifications of changes to the project.

Money? Schedule? All in a day’s work for an architect.

After spending a good week at TechEd Developers in Barcelona, going to some of the sessions, having a late-night chat with the WF product guys, and some general blue-sky thinking, my thoughts around workflow foundation have begun to crystallize.

I know that WF was designed to be general purpose, but I don’t like general purpose tools, not for the projects I work on. I don’t like that it has its own threading model and that I have to override it. I don’t like that it has its own activation model and that I have to override it too. These are architectural concerns that need to be in sync with the entire project – I can’t have every part of the system doing its own thing.

Although not surprised, I was a bit saddened when I was sitting through the Iron Architect contest and each participant described how they would implement the business logic of the system with WF. Personally, I think that that’s a bad choice. Object-oriented domain models do an excellent job of modelling complex business logic. The procedure-oriented nature of workflows predisposes them to the historic failures that method has brought in the past.

One area where I can’t think why WF wouldn’t do well in is for web-based page navigation. I’m sure there are others, but for the systems I work on there are usually better alternatives in those areas. When it comes to products, on the other hand, WF might be a smash. I’m pretty sure that the Sharepoint guys are betting the farm on WF for the human workflow there. Again, since I’m a project guy and not a product guy I don’t think I can do WF justice there.

One area I’m really interested in is long-running workflows and their use in SOA. WF has a very important, and non-trivial thing called Persistent Timers in this area. This is incredibly important if you need your workflows to continue to be correct even in the event of a server restart, I know I do. WF supports a number of scenarios in terms of communication that currently don’t interest me but I am looking forward to seeing how their going to support WCF’s duplex communication patterns.

All in all, WF is an intersting bit of technology that I will continue watching as it evolves.

Get it here.

[Salt and Pepper, Peanut Butter and Jelly, Toast and Vegemite (if your down under) – these are all things that go together. But what goes with SOA you ask? Why Workflow of course! On this episode we are joined by Microsoft Archtiect MVP Udi Dahan who gives us his insight into putting these two technologies together.]

I just can’t seem to shut up about these things. It’s gotten so bad that I’ll be inflicting the same session I gave in TechEd Developers Europe on our local Israeli crowd at the end of this month. You can find out what other horrors Microsoft has in store here.

After slogging through a blog engine update, the flu, new year, and a project release we welcome you back to our regularly scheduled blogging.

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.

Clatoro’s NetBlog points to a survey showing that “Typical SOA Development Takes 3-6 Months”. First of all, statistics can be doctored to show whatever you want. Second, seeing as the definition of what exactly constitutes SOA is unclear (is WS-* in or out?) the value in comparing that to your current SOA effort is questionable. Finally, does that development include testing, deployment, support, etc, or is this just pie-in-the-sky coding?

Bottom line, don’t believe it for one second. Just getting a handle on the coupling between the applications and systems in your enterprise can take a couple of years. It’s worth it, but don’t kid yourself – it takes time.

Following my recent post on Datasets and O/R mapping, I’ve received some comments and one in particular I wanted to call out.

Jacob Proffitt, the Rabid Paladin, wrote up a post on how to handle DbConcurrencyExceptions when using datasets. 4 different ways, wow. I don’t think that any of them would work if the same row got 2 (or more) updates before getting sent to the database, since then we’d lose the ability to implement our nice business logic in dataset internals.

The main problem that I have with datasets is how they are used. They are the answer to databinding, sending data around (the all powerful DTO), and doing online transaction processing (OLTP), and do pretty much all of them OK in the simple case. If you are building a simple system, they’re probably right for you. Unfortunately, I’ve seen too many projects whose requirements were quite complex and got mired down so bad with datasets that they couldn’t continue. And this isn’t me here, who never spent the time getting good with datasets – these were people who were VERY experienced and knowledgeable in their use.

When those same projects used different solutions for databinding/reporting, distribution, and OLTP – everything became much simpler in the common case. Complex cases that were intractable became possible.

My thanks to Jacob for making it clear how to make datasets handle common OLTP scenarios. I wonder – why didn’t they make datasets do that out of the box?