Paolo's Notes

Voice 2.2 test

Pmarcucci — Sat, 24 Apr 2004 11:40:00 GMT

Third test from Voice 2.2

Free bug tracking offer

Pmarcucci — Sat, 31 Jan 2004 08:59:00 GMT

This is making the rounds...

Axosoft is offering bloggers a free 3-user version of their .NET & SQL based OnTime defect tracking software (bug tracking software). For more information, visit http://www.axosoft.com/Free3UserOffer.htm.

The fun is back

Pmarcucci — Thu, 29 Jan 2004 00:49:00 GMT

Well, I'm going on developing infrastructure code for NFFTI (yeah, I know. I'll post more gruesome details later) and I realized a simple fact:

I'm having fun.

It has been years since I had real fun coding, since Turbo Pascal 5.5 or the early Visual Basic 6 days. Java had never been "fun", just a tool I had to use for my job. And nobody in his clear mind would call PL/SQL a fun language or development environment...

But C# and Visual Studio and (most important) the incredible community around them is making the task of sitting down and pounding code a non-dreaded occupation anymore. I have some people to thank for this so, in perfect Academy Awards style, here they are in no particular order:

Jamie Cansdale, Peter Provost, John Bristowe, Eric J. Smith, Joshua Allen, Jason Moore, Dominic Pease, Kurt Mackey, Paul Hill, Peter Dampier and all the other people I don't know personally but are doing an great job of pushing forward with the community.

Oh, and thanks to Robert Scoble to bring most of these people at PDC03. That was mondo fun :)

[Now Playing: - Promised You A Miracle - Simple Minds]

WS POLICY SI TEH WIN!!111

Pmarcucci — Thu, 22 Jan 2004 13:40:00 GMT

In the comments on my previous post, John Bristowe gently offered his help to guide me across the Dead^H^H^H^H WSE 2.0 Marshes...

Fool! He didn't know what was expecting him! But in the end, he provided me with invaluable knowledge, tips and simply buckets of code big enough to drive into my thick skull a faint glimmer of comprehension about this whole new way to deal with web services.

So, what was my initial take, based on a cursory reading of the few web pages I was able to find? A procedural based, hardcoded approach to the authentication/signature/authorization/encryption problem. Plenty of code (to be tested) and lots of possible failure points. Plus, it wasn't really working anyways...

So John introduced me to the marvels of Policies. A declarative approach, how novel! Basically this removed all the ugly plumbing code from my web methods and put all the business knowledge about, say, authorization into a series of XML files that can be edited at runtime.

So, what about some samples? Sure thing! After having enabled WSE 2.0 on both Nfftiws (the web service) and Test Harness (the, duh, test harness), I modified Test Harness' app.config file thusly (sorry, I always wanted to use this word...):

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
    <section name="microsoft.web.services" type="Microsoft.Web.Services.Configuration.WebServicesConfiguration, Microsoft.Web.Services, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</configSections>
<microsoft.web.services>
    <policy>
      <send>
        <cache name="policyCache.xml" />
      </send>
    </policy>
</microsoft.web.services>
</configuration>

The section "microsoft.web.services" enables WSE 2.0 for this project and the element named the same way defines a send policy to be defined in the policyCache.xml file. That, by the way, is filled by these characters:

<?xml version="1.0" encoding="utf-8"?>
<policyDocument xmlns="http://schemas.microsoft.com/wse/2003/06/Policy">
<mappings xmlns:wse="http://schemas.microsoft.com/wse/2003/06/Policy">
    <mapDefault policy="#policy-b298142f-0c50-446b-8938-079b27891512" />
</mappings>
<policies xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">
    <wsp:Policy wsu:Id="policy-b298142f-0c50-446b-8938-079b27891512" xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy">
      <wsse:Integrity wsp:Usage="wsp:Required" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">
        <wsse:TokenInfo>
          <SecurityToken xmlns="http://schemas.xmlsoap.org/ws/2002/12/secext">
            <wsse:TokenType>wsse:UsernameToken</wsse:TokenType>
          </SecurityToken>
        </wsse:TokenInfo>
        <wsse:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()</wsse:MessageParts>
      </wsse:Integrity>
    </wsp:Policy>
</policies>
</policyDocument>

Pretty ugly, eh? Luckily this file was generated automatically by the same property dialog where you enable WSE 2.0, by going to the Policy tab and clicking on the Create/Edit... button in the Sending Side Policy Cache group. When the Wse Security Policy Editor dialog pops up, click on Add Policy, select "default" as the Service Location, select the Require Signature checkbox, enter UserNameToken as the token Type, leave all the other fields untouched and click Ok. The file policyCache will be created and dropped in the wrong place. You will have to manually copy it from the project top folder to bin/debug for the purpose of development. We'll see in later posts how to deal with deployment.

Ok, what have we achieved? Now we have a client application that knows how to speak WSE and will make sure to authenticate its method calls to the target web service.

Now we have to configure the web service... Again, enable WSE 2.0 for this project. Then modify web.config like this:

just after <configuration>, before <system.web>, add:

Just before </system.web> add:

Finally, after </system.web>, add:

<microsoft.web.services>
    <security>
      <securityTokenManager type="Nfftiws.SecurityPassword, Nfftiws" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext" qname="wsse:UsernameToken" />
    </security>
    <policy>
      <receive>
        <cache name="path to the project folder\NFFTIWS\bin\inboundPolicy.xml" />
      </receive>
    </policy>
</microsoft.web.services>

While the first two pieces of XML are basically boilerplate (I already feel the wrath of the More Competent Developers(tm) out there), the last fragment defines the method that implements the authentication (Nfftiws.SecurityPassword) and points to the file defining the authorization policy that will be applied on the incoming messages. But that's all for web.config, in the next post we'll see what's in inboundPolicy.xml.

WS-I thinghies

Pmarcucci — Thu, 22 Jan 2004 01:28:00 GMT

So we have Nfftiws (the web service that deals with Users). We can call the GetUser method by passing email and password and get all the user's info and...

Now wait a second. Passing email and password to a web service? Using SOAP? On the public internet?

You have to be quite brave to do that...

So, what can we do to avoid snooping, spoofing and general bad things happen to our web service? Luckily there's an industry-wide effort going on to attack these issues called WS-I. There are cross platform protocols for security, authentication, encryption, etc... Microsoft's implementation of these set of protocols is provided by WSE 2.0 (now in technical preview stage).

Once you download and install it, you have a new entry in the pop up menu that comes out when you right click on a project, where you can enable WSE and set a lot of other options.

There is a big downside. The documentation is... uhm... how can I say this in a nice way... lacking? :)

So I had to dig deep into Google and finally got a series of pages that, while none of them was complete, gave me a general idea on how to use WSE for my project...

Hashtables and Web Services and .NET. What's up with that?

Pmarcucci — Thu, 22 Jan 2004 00:55:00 GMT

The UserSet class was supposed to be implemented like this:

public class UserSet
{
    public NFFTI.User user;
    public NFFTI.GroupCollection groupCollection;
    public Hashtable propertyCollection;

    ....
}

propertyCollection being (quite obviously) a Hashtable member that the Web Service could access by using the name of the property (ex: string fakeID = us.propertyCollection["Fake ID"];). That makes sense, right? Except that Hashtable does not implement IXmlSerializable, thus rendering it useless as a member of a class that's supposed to be returned by a web service method call.

Uhm...

After a bit of discussion with my partners in crime, Dominic Pease and Jamie Cansdale, we found a sample SerializableHashtable class on Usenet that implements both Hastable and IXmlSerializable. That looked perfect and it worked, except for the fact that the unserialized member would come out as a DataSet, and not an Hashtable. I'm sure that it would be possible for a better developer than me to modify SerializableHashtable to output a proper type, but in the end I decided to modify the Reference.cs generated file in the Test Harness project by adding

using UserSet as NFFTI.UserSet;

at the beginning and commenting out the UserSet proxy class in this file. Contrary to popular (and my) belief, it worked fine and now I can access properties by name. The main drawback of this fix is that I have to reference the Business Object project from the Test Harness in order to know about the UserSet class. I'll gladly accept suggestions on how to avoid having to rely on this kludge :)

[Now Playing: Depeche Mode - Wild Boys]

NFFTI architecture and experiments

Pmarcucci — Thu, 22 Jan 2004 00:24:00 GMT

The NFFTI administration engine is composed by a set of web services that will be accessed by a web interface and a rich client application. To start experimenting with the overall architecture, I generated a series of Data Access classes (using CodeSmith with my OleDbDALC templates, not yet released) for some tables, namely Users, Groups, UserGroups (cross reference), PropertyTypes and UserProperties (another cross reference table). Once these were generated, I put them in a Data Access Layer project along with a Global class that will deal with the connection strings.

After verifying that all these classes were working fine, I created a Business Objects project where I dropped a UserSet class. This class will manage in a single entity user data, properties and the groups to which the user belongs.

These two projects are simply class libraries. To interface them to the outside world I had to create another project (Nfftiws). This is a ASP.NET Web Service project that, for the moment, implements a UserManager class that deals with login, logout and retrieving information about a user.

Test Harness is a Winforms project that will let me test Nfftiws' implementation.

And just to finish the day...

Pmarcucci — Fri, 16 Jan 2004 11:34:00 GMT

The mandatory (temporary) logo:

[Now Playing: Jamiroquai - Emergency On Planet Earth]

NFFTI

Pmarcucci — Fri, 16 Jan 2004 11:08:00 GMT

By the way, the engine upon which the two websites will be built is going to be called NFFTI. Yes, it's an acronym. No, you are not allowed to know what it means, yet :)

[Now Playing: Duran Duran - Hungry Like a Wolf]

New year, new impossible project

Pmarcucci — Fri, 16 Jan 2004 04:53:00 GMT

As usual, new year resolutions include -in some way or another- the nebulous objective of making more money. With the objective firm in my mind, I had to start thinking about a way to achieve it. I wouldn't mind getting rid of a chunk of my house mortgage and that requires some serious work to be done.

After a couple of seconds of consideration, I selected a couple of web projects I had completed three or four years ago and that were in dire need of some technological updates. I contacted the client about it and he sounded quite happy with my proposal, but nothing is yet decided, so I'm in the enviable position to start thinking about the solution without having too much pressure.

Neat, eh?

Anyways, the websites are marketing/community tools for a company that deals with the entertainment industry. They have to be able to post articles, stories and news, control the submission workflow, provide downloadables and discussion forums, event calendars, RSS feeds. They have to be able to move the sites easily between hosting companies (so, not too many dependencies on the underlying platforms, albeit I'm putting my foot down at mandating .NET).

In the following posts I'm going to detail my design process and hope someone will chime in with helpful suggestions. See ya.