ASP.NET, C#, Search

Lucene Wrapper Project

Chapter One: Life Before Lucene

A large part of the Objectify CMS (well any good CMS) is it’s search capabilities. This is compounded by the fact that the Objectify CMS includes a powerful Knowledge Management System (KMS) component as well.

A few years ago I wrote my first ever search engine… it was a powerful, full text indexing, stemming, soundexing (sic) fully custom built indexing system for use with the Objectify CMS and KMS. It worked a treat, was fast, worked with the CMS’s HTML content and its XML based Knowledge Base content… but it had a few flaws. It’s query syntax was limited, it was complex and hard to maintain – and it didn’t scale over about 10,000 records (paltry??)… the memory requirements started scaling with it.

Building this search engine was a long a arduous task, with my gotchas, pitfalls and hurdles along the way. Performance and scalability where perhaps the largest and most difficult issue to deal with (err… sounds like any IT project to me – ed). Long story short the system worked well, but the time came to add a raft of new features and address the scalability concerns. The query syntax needed a few tweaks also.

Chapter Two: My new love – Lucene

Oh Lucene how I love thee. The decision was hard, but I decided it would be best to fully re-write the search engine in Lucene – boy am I glad I did.

Chapter Three: The first date

It took me a while to sort out the best way to manage documents in Lucene, all the options, the patterns and practices, and how to integrate it into the Objectify CMS and KMS products.

Basically, Lucene is built to be really generic – it can work in just about any situation you need a search, from Windows forms applications, web applications, services you name it. And it can scale… and scale and scale… 13 million records on a moderately equipped machine is nothing to Lucene… and it can handle multiple gigabyte indexes with ease. Long story short it’s a set of search engine base classes, certainly not a fully fledged search engine – it’s up to the developer to implement all the features… which is probably why you are reading this – you want full control.

Chapter Four: Third base

With all this in mind, I thought I would put together a little class library that you can use to create and search with. It’s really quite simple… just grab the code, grab Lucene.NET and build away!

My aim with this two project is to hit one of two goals:

1) You take this project and use it in your own projects with none/little change and it helps out immensely with your project deadlines

2) You take this project, pull it apart and learn all about how to implement Lucene.NET by example – cutting down the time it takes to get your own test projects up and running.

Chapter Five: How to use this project

Using this project is quite straight forward. Look in the lJak Tests project for a test class which should have all the information you require.

Lucene.NET and other search engines work great with TDD (Test Driven Development) so use the tests to your advantage as you develop – it will save you piles of time.

The basics are:

1. Choose an ID for your document. Something like the file name of the source page, a GUID or the ID of the piece of content from your database. You will use this ID later to refer back to the original document from the search results.

2. Split up your document/parse into logical blocks. You may want to split a HTML page into areas like Title, Heading, and each P/DIV tag or something. That way the end user could search on just title, or just body etc.

3. Parse apart the content. This code does not include a parser. So, you have to break the content up yourself. It would be a good idea to strip out HTML etc also. For the CMS/KMS products I wrote a parser that takes the content XML and breaks it up based on tag name, id and whether it’s and attribute or child node etc. If i get some time I may post a sample parser.

4. Instantiate the LuceneDocument complete with your ID and a path to your index.

string id = "somefile.aspx";
string indexName = "TestIndex";
LuceneUpdateDocument target = new LuceneUpdateDocument(id, indexName);

The index will be automatically created in the loading assemblies directory\index. You can change this behaviour in:


public static IndexWriter GetIndexWriter(string name)

...

DirectoryInfo indexBase = new DirectoryInfo(AppDomain.CurrentDomain.BaseDirectory + "\\Index\\" + name);

...

Note: Hrm, I must have been tired when I wrote that, should have used String.Format.

5. Add fields to the document. These are what will actually be searched. You can choose to add the field so they can be searched and read back from the index, or you can add them so they can be searched but not read back from the index- use the first option for attributes like filename, date and other small pices of metadata, and use the second option for the main bulk of content. Your index will be too big if you try to store everything in there – so ensure your main content is indexed but not stored (thus not read back).To index attributes:


target.AddField("Title", "This is a test document", LuceneUpdateDocument.FieldStoreType.Attribute);

To index main content areas:


target.AddField("Content", "This is the main body content", LuceneUpdateDocument.FieldStoreType.Content);

6. Commit the new items to the index. This indexes the content and commits it to the index. It also clears out some internal caching that the wrapper class performs.

target.Commit();
Index.ClearCache();

7. Search your new index! Searching is easy!


//Create an instance of the searching class, passing in the same index that you used to add the content
Search s = new Search(indexName);
//This line searches for the word "document" in the Title and Content fields.
List results = s.QueryBasic("document", "Title", "Content");

//This line searches for the word "Main" in the Title and Content fields.
results = s.QueryBasic("Main", "Title", "Content");

foreach (SearchResult sr in results)
{
     string title = sr.GetFieldVal("Title");
     Assert.AreEqual(title, "This is a test document");
}

As you can see above, to search the index the syntax is

 s.QueryBasic("Some Query", "FieldOne", "FieldTwo", ..., ..., "FieldX");

The first parameter is the search query, you can look up all the Lucene query syntax here. After the first parameter you can list as many search fields as you like using the parameter array. Only the fields you list here (or any fields you specify in the query using special syntax) will be scanned by Lucene.

8. Reading the content from the index. Searching isn’t much good unless you can read information from your search results! Reading your attributes is easy, because they are searchable and stored in the index for quick retrieval (remember above how some items where marked as attributes and stored whereas other items are marked as main content – thus not stored). Note in the code sample above there is a foreach statement which iterates over each search result. In this foreach it pulls out the title field and performs an assert on it.

string title = sr.GetFieldVal("Title");

It’s too easy to get the stored attributes. But how about main content? Well this is up to you. Using the ID that you stored earlier (get it out like the title attribute above) load the original document and read what you need – or just redirect the user to it to view. Review the Lucene query documentation for a full list of all the cool stuff you can do!

Chapter Six: That’s a lovely story, but I don’t give a crap – where is the code man??

Firstly you will need to get the Lucene.NET DLL from here http://incubator.apache.org/lucene.net/. I didn’t include it in the download as I wasn’t sure of the legality – and I couldn’t be bothered reading their re-distribution policy.

LJAK – Lucene.NET Wrapper Class (Source).

Documentation (haha just kidding, like there is documentation).

Legal – Please read legal stuff at the top of the LuceneDocument class.

Happy indexing and searching!

Linq

How to do a join between two XML files with Linq

Linq is still a relatively new concept, but with the release of Visual Studio 2008 beta 2 and talk of a release candidate version it is about to become available for production use.

I’ve been knocking around with Linq for a little while now, and so far I really like what I see. There is plenty of talk about it around the internet and some excellent tutorials kicking around also. For a great look into Linq to SQL and also an overview of lambda expressions and extension methods check out Scott Guthrie’s blog.

First let me begin by saying that I make no pretences to being any form of Linq expert. My linq skills are still very much in their infancy… but I’m going to have a go at talking you through a little problem I had to solve the other day.

The Problem

You have two XML files, or a single XML file with two distinct tree’s. The first file/tree contains some records with primary keys of sorts. The second file/tree contains some joining information. The example I will use here is a list of words and synonyms.

File A may look like this:

<words>       <word>          <id>1</id>
         <text>Accident</text>      </word>      <word>          <id>2</id>
         <text>Mistake</text>      </word>   </words>

File B may look like this (linking the word and its synonyms):

<links>       <link>          <id>1</id>
         <refId>2</refId>      </link>   </links>

A little disclaimer here: Obviously given the chance you would use the hierarchical nature of XML to store the relationships, but because the source of the data I had to deal with was flat I had no choice.

When using linq to SQL you get lovely typed data and all the relationships are mapped out for you (or you map them out using the linq to SQL designer if they are not present in the source data). Unfortunately with linq to XML we can’t explicitly map these relationships *yet*.

Enter stage left the linq join functionality. The join keyword available in linq basically lets you write similar joins to what you might be used to with SQL (left, inner, outer etc).

An SQL query to select a word and find all the synonyms using the ref table might look something like this:

SELECT words_1.word
FROM links INNER JOIN
words ON links.id = words.id INNER JOIN
words AS words_1 ON links.refId = words_1.id

Pretty simple in SQL… but in linq to XML how to you achieve the same result? Using the join keyword of course.

Start off by loading the two XDocuments – one for the words and the other for the linking information:

XDocument wordDoc = XDocument.Load(AppDomain.CurrentDomain.BaseDirectory + "\\words.xml");
XDocument linkDoc = XDocument.Load(AppDomain.CurrentDomain.BaseDirectory + "\\links.xml");

Then start the linkq query in the usual way.

 var wordMatched = from w in wordDoc.Elements("words").Elements("word")

This will iterate all the elements in words/word, and place them into the w variable.

Next we can start populating the return var with information on the currently selected word element.

 select new
 {
 id = w.Element("id").Value,
 term = w.Element("text").Value,

Basically each item in the wordMatched IEnumerable object will contain .id and .term when you iterate them. That’s all really interesting but it doesn’t really do much yet, we want each wordMatched element to contain multiple child synonym words.

 syns = from refIds in linkDoc.Elements("links").Elements("link")
        join synLinkedWord in wordDoc.Elements("words").Elements("word") on refIds.Element("refId").Value equals synLinkedWord.Element("id").Value
        where refIds.Element("id").Value == w.Element("id").Value
        select new
        {
           id = synLinkedWord.Element("id").Value,
           term = synLinkedWord.Element("text").Value
        }

The join here is selecting words from the same XML file first up… this is because the final data we want resides in the same XML file as the words (i.e. words and their synonyms are identical, its the linking table that joins them up). The next part of the join says: we want to make the refIds in the other XML file match the ids of words in the original table.

Next is the where clause, which places a restraint on the query, or the join will return all items that are referenced in the links table… so only return items from the links table that have an id the same as the id on the original “w” object.

Finally we select some data from the original table again (this time using the word that our linking XML gave us).

To read this data is quite simple:

 foreach (var word in wordMatched)
 {
     txtOutput.AppendText("\r\nWord: " + word.term);
     foreach (var syn in word.syns)
     {
          txtOutput.AppendText("\r\n\t->Syn: " + syn.term);
     }
 }

As you can see each word contains the id and term properties, but also contains another IEnumerable properly called syns, each one containing the details of the syns!

Problems

There is one problem which I cannot solve as yet, and this is due to my total lack of depth in linq… Iterating through the wordMatch enumeable will return words which were listed as syns in other words… i.e. in our example mistake will be listed as a syn under accident, but it will also be listed by itself as a main word. This can probably be solved with some more where clauses and possibly another join… comments would be greatly appreciated on this!

Edit 9 Movember (sic) 2007

I solved my own problem whilst working on another problem… Insert the following line below the first from w in wordDoc xxxxx line:

where linkDoc.Elements("links").Elements("link").Where(p=>p.Element("refId").Value==w.Element("id").Value).Any() == false

This line adds a where clause that runs a scan on the links XML document searching for items that have a refId that is the same as the current id. The lambda expression in the .Where checks all elements in the linkDoc.Elements(“links”).Elements(“link”) enumerable to see if their ids match. The .Any() method returns true when the returned enumerable contains one or more items. So if an items id is a refId in the links table we assume that it is a synonym.

Full Listing

XDocument wordDoc = XDocument.Load(AppDomain.CurrentDomain.BaseDirectory + "\\words.xml");
            XDocument linkDoc = XDocument.Load(AppDomain.CurrentDomain.BaseDirectory + "\\links.xml");

            var wordMatched = from w in wordDoc.Elements("words").Elements("word")
                              where linkDoc.Elements("links").Elements("link").Where(p=>p.Element("refId").Value==w.Element("id").Value).Any() == false 			      select new
                              {
                                  id = w.Element("id").Value,
                                  term = w.Element("text").Value,
                                  syns = from refIds in linkDoc.Elements("links").Elements("link")
                                         join synLinkedWord in wordDoc.Elements("words").Elements("word") on refIds.Element("refId").Value equals synLinkedWord.Element("id").Value
                                         where refIds.Element("id").Value == w.Element("id").Value
                                         select new
                                         {
                                             id = synLinkedWord.Element("id").Value,
                                             term = synLinkedWord.Element("text").Value
                                         }
                              };

            foreach (var word in wordMatched)
            {
                txtOutput.AppendText("\r\nWord: " + word.term);
                foreach (var syn in word.syns)
                {
                    txtOutput.AppendText("\r\n\t->Syn: " + syn.term);
                }
            }
Web Services

Encrypting and securing web service traffic without SSL

Sometimes the need arises to have secured web service traffic without depending on SSL. The web service in a windows service without IIS from the previous post cannot use SSL anyway (well not that I know – any comments on this). There also may be a need to authenticate to the web service, either through the usual user and pass system, or my preferred method of using AES and pre-shared keys. Security experts agree the world over that AES is a very tough security standard. This method is great for two reasons:

  • No need to type in a user and pass, just ensure the keyfile is on each machine – if they keys match then the data is readable
  • Very high security

It does have a couple of downsides however:

  • Each client must have the same key – unless we use soap headers to first identify the user, the server will use this info to load the appropriate key
  • Keys cannot distinguish users without the soap header above or something similar, so user accounting is a smidge more tricky than straight user and pass

Of course on IIS you can use both the pre-shared key and user/pass authentication for extra security – NTLM kerberos and pre-shared AES key… pretty damn secure in my book.

A basic outline of the steps involved in this little project is:

  • Create webservice
  • Create encryption class
  • Create SOAP header class to provide a secondary layer of security
  • Maybe some user/pass authentication if I get time (for IIS only)

I’m going to use the web service created in the previous post, but this should work with any web service, WSE or not.

First we will get the basic encryption stuff out of the way, so create a new public class called Crypto… mine is in a class library. This class will create a key if one doesn’t exist, and will provide the encryption and decryption duties. This article isn’t focused on encryption, so I’m going to just dump the encryption class code in one blob.


using System;
using System.Collections.Generic;
using System.IO;
using System.Text;
using System.Security.Cryptography;
using System.Xml;

namespace Web_Service_inside_a_Windows_Service
{
    public class Crypto
    {
        byte[] key;
        byte[] iv;

        public Crypto()
        {
            keyInit();
        }

        //pretty much a straight copy of MSDN
        public byte[] Encrypt(string input)
        {
            UTF8Encoding textConverter = new UTF8Encoding();
            RijndaelManaged rijndael = new RijndaelManaged();
            byte[] toEncrypt;         

            ICryptoTransform encryptor = rijndael.CreateEncryptor(key, iv);

            MemoryStream msEncrypt = new MemoryStream();
            CryptoStream csEncrypt = new CryptoStream(msEncrypt, encryptor, CryptoStreamMode.Write);

            toEncrypt = textConverter.GetBytes(input);

            csEncrypt.Write(toEncrypt, 0, toEncrypt.Length);
            csEncrypt.FlushFinalBlock();

            return msEncrypt.ToArray();
        }

        public string Decrypt(byte[] input)
        {
            UTF8Encoding textConverter = new UTF8Encoding();
            RijndaelManaged rijndael = new RijndaelManaged();

            byte[] fromEncrypt;
            int discarded = 0;

            ICryptoTransform decryptor = rijndael.CreateDecryptor(key, iv);

            MemoryStream msDecrypt = new MemoryStream(input);
            CryptoStream csDecrypt = new CryptoStream(msDecrypt, decryptor, CryptoStreamMode.Read);

            fromEncrypt = new byte[input.Length];

            csDecrypt.Read(fromEncrypt, 0, fromEncrypt.Length);

            return textConverter.GetString(fromEncrypt);
        }

        //check for keys and if not present the create them
        //load keys into local vars
        void keyInit()
        {
            //place the keys in a nicely accessible location so other applications that use this class can use them - note this location is probably
            //not secure on most machines
            FileInfo keyFile = new FileInfo(System.Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) + "\\CryptoKeys");

            string sKey;
            string sIv;

            if (!keyFile.Exists)
            {
                sKey = generateHexKey();//set the keys into the local vars as they are created
                sIv = generateHexIV();
                XmlDocument doc = new XmlDocument();
                doc.LoadXml("");

                XmlNode keyNode = doc.CreateElement("key");
                keyNode.InnerText = sKey;
                doc.DocumentElement.AppendChild(keyNode);

                XmlNode ivNode = doc.CreateElement("iv");
                ivNode.InnerText = sIv;
                doc.DocumentElement.AppendChild(ivNode);

                if (!keyFile.Directory.Exists)
                {
                    keyFile.Directory.Create();
                }

                doc.Save(keyFile.FullName);
            }
            else
            {
                XmlDocument doc = new XmlDocument();
                doc.Load(keyFile.FullName);
                sKey = doc.DocumentElement.SelectSingleNode("key").InnerText;
                sIv = doc.DocumentElement.SelectSingleNode("iv").InnerText;
            }

            key = Convert.FromBase64String(sKey);
            iv = Convert.FromBase64String(sIv);
        }

        string generateHexKey()
        {
            //Rijndael *is* AES
            RijndaelManaged rijndael = new RijndaelManaged();
            rijndael.GenerateKey();
            return Convert.ToBase64String(rijndael.Key);
        }

        string generateHexIV()
        {
            RijndaelManaged rijndael = new RijndaelManaged();
            rijndael.GenerateIV();
            return Convert.ToBase64String(rijndael.IV);
        }
    }
}

There. Nothing fancy, pretty much the default encryption stuff from MSDN, except i change the ASCIIEncoder to a UTF one so that way it will support any character we throw at it. Oh and the comments are poor as you can see.

Okay, so now we can encrypt stuff, lets use it and get some secure web service action happening. First we need to update the web service. In your web service code behind make the following adjustments.


using System;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;

[WebService(Namespace = "http://myURI/MyLittleWebService")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class WebServiceCodeEncrypted : System.Web.Services.WebService
{
    Web_Service_inside_a_Windows_Service.Crypto crypto = new Web_Service_inside_a_Windows_Service.Crypto();
    public WebServiceCodeEncrypted()
    {
    }

    [WebMethod]
    [SoapHeader("AuthKey", Direction = SoapHeaderDirection.In)]
    public string GetMessages(string sGuid)
    {
        string guid = decString(sGuid);
        return encString("At the third stroke the time will be " + DateTime.Now.ToString() + ". Your guid was " + guid);
    }

    string encString(string input)
    {
        //convert the byte array that comes out for easy transport.
        return Convert.ToBase64String(crypto.Encrypt(input));
    }

    string decString(string input)
    {
        return crypto.Decrypt(Convert.FromBase64String(input));
    }

    public class AuthorisationKey : SoapHeader
    {
        public byte[] EncData = null;

        public AuthorisationKey()
        {

        }

        public bool Validate(System.Web.HttpContext context, string WSMethodName)
        {
            try
            {
                //EncData should contain the ticks of the date time that hte request was made...
                //by checking this we are doing two things a) the key is right if we get a valid date time and
                //b) the request is only valid for 5 minutes, cause after that runDate will be less than now - 5 mins.
                string ticks = crypto.Decrypt(EncData);
                DateTime runDate = new DateTime(Convert.ToInt64(ticks));
                return runDate > DateTime.Now.AddMinutes(-5);
            }
            catch (Exception ex)
            {
                //maybe throw a nice exception here - like the key was bad or something.
                throw ex;
            }
        }
    }

}

A few notes:

  • Added decrypt and encrypt string methods. They user the base64encoding stuff in the Convert class library to turn the byte array into a string.
  • We could have just put return type of byte[] on the GetMessages web method (.NET will base64 encode it anyway), but I like strings better because they are easily stored in formats like XML.
  • We added in the soap header authorisation class. More on this a bit later.
  • Changed the web service class name to WebServiceCodeEncrypted because you need to include a reference to your main project to bring in the new crypto class library, and there would have been two classes named the same (the original copy of the webservice is in the other class remember)
  • Note that any unsafe string (i.e. un encrypted) should always be named in a way that indicates its status. For example, you could call your safe encrypted string sSomeName and your un-encrypted ones uSomeName… then hopefully you wont ever accidentally transmit around an unsecured string.

Ensure you copy this updated webservice code into an IIS based “real” web service and update the reference in your project.

Now accessing the webservice is the fun part. Update the code in your WebServiceQuery class:


WebServiceCodeReference.WebServiceCodeWse wsc = new WebServiceCodeReference.WebServiceCodeWse();
WebServiceCodeReference.AuthorisationKey key = new WebServiceCodeReference.AuthorisationKey();

Crypto crypto = new Crypto();
key.EncData = crypto.Encrypt(DateTime.Now.Ticks.ToString());

wsc.AuthorisationKeyValue = key;

IPHostEntry ip = Dns.GetHostEntry(targetMachineName);
wsc.Url = "soap.tcp://" + ip.AddressList[0].ToString() + "/MyLittleWebService";

string result = wsc.GetMessages(Convert.ToBase64String(crypto.Encrypt("This here is a test string")));

string decResult = crypto.Decrypt(Convert.FromBase64String(result));</pre>
<pre>return decResult;

First and foremost if you run this from your test application or service, the data will be encrypted! Secondly you can see we are creating an object to implement the call to the soap security header… we put the current date time in there, so the server can get *its* current date time, take off five minutes, and compare it to the one passed in… this means that each message is only valid for five minutes (so no nefarious beings can pinch your packets and spoof another request to the server – well not after five minutes anyway).

If you are running your web service on IIS then you can add in the following code to authenticate with user and pass while still using the pre-shared key system:


	if (user != null && user!=string.Empty)
            {
                if (user.ToLower() == "integrated")
                {
                    wsc.Credentials = System.Net.CredentialCache.DefaultCredentials;
                }
                else
                {
                    NetworkCredential netCred = new NetworkCredential(user, pass);
                    wsc.Credentials = netCred;
                }
            }

Pass the user and pass variables into your method. Set the user the integrated to use the NTLM based single sign on authentication of the current windows user.

Update: 31 October 2007

Another reason why using built in encryption rather than SSL etc is that SSL is transport level encryption, meaning you cannot access the encrypted version of the content. With the AES inbuilt version you could save off your messages to DB or filesystem without the need to re-encrypt them.

Update: 16 May 2008

Added missing soap attribute from GetMessages method.

Web Services

Web service inside a Windows service without IIS

Update: If you have any questions about this article or any other web-services related queries then please ask! I see alot of traffic coming from Google about web-services and related issues/problems which this text doesn’t cover but I can probably help with! Leave a comment and I will respond quickly – if I don’t have the answers then I bet I know someone that does.

Skip to the Ramble End section to get into the guts of the article… the first part is just me talking too much as usual.

I’ve decided I need to get out more (it was either me or my shrink – I cant remember. Ed.); see the sights, expand my horizons, meet new media dissemination platforms.

I find myself writing and documenting code for my team mates at Objectify – tidbits of information here and there, how-to’s, faq, code snippets, my secret pasta recipe etc. – all usually transmitted in email form, with the occasional Word or PDF doc if they are lucky. If they are really lucky I may enter it into our internal FAQ system… for a fee.

Why not blog about some stuff too? See just for interests sake if anybody is interested in anything I say.

I thought I would start off nice and easy – ease into the Blogoshere nice and slowly (note to self – blog about hating the word “Blogoshere”… oh someone already did, damn). So I’m opening up the innings with a little ditty about hosting web services inside a windows service without the need for IIS. I wrote this doco about a year and a half ago, so its basically a translation of some old stuff… Sure its nothing too technical, its not ahead of the curve so to speak, and its probably been done a thousand times but we all gotta start somewhere. If we get time we may even throw in some SOAP headers and AES encryption for good measure – nothing like a pre-shared key to brighten your day. Okay well maybe in the next entry.

I first came across the need for a web service inside a windows service when thinking about ways to decentralise the Objectify CMS debugging system. Basically the debugging system goes way back to the days of the first CMS, all written in VB6 mind you, and uses mail slots to transfer messages from an array of COM objects to the debugger output application. Problem was that clients (and internal testers etc.) had to log into the server and run the application to see the messages. Now I know what you are going to say – you can pipe mailslot data between machines, problem solved… but I wanted to try something new, so web services it was.

Ramble End

We will end up with a simple web service windows service (WSWS?) with an interface to query which will do some simple processing for posterity’s sake and return a message to the client.
Firstly, you are going to need Web Services Enhancements 3.0 from Microsoft. Hop along to http://msdn2.microsoft.com/en-gb/webservices/Aa740663.aspx and grab a copy – make sure you install the developer option (the Visual Studio developer option if you are using VS). It will distribute itself with your app when you build the installer (if you choose to) so no need to install the MSI on your target machine.

Start your new project by creating a class library. I called mine something original – Web Service inside a Windows Service. This is where we will be placing the bulk of the code. Create a new public class called HostWebService.

Add in references to Microsoft.Web.Services3 and System.Web.Services.

Begin your code by adding the following namespace includes:

using Microsoft.Web.Services3;
using Microsoft.Web.Services3.Addressing;
using Microsoft.Web.Services3.Messaging;
using System.Net;

Okay so we are ready to go. Too easy. In the constructor we need to do some things to start our little web service listener. First, we need to know the local machine’s DNS address, and use this address to create a URI for our new Web Service (i.e. the address that will be used in the client application to query the service).

 string hostName = Dns.GetHostName();
 IPHostEntry ipEntry = Dns.GetHostEntry(hostName);
 Uri address = new Uri("soap.tcp://" + ipEntry.AddressList[0].ToString() + "/MyLittleWebService");

By the way, did I mention that if you know a better way to do any of this the please feel free to comment – i.e. is that the best way to get the IP of the local machine?

You can see above that the Uri address=xxxxx line is where you set the actual URI of the service, you can change the last part from MyLittleWebService to something more fitting if you like.

Now we need to create the actual web service code… It’s basically the same code that is generated by Visual Studio when you create a web service (the code behind in the Service.asmx file). Create a new class called WebServiceCode.cs and paste in the following:

using System;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;

[WebService(Namespace = "http://myURI/MyLittleWebService")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class WebServiceCode : System.Web.Services.WebService
{
    public WebServiceCode()
    {
    }

    [WebMethod]
    public string GetMessages(string guid)
    {
        return "At the third stroke the time will be " + DateTime.Now.ToString();
    }

}

Nothing too tricky there, stock standard web service stuff. Next we go back into the HostWebService class and add the following just below the URI stuff:

 SoapReceivers.Add(new EndpointReference(address), typeof(WebServiceCode));

And we’re done… almost. Well we’re done to the point that if you run that code (from a test app or something) then you will have a windows app that is hosting a web service. Thats great, but how do you query said service?

Accessing the new service

Before we can access the new web service we need to add it as a Web Reference to our project. Normally this is nice and easy, just right click and add a Web Reference in Visual Studio and let WDSL do the work. Problem is this new web service isn’t published anywhere yet, and even when its installed on the target machine and running, its URI will be unknown to the client.

Lets start by getting the web reference. Create a new ASP.NET web service project (call it tempservice or something, you wont need to keep it for long) go to the Service.asmx code behind and paste in the code from your WebServiceCode.cs file. Then right click the Service.asmx file and View in Browser. Copy the URL from the browser window that pops up, and add it as a web reference to your main project (right click References, Add Web Reference, paste into field, click Go, click Add Reference).

Great we have a description of our web service for the client app to use when querying.

Create another class called WebServiceQuery. Add the following to the namespace references section:

 using System.Net;

Now create a public method called Query that returns a string (or you can just paste in the following code):

 public string Query(string targetMachineName)
   {
      Web_Service_inside_a_Windows_Service.WebServiceCodeReference.WebServiceCodeWSE wsc = new Web_Service_inside_a_Windows_Service.WebServiceCodeReference.WebServiceCodeWSE();

      IPHostEntry ip = Dns.GetHostEntry(targetMachineName);
      wsc.Url = "soap.tcp://" + ip.AddressList[0].ToString() + "/MyLittleWebService";
      string result = wsc.GetMessages("some guid");

      return result;
   }

NOTE: The object we create is the WSE version (WebServiceCodeWSE), without this the calls to soap.tcp will not work.

Simple – first we instantiate our web reference object. Then we set the URI of the newly instantiated object the same way we did for the service itself. Finally we query the service and return the value. Note the GUID parameter on the service call – this is just in there to demonstrate calling methods and passing in parameters, but you already knew how to do that.

Now you can create a test application, start the service and then query it! All that’s left is to create a Windows service and create an instance of your calling class.

Just a note on the URI creation parts – if you are getting an error do do with port parsing, check that the IP address its getting isn’t and IPV6 address…

Okay so that’s it, my first post. Its long and boring.

Next time I will visit security using SOAP headers and how to encrypt the SOAP data using AES (Rijndael).

Cheers.