Yves Reynhout's Blog

MVVM Mediator Deluxe

yreynhout — Tue, 06 Oct 2009 23:05:21 GMT

From what I’ve been reading on the implementations of the Mediator pattern for MVVM, I must say I’m a little disappointed. Maybe it’s my background with a certain UI design methodology (for which I must credit Philip Almey, a former colleague) for the last five or six years. Using (hierarchic) state charts to design user interfaces allows you to think about it’s behavior without being hampered by technology nor content or style. I’m happy that this “way of thinking” still stands firm as technology progresses (into Silverlight/WPF that is). Translating such charts into the asynchronous code flows that rule the “new world” is a challenge. One that requires clear separation of concerns, and the MVVM pattern adds a lot of value to solve this challenge. Another piece of the puzzle is the EventAggregator (Prism term) / Mediator / Message Bus / Messenger that provides the communication mechanism between your views and view models. But current implementations seem to focus on using the mediator as a publish/subscribe pattern vehicle and going to great lengths to eliminate memory leaks (which I personally find a little over the top considering that “unsubscribe” should be something explicit).

Looking at the mediator communication mechanism from a messaging perspective, I see a lot of room for improvement. There is no explicit concept of addressability (think WS-Addressing). If I want to send a message to a specific view, I’ll have to juggle with predicates and properties to make it work. Mind you I’m not advocating for tightly coupling views and view models (although some implementations already do this on subscription ;-)). After all, for addressability, one can simply use System.Uri. Along with addressability comes explicit support for the request/response message exchange pattern (alongside the existing publish/subscribe pattern). I’d like to see an API along the following lines:

//Receive any message of the specified type
IDisposable Accept<TRequest>(RequestCallback<TRequest> callback) where TRequest : RequestMessage;

//Receive messages of the specified type matching the predicate
IDisposable Accept<TRequest>(Expression<Predicate<TRequest>> predicate, RequestCallback<TRequest> callback) where TRequest : RequestMessage;

//Reply to a request message
void Reply<TReply>(TReply reply) where TReply : ReplyMessage;

//Send a request message
void Request<TRequest, TReply>(TRequest request, ReplyCallback<TReply> callback)
where TRequest : RequestMessage
where TReply : ReplyMessage;

Remark: People who have used WSE3 (yes, really) will know that you can use the message to specify the addressing bits.

I know this API is more rigid (contrary to sprinkling Action<T>) but that’s also its strength. It forces you to think in terms of request/reply messages that flow around. This is how I discovered that sequence diagrams are the new hype all over again to model the communication between views and view models and how they help me understand the message flow. I realize that there are a lot of details and mechanics about the API that I haven’t explained, but this post is just intended to get the juices flowing.

My conclusion: Is it impossible to achieve the above with the current incarnations? No, but it’s cumbersome and too verbose.

DLinq - First Impression

yreynhout — Fri, 16 Sep 2005 10:32:00 GMT

I thought I'd just have my say about this as these gentlemen already have [ PeeWeeWilson & Fouma ]. After having read the overview paper (rather diagonal I might add) I can't help but notice the three-way mapping is gone (domain schema <-> mapping schema <-> relational schema), which I find a pitty. From the simplicity point of view I can fully understand why, but believe me when I say that flexibility is sacrificed.
Recently Steve Eichert mentioned using DataContract as a way to describe what is persistable and what is not. An interesting idea, but there are too many references to the web service world (Namespace, MustUnderstand, ...). Secondly, if I'd like to expose the class/message using [DataContract] via a web service I wouldn't feel very comfortable with "what is persistable" and "what is part of the message" being the same. Creating a new set of attributes [PersistenceContract], [PersistenceMember(Name=...)] and [PersistenceMemberReference(Name=...)], [PersistenceConstructor] sounds more appealing to me. They could form the domain/persistence schema, which could in turn be consumed by the mapping schema or code which defines the mapping/transformation.
Unlike Paul and Frans, I don't advocate against using attributes. What I do advocate against is the fact that relational concepts such as table, column, native or abstract column types, primary or foreign key and relationship show up in my domain model, and this for the very same reasons as Paul & Frans do (call it one thing in SqlServer, call it another in Oracle; inject some kind of custom transformation in the mapping because there is a mismatch between the CLR type and the native db type). Unfortunately this is exactly what DLinq does. Marketing-wise this could be interpreted as "Let's sell more SQL servers". Opening things up would only allow you to switch to Oracle more easily. Wether that was the reasoning behind this all, I really don't know. Let's just hope that in the future DLinq will embrace flexibility and database independence.
Resources on Linq

Computing on demand

yreynhout — Thu, 02 Jun 2005 18:22:00 GMT

An interface I find very useful lately is IComputeOnDemand (although it is highly debatable if it should be an interface at all):

/// <summary>
/// Behavior for things that can be computed on demand.
/// </summary>
public interface IComputeOnDemand {
/// <summary>
/// Gets a value indicating whether this instance is computed.
/// </summary>
/// <value>
///     <c>true</c> if this instance is computed; otherwise, <c>false</c>.
/// </value>
bool IsComputed { get; }

/// <summary>
/// Gets or sets the inner value.
/// </summary>
/// <value></value>
object InnerValue { get; set; }
}

Classes often have properties that only need to be computed once. The most used approach to handle this is by introducing some variable (e.g. loaded, calculated) which indicates if some computation has taken place. An example:

public class SomeClass {
private bool loadedField1;
private int field1;

public int Field1 {
    get {
      if (!this.loadedField1){
        //Do some "heavy" computation here.
        this.field1 = resultOfComputation;
        this.loadedField1 = true;
      }
      return this.field1;
    }
}
}

While this is fine for one field, consider this scenario for multiple fields in one class. Pretty soon the class gets cluttered with these "loaded" fields. But there's even bigger danger lurking: What if you bypass the property and start using the field without it being initialized? Will you ever know? Ofcourse you only get this within the class itself (I'm assuming you've banned the evil called public fields). Let's add a new exception:

/// <summary>
/// The exception that is thrown when something is not computed.
/// </summary>
public class NotComputedException: ApplicationException {
/// <summary>
/// Creates a new <see cref="NotComputedException"/> instance.
/// </summary>
public NotComputedException(): base() {}
/// <summary>
/// Creates a new <see cref="NotComputedException"/> instance.
/// </summary>
/// <param name="message">Message.</param>
public NotComputedException(string message): base(message) {}
/// <summary>
/// Creates a new <see cref="NotComputedException"/> instance.
/// </summary>
/// <param name="message">Message.</param>
/// <param name="innerException">Inner exception.</param>
public NotComputedException(string message, Exception innerException): base(message, innerException) {}
}

What's next? Well, time for some code smitherings: For each of your compute on demand data types, you generate a "typed" holder class. I took System.Boolean as an example (mind the "no boxing here"):

/// <summary>
/// Represents a placeholder for a <see cref="Boolean"/> value.
/// </summary>
public class BooleanHolder: IComputeOnDemand {
/// <summary>
/// Creates a new <see cref="BooleanHolder"/> instance.
/// </summary>
public BooleanHolder() {
}

/// <summary>
/// Creates a new <see cref="BooleanHolder"/> instance.
/// </summary>
/// <param name="innerValue">Inner value.</param>
public BooleanHolder(Boolean innerValue){
    this.InnerValue = innerValue;
}

/// <summary>
/// Gets a value indicating whether this instance is computed.
/// </summary>
/// <value>
///     <c>true</c> if this instance is computed; otherwise, <c>false</c>.
/// </value>
public bool IsComputed {
    get {
      return this._computed;
    }
}bool _computed = false;

/// <summary>
/// Gets or sets the inner value.
/// </summary>
/// <value></value>
public Boolean InnerValue{
    get {
      if (!this.IsComputed) {
        throw new NotComputedException();
      }
      return this._innerValue;
    }
    set {
      this._innerValue = value;
      this.MarkAsComputed();
    }
}Boolean _innerValue;

/// <summary>
/// Gets or sets the inner value.
/// </summary>
/// <value></value>
object IComputeOnDemand.InnerValue {
    get {
      return this.InnerValue;
    }
    set {
      this.InnerValue = (Boolean)value;
    }
}

/// <summary>
/// Marks as computed.
/// </summary>
/// <returns></returns>
private void MarkAsComputed(){
    this._computed = true;
}
}

Using this approach you get a less cluttered class and a nice exception when using a field that wasn't computed. As noted by John Ritsema, in Whidbey generics can be used to simplify things (see comment for how-to).

public class SomeClass {
private BooleanHolder field1;

public bool Field1 {
    get {
      if(!field1.IsComputed){
        //Do some "heavy" computation here.
        this.field1.InnerValue = resultOfComputation;
      }
      return this.field1.InnerValue;
    }
}
}

I tend to appreciate the small things in life...

Patents: System.Data.Mapping to resurface?

yreynhout — Wed, 18 May 2005 18:58:00 GMT

What have we here?

Visiting SQL - Update

yreynhout — Sun, 24 Apr 2005 18:45:00 GMT

It seems like I'm not the only one who has been playing with this idea: sqlom

Visiting SQL - Part 2

yreynhout — Tue, 12 Apr 2005 21:02:00 GMT

In part 1 I explained how I got a "typed model" of a database schema for building SQL in code. By itself I found this useful, but I still hated the string concatenation involved (not to speak of the scattering of all this string manipulation). So I came up with the idea to build a hand-made object model for all SQL query related objects. This model would allow me to build SQL statements in a typed and database-agnostic fashion, integrating nicely with my typed database schema model. To give you a rough idea I included some schematics:

- The core interfaces -

- The core classes (and some derived ones to give you an idea) -

The main interfaces of interest are ISqlSerializable (a.k.a. IVisitable with the accept method replaced with the more appropriate WriteSql) and ISqlWriter (a.k.a. the Visitor). Basically, I've taken the visitor pattern and applied it to writing SQL, allowing for extensibility (for each of the SQL dialects out there) and refraining developers (in theory) from polluting the code with string concatenated SQL. The not so apparent added value is the amount of reuse one can achieve with this type of model (from caching to creating dynamic views).
The only drawback (maybe there are more, but this is the major one) to using an object model is that your SQL becomes very much unreadable as complexity grows. Then again, this may be a sign that you're not doing enough in your domain model or (e.g. for performance, security reasons) it might be wise to push this logic into a stored procedure. But even this can be solved, by simply modelling each query statement as a class, which can be easily serialized into SQL to see if you get the desired SQL statement (the truly brave might even parse a SQL string and reverse engineer it into the object model).
I think there's enough food for thought in here. Sorry if I haven't gone into too much detail, but a high-level overview is what I had in mind. Feel free to inquire for more.

Visiting SQL - Part 1

yreynhout — Fri, 08 Apr 2005 22:31:00 GMT

Apparently, after some months of intensive work, I'm dieing to share (and reflect on) some of the things I've worked on.

Although "pluggable database backends" and "SQL abstraction" were not directly goals of the project (regular OLTP app), I kind of stumbled on them by accident (just don't call me nuts yet). First off, a lot has already been written about "pluggable database backends", achieved using the IDbXYZ and IDataZYX interfaces which any decent .NET data provider implements, so I'm not gonna talk about that.
At work, I tend to use a lot of dynamic SQL because I don't want too much of my business logic "locked" in stored procedures. The whole dynamic SQL versus stored procedures topic is not something I want to delve in now, so we're not gonna talk about that either. Dynamic SQL built in code suffers the problem that as the database schema changes, the "SQL building code" should change along with it. So how do you know which SQL building code is affected by changes in the database schema? If the SQL was somehow typed, the compiler would tell you. Making the SQL typed would mean that there should be some object model in place that, for starters, allows you to represent the database objects (think views, tables, columns, ...).
Datasets, and in particular the typed flavor, come to mind. But they're a little bloated just to represent a schema (and probably limited as to the types of database objects they can represent). I had a look at CodeSmith's SchemaExplorer (which BTW has a slick object model) but couldn't use it because it's use was primarly to discover the database schema at runtime. What I was looking for was a static definition of the database schema in C# code at design time (which I dubbed RelationalSchema). Although I'm not a big proponent of DIY, I really don't think I had much choice at the time. I borrowed some of SchemaExplorer's object model (in redux I might add), and made it xml serializable using one of those fine WSE interfaces, namely IXmlElement(who said you can't reuse wonderful material).
Now that RelationalSchema was born, containing RelationalSchemaDatabase, RelationalSchemaTable, RelationalSchemaView and RelationSchemaColumn, I used CodeSmith to build a template that generates my xml representation of a relational schema. This way I could have an xml representation of any database schema I liked; just a matter of setting the proper connectionstring. Still, this was just a "generic" representation of a database schema. I still wouldn't detect database schema changes this way. Much like datasets definitions can be used to generate typed datasets, I needed a way to generate a typed relational schema. Again, CodeSmith to the rescue. I made a template which creates a typed object model based on the generic object model.
If I was planning on using the "building SQL using strings" approach than my story would be done here. But it isn't...

The "facets-enabled" meta model

yreynhout — Fri, 08 Apr 2005 18:04:00 GMT

During the course of my current project at work, I've been trying to come up with a way to describe the meta data of my domain model (which I dubbed the meta model). Because I've taking a rather ObjectSpaces-like approach to object-relational mapping, the domain schema I created seemed like a good place to store the facets of my class members(fields and/or properties). Here's an example of what it looks like:

<?xml version="1.0" encoding="UTF-8"?>
<DomainSchema AssemblyFullName="SomeProject, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" 
xmlns="http://www.seagile.com/domainschema-1.0/" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.seagile.com/domainschema-1.0/
D:\WorkSpace\SomeProject\trunk\Schemas\DomainSchema.xsd">
    <Classes>
        <Class FullName="Seagile.SomeProject.SomeBaseClass" IdentityMember="ID">
            <Members>
                <Member Name="ID" Field="_id" Type="System.Guid"/>
            </Members>
        </Class>
        <Class FullName="Seagile.SomeProject.SomeClass" BaseClass="Seagile.SomeProject.SomeBaseClass">
            <Members>
                <Member Name="Name" Field="_name" Type="System.String">
                    <Facets>
                        <MinLength>1</MinLength>
                        <MaxLength>5</MaxLength>
                    </Facets>
                </Member>
                <Member Name="ExternalCode" Property="ExternalCode" Type="System.String"
                    Required="False" Default="MCQ000">
                    <Facets>
                        <FixedLength>6</FixedLength>
                        <Pattern>^MCQ\d{3}$</Pattern>
                    </Facets>
                </Member>
                <RelationshipMember Name="Category" Field="_category" RelationshipType="One" 
                    TargetClass="Seagile.SomeProject.SomeOtherClass"/>
                <RelationshipMember Name="Materials" Field="_materials" RelationshipType="Many" 
                    TargetClass="Seagile.SomeProject.Material"/>
            </Members>
        </Class>
        <Class FullName="Seagile.SomeProject.Material" BaseClass="Seagile.SomeProject.SomeBaseClass">
            <Members>
                <Member Name="Name" Field="_name" Type="System.String"/>
                <Member Name="TotalParts" Field="_totalParts" Type="System.Int32">
                    <Facets>
                        <MinInclusive>2</MinInclusive>
                        <MaxExclusive>11</MaxExclusive>
                    </Facets>
                </Member>
                <Member Name="BarCode" Field="_barCode" Type="Seagile.SomeOtherProject.BarCode, SomeOtherProject" 
                    TypeConverter="Seagile.SomeOtherProject.Data.BarCodeConverter, SomeOtherProject.Data"/>
            </Members>
        </Class>
    </Classes>
</DomainSchema>

By itself the schema is worth nothing, but in conjunction with a mapping and relational schema it's "easy" for a generic mapping layer to interpret how to retrieve and store objects. Strictly speaking the mapping layer doesn't need the type information and facets. But their presence is very much appreciated by the domain, application and presentation layers. The presentation layer can use the information to constrain the input fields, and both the domain and application layer can feed these facet values to validators (LengthValidator, RegularExpressionValidator, Int32RangeValidator, ...).
The xml representation is both a blessing and a curse. On one side, it's very easy to get up and running (using an xml schema to drive the intellisense and validation). It feels like a modelling tool if the schema is what you start out with. If the domain model is already in place it's a pesky task. Maintenance wise, however, it's a little devil. Having a validator to compare the declarative xml representation against an assembly is not a luxury. Keeping the code and xml in sync is asking for trouble. I think the best way to handle this is (a) to forget this whole idea, (b) have the xml representation generate the code or (c) have the code generate (attribute-based approach) the xml representation.
But lets not forget the problem I'm trying to solve, namely preventing the scattering of the domain's meta data. Where do you store the fact a column is 5 long, how do you constrain the textbox representing that same conceptual value to only take 5 characters to have an overal nice end-user experience, and how about duplicating that value once more in the domain layer so that other "clients" of your code play by the rules? How do you deal with change and know where to look if 5 becomes 10?

Collection classes and behavior

yreynhout — Mon, 04 Apr 2005 22:03:00 GMT

Lately I've come up with a technique to implement custom finders/queries/filters on my collection classes. Instead of implementing these finders/queries/filters directly in the collection class itself, which gets in the way of generating these types of classes anyway (for the record, I am aware of techniques like CodeSmith's merge regions), I defined a set of new behaviors:
/// <summary>
/// Behavior for things that can be evaluated.
/// </summary>
public interface IPredicate {
    /// <summary>
    /// Evaluates the specified obj.
    /// </summary>
    /// <param name="obj">Object to be evaluated.</param>
    /// <returns><c>true</c> if obj meets the predicate; otherwise <c>false</c>.</returns>
    bool Evaluate(object obj);
}

/// <summary>
/// Behavior for collections from which items can be extracted using the given <see cref="IPredicate"/>.
/// </summary>
public interface IExtractable {
    /// <summary>
    /// Extracts the items from the collection given the specified predicate, leaving only the items that didn't meet the predicate.
    /// </summary>
    /// <param name="predicate">Predicate used to evaluate items against.</param>
    /// <returns>A collection of items that meet the given predicate.</returns>
    object Extract(IPredicate predicate);
}

/// <summary>
/// Behavior for collections that can be filtered using a given <see cref="IPredicate"/>.
/// </summary>
public interface IFilterable {
    /// <summary>
    /// Filters the items in the collection given the specified predicate, effectively removing the items that match the predicate.
    /// </summary>
    /// <param name="predicate">Predicate used to evaluate items against.</param>
    void Filter(IPredicate predicate);
}

/// <summary>
/// Behavior for collections from which items can be selected using the given <see cref="IPredicate"/>.
/// </summary>
public interface ISelectable {
    /// <summary>
    /// Selects the items in the collection given the specified predicate but leaves all items in the collection.
    /// </summary>
    /// <param name="predicate">Predicate used to evaluate items against.</param>
    /// <returns>A collection of items that meet the given predicate.</returns>
    object Select(IPredicate predicate);
}
Next I implemented the ISelectable, IExtractable, IFilterable in my collection class template (regardless of the templating mechanism you use). I even provided typed implementations of these methods (using explicit interface declaration).
Foreach rule/condition I've come across in code, I've created a class implementing IPredicate. Feeding instances of my predicate classes to my collection classes allows me to perform either select, extract or filter operations on them. I've even taking this a step further and implemented a CompoundPredicate which basically is a collection of predicates and a predicate decision combinator (IPredicateDecisionCombinator). When a compound condition is passed to one of the select/extract/filter methods, multiple conditions are evaluated at once and the way the result of these evaluations are combined is the concern of the predicate decision combinator (so you can vary from the simple boolean and/or).
There's some room for improvement, namely the Select and Extract could return ICollection or IList instead of object, but that's a matter of taste to me.
The beauty of this solution is that the condition (predicate) is totally separate from the function (extracting, filtering, selecting) I want to perform on the collection. Conceptually it is quite similar to Predicate<T> in .NET 2.0 or to IComparer and the Sort method in .NET 1.1 and to some extent to closures. Ofcourse in 1.1 it requires a little more work on your behalf, namely passing around contextual data via the constructor of the predicate whereas in 2.0 anonymous methods will do most of the lifting for you.

SCC in Microsoft Visual Studio.NET 2002/2003: The good, the bad and the ugly

yreynhout — Wed, 06 Oct 2004 19:45:00 GMT

GrantRi inquires about what type of SCC the hobbyist programmer uses. I was going to write a comment, but decided to rant about what has been annoying me with SCC in VS.NET 2K2/3.

There are several reasons not to use the standard scc integration. For one, all this source control information is persisted inside the solution and/or project files. If you have ever tried to branch a solution, you will know what I mean. If you open the solution, you will notice that it is "bound" to the source control location it was originally branched from. To "bind" to the new location, you can use the "Change Source Control" functionality of VS.NET. In some cases you may want to get rid of this source control information. In that case you have to use the "unbind" functionality in VS.NET or alternatively alter the solution and/or project files by stripping the source control information. Secondly, the solution load time is increased if you use the SCC integration. Thirdly, if you use web projects and want to use your main development and branch versions concurrently, you're in for a big mess (although this statement also applies to other source control systems).
The only positive thing about the source control integration is that using "Open from Source Control" a solution is "gotten" automagically (provided you accept that web projects are "gotten" to your local wwwroot ).

For those who want to use the standard SCC integration in VS.NET with other sourcecontrol systems, you can use:
Working with CVS: http://www.pushok.com/soft_cvs.php
Working with SVN: http://www.pushok.com/soft_svn.php

Personally, I'm leaning towards Subversion(Server), TortoiseSVN(Client) and ANKH(IDE Integration).

WSE 2.0 Extensibility: From spec to code

yreynhout — Sun, 27 Jun 2004 22:03:00 GMT

I've started work on a WS-ReliableMessaging implementation over at Plumbwork.Orange. Although I haven't made any serious advances (usability wise), it already shows that WSE 2.0 extensibility model is awesome! If you plan on writing an implementation of a spec yourself on top of WSE 2.0, dig in using Reflector or fetch a fresh copy of the Plumbwork.Orange source.

So, how's the code organized? You have a WS<spec>.cs containing all the string identifiers (namespace, actions, element names and attribute names) relating to the spec. This class has a real "add code as we go" feeling to it. Next up are the elements and their associated attributes described in the spec. Basically you need to provide an object model, and write the serialization & deserialization code for each element. The namespace in Microsoft.Web.Services2.Xml will provide usefull services in this area. Carefully examine the spec to see if you need to derive from OpenElement (allowing any (elements) and @any (attributes)) or OpenElementElement (allowing only any (elements)). The structure of these element classes smells like what xsd.exe /c would generate for you (instead of attributes, think deriviation and add the implementation of an IXmlSerializable look-a-like). If the spec exposes service methods, then add a <spec>Service class (as you would implement a regular webservice using WSE 2.0) and provide the implementation for those methods using the element classes you've created. If the spec requires the use of custom headers, derive from SoapInputFilter and SoapOutputFilter (found in Microsoft.Web.Services2) and handle the headers (again) using the element classes.

In a follow-up post I'll discuss where soap faults and policies go...

From the trenches: WseWsdl2.exe

yreynhout — Thu, 03 Jun 2004 23:15:00 GMT

This post has been deprecated by WSE 2.0 SP1 (they've added the "name" commandline parameter to wsewsdl2.exe).

"This WSDL to SoapClient tool generates proxy code for Web service clients from WSDL files."

The documentation states you can retrieve the WSDL via soap.tcp:
"Soap.tcp locations will be retrieved with a SOAP message ("GetDescription")."

Well, the documentation is not correct. First of all its not GetDescription but RequestDescription. Second, you need to inherit from SoapService in order to get the RequestDescription out-of-the-box. The GetDescription method exists in the SoapReceiver class and by default returns null. So if you happen to inherit from SoapReceiver(which BTW SoapService inherits from), you can provide an implementation for SoapReceiver.GetDescription. But this buys you nothing. You need to provide a method with a SoapMethodAttribute which has a value of SoapReceiver.RequestDescriptionAction (== "http://schemas.microsoft.com/wse/2003/06/RequestDescription").

Nevertheless, I did not get it to work properly (the proxy generation using soap.tcp that is). I kept on getting "Microsoft.Web.Services2.Addressing.AddressingFault: Destination Unreachable". On the net I found one other place where this was mentioned, but no reply. The funny thing is, that if I requested the description using a self-fabricated class inheriting from SoapClient and defined the RequestDescription method using the proper SoapMethod attribute, I got the WSDL back. So I started digging a little using Reflector and came to the conclusion that there was only one main difference between WseWsdl2 and my custom implementation. I used an EndPointReference with both an Address and a Via to initialize SoapClient, whereas WseWsdl2 used the constructor of EndPointReference specifying only the Address. So I changed my code to use the same constructor, and low and behold, I got the same error. If address (specified on the SoapService itself via the SoapActor attribute) and via are the same, WseWsdl2 should work over soap.tcp!

I whipped up a little tool to call the soap.tcp RequestDescription method using the proper EndPointReference constructor.
Usage: soaptcpwsdl /address:<uri> /via:<uri> /output:<wsdl file>
You can use WseWsdl2 on the wsdl output to generate the proxy class.

UPDATE: Seems like I'm not the only one experimenting [http://weblogs.asp.net/gsusx/archive/2004/06/08/151351.aspx]
UPDATE: Aaron Skonnard points out the use of WseWsdl2 [http://www.pluralsight.com/aaron/default.aspx?key=2004-06-04T21:48:22Z]

WSE 2.0 Guts

yreynhout — Tue, 01 Jun 2004 23:25:00 GMT

For the last couple of days I have been stairing at the inner workings of WSE 2.0 (using that well known tool) and I must say it's a fine piece of craftmanship. My focus has been on the Microsoft.Web.Services2.Messaging namespace, which provides the infrastructure (at long last) to host a soap server in your own application (without reverting to ASP.NET runtime hosting). It takes a while to wrap your head around the workflow because I've never seen that many asynchronous methods used together. It is a good example of how to use delegates, asynccallbacks, waithandles, ... to provide a scalable messaging solution.

WaitHandleAsyncResult (found in Microsoft.Web.Services2) was a new concept to me. Basically an IAsyncResult implementation that doesn't fire an AsyncCallback until a WaitHandle is signalled. Very powerfull for multi-threaded communication and it's public(better rebuild it yourself in case they pull it from WSE 3.0). Too bad these kind of patterns don't get more attention. Another nice example (although hidden from the public eye) is Microsoft.Web.Services2.Messaging.SoapClient+SoapClientAsyncResult which shows you how to asynchronously send a soap request and on send completion, sit around and wait for the response to get back (again, asynchronously).

When building your own transport, beware to derive your custom Soap<transport>InputChannel from SoapInputChannel, unless you plan to rewrite SoapTransport.DispatchMessage. An interface-based contract would have done the trick here, but I must agree that it probably would have confused the custom transport developer. SoapInputChannel internally uses a System.Collections.Queue to buffer messages and SoapTransport.DispatchMessage puts them into the buffer. Also note that you can't configure your custom transport (and thus scheme) using the configuration file. You must do this in code (or write your own config section handler which does the lifting). For some reason, the folks implementing the SoapTcpTransport where not happy using the Begin/EndAccept members of a socket, and implemented a windows socket event sink. They must have had their reason for doing this ... wonder what it could be.

All in all a nice release ... one we can learn from.

UPDATE: Steve Main shows us how to configure your custom transport (scheme) using the configuration file [Permalink]

UPDATE II: After doing some more digging (actually stairing at same code over and over again) I finally found what I had been misinterpreting. If you specify a type attribute on the <messaging><transports><add> tag, another branch of the code is executed which does the transport type loading.

So to conclude,

SOA and the domain model

yreynhout — Sun, 07 Mar 2004 22:14:00 GMT

Frans Bouma touches the architectural topic of object-message mapping (or what Martin Fowler calls Data Transfer Object).

Do we need an domain model when working in a SOA (a.k.a. the moving target of today) environment and hence a way to map SOA's message oriented nature onto the object oriented nature of the domain model? I think it's a matter of context, complexity, personal architectural liking and who was there first, namely the chicken(SOA) or the egg(domain model)?

Context:

What's a service?
How do you envision your services?
Who will be the consumer of your services and to what end/purpose will they be consumed/used for?

Complexity:

How complex will the logic behind your service to be?
Exactly how coarse-grained are they (your services) going to be?
Are you going to reuse the logic inside your service (e.g. in another service)?
Are you going to reuse that logic in a non-SOA environment?
Will a domain model allow you to better understand and maintain your logic?
What's the added value of having a domain model behind your service?

Personal Architectural Liking:

How did you develop services before the SOA hype?
Is a service an orchestration of cooperating domain objects or an orchestration of other services and messages, to you?

Do Da Unit Testing Database

yreynhout — Tue, 02 Mar 2004 22:41:00 GMT

When working with temporal data stored in an RDBMS it can be tricky to do proper unit testing (actually it's nearly impossible). Essentially, to be able to re-run unit tests you need to be able to restore time and space like it was the previous run. A technique I found usefull was explicitly setting the system time before starting the actual test (PInvoking a Win32 API). After the test had run, I'd just sync up with the domain controller using net time. Ofcourse, it's never going to be 100% the same, but for most non-real-time systems this will do.

A common problem when doing unit testing is restoring a database(SQL2K) reliably to a known state. The good news is that it's quiet simple (and compared to database recreation via scripts, very fast)!

Make sure your database has it's AUTO_CLOSE option set. Detach it and remember where that .mdf is located!
The connection string used by your DAL or ObjRelMapper should look like: "Data Source=(local);Initial Catalog=MyDataBase;AttachDBFilename=D:\MyDataBase.mdf;Pooling=false;Integrated Security=true;"

AttachDBFilename points to the detached database(a copy would even be better).
Pooling=false ensures you will be able to detach the database later on (should we want to) and that you can re-run the unit tests without exiting the test environment.

If you want to detach your database, use a connection string which connects to the master database and do an sp_detach_db of your test database. This will allow you to move the .mdf around.