Léon

- ‘L__é__on, what exactly do you do for a living?’ - ‘Cleaner’ - ‘You mean you’re a hit man?’ _- ‘Yeah’ _

Léon is an astonishingly original film. Natalie Portman plays Mathilda, a girl of twelve who befriends a milk-drinking hit-man after he rescues her from thugs who are murdering her family. She asks him to teach her the ways of his chosen career to enable her to exact revenge. And, incredibly, he does.

James Cameron, in his DVD commentary for Terminator 2, stated that he didn’t want to portrary Edward Furlong’s character (young John Connor) pointing a gun at anyone during the film, for moral reasons. I never really understood what he was particularly bothered by. In any case, director Luc Besson certainly doesn’t let this stop him investigating the association between youth and violence in this film, and in my opinion adopts a more mature attitude toward it - after all, it’s not like this film doesn’t have morals - you certainly leave it aware that everyone has got their just desserts.

Sadly, it appears that the region 2 version I’ve just watched is not Besson’s ‘version intégrale’, which expands somewhat on some of the more controversial aspects of the film (primarily Mathilda and Léon going on hits together). This is a great shame and the fact that Besson felt the need to do this is a sad reflection on the immature attitude our society still has toward films that encourage us to confront things that are out-of-the-ordinary. Sure, Léon is a largely unrealistic film in many respects, but the relationship between the two main characters is superbly played, couldn’t be more fascinating, and it’s a shame to miss out on the opportunity to see it developed further.

Office Politics is Worth Understanding

Scott Berkun’s excellent book, The Art of Project Management, contains a chapter on ‘Power and politics’. In it, he describes a realisation he had - from thinking that politics was something practised by selfish and evil people, to thinking that it was a useful skill to develop - something everyone does, for better or worse.

His prose convinced me, and I am encouraging myself not to put things I don’t like down to ‘politics’ but instead to try and understand them at a deeper level. I think there is a great temptation to put problems and shortcomings down to politics, without realising that it’s part of the way human beings interact and not something that’s disposable, however ‘nice’ everyone is. Ignoring it is intellectual laziness. I think the reason I found it hard to face up to this truth before was that I thought I didn’t understand politics, but Scott makes it easy - with descriptions of different types of power, where it comes from, and how to influence those who have it. Practicing politics is still hard, but it’s worth trying to improve one’s skill.

(Note: I’m talking mostly about office politics here, but some of the lessons carry outside that domain - that’s just where I have most experience).

Irony of the Day #972

You frequently see fire doors illegally propped open outside buildings across the UK. But to see this at a fire station, as I did today at Winchester? Now that’s irony.

WebSphere ESB Topologies (Part 1)

WebSphere Application Server (WAS) has a variety of ways of defining servers, and their relationships to each other. These are often called WAS topologies. Let’s revisit some of the WAS topology concepts from a WebSphere ESB perspective (although many things you may know or learn about WAS topologies probably apply equally to WebSphere ESB, and vice-versa, because ESB is built on top of WAS).

There is a hierarchy of objects in an ESB topology:

  • Cell - This contains one or more nodes. Cells are completely independent of each other from a topology perspective.

  • Node - This contains zero or more servers.

  • Server - This is a physical server (we’ll be talking primarily about application servers here). There is a 1:1 mapping between a server and an OS process.

An ESB installation can have one or more profiles, which define nodes in a topology (in other words, there is a 1:1 mapping between profiles and nodes). These profiles can have three types:

  • Stand-alone

  • Deployment manager

  • Custom

These profiles and the overall topology are orthogonal to ESB installations. An entire topology (with a variety of profile types) can be run from a single installation, or each profile can be part of a separate installation. To further confuse matters, a physical machine can have one or more ESB installations (although typically it only has one).

A stand-alone profile is easiest to understand. This defines a single node, which exists in a single cell. The single node contains a single default server. If you install ESB using the ‘Complete’ option, you will get a profile created of this type - called ‘default’, containing a server called ‘server1’ (the node and cell name will be some permutation of the hostname of your machine). Administration is done through an administrative console attached to the node.

Alternatively, you can set up a more complex configuration. If you create a deployment manager node, you can use this to manage other nodes. Typically those other nodes start out as custom nodes. When you ‘federate’ them to a deployment manager, they become part of the deployment manager’s cell, and a special type of server called a ‘node agent’ is created on the custom profile. Often this federation is done when the profile for that node is created. This federation allows configuration information to be shared between nodes - the administrative console used is now part of the deployment manager node, and configuration information is synchronised according to a schedule, or on demand. Resources (for example, JDBC connections), can be created at ‘cell’, ‘node’, or ‘server’ scope, and can only be seen at that level. Application servers also need to be manually created for custom nodes - they don’t contain any by default. Cells can only contain one deployment manager.

I plan to write a Part 2 on this topic soon, covering clustering. Watch this space…

What Clients Do I Get with WebSphere ESB?

So it’s Christmas morning, and you’ve unwrapped the shiny paper, and you see that Santa has left you a copy of WebSphere ESB 6.0.1. You’re keen to get going on developing your first SOA solution, but you’re a little bemused by the ‘Message Service Clients’ inside the jiffy bag, on CD2. Well, here’s what they are:

  • IBM Message Service Client for C/C++ (aka C/C++ XMS) - this is available for Windows and Linux.

  • IBM Message Service Client for .Net (aka .Net XMS) - this is available for Windows only.

  • IBM Web Services Client for C++ (aka WSCC, CWSS) - this is available for Windows and Linux.

These packages allow you to build client code that can be used against a WebSphere ESB system (as well as other messaging systems).

The XMS clients are essentially re-implementations of the JMS API in their respective programming environments: C/C++, and .Net. They are designed to match the JMS API as closely as possible, and are thus useful for client developers who are already familiar with JMS. The clients can work with three different JMS provider families:

These families use different wire protocols for the JMS messages, so the family being used has to be specified in the client application. Otherwise, though, the API is identical.

The WSCC client is slightly different: it allows one to write a web services client in C++ from an existing WSDL web service specification (such as one produced by ESB when one uses a Web Services Export in a mediation module, for example). Typically this is done using the supplied WSDL2Ws tool to create stubs that can be used to create the client.

The clients are also available as IBM SupportPacs for download, although you’ll want to check the licensing conditions for your support status when using these.

(Note: the ‘Application Client for WebSphere Applications Server’ is also shipped with WebSphere ESB, although, as the name implies, this isn’t specific to ESB - it’s the same client available with WAS). For more information, see:

  • The excellent article on IBM Developerworks - Introducing XMS.

  • The comprehensive documentation for the WSCC client - the file wscc.pdf in the docs/ directory where the client is installed.

subscribe via RSS