The Impatient Commuter's Guide to DLR Optimisation (part one of an occasional series)

My esteemed colleague Ben Thompson remarked in the comments to this posting that my blog lacks a visual aspect.

I think he makes a fair point.

Therefore, this article is brought to you through the magic of PowerPoint.

I am sure many of my readers often ask themselves: "Where should I stand on platform 9 of Bank station to ensure I will leave the train as close as possible to the exit at Westferry station"? Those readers should fret no longer for the answer is this:

Assuming you are entering platform 9 from the Bank side (rather than the end nearest Monument station), you should walk along the platform as far as the overhead matrix display. At this point you will have gone too far. Turn around. You will see a shiny line on the ground running from near the information desk to the platform edge. This is the Marker of Magnificence. Stand on it and use the door that appears immediately in front of you when the train arrives.

Walk to the opposite set of doors and occupy the corner space (so that you don't block passengers getting on and off at Limehouse).

Thus:



Upon arrival at Westferry, use the door opener to your side, exit the train and scurry straight on to beat the other passengers who are heading to the exit that you have just arrived at. You should arrive there before everyone else. Ha! You win again.



Being the first passenger off the train, you have no slow-coaches ahead of you and so can descend the staircase at a pace that suits you. Truly you are a premier passenger.

Ben: Happy now?

Going to the movies on a Monday afternoon

For reasons I don't fullly understand, RSS Bandit insists on dumping "Fast Company" feeds in my "tecosystems" subscription. Most odd.

Either way, it has the beneficial effect of forcing me to read the occasional Fast Company article.

This is a fantastic first line for an article: "People who have learned to answer email on Sunday evenings also need to learn how to go to the movies on Monday afternoons"

Anybody flying between London and Manchester soon?

If so, take a look at this..... nice free train journey offer: http://forums.moneysavingexpert.com/showthread.html?p=1607521#post1607521

DB2 sucks

Not really, of course.... But I figured every time this blog posting appears in a google search, someone else's doesn't.

Stephen O'Grady at RedMonk linked to this post about one user's attempts to install a trial version of IBM's DB2.

It's worth reading in its entirety. He begins by describing in excruciating - and depressing - detail the problems he hit when he tried to get a trial download of the product to install on his UNIX box.

The thing that struck me was that it was yet another example of how a user's first experience of a product or service is of paramount importance. In my time at IBM I've been impressed at how far the development teams have come in this area. In my area of specialism, the installers for products like WebSphere MQ are fabulous. You immediately feel confident that the install will be easy and that you will do it right.

Posts like this one, however, remind me that one should never get complacent... there will always be an issue you didn't forsee. So it's gratifying that there was such a great support structure in place for him to turn to. I've worked with DB2 product support in the past on various client problems and have also been impressed by their abilities.... nice to see them get some recognition.

It's a pity that a couple of (actually very minor) gotchas made the experience harder than it should have been but I'm glad he took the time to get resolution and, importantly, to share that for others to benefit from.


[UPDATE 2006-05-24 11:20] A colleague (thanks Axel!) has pointed me to this detailed article on some of the cool stuff in DB2 8.2.

For your messaging people out there...

.... my colleagues Andy Piper and Ben Thompson (update your blog so I can credibly link to it!!) have also been published on developerWorks today. Ben and Andy are probably two of the deepest WebSphere Message Broker experts in the world. I always sit next to them when I go to Hursley so that I can stay current on that product by osmosis.

Hello to my readers from developerWorks

If you're reading this post thanks to my recent article on developerWorks, welcome to Gendal World!

I've been involved with IBM's WebSphere Process Server product for well over a year now - having worked closely with the development labs prior to release, consulted on some of our first engagements, contributed to our education materials and written various articles. One of the areas I focussed on was how to build applications that are robust against change. I recorded a PodCast on this last year.

If you're looking for more posts I've made about Process Server and related technologies, you might want to start with this Google Search which pulls up a lot of the articles.

It's OK to admit two words are synonyms

I hope I'm not about to expose my ignorance of the space in which I specialise.... but I'll take the risk. I'm going to admit that I don't know the difference between "orchestration", "workflow" and "choreography". There. I said it.

Actually, I'm not being entirely honest. It's not that I don't know the difference; I just don't think there is any difference.

I freely interchange these words when I talk to clients and I make no apology for it. I've seen no attempt to differentiate the terms that resonates with me and, until I do, I'll carry on doing what I'm doing. As far as I'm concerned, the concepts of orchestration, process choreography and workflow are the same thing.

You can try to tell me that it's all to do with granularity or that it's all to do with the life-time of a process or it's all to do with whether humans are involved or not. I don't care. I'm going to stick my fingers in my ears and yell "La La La! I can't hear you!"

Sure... different runtimes may be optimised for different kinds of scenarios (a BPEL execution environment may not be the place you transform 1000 messages per second as they flow between two systems across MQ) but that's orthogonal.

So, it was with highly sceptical eyes I read this post by Polar Lake's Warren Buckley. Warren appears to be their new blogger-in-chief after the departure of the impressive Ronan Bradley. He tries to differentiate "choreography" and "orchestration". I think he's guilty of verbal gymnastics that would shame a politician but don't let that distract you from his point. His discussion of Control Theory is most interesting. I *think* he's describing the same kind of thing we talk about with our WebSphere Process Integration story but I need to think some more about it. Either way, it was an interesting post.

So, hello, Warren. I look forward to reading more of what you write :-)

All Change!

Everybody's getting new jobs!

So... Rich Turner at Microsoft... good luck in the new InfoCard role.

And... Ronan Bradley of PolarLake... good luck in your new role too.

What with RedMonk hiring a new guy (hello!) and my favourite editor moving on to new pastures, you could be forgiven for believing the world wasn't static, after all. Who'd have thought it?

Pragmatism is a beautiful thing

I've been having an interesting (but ultimately unresolved) debate on the comments of my colleague Bobby Woolf's blog. I was trying better to understand the differences between REST and SOAP. I now realise that, although I thought I wasn't, I was actually conflating several themes. Thanks to this post by Don Box for helping me to cut through a lot of the debate.

Verdana is taking over the world

I've long had a vague feeling that all the "Web 2.0" websites I've viewed have looked the same.

I thought it might be due to the current fashion of making use of lots of white space and bold graphics.

But no.... they just all use Verdana. Every single one of them.

Examples:

Skype
Haloscan
Technorati

It was therefore heartening to discover the Service Component Architecture Portal (thanks for Jeff Schneider for pointing me to it in the comments of this post)

This website also uses Verdana gratuitously. Since I have established that Verdana = Web 2.0 = cool, I think we have conclusive proof that SCA is cool. Excellent.

As for the content... well, I have better things to do on a Saturday night than read it... that will be a task for the week. But it does have some interestingly titled articles. ServiceComponent.com could turn into a very valuable resource.

We need some better FLAs!

Having exhausted the world of Three Letter Acronyms some time in the last millennium, the IT industry is currently working its way through the four-letter type.

The TLA crusades are over. TCP beat SNA.... The HDD outlived the FDD.... The discerning traveller will even agree that LCY is better than LHR.... But the four letter wars have barely begun....

I've been debating the nature of SOAP and REST with some commenters on Bobby Woolf's excellent blog. I'm still trying to get my head around the subtleties; I'd certainly appreciate other contributions to the debate (from either "side"). However, something tells me that, in the end, REST just sounds cooler.

Naming matters :-p

XMS

Microsoft's Omri Gazitt mentioned IBM's XMS technology recently on his blog. He argues, correctly, that interoperability between messaging systems is A Good Thing. However, as I posted in his comments, I think XMS is trying to solve a subtly different problem.

Either way, it's good to see that XMS is getting noticed; it deserves wide adoption.

How to avoid crashing into strangers without slowing down

When not visiting clients, I tend to work in IBM's office in Central London. The office is very near to one of London's busiest commuter stations so I find myself travelling in the opposite direction to most other commuters: I am using the London underground network to reach Waterloo station when most other workers are trying to leave Waterloo and vice versa.

This makes for a more relaxing journey (fewer people to compete with for space on the trains I use, etc, etc). But it does cause one problem when walking: there is almost always a wall of people hurtling towards me.

This problem is particularly acute near my home in Canary Wharf. There are lots of very modern office blocks in a regimented pattern, with blind corners.

This means that when I approach a blind corner I have to slow down to avoid the risk of bumping into the crowd coming the other way. This makes my life somewhat difficult as I don't "do" slow walking.

n the diagrams below, the blue blocks are buildings, I am the green path and the oncoming crowd is in black.

The first diagram below shows the problem: blind corner and oncoming crowd.

The second diagram shows my solution. As I approach a blind corner, I change direction and walk across the potentially oncoming crowd. If no crowd materialises, I am not really worse off. But if there is a crowd, I am walking perpendicularly to it and so have several precious milliseconds to find a gap between people to dart into.

This increases the distance I walk but means I have no need to slow down. Excellent!

Is polling always evil?

Microsoft's wonderful Raymond Chen discussed the evils of polling a few weeks back. He is, of course, correct that it's usually a bad idea. My rule of thumb when considering such scenarios is that if something intuitively feels wrong then it usually is. And polling feels wrong.

However, I think it's possible to be too disdainful of polling. In particular, I am increasingly of the opinion that it can be used in judiciously-chosen scenarios to help build significantly more robust systems than would otherwise be possible.

The example I have is from the Enterprise Application Integration world. Assume we have a monolithic application which is supporting some business function.

For whatever reason, we need to know when various tasks have been performed ("new customer record created", "purchase order modified", etc). When such an event occurs, we need to send the information to some other system. This is the bread-and-butter of integration. Call it EAI, BI, ESB, whatever.

Now, how do we detect such events? There are two broad approaches. We can configure the source application to notify the integration layer when something of interest has happened (e.g. by sending an event into the bus, by calling a web service, by placing a message on a queue... whatever). Or we can configure the integration layer to somehow detect the event.

The latter is most often achieved by configuring the source application to record than an event has occurred (e.g. in one of its database tables) and for the integration layer to periodically check this event store. i.e. we configure the integration layer to poll.

Who, in their right mind, would ever regard the latter as a reasonable approach?

Well..... me, quite often. And here's why.

The former approach has plenty of advantages: real-time notification of an event, no polling, the event flow is clear, etc, etc. But... it also has two potential drawbacks. The first is that the source application has to be configured to talk to the integration layer. In most cases this is no trouble at all but in some situations (especially with older, bespoke software) it is quite difficult. Worse, this approach has added a dependency to the source application. It now requires the correct functioning of (part of) the integration layer - or must have sophisticated error handling added to deal with the times when the integration layer is unavailable. So, high availability scenarios have been complicated. Considerations such as these can make achieving buy-in from application owners to an integration project much harder.

The polling scenario has plenty of obvious disadvantages (polling can be costly, polling can introduce latency, etc, etc). But it has a very nice advantage: we have added no dependency to the source system; it can generate events that the wider scenario requires without complicating its own operations. This is since the integration infrastructure (perhaps in the form of an adapter) is making a call to the application, rather than listening for a call from the application.

My view is that polling can often be considered a transitionary state: get a project working and demonstrate value to the business sponsors and the application owners. Once the integration infrastructure has been proved (and has been shown to have higher reliability than the applications with which it integrates!), resistance to modifying the applications to call the integration layer often evaporates. Polling performs a valuable role in allowing us to get to that point and in solving problems where direct notification is unachievable.

So, no. Polling is not always evil. It is merely usually evil...

"The fear of getting it wrong was surpassed only by the fear of not delivering anything at all"

I overheard this comment on a train back into London a couple of evenings ago. Two young trainee lawyers were discussing their careers to date and comparing their workloads - and the high expectations that had been heaped upon their shoulders.

I tried to imagine the circumstances under which somebody in IT would find it credible to articulate a comparable fear. I'm not talking about the natural desire to do things right and to ensure one's deliverables are good quality. Rather, how often do we find ourselves in situations where our professional credibility, the wellbeing of our client (and our own chances of advancement) rest entirely on a single piece of work?

It's easy to think of examples in the "traditional" professions: if you put your name to a company's audited accounts, you'd better be sure they're correct. If you're playing with billions of dollars of your bank's own capital, you'd better be sure your trading strategy is sound. It's easy enough to think of examples from the worlds of medicine and law.

I'm interested in hearing my readers' thoughts on what the equivalents in IT are. I have a few ideas of my own but I was surprised at how few good ones I could think of. I'm hoping you can help me out. So, comments are open as always. I'm looking for examples from your IT career where the outcome of a single piece of work could have had truly serious effects had you got it wrong. "The patient either died or lived". "The defendent either went to prison for life or walked free". "The bank either went bust or made a fortune".... what do you think is the equivalent for a professional in IT?

Describing SOA with a famous brand of plastic building blocks

Jeff Schneider has a funny piece that puts SOA in an historical context.

Although the "famous brand of plastic building blocks" analogy is not new, it is very important. I get asked a lot why we need specifications such as the Service Component Architecture. "Why do we need another invocation mechanism?" The answer is that SCA isn't just an invocation mechanism. Rather, one of its key features is the ability to regard logical chunks in our infrastructure and applications as reusable building blocks. Blocks that both provide and consume other services. Jeff's piece illustrates that quite nicely.

Scandinavian Airlines

Does anybody understand Scandinavian SAS airlines' business model? They introduced a two-tier economy cabin for short-haul flights a year or so ago and I remember thinking it odd at the time (mainly because I had been booked into the lower tier and so was forced to pay for my dinner). If I have understood the offering correctly, they have an economy fare which offers inflexible tickets and requires payment for onboard refreshments. Economy Flex provides flexible tickets and an onboard catering service. This is in addition to their business class.

When I first noticed this behaviour, I thought it was just SAS being quirky. However, I read a remark in their in-flight magazine yesterday that suggested it actually has a history going back to the late 70s and was part of a strategy to innovate in a regime of heavily regulated fares.

It's still all a bit odd, though.....

Business-integration, Business-partners and Bandy

I have just spent an exhausting week in Stockholm discussing how WebSphere Process Server can solve some pressing concerns at one of our business partners. My time was split between teaching our standard introductory class and discussing specific problems they were trying to solve. It was a tremendously rewarding week: the pressing problems they had made them attentive students and they were extraordinarily talented.

Not only did they have to listen to my descriptions of a new technology and relate it to their existing technologies in real time, they had to do it in English (my Swedish skills being somewhat weak...).

However, an attentive, question-filled class is a demanding class and I was thoroughly exhausted every evening.

I did manage to take time out on Thursday evening. My colleague (who organised the class) took me to see a game of "Bandy". Those who know me well will know quite how low my interest in sport is but I'm always willng to try something once. Unless that "thing" is a roller-coaster that goes upside down but that's just good sense: if we were intended to travel upside down, our pockets would not be open at the top.

Bandy seems to be a cross between ice hockey and football. The game we saw was Sweden vs Norway and it attracted a good crowd. I'd recommend any visitors to a Bandy-playing nation take the opportunity to see a game.... just make sure you wrap up warm. Spectating is not an endeavour for the inadequately clothed.