The Geek Blog

I spent a good 50+ hours on trying to consume a Microsoft WCF secure web service with a Java solution.  I tried Spring Web Services, Axis2, and looked at Metro/Tango and decided Axis2 was the “easiest” solution.  The web service I’m connecting to implements WS-Security, WS-SecureConversation, WS-Policy, WS-Trust and WS-Addressing (at least) and it’s provided through a .NET 3.5 WCF endpoint.

It doesn’t work.

Axis2 can’t handle SpNego which is a WCF closed protocol allowing two WCF machines to negotiate the credentials between them.  The client has spent way too much money paying me to continue to figure out a Java solution, so I wrote a .NET 3.5 C# client.  Took me literally five lines of code and it’s working.  That’s great for .NET developers but a whole lotta horse shit for the rest of the world.  I’m hoping Axis2’s Rampart module is updated to play nice with WS-SecureConversation and a .NET WCF web service.  Until then, I’m using the .NET client to download the data and I’m storing the SOAP body into a database table.  On the Java side, I’m still using JAXB2 to unmarshall the data into Java objects and process it through our existing persistence framework.

Go me!

After spending a significant amount of time this week on writing JUnit tests for a Spring Web app, I’ve come to a conclusion.  College courses, even in the grad classes I am taking don’t spend enough time on the concepts behind unit tests.  Granted JUnit and NUnit has been covered in the classes I’ve had but really only the testing framework is discussed.

Test-driven development (TDD) teaches us how to write a test first, make it fail, stub out your methods, and then code until your test passes.  The practicality of TDD in the real world is limited because a requirement is to have your system well designed up front.  Getting to a point where you’ll know method names ahead of time means you’ve spent a significant amount of time thinking about the design and analyzing that design. 

We all know that is rarely the case.

There needs to be a course on the concepts that we need to keep in mind when designing a system so it can be tested later.  What kind of concepts?  Understanding exactly what you shouldn’t do to make tests difficult – limited coupling and high cohesion.  I started to get a better idea of those concerns when I took a training course on the Spring Framework.  Spring lets you use plain old Java beans for most of your core controllers which lets you test the functionality of the controller and not have to test the framework.  Keeping those concepts in mind during your development will help out later.

In this last semester I took a software engineering course.  In one of the lessons, a simple rule came up that I felt was totally appropriate for this theoretical Unit Testing course.  Any methods you create should only take the exact type of arguments you’ll use in that method.  If the method calculates a pay increase for an employee, the method should take float for the current pay and a float for the percentage increase.  Creating a method signature with an Employee object and something like an AnnualReview object doesn’t define the method, it only confuses the developer.  How can you write a JUnit when you don’t know what the method is going to use?

So that’s enough of my rant for now.  I think I’ve written more in this post than I did for my final paper in the class.  Ha!

So I spent most of the past few months learning the bleeding edge of the Spring Framework, 2.5.x.  The training I went to covered this version, the books I had covered the same.  My first assignment?  Using Spring 2.0 and Web Flow 1.  Talk about crushed.  Now I have to unlearn everything and go back to a previous version.  This happens a lot, from what I’ve seen.  Companies aren’t willing to upgrade because of fear of stuff breaking; but they’ll write shit loads of work-around code to keep old solutions working.  That eventually bites them in the ass when the product they’re on goes off support and they’re forced to do a huge conversion.

Fun stuff.