Preparing for failure; part 2

Setting the foundations for project success

So, we’ve ascertained that projects are more likely to fail than succeed; but somehow we succeed a lot of the time. There are some general principles that I apply when delivering any project which I’ve found makes everyone a lot happier; the team, the business stakeholders, and me. A word of warning; anecdotal evidence is not science, no matter what some alternative therapists would have you believe; I’m not a PMP and I don’t have any qualifications from the PMI. All of this might just be hokum and inapplicable outside of my experience.

MSMQ and Java interoperability

Bridging between MSMQ and java using the adapter framework

Microsoft Message Queueing is a pretty good way of allowing applications running on different servers to communicate in a failsafe manner; it’s baked directly into all recent versions of Windows and has extensive API support via Visual Studio. However, all your applications are going to be running on the Windows platform and this can cause issues if your technology stack spans multiple platforms. Bridging between MSMQ and other platforms like a java based ESB might be causing you a bit of a headache.

Preparing for failure

Mitigating project failure conditions

It often occurs to me that a fair number of project managers are inordinately optimistic when it comes to managing the delivery of a project. Given the number of high-profile failures reported in the media, and their own experience, you’d think that we would have learnt to temper our optimism with a healthy dose of realism. Seems not.

Character encoding behaviour in the adapter

Adapter behaviour and character encoding

Working with different character encodings is almost fun. I do get asked a lot about this kind of thing; my transform doesn’t work, or this EDI document doesn’t parse properly (I suppose the customer thinks that diacritics are allowed in the UNOA character set?); I like to say that the adapter only knows as much about encoding as you do; everything is configurable so your choices (or tacit acceptance of the defaults) will have a huge impact on how the adapter behaves.

JMS Part Two; tuning behaviour

Second in series about the Adapter + JMS

JMS is the bread and butter of the adapter; it’s been supported even since it was first released. We use JMS as the backbone of all our community deployments; we aren’t picky about the vendor, so long as it supports JMS 1.0 then the adapter will quite happily work with it. I’ve written previously about JMS Connections and the adapter. Most of time, it just works; the problems that you might be having will be configuration based because the default behaviour just aren’t suitable for your environment.

Pagination


© all-the-years. All rights reserved.

Powered by Hydejack v9.2.1