Holy moly! That was hard work. I have never spent any time with the blogging APIs (blogger and metaweblog) and needed to at least push a post out from BLInk!. I wanted to make sure I could do this against dasBlog and dotText (from which so many blog sites are now derived). With help from :

• The Blogger boys’ (hey where’d the picture go???)  blogger api
• Dave Winer’s metaweblog api
• CookComputing’s xml-rpc.net
• sample code from Charles Cook for using the blogging functions with his dll
• some help from Scott Watermasysk on using the metaweblog functions to post to dotText from his work on Blogert

I was able to scrap together some functioning code (in C# no less!!!!!) to successfully post test posts to both my dasBlog blog and my dotText blog.

Now I have to take those tests, tighten them up (eg: passwords, urls, etc are currently hardcoded) and wrap them into BLInk!.

My intention is not to build a full-fledged blogging tool (get posts, edit posts, etc) because the real purpose was to work out some concepts for blogging with ink. But I think pushing up a post that is created in ink is pretty necessary. From there, the user can go into there regular interface to edit, etc.

Just got word that I will be speaking at DevTeach again in 2004 (Montreal, June 19-22). This is a great conference and Rob Howard and Scott Guthrie will be doing the keynote. It is only a 2 hour drive from home, so I like that a lot too. Montreal is beautiful. The conference is very inexpensive even before you convert to US$ and it is partially over the weekend so that it doesn’t conflict with work. Definitely check this one out!

I will be doing the “What’s new in Whidbey Base Class Library” talk that I am slated to do in February in Boston at EdgeEast 2004 as well as a talk on tablet pc development. The tablet talk will not be about how to manipulate ink, but about the many design and implementation considerations that need to be taken into account that are very different than anything we have done before. I have been through this process in working with a corporate data entry application that will be used on Tablets. YOu can find a lot of posts about that here as well as a really nice summary of them by Peter Rysavy (TabulaPC) here.

I must pass along this post by Don Kiely on a new book that Kathleen Dollard has just completed  for APress! – Code Generation in Microsoft .NET.

Don says, “I guarantee that this will be the hardest book you read in 2004, but also that it will be the single most important book for making you as productive as you can be as a .NET or SQL Server programmer.”

Don and Kathleen are both people who I absolutely listen to when it comes to programming. Read more here…

I also want to share Kathleen’s bio for those of you who may not be familiar wtih her – which means you don’t read Visual Studio Magazine – where she has a gazillion articles! Kathleen is also speaking at Visual Studio Connections in April.  I am always astonished when people say “Kathleen Who?“

Kathleen Dollard has been involved in the computer industry for a long time. She started (she claims) by experimenting with programming in junior high. After graduate work, she worked with the computer group at Texaco Research writing Fortran, and helped usher in the age of PCs doing Lotus 123 macros. After working with 4GLs and Clipper, Dollard became an Independent Consultant, ultimately moving to Visual Basic when it became clear that Computer Associates would not release the Windows version of Clipper.

Dollard is well-known for her participation over the last 15 years with on-line communities, including BBSs, Compuserve, Fawcette, DevX, and Microsoft public newsgroups. She has been recognized in some form for her online work since 1994 and a Microsoft MVP since 1998. Dollard is also active in the real world communities of user groups – most recently with the Denver Visual Studio User Group and the Northern Colorado .NET SIG startup. A well-known writer and speaker, she is currently doing pioneering work in code generation using .NET and XSLT.

I just had a thought about what I was working on yesterday with encrypting data that is passed back to a client in a SOAP response. I was using examples from two sources. In those samples, there was a key created in the webservice for encrypting. That same key was added into the client app in order to unlock the encrypted data. I used the sample “to a T”, including the example key. If I didn’t change it, that means that anyone who read the article could create a client that uses the same key and have access to my data. Not really, because the web service also requires authentication… but you get the point, right? It’s kind of like the www.tempuri.com problem. Many people don’t change that “placeholder” URI and leave the possibility (very slight as it may be) that someone accessing two separate web services with functions of the same name and the same namespace (”www.tempuri.com”) will have a definite conflict.

Anyway, time to go change my keys!

ahh – another lost post – why oh why?

ok here’s the short version… I just spent all day working with SOAP and encryption and xmldocuments. Don Box just wrote a post that addresses a misconception that I had when working on my solution today. “What caught my attention was the implication that there are somehow two classes of XML – documents and something else.” Because I was dealing with SOAP I thought I had to send a “real” xmldocument, not whatever xml is created magically when you send a dataset from a webservice. So I converted my dataset to an xmldocument object, sent that back to my client then took the resulting xmlNode, converted back to an xmldoc and then back to a dataset.

Another thing I wanted to point out about his post was that it addressed my little nit with the fact that the xmldoc is transformed into an xmlNode somewhere in the pipe. In his post, Don says that “it’s exceedingly tricky for a SOAP envelope to contain an XML Document due to the problems of embedding XML inside of XML (embedded DOCTYPE, ID collisions, non-nesting CDATA sections, etc.).” OK, I can live with the transformation! 

So, if you have missed his post, definitely read it if you are not 100% solid on SOAP and would like some clarity. 

(add: as per this and this, I modified my webservice to return a plain old dataset in the encrypted soap header – as I would for any other dataset returned by a web service – rather than turning it into an xmldocument first. Actually, also check out this from Sean Wildermuth, which is what convinced me over a year ago that it is a-o-k to return datasets from webservices)

Well! That was educational!

I now have a web service that grabs a dataset of super-secret information from sql server, converts it to an xmldocument and returns it to my client as the body of an encypted Soap message. It’s possible to encrypt different pieces of the soap message. And I had to deal with that p.i.a. transformation of an xmldoc to an xmlnode on it’s way through the pipe. But at least I remembered that from the last time I encountered it!

My smart client retrieves this encrypted message (thanks to the last key of remembering to modify the web service proxy by replacing
Inherits System.Web.Services.Protocols.SoapHttpClientProtocol
with
Inherits Microsoft.Web.Services.WebServicesClientProtocol)

I was able to pull this part off with both Bill’s book and Jeannine’s article (see previous blog for details) close at hand.

Once I had the data safely in my client’s clutches I still had another task which was to persist the data for off-line use. Of course, if the data is sensitive enough to need to encrypt it on the way through the pipe, I didn’t want to just create a little xml file that could be opened up in notepad! So I used a System.Security.CryptoStream (and a little help from this article) to encrypt the data, yet again, along with WriteXML to persist the data. The application that needs the data offline then got a reverse engineering job to do a dataset readxml and decrypt the data.

Phew! I am whooped. Now on to WSE2 where I have been promised I’ll be hitting my head wondering why I wasted all of that time with this WSE solution. Though the true answer is that I needed to use it in production and the WSE2 tech preview is not licensed for production use. That’s why.

Inspired by Rory Blyth’s post on what .NET techonology we fear the most (hands down for me, it’s WSE) and a need to return login data from a web service in a secure manner, I am about to finally (finally!) use WSE. I have just installed WSE1 SP1 SDK on my dev machine and the runtime on my webserver. (add: and the WSE Settings Tool!!)

I have at my disposal Bill Evjen’s Web Service Enhancements book and this MSDN article (Encrypting SOAP Messages Using Web Services Enhancements) by Jeannine Hall Gailey.

My plan to grab the data via a dataset, writexml to an xmldoc and then send the xmldoc back to the client inside an encrypte soap body. (BTW – I am not looking for instruction, correction, hints, etc – I want to do this myself!!)

I am a perfect guinea pig for WSE. I even concede: the person who they are writing Indigo for. Once I get past this, then I can confidently say “if *I* can do it, anyone can!”.

P.S.  I’m well aware that WSE2 is right around the corner and I’m SOSOSO far behind with this but WSE2 is not for production. So I’ll cust my teeth on with WSE1 and then look at the tech preview of 2.