WCF was designed with a lot of options for you to tweak so your services run the way you need them to.  This flexibility is probably my favorite feature of WCF because you have a lot of power to choose things like instancing mode, transactional support, and so on.  The drawback is "discovering" how these things work together.

I have a transactional queued service that needs to behave like a singleton.  This service holds onto a resource that must always be available and there should not be many instances of it running (it's a TCP socket listener so I don't want a new one for every message I process).  During testing I discovered that though I had the InstanceContextMode set to Single WCF was still creating a new instance for each message received.  After some research I decided to tweak a few knobs starting with ReleaseServiceInstanceOnTransactionComplete.

While that name is probably longer than what Mcconnell might suggest it sure does make it clear what behavior to expect.  The property is a boolean but I went ahead and set it specifically to false and voilà, problem solved.  My service now behaves as a singleton.  For good measure I also set the ConcurrencyMode to Multiple to ensure that my service can be accessed by multiple threads.  Because I'm doing a lot of asynchronous work it will perform better under these settings.

School was never really my favorite activity so the idea of taking tests and getting certifications wasn't totally appealing although I think in these days they are definitely necessary.

Three of my fellow co-workers and myself attended two days of sessions for the Justice Information Exchange Model (JIEM) certification.  The methodology and tool were not difficult to learn and the exam was a little tricky; not hard, just a little tricky.  It is definitely exciting to have some extra credentials especially as it applies directly to work I do everyday.

A big benefit of sending four of us is that we've all been exposed to this same methodology and tool which brings new perspective on how to apply it.

Congratulations to the three (if you had blogs I'd link you...) who passed!

Registration for the St Louis Day of .NET started last week.  The organizers have put together a great web site that has all the info you'll need for the conference.  Cost is $40 if you register before December 1st ($50 after that) and includes a conference polo shirt, 1g USB drive containing all conference presentations, projects, and other materials, full continental breakfast, and a boxed lunch.

I will be delivering the presentation "A Lap Around Oslo".  Drop in for that session if you're at the conference.  Mention this blog and you'll get a surprised look that you actually read it!

The full conference details will be coming soon so you can look forward to a full day of .NET presentations and demos on December 13.  I will be delivering the session "A Lap Around Oslo" covering Microsoft's forthcoming "Oslo" product; a new modeling platform that will change how applications are developed.  It will be my first speaking engagement since the Internet Librarian Conference in 2006 and I'm really looking forward to it.  Many kudos to Clint for hooking me up with the opportunity.

As soon as the site is completed I'll post up the link so you can get registered.  There will be at least 19 sessions with plenty of content to suit any .NET developer!

When you lead from the front you often have to be the jack of all trades.  You got there because you were the best you could be at all the other jobs that make up what you do.  Your coworkers come to you for guidance.  Managers look to you for your opinion.  You end up going to meetings one and two levels above your pay grade.  Most of the time tackling tasks yourself seems faster than explaining it to someone and setting them on their way (which would require you to monitor their progress as well).

All this adds up to you not getting the real work done.  You spend your days filtering questions, going to meetings, and tackling issues you shouldn't be worried about; all the while your to-do list grows and nothing is being crossed off.

This is when it's time to let go.  Time to shed.  Shedding will likely involve delegating something you really wanted to work on but you have to be honest with yourself: It's just not possible to do it all.  It may also involve casting something off as unimportant.  Both are tough calls to make but in the end it will be necessary.

Forget about those things that are truly marginal.  Do the stuff that only you can do and can do best.  Let someone else do something that you don't have time to be doing.  They might be good at it too.

I never fully understood the true value of mindset until after I survived two rounds fighting cancer in my early 20s.  I spent a lot of time studying martial arts in my younger years and as I got older I studied military tactics down to the individual soldier level.  Tying all those together it became clear to me that in order to make it through the hard times you have to have the mindset that will get you there. 

As a child of the 1980s I grew up with a movie that teaches you more about mindset in three words than these few paragraphs will.  My close friend Frank recently unleashed his graphic artist skills pulling a quote from one of my favorite movies from the 1980s.

Head over to his site and download this wallpaper.  It will serve as a gentle reminder to stand by your principles and to never, never give up.  So put this on your desktop to let your boss know that you won't be backing down anytime soon.

I recently ran into a situation where the WSDL was altered to allow for xs:any in part of the expected SOAP body for a WCF service I am implementing in support of the project.  I have handled this situation before in WSE 3.0 and ASMX web services and was anxious to find out how WCF would handle it. 

When working with large XML models such as the National Information Exchange Model (NIEM) it is becoming common to use xs:any for parts of messages because the schemas that support the message structure are too complex to include in the WSDL.  For the large data sharing projects I work on at the state and federal level this is pretty much the standard.  Just about everyone has a "Payload" element that is of type xs:any.

With WSE 3.0 and ASMX web services .NET would convert the xs:any part of the SOAP body to a System.Array containing a single item of type System.Xml.XmlText.  I was only able to discover this because I was provided a Java based client to send requests to our service so that I could debug and see what types were coming across.  Somehow when I sent the same requests from .NET the xs:any was interpreted as a System.String and I did not have to do any further work to get the data I needed from that part of the message.

When I learned I would be in that same situation with WCF I started searching to find any documentation on what might possibly happen.  To my dismay I could not locate any via searches on MSDN, Google, etc. 

I ran some tests using a .NET WCF client and used message tracing to capture the raw soap message.  Upon inspection I noticed that the .NET client was appending xsi:type="xsd:string" on the element that was of type xs:any per the WSDL.  Also the first item in that tag was the XML declaration tag.  When my WCF service received that request it treated that element as a string and capture the raw string XML.

After searching I decided to use SoapUI to run the tests.  I installed SoapUI and began a test project.  I took the raw SOAP message captured in my .NET test and pasted that into the body of the test data window in SoapUI.  While testing I discovered that in SoapUI you need to remove the <soap:Header> element if one is included in the trace data you are using (it was causing errors with the ws-addressing headers).  Once I did that I was able to get some messages to hit the service. 

Test cases:

Soap Body included: <Payload xsi:type="xsd:string"><?xml version="1.0" encoding="UTF-8"?> ... xml content ...</Payload>
Result: InvalidOperationException - Error in XML document at Line {N} Position {N}

Soap Body included: <Payload xsi:type="xsd:string"> ... xml content ...</Payload>
Result: InvalidOperationException - Error in XML document at Line {N} Position {N}

Soap Body included: <Payload> ... xml content ...</Payload>
Result: Payload property on incoming message received as a System.Array containing one item that was of type System.Xml.XmlElement

What I found was very interesting was that when I used the exact trace output from the message created by my .NET client it received an exception when I sent it with SoapUI.  I tried a few variations of escaping characters to no avail.  There must be some type of escaping that .NET does in order to facilitate sending the xs:any portion of the message as a string, I just couldn't guess them.

I'm still curious as to how the .NET WCF Client is encoding the content in the xs:any element to get it to pass those deserialization checks.  If anyone has any thoughts, leave me a comment.

In my opinion the principles driving service oriented architecture are a great evolution of software design.  I have been working to apply many of those principles in work we are doing to update our core offerings as services.  While the principles are widely published I wanted to add some of my own value to them from recent experience and reflection.

Services should enable business processes. If process can't be completed "on paper" or no one understands it exposing it as a service may not be successful.  Services should expose that business process in a meaningful way that replicates the paper process as closely as possible.

Services aid in loose coupling between systems.  By exposing services with standard contracts that represent their messages in a canonical format you reduce coupling between systems.  The schemas and WSDL become the contract by which clients and the service communicate.  As long as that contract is not violated the service can do whatever is necessary to fill requests.  Changes to data stores or processes should have no impact on those contracts.

Services exchange messages. I have seen several services which were passing encrypted byte arrays that were strings which were cast into a byte array, encrypted, and serialized  by the service then deserialized, decrypted, and cast into a string and transformed to an XML document on the receiving end.  While this offers security through obscurity it violates other principles including meta data exchange and contract first design which uses that meta data so all clients know what messages to expect.  Services should use messages that are exposed in a canonical format via schemas and WSDL's (for web services).

Messages should contain all the elements required to complete the business process.  This is a great principle I found via Nicholas Allen's Indigo Blog in a white paper published by Ythos.  This will allow you the most flexibility in situations where that message will be routed to several services to fulfill the business process.  In a real world context I can think of few, if any, processes where you fill out multiple parts of a form and send it to different entities for processing.  The form contains all the data needed and you send to one place and are not concerned if it needs to be routed to several locations to complete your request.

If systems need data from each other they should ask for it.  This is one of my favorite principles gleaned from Clint Edmonson.  The simplicity of this principle is also its source of elegance.  A good service offers meaningful ways for clients to request the data that service knows about.  The requests should require minimal amounts of "state" or "context" and be flexible to allow for data to be requested multiple times if one attempt fails.

Exposing processes as services lets you focus on the process and build several different UI's to consume those services.  I have not yet reached a point where this is a reality at my employer but we are very close to getting there.  As you build more services and more processes are enabled in standard ways you can begin to design different types of UI's to interact with those services.  Do you have a core service exposed as a web service using SOAP but are concerned that is too much lifting for your AJAX clients?  No problem, expose a wrapper service that uses REST and a lighter message format and have that translate to your internal web service.  This keeps your functionality in a central location but has the flexibility to meet special needs for clients.

These are some practical things I and others have been working to apply with great success.  A key to building an SOA from the ground up is to start with simple services and keep them simple.  The trick is to keep an eye to the future and be sure your services will be governable and promote reuse of data models, etc.  While a ground up approach is not always the best in some situations that is where the call to services needs to begin.  Good architects will be looking out for what will better align IT with the business, add value to the processes, and save on costs due to a more maintainable infrastructure.

Back in January I made a crucial mistake.  I asked for work.  I asked for a lot of work.  I didn't get it in January but eventually I did.  Last week it looked like my random vacation week was about to get canceled; fortunately it did not.  I'm now sitting in my pajamas while my wife is rocking out with Guitar Hero III and I'm trying to get back some of the energy I had when I asked for all that work.

I have a lot of energy and I'm willing to devote it to my employer and to go above and beyond what is necessary.  I do that when I have that energy available and when I believe what we are doing is the "right" thing.  Apparently I'm not alone in this.  Discretionary Energy is a hot topic in leadership and organizational development. 

Not that it's anything new.  Militaries have used this throughout history.  How else could you get someone to go to their potential death for little or no pay and without other methods of coercion?

Last week we had a reconnect session with the RLF and LLF graduates at REJIS.  Dick Dooley was there and we got about an hour worth of verbal 'beating' from him (more like gentle reminders of the things we need to be doing).  We talked a lot about discretionary energy because every organization needs it and needs its employees to devote some level of it to get the real work done. 

The title of this post comes from one of Dick's sayings which really clicked with me.  I think it's very true and has real meaning to all of us.

Keep practicing hard because the real work happens next year and it won't be any easier.

I saw this meme floating around the development community and thought it was a fun one.  Clint Edmonson has called me on it so I'm going to give it a shot.

How old were you when you started programming?

My first experience with programming was on the Atari XE.  I was around 8 or 9 when my dad and I went through the manual and followed the line by line instructions to build a program that displayed an American flag waving in the wind.  I learned a lot about the Basic language and it kind of stuck with me.  I didn't do much programming after that unless you count the magic of format C: in Dos 6.  Most of my computer experience during my teens was on the fix broken ones side.

What languages have you used since you started programming?

I haven't strayed far from languages who have a lineage with basic.  In college I started as a Computer Science major but I did not like the prospect of intensive math.  I was exposed to C++ there which I enjoyed but was looking at switching to Management Information Systems.  If you've read my bio then you'll know during those college years I had a battle with cancer a few times that took me on some interesting paths.  When it all settled I went back for my MIS degree where I spent time with VB 6, VB.NET, and SQL.  I've also touched on PHP, Java Script, and even Java (which I now respect a lot more than I did a few years back).

What was your first professional programming gig?

My first gig probably isn't as interesting as the path that got me there.  When I worked for Lewis & Clark Library System I started as a PC technician.  Most of my IT background through college was working for Internet providers and a few LAN gaming centers.  At LCLS they had a lot of IT needs and I had a lot of jobs I could do.  I bounced from a traveling PC tech to a server admin, security guy, and also the web master.  After getting through my battle with cancer I had an opportunity to choose a path.  We wanted to make our web site dynamic so I dove right in and started with ASP (we had Microsoft servers) and MS Access database on the back end.  From there my journey into development really took off.  I became the full time web master and eventually changed the title to Internet Application Developer.

If you knew then what you know now, would you have started programming?

I would have started sooner and studied more languages.  I've been pretty vertical in my language market and would have liked to have been more multilingual.  I would have also studied object oriented a lot more thoroughly to fully understand the concepts that drive it.

If there is one thing you learned along the way that you would tell new developers, what would it be?

Study development outside the context of a language if possible.  I have been struggling to unhinge myself from language centric development into the broader realm of software design outside of a specific language.  This is difficult to do when you're grounded in a language.

What's the most fun you've ever had ... programming?

Those first experiences where you spend minutes or hours typing away and then tell the program to run and watch it work are the best.  Once you get past that programming is still a lot of fun but the challenges change and so do the motivations.  That feeling of watching it work is always there and I think that is the big draw for me.  Programming is a lot like art.  Prior to my development life I spent a lot of time writing and drawing.  I don't do as much of that with pen and paper, but I'd like to think of my development as an art form and it's satisfying to see your work out in the field helping people do their job.

Who am I Calling Out?

The people I want to call out do not blog (that I know of).  Which is too bad.  I don't want to end this meme but sadly I have to for now.