With many web 2.0 applications there’s a basic three-tier architecture..   In our case the client is a Flex 3/Caringorm application, the Services are WCF/ASP.NET Web Services, and the Database SQL 2005.

One of the typical approaches to creating Web Services for this type of system is to use a CRUD type pattern. That is: all methods are based around either Creating, Retrieving, Updating, or Deleting records.  In most usually done on a per-table basis, and means that you’re effectively making the Web Services a HTTP enabled SQL client.

For our situation, this wasn’t really appropriate for a number of reasons, including complex relationships between tables, and a need to reduce the amount of network traffic.

Another concern, although relatively minor, is to reduce the amount of work needed by the Flex team to implement the Web Services. 

Ideally, we wanted to be able to share business objects as widely as possible, to reduce the amount of rework needed by everyone involved in implementing the interfaces.

Therefore we chose to go with task, or semantic based methods, and using the objects as needed by the Flex front-end.  The work of validation, and mapping to appropriate tables would be done by the Web services.

An example of this might be that a Document had many properties, such as Media Items (pictures, video, etc), Tags, Authors, etc.  However, within the database there might be a necessity to track Document Versions, What versions are Live, the relationships between Documents, Document Versions and Media Items. 

Because the objects that I needed to send/receive didn’t match the objects that needed to be saved in the database, I needed to write a lot of “left hand/right hand code”: ServiceDocument.Property =   SQLDocument.Property.  Most of this was fairly simple code to write, but tracking the places where this takes place can be grow to become quite a challenge when the solution grows to dozens of tables.

This is an approximate list of what I need to do to add a property to one table:

• Add the Property to the Service Types
• Add conversion pieces to transpose the Service Type to/from the LINQ to SQL Object equivalents.
• Add the column to the Table in the Database Model for LINQ to SQL
• Add the column to all Stored Procedures in the Database Model which reference this, removing and re-adding them if this means new properties too.  Don’t forget to ensure the return types on the re-added Stored Procedures are set correctly.
• Add the columns to the actual Stored Procedures, update parameters, etc
• Add the column to the actual Table

I can only imagine the Version Control conflict chaos that would ensue if you had several people making these changes concurrently.

I highly recommend grouping changes into a per-table basis, because it can take a while to go through all the additional pieces you have referencing the LINQ to SQL and Service Type object equivilents.

Here’s two things that caused me a bit of pain when working with WCF. Hopefully these pointers should help you get back to more productive things.

No Output when returning Serialized / Serialised objects.

I had been working on adding a significant number of methods and properties to a series of classes, and when I went to test the service I got literally no output.

Debug points indicated that all properties were there, and valid - but still WCF wasn’t returning anything. There was no exceptions  being returned to the client.

The best tool for debugging these sorts of solutions is to first of all enable Tracing and MessageLogging.  This is done via the WCF Service Configuration Editor, on the Diagnostics tab. 

Once you’ve done that, and re-run the projects - you can open up Service Trace Viewer.  For me under Visual Studio 2008, this was under Microsoft Windows SDK v6.0A > Tools.

This tool then lets you open up the trace log generated in your solution directory, and see all the activity that’s been happening.

From here, it was just a matter of scrolling down to the activity entry that had the yellow hilighting (indicating a warning), selecting it - then clicking on the Errors.

For me, the first time this happened to me, it was because I had stuffed up the DataMember Name values. It has also occurred for other reasons, such as a property not being populated, when I had specified that it was both required, and also that it could not emit a default value.

Can’t get mex to work

No, this isn’t a misguided racial slur. I was having issues setting up the mexHttpBinding on an ASP.NET AJAX WCF Service.

The solutions all point towards the same thing, that you need to set up an endpoint, and set the contract to IMetaDataExchange, then set the behaviour to have <serviceMetadata />. Except that it just wouldn’t let me add that property to my endpoint behaviour, and whenever I changed it to a service behaviour it would then not allow me  to set the other properties I needed for that.

Well, perhaps I’m particularly slow - but hopefully this pointer will help someone else.

1: Create a NEW service behaviour:

<serviceBehaviors>
  <behavior name="MyServiceBehavior">
    <serviceMetadata
      httpGetEnabled="true"/>
    <serviceDebug
     includeExceptionDetailInFaults="true"
     />
  </behavior></serviceBehaviors>

2: Add a new endpoint to your  existing service

<endpoint
   address="mex"
   binding="mexHttpBinding"
   bindingConfiguration=""
   contract="IMetadataExchange" />

3: Add the behaviorConfiguration you added in Step 1 to the Service (NOT the endpoint).

<service
  behaviorConfiguration=”MyServiceBehavior”
  name=”MyProject.MyService”>

I kept trying to add it to the endpoint, and failing miserably. So much time spent back-and-forth on this!

That’s it for this instalment of “WCF is great, but I wish the config was a bit easier to understand”. Stay tuned for more exciting episodes!

Today I spent about half an hour banging my head against this problem:
Whenever I would try and return a business object, I’d simply get no response from my WCF Service. Litterally nothing.

The problem turned out to be that I had accidentally specified the DataMember Name of a property in a sub object twice.

So, I had my broken class set up like:


[DataContract(Name = "MyClass", Namespace = "Example")]
public partial class MyClass
{
[DataMember(Name = "property1")] public int Property1 { get; set; }
[DataMember(Name = "property1")] public string Property2{ get; set; }
}


An instance of this class was used as a property in another object, which was being returned from WCF.

.NET didn’t throw any sort of error unless I tried to return just “MyClass”.

Sure, it was my fault, but if you have a complex data structure, this could get awefully difficult to find without some sort of message from WCF.

Yes, this is part of that ultra nifty WCF JSON .NET 3.5 Flex project at work.

(A note to readers: This is all pure geek/coder content - Please skip this if nothing in the subject line makes sense)

I started on a new project at work for a client a bit over a week ago, by virtue of the requirements, we decided to investigate the use of new version of Microsoft’s  .NET Framework, Version 3.5, for all of the server-side services.

Microsoft have been quite strongly pushing the benefits of the new features of .NET 3.5. There’s been a few key features which are particularly interesting, and if all goes according to the marketing hype, should end up saving a huge amount of time and effort, whilst ensuring that we use well known and standardised interfaces.

What features?

Windows Communications Foundation (WCF) is particularly interesting because it promises to let you (mostly) remove the whole ‘how’ and ‘where’ portion of communications between tiers, and let you focus on the ‘what’ and ‘when’.

In essence, WCF should let me state that I want to create (say) a Web Service, that accepts information in format X, and outputs responses in some other format. It doesn’t have to be a Web Service either, it could be a Peer to Peer network speaking in straight binary streams.

For this project the client-functionality is all in Flex, so we need to ensure that the Flex guys can quickly decode all the responses and turn them into Action Script objects. Through a bit of experimenting and application prior experience - Web Services speaking JSON appeared to be the easiest and most light weight method of doing this.

Language Integrated Queries (LINQ) is another particularly interesting technology, particularly because it lets me focus on what I want to do with the data I have, rather than spending time transforming it from the Database tables, rows, and procedures, into .NET objects and methods.

There are a number of implementations of LINQ, which enables you to query a variety of sources - the one that I’m most likely to use is LINQ to SQL (talking to SQL Server). Regardless of what I’m accessing however, the syntax is identical - again, removing the need to modify my code if I need to query an XML file, Oracle or MySQL Database, or even native .NET objects.

You can probably see a common theme here - WCF lets me focus on communication with the outside world without needing to write that interface or conversion functionality, and LINQ lets me access and manipulate data, without needing to write that interface either.

So, it’s all plug and play?

Well, that depends entirely on what you’re doing with your data. If you’ve got something like a CRM application where the client is responsible for managing (most of) the data, then yes it can quite possibly be almost plug and play if you’re going with a “CRUD” interface.

If your data structure is more complex, then you need to determine exactly where the split is. In this specific project, I’m presenting an abstracted view of the data that the client needs, and doing all of the business logic to manage data management in the SQL and Web Services Layer.

So far, the whole WCF and LINQ combination looks good. I’m hoping to post some more detailed posts later on.

Further Reading

I highly recommend Scott Guthrie’s LINQ to SQL series of posts. Start with Part 1: Introduction to LINQ to SQL

These resources have also been of a great help in getting my head around the whole LINQ thing:

• Kirk Allen Evans’s Blog : Using WCF, JSON, LINQ, and AJAX: Passing Complex Types to WCF Services with JSON Encoding
• Programming JSON with WCF in .NET Framework 3.5
• LINQ to SQL - 5 Minute Overview - Hooked on LINQ
• WCF + LINQ? - Rudi Grobler
• Talking to WCF with Flex 3 via JSON or XML