Daily Archives: October 26, 2005

BizTalk 2004 and WebSphere MQ Adapter – Losing Messages

Twice in the past two or three months I have encountered a problem with BizTalk 2004 and the WebSphere MQ Adapter where the message leaves the queue, but doesn’t arrive in BizTalk – I can’t even track it with the Health and Activity Monitor. There seems to be some kind of condition that causes the adapter to do this because the machine I went back to today was working perfectly a month or so ago.

Re-installing the adapter seems to fix the problem, but it is still a bit wierd. I presume there is some setting _somwhere_ that I can restore without having to go through the whole configuration nightmare.

Hobart, Virgin Blue Gate Lounge

It’s 6am, well, actually its 5am, people in Tasmania like to pretend that it is 6am. I presume it makes them less upset about being up this early – heck – lets make it 11am, that we we can be positively joyous! It doesn’t alter the fact that I really only got about four hours sleep last night, and about four hours sleep the night before that.

I flew down the Hobart yesterday so that I could present at the Hobart .NET User Group meeting on Visual Studio Team System. The session whent for about two and half hours and I showed people through some of the work item tracking features, source code control features and testing features of Team System. We had about twenty people turn up which not a bad turn out for Hobart I believe.

Now – I actually need to thank Sean Malloy and David Burela. Sean is the leader of the Hobar .NET User Group and looked after the logistics of getting word of the event out, and David provided the venue at the Wrestpoint Casino. Thanks guys!

Feature Request? Encrypting soap:Body fragments with WCF.

William Tay has come across a scenario which is supported in WSE 2.0 but not in WCF (Windows Communication Foundation). It has got to do with encrypting entire SOAP message bodies as opposed to individual elements within the payload. You should refer to William’s blog post for more background.

Unfortunately I can’t use Indigo at the moment with the build of Visual Studio 2005 that I am running to see if I can workaround the issue but I am going to assume there isn’t one – so this is more of a discussion of the pros and cons of supporting such a feature in WCF.

William doesn’t try to make a case for performance, but he does point out that only encrypting a portion of the soap:Body can reduce payload size. On smaller messages this optimisation would have less of a relative impact because the WS-Security headers that get placed in soap:Header element. On larger messages however the xenc:Encrypted data element can blow out the message size quite dramatically so you need to do the math and figure out where this sweet spot is for your particular message.

My question is – where do you apply meta-data to make this optimisation? It doesn’t feel right putting it on a DataContract – those should be somewhat abstracted from this transport level optimisation. So what about on a MessageContract? It is probably the right level in the abstraction to factor something like that in – but if you forced anyone to go any deeper it might be a case of a leaky abstraction.

Feature Request? Encrypting soap:Body fragments with WCF.

William Tay has come across a scenario which is supported in WSE 2.0 but not in WCF (Windows Communication Foundation). It has got to do with encrypting entire SOAP message bodies as opposed to individual elements within the payload. You should refer to William’s blog post for more background.

Unfortunately I can’t use Indigo at the moment with the build of Visual Studio 2005 that I am running to see if I can workaround the issue but I am going to assume there isn’t one – so this is more of a discussion of the pros and cons of supporting such a feature in WCF.

William doesn’t try to make a case for performance, but he does point out that only encrypting a portion of the soap:Body can reduce payload size. On smaller messages this optimisation would have less of a relative impact because the WS-Security headers that get placed in soap:Header element. On larger messages however the xenc:Encrypted data element can blow out the message size quite dramatically so you need to do the math and figure out where this sweet spot is for your particular message.

My question is – where do you apply meta-data to make this optimisation? It doesn’t feel right putting it on a DataContract – those should be somewhat abstracted from this transport level optimisation. So what about on a MessageContract? It is probably the right level in the abstraction to factor something like that in – but if you forced anyone to go any deeper it might be a case of a leaky abstraction.