NSilverBullet

Complex solutions for simple problems.

Jim Webber: "Business people are spaghettiheads!"


Thursday 29 May, 2008 (Architecture | Interviews | SOA)

This is a guest post by Herbjörn Wilhelmsen @ Objectware

After working for years with business people and SOA Jim Webber has come around to thinking that fighting against real world complexity is neither successful nor valuable.

Jim Webber handling spaghetti?

Dr Jim "World Wide" Webber - an author as well as global architecture lead for Thoughtworks - gave an interview last month after finishing his "Guerilla SOA" presentation at the Developer Summit 2008 conference in Stockholm.

Watch the interview to see Jim Webber

  • Say that business people are spaghettiheads, tell us why business people scare him and that business people should be the architects of our projects!
  • Come down hard on message oriented middleware (ESB’s) and WSDL
  • Give his definition of a what a service should be
  • Talk about why MEST and SSDL makes for better SOA
  • Describe how MEST and SSDL helps you handle versioning problems in an SOA
  • Talk about his next big thing: Middleware! (despite his grudge for ESB’s)

Jim does a great job - he explains things that seem contradictory in a very smooth and straightforward way and in the end you just can't help yourself: You have to like him!

Thanks for the interview Jim!

I also want to thank my colleague Joshua Anthony (the owner of this blog) for standing behind the camera and doing a lot of post production work!

Update:
During the interview Jim talked about the SOYA project and a case study. Here are some links:

  • SOYA @ sourceforge
  • A description of the LIXI case study can be found inside Patric Fornasier’s master thesis

Comments [1]


Why NSilverBullet?


Tuesday 20 May, 2008 (About | Blogging)

I have been meaning to write a post on why I chose the name NSilverBullet and the subtitle "Complex solutions for simple problems." ever since I created this blog back in 2005. I have just never got round to it. After getting a couple of questions from my co-workers at Objectware I felt that I really should try to write something about it.

The name NSilverBullet was taken from a forum post on O/R mapping frameworks that I read where someone had written that O/R mapping wouldn't solve every problem that we as developers run into and that it would be great if someone could develop something for .Net developers that would. Their ironic proposal was that a silver bullet framework for .Net should be developed - NSilverBullet. As most .Net developers know open source frameworks and tools for .Net are often prefixed with N to distinguish them from their Java counterparts: NUnit, NHibernate and so on. I found the idea rather fun and had it rolling around in my mind for a couple of months before I did anything about it. When I decided to try my hand at blogging the title nSilverBullet was geeky enough for me to find amusing and at the same time I felt it captured the topic of what I was planning to write about - problems that I or others have run into while developing .Net solutions and how to solve them.

The subtitle is obviously based on all developers aspirations to find really simple (and elegant) solutions to complex problems. Often times we find ourselves in situations were something that ought to be simple and easy turns out to need an overly complex solution - complex solutions for simple problems!

Comments [0]


Java Web Service Client problems


Thursday 15 May, 2008 (.Net | Bugs | Java | Web)

I have been having some trouble lately trying to debug a .Net web service that I have constructed for a proof of concept. The scenario is that we have a Java application that calls a web service and the web service passes the call on to BizTalk for processing. Not a terribly complex scenario so I wasn't expecting much trouble setting up the POC. Unfortunately we have experienced  some really strange problems. Calling the web service from a .Net client works without problems but when the exact same SoapEnvelope is used in the Java client through a proxy we get a "HTTP/1.1 400 Bad Request" error!

How is this possible? Well after much trial and error, searching the net and generally scratching my head I finally found a clue to the root cause of the error. One of the scenarios when "400 Bad Request" is returned is if the value of the content-length header is smaller then the actual length of the message body. I could not find a simple way to get IIS 6 to log the actual HTTP headers which were received and my favourite HTTP debugger Fiddler couldn't be used when the calls came from the Java client so it was very difficult to verify. The WSE input tracing showed a correct request and the application log contained the following unhelpful message

Process information: 
    Process ID: 5856 
    Process name: w3wp.exe 
    Account name: AD\serviceaccount 
 
Exception information: 
    Exception type: HttpException 
    Exception message: Server cannot clear headers after HTTP headers have been sent. 

I managed to get a nice raw HTTP dump sent to the application log by adding the following to my Global.asax

void Application_BeginRequest(object sender, EventArgs e)
{
	//save position for reset
	long position = HttpContext.Current.Request.InputStream.Position;
	string requestBody = new StreamReader(HttpContext.Current.Request.InputStream).ReadToEnd();
	//reset the position
	HttpContext.Current.Request.InputStream.Position = position;
	EventLog.WriteEntry("Service HTTP Dump", Server.UrlDecode(Context.Request.Headers.ToString()).Replace("&", Environment.NewLine) + Environment.NewLine + requestBody);
}

Using this I could verify that it was in fact an incorrect content-length in the HTTP header which was causing the problem. Using Notepad++ and Fiddler I could see that the actual content-length was 634 using CRLF and 631 using only CR. The Java client was specifying 631 but the .Net web service was actually receiving 634. With the help of Telnet I could send in a call with 631 characters and CR as line-end and verify that the .Net web service handled the request properly. For the sake of clarity this is a sample Java HTTP header:

POST /path/service.asmx HTTP/1.1
Host: servername:80
Cache-Control: no-cache
Connection: close
Pragma: no-cache
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.1
SOAPAction: "http://schemas.example.com/2008/04/22/Service:ValidateRequest"
Content-Length: 631

The same request from a .Net client:

POST /path/service.asmx HTTP/1.1
Host: servername:80
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.1433)
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://schemas.example.com/2008/04/22/Service:ValidateRequest"
Content-Length: 634
Expect: 100-continue

Both requests had a length of 634.

More info on the exact nature and calculation of the HTTP headers are in the RFC and in section 3.7.1 of the RFC valid line endings for the message body are defined. Basically it says that CR, LF or CRLF should be valid as long as they are used consistently but CRLF should still be treated as two characters for content-length (the spec doesn't explicitly say that but I presume that it is required). So the .Net web service has a correct behaviour, the specification also says that content-length may be omitted in HTTP 1.1 although it should be honoured if it is specified. Since it is required in 1.0 and it is usually very easy to calculate it isn't something that you usually have to think about trying to omit and it is hidden in the web calling infrastructure of Java and .Net.

I am not sure where our error is introduced. It could be when the original message is constructed in Java, whatever library is used to calculate the content-length could do so incorrectly (not likely). A more probable source is that the message is constructed with correct line-ends in the body (CR or LF) but that the intermediary proxy recodes the call with new line-ends (CRLF) without updating the content-length.

How can we fix it? I believe that there are three possible solutions for the problem (we haven't solved it yet).

  1. Remove the proxy, should be the easiest but due to the network configuration that isn't possible at the moment.
  2. Change the way that the Java client creates it's content so that it uses CRLF by default thereby forcing a correct larger content-length.
  3. Use the Application_BeginRequest method in Global.asax or an HTTPHandler to somehow rewrite the input stream or recalculate the content-length. At the moment I am not sure that either is possible.

Update

We managed to remove the proxy (which was actually part of a VPN connection) and our troubles disappeared.

Comments [0]


New Theme for dasBlog - now with Google Search


Wednesday 14 May, 2008 (Blogging | dasBlog | Web)

I have created a new theme for my blog, I feel that this theme is more modern and has a lighter feel to it. I based the theme on an open source / free web template named Multiflex. It is available from www.1234.info this theme is based on Multiflex version 5.4. It took a lot more time to convert the web template into a dasBlog theme than I had figured on - partly because i also changed the page width of Multiflex which meant that I had to redo all the border images and partly due to Multiflex being gray only and I had to go through all the CSS to restyle the entire template! I am pretty pleased with the end result at the moment, although I am sure there are a couple of glitches that will need to be ironed out. One thing that irritated me with dasBlog and theme modifications is that it doesn't seem to be possible to change how certain parts are rendered for example post comments and related links. A lot of the content gets put in tables and modern design doesn't use tables but advanced CSS for positioning and flow control.

I can whole-heartedly recommend Multiflex to anyone who wants to create web pages but, like me, is not super gifted in the arts department! The template is well documented, there is a content toolkit for building your page structure and the CSS was easy to understand and modify. I found it at www.openwebdesign.org there is also a Color Contest there which I will check in on in the future to see how my color scheme compares to others. I used a flash-based tool from www.colorsontheweb.com to create a pleasant color scheme, it was a great help since I am not that good at picking out matching colors.

One major addition in this theme for my site is the Google search box in the top right-hand corner. Originally I tried to just add the Google search code in my old theme but since the Google code contains a <form> element it conflicts with the predefined form in dasBlog/ASP.Net. I solved it by placing the Google form in a separate html file and just including that file as an iframe.

Comments [0]


Messing about with dasBlog templates


Wednesday 30 April, 2008 (Blogging | dasBlog)

I am thinking about doing a complete graphic do-over of this blog due to the home and item templates being pretty messed up after all my editing and experimenting with them over the last couple of years. While I was going over some of the macros that you can use I found a nice little page with most (if not all) of the dasBlog macros described including syntax, screenshots and which version they are available from. It takes a lot of the guessing out of using the built in functionality.
http://www.jforsythe.com/jforsythe/projects/dasBlogMacros.html

I also found a customisation category at dasblog.info where you can find information about how customisation of the templates and themes works: http://dasblog.info/CategoryView,category,Customization.aspx

I have also switched the rss feed over to feedburner so that I can get some proper rss statistics.

Comments [0]