December 2004 - Posts
During these "vacation" days I studied the Tracing capabilities for a web application (both in ASP.NET 1.1 and 1.2). The solution is pretty simple, ASP.NET doesn't works on System.Diagnostics.Trace class but on System.Web.TraceContext. Then, if you need to trace something with ASP.NET (Web Services too) you have to use TraceContext's methods (Write and Warn).
In order to write ASP.NET trace messages to some trace listener you have to set writeToDiagnosticsTrace to true (<trace enabled="true" writeToDiagnosticsTrace="true"/>). In this way, all messages (using both Trace or TraceContext) will write to the listeners defined.
I continued my tests without much success. I rolledback to FX1.1 and create a basic web service:
<%@ WebService Language=C# Class=Util %>
using System;
using System.Web.Services;
[WebService(Namespace="urn:pierre")]
public class Util : WebService {
[WebMethod()]
public string Time() {
System.Diagnostics.Trace.WriteLine("Time call");
return Context.Timestamp.TimeOfDay.ToString();
}
}
Then I created its web.config:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.diagnostics>
<trace autoflush="false" indentsize="2">
<listeners>
<add name="traceListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="D:\Inetpub\wwwroot\log\myTest.log" />
</listeners>
</trace>
</system.diagnostics>
</configuration>
Finally I created myTest.log file (empty) getting the modify rights to ASPNET user on the folder D:\Inetpub\wwwroot\log
Running the web service nothing happens. The log file is still empty. I've searched on Google but it seems that many people requested help but there isn't a solution available (or I didn't find it). Any clues ?
Today I'm playing with december VS 2005 CTP and I'm trouble. I don't know why the tracing isn't working (I'm sure I'm missing something...too much italian wine and food during Christmas's day). So, I started adding the following code to my web.config:
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<system.diagnostics>
<trace autoflush="true">
<listeners>
<add name="traceFile" type="System.Diagnostics.TextWriterTraceListener" initializeData="C:\Inetpub\wwwroot\WebTest\Log\trace.log" />
<remove name="Default" />
</listeners>
</trace>
</system.diagnostics>
<appSettings/>
<connectionStrings/>
<system.web>
<trace enabled="true" />
<compilation debug="true"/>
<authentication mode="Windows"/>
</system.web>
</configuration>
Then I set the write access to the log file folder (ASPNET, I'm using Windows XP SP2) and finally I added a WriteLine to my HelloWorld web service:
System.Diagnostics.Trace.WriteLine("Hello world called");
I ran it and no log file written. I checked the Trace instance and the listeners is in the collection. But no log. Mmmm, do I miss something ?
I have to admit that the authorization process of the
membership management isn't so good as I was excpecting. I sincerly don't understand way Microsoft didn't used the
authorization manager ideas for the upcoming framework. I'll probably implement my
provider by myself :-))
Christian's articles and blogs are one of the most interesting information point that focus on how to design, develop and test web services. He shows how it must (should) be done and propose some interesting tools to make them easier.
But; I would share another way to implement a web service maintaining the SOA principle. So, let's start with a basic example: we have to save a contact information (simply first and last name) into our backend system. Since we have just to save the contact, this is a one-way message pattern. We then have to create the schema (XSD) of the request message. Since the XML .NET serialization maps types to XML schema (and viceversa) we can create directly a class library containing the request type:
[XmlType(Namespace="http://www.peway.com/contact/v1/messages")]
public class SaveContactRequest
{
public string FirstName;
public string LastName;
}
We have defined the first part of the contract ! Well, now the operation. We can start creating the interface containing the behavior of the service (this isn't mandatory but correct from an OO point of view):
public interface IContactService
{
void SaveContact(SaveContactRequest contact);
}
Finally we have to implement the interface:
[WebService(Namespace="http://www.peway.com/contact/v1/service")]
public class ContactService : IContactService
{
[WebMethod()]
[SoapDocumentMethod(OneWay=true, ParameterStyle=SoapParameterStyle.Bare)]
public void SaveContact(SaveContactRequest contact)
{
// Save the person here....
}
}
We have the service class too ! That is really perfect, it should be nice to decorate the interface instead of its implementation, but we can't since the WebService attributa isn't applicable to an interface (I hope that this kind of limitation will have a solution soon). The last thing we have to do is to copy the class library into the bin folder of the web site and add the following asmx document into the web site folder:
<%@ WebService Class="MyLib.ContactService, MyLib" %>
That's it !! The web service is ready to run.
Fixed properties works well when you have a clear and stable idea of the entity but it provides some kind of restriction. Some properties are fixed, such as names, email and so on, but other can change frequently and depending on the business context. In such situations dynamic properties can help. Basically there are several ways to create dynamic properties, probably the most common is to create a list of key/value pair. But of to define the key ?
There are several ideas:
- System.String : property name (ie FirstName)
- System.String : object name/property name (ie. Person.FirstName)
- System.String : fully qualified object name/property name (ie. MyNamespace.Person.FirstName)
- System.Xml.XmlQualifiedName: (ie. MyNamespace.Person:FirstName)
Any other idea ?
Today we have many standards (and conventions) to describe processes, entity relationships, entity operations and properties, contracts, and so on. But sometimes analysts consider the algorithm as a balck-box and the documentation is always incomplete. To describe an algorithm I found three distinct ways:
- flow chart (with many notes)
- IPO chart
- pseudo-code
I'm not impressed by none of them, but I didn't found something better. Does somebody has some suggestions ? Thanks a lot ;-)
More Posts