Web services Design Feed

Session-Materialien von der BASTA! Spring 2015

Hier sind die Folien zu meinen Sessions auf der BASTA! Spring 2015 in Darmstadt:

 

Vielen lieben Dank an alle Teilnehmer und an die Organisation der Konferenz!

Bis zum nächsten Mal Smile


You think WCF needs more of ‘you’? Go and vote for your most desired features now

The WCF team has set up a uservoice page for voting on WCF v-Next features. Go ahead and influence WCF!


Light-weight web-based architectures: Web APIs & Services (or: ASP.NET vs. WCF?) – a personal view

As much as I like WCF (and as much as I made money with it in the past years) – I think it is now time to re-think some approaches and some architectural ideas. What is ahead of a lot of us is what I call ‘light-weight architectures for reach’.

Just to give you some scope: I am one of the original Digerati board members of Indigo (WCF). Some people say I know WCF inside-out - I have given several dozens of introductions to WCF in seminars, conference and user group sessions world-wide and did numberless consulting gigs in Europe with WCF (and no, I did not really find time to write a book – besides a chapter here).

OK, so here goes...

There is currently a shift - or rather a new focus - in distributed application architecture. And no, I am not going to call it REST and I am not saying it is the one and only true thing from now on. But we have new drivers like application mash-ups, mobile devices and cloud computing which force us to move away from the good old feature-rich (and somehow heavy-weight) SOAP-based approaches. This development and this need is non-discussable and undeniable. One possible solution to these new needs is the use of light-weight Web APIs (which can be evolved into a REST-ful API or be used 'just' in an RPC-ish way).

So, which technology framework should we as .NET developers choose to build Web APIs? One choice is to leverage WCF's WebHttp model. After working with it for some years I quickly noticed a number of shortcomings (testability/mockability, serializers, ...) and wished that Redmond would come up with something better. *Of course* it had to be WCF, it had to be part of the overall "let's abstract away communication 'details'". And so it happened that they announced WCF Web API (and I was lucky enough to be part of the advisory board, again). All was fine in my world. It seemed.

Fine until I again realized that it has shortcomings when building some more flexible and advanced Web APIs. But this time it was actually the fact that the limitations were in WCF itself. The 'SAOP message' model of WCF just does not fit at all into this world. Everything the team tried to accomplish and to provide features for a web-based paradigm was just trying to put the round into the rectangle (and vice versa). For a web-based base framework maybe WCF is not the right choice.
And it turned out that there is a very good framework that can deal with the web and HTTP in a fantastic way. So, the decision to build a .NET web API framework on ASP.NET (and ASP.NET MVC, to be more precise) was somehow natural.
I personally had one very strong wish - something I have learned in the past years is invaluable for a lot of our customers... self-hosting! So, the advisors pushed hard to get self-hosting, and here it is: we can perfectly build our own host processes and host the exact same Web API implementation either there or in IIS/ASP.NET.

Today, I am quite happy with what happened. The only issue I still have is the name: I would definitely have not called it ASP.NET Web API, but rather .NET Web API. If you are working in my geographical area then you may understand why.

Anyway... talking a bit about application architecture (.NET server-side):
I would build a WCF service and an ASP.NET Web API (at least with the RPC-ish approach) as a facade only - the actual logic (business logic or data/resource access) is hidden beyond that facade. With this simple pattern it is no problem to have both WCF SOAP services and ASP.NET Web APIs sitting right next to each other happily ever after. I am doing it all the time. And you are then actually in the power to leverage the full power of each framework - get the most out of SOAP/XSD/WSDL/WS-* and the best out of web APIs/REST/whatever.

Fact is, I am using Web APIs quite a lot these days as we are building cloud-based systems in an increasing number and also cross-device mobile apps.

My 2 services cents.
Flame away.


thinktecture WSCF.blue has hit the 10,000 downloads landmark on CodePlex

After thinktecture StarterSTS has hit the 5,000 downloads mark a few weeks ago (congrats again, Dom!), we now have hit 10,000 for our WCF-based Web Services contract-first tool WSCF.blue.

[Want to learn more about it and the idea behind it…? Read this MSDN Magazine article]

Thanks to a great team!

image


thinktecture StarterSTS now officially ‘powered by Windows Azure’

A few hours ago I got the final notice that StarterSTS is now officially allowed admittance to the Azure Cloud olymp:

 

OK, Dominick: up to releasing 1.5… Smile


Whitepaper: The ins and outs of data type interop between .NET/WCF and Java – add it to your [web] services tool belt

Recently, Buddhike and I wrote a whitepaper for MSDN which details the mapping of .NET/WCF and Java data types in a XML/XSD-ruled world.

As a developer it’s almost inevitable running into XML-based Web Services these days. Literally, they are everywhere. Web Services are often available as either REST style services or SOAP messaging style services built using various tools and running in different operating environments. Therefore, a number of standards have been defined over the years in order to ensure seamless interoperability between Web Services running in different operating environments. However, it is still somewhat challenging to develop interoperable Web Services because of how different platform vendors support industry standards. This whitepaper is written based on an interoperability analysis carried out between .NET 4 and three major Java based platforms - IBM Web Sphere, Oracle WebLogic and Oracle Metro (referred as Java client/server systems hereinafter).

Interoperable Web Services use universal type system - XML Schema Definition (XSD) constructs to define the data and message structures used for communication. However, the advanced tools and runtimes used for Web Service development usually abstract the details of XSD (and other protocols) from the developer. As a result developers can elaborate their Web Services using the programming language artifacts they are familiar with and leave the heavy lifting to the tooling/runtimes to translate those into the standard format. Even though some developers favor developing their type system using XSD (also known as schema first development), interoperability issues still arise due to limitations in various platforms for some XSD features. In this whitepaper, our analysis primarily focuses on the interoperability problems that occur while translating XSD artifacts to various platform level artifacts and vice versa.

[…]

Some illustrations used in paper are considered as bad practices for designing Web Service contracts. This paper acknowledges those shortcomings but provides those samples nevertheless to demonstrate the consequences.


Topics being covered:

  • Primitive Types
    • .NET Server to Java Clients Mapping
    • Java Server to .NET Client Mapping
  • Arrays and Abstract Data Types
  • Date & Time
  • Guid
  • List
  • Dictionary
  • Queue
  • Stack
  • Tuple
  • Binary Data
  • Programming Language Constructs
    • Inheritance
    • Generics
    • Interfaces

Hope this article helps someone out there.


Using JSON.NET as a default serializer in WCF HTTP/Web/REST (vNext)

Just yesterday a client walked up to me and asked how to replace the default JSON serializer in WCF’s web programming model (whether in .NET 3.5 or 4.0).
Honestly, this is not too easy – if you aim at adding a different JSON engine - like the wonderful JSON.NET – to the WCF pipeline you won’t have too much fun. A lot of plumbing works needs to be done. A more practical approach is to use Message or Stream as the response/request type and apply the serialization/deserialization inside the service façade operation implementation.

I thought there should be an easier and more HTTP/Web/Rest-style way to do this.

Good news: I found one.
Bad news: it is based on the WCF HTTP Preview 1 (and thus non-RTM bits)

To get you up and running with the ideas of WCF HTTP vNext please refer to the master–of-disaster-PM Glenn Block’s blog Smile

 

So, in order to support JSON.NET all I had to do is to write a custom media type processor by deriving from MediaTypeProcessor. Please also refer to Cibrax’ great blog entry about versioning REST services with processors.

Here is a little sample for the JsonNetProcessor class::

namespace Microsoft.ServiceModel.Http
{
    using System;
    using System.Collections.Generic;
    using System.IO;
    using System.ServiceModel.Description;
    using Microsoft.Http;
    using Newtonsoft.Json;
    public class JsonNetProcessor : MediaTypeProcessor
    {
        private Type parameterType;
        public JsonNetProcessor(HttpOperationDescription operation, MediaTypeProcessorMode mode)
            : base(operation, mode)
        {
            if (this.Parameter != null)
            {
                this.parameterType = this.Parameter.ParameterType;
            }
        }
        public override IEnumerable<string> SupportedMediaTypes
        {
            get
            {
                return new List<string> { "text/json", "application/json" };
            }
        }
        public override void WriteToStream(object instance, Stream stream, HttpRequestMessage request)
        {
            var serializer = new JsonSerializer();
            
            using (var sw = new StreamWriter(stream))
            using (var writer = new JsonTextWriter(sw))
            {
                serializer.Serialize(writer, instance);
            }
        }
        public override object ReadFromStream(Stream stream, HttpRequestMessage request)
        {
            var serializer = new JsonSerializer();
            using (var sr = new StreamReader(stream))
            using (var reader = new JsonTextReader(sr))
            {
                var result = serializer.Deserialize(reader, parameterType);
                return result;
            }
        }
    }
}

 

Very straight-forward and actually almost too easy. As JSON.NET also supports binary JSON, named BSON, I added another class BsonProcessor for this as well:

namespace Microsoft.ServiceModel.Http
{
    using System;
    using System.Collections.Generic;
    using System.IO;
    using System.ServiceModel.Description;
    using Microsoft.Http;
    using Newtonsoft.Json;
    using Newtonsoft.Json.Bson;
    public class BsonProcessor : MediaTypeProcessor
    {
        private Type parameterType;
        public BsonProcessor(HttpOperationDescription operation, MediaTypeProcessorMode mode)
            : base(operation, mode)
        {
            if (this.Parameter != null)
            {
                this.parameterType = this.Parameter.ParameterType;
            }
        }
        public override IEnumerable<string> SupportedMediaTypes
        {
            get
            {
                return new List<string> { "application/bson" };
            }
        }
        public override void WriteToStream(object instance, Stream stream, HttpRequestMessage request)
        {
            var serializer = new JsonSerializer();
            
            using (var writer = new BsonWriter(stream))
            {
                serializer.Serialize(writer, instance);
            }
        }
        public override object ReadFromStream(Stream stream, HttpRequestMessage request)
        {
            var serializer = new JsonSerializer();
            using (var reader = new BsonReader(stream))
            {
                var result = serializer.Deserialize(reader, parameterType);
                return result;
            }
        }
    }
}
 
Well. This is it. No more buzz.
Now let’s register the new processor with the pipeline by implementing a custom host configuration:
public class MyResourceConfiguration : HostConfiguration
{
    public override void RegisterRequestProcessorsForOperation(HttpOperationDescription operation, IList<Processor> processors, MediaTypeProcessorMode mode)
    {
        processors.Add(new JsonNetProcessor(operation, mode));
        processors.Add(new BsonProcessor(operation, mode));
    }
    public override void RegisterResponseProcessorsForOperation(HttpOperationDescription operation, IList<Processor> processors, MediaTypeProcessorMode mode)
    {
        processors.Add(new JsonNetProcessor(operation, mode));
        processors.Add(new BsonProcessor(operation, mode));
    }
}
Done.
Looking forward to more Web/HTTP goodness for WCF vNext
(and yes, feel free to discuss with me why bother about WCF at all when it comes to
HTTP-close-to-the-metal-programming…).

Slides & Samples für meine Vorträge auf der BASTA! 2010 in Mainz

Wie immer war die BASTA! ein interessantes Erlebnis und ich bedanke mich bei allen Teilnehmern, die in meinen Vorträügen waren – es hat sehr viel Spaß gemacht und ich hoffe, Sie konnten viele neue Ideen und neu Gelerntes mit ins Büro und mit nach Hause nehmen. thinktecture war dieses Mal mit allen Experten vor Ort.

Hier finden Sie die Slides & Samples von meinen drei Vorträgen (außer die MonoTouch Samples):


Bis zur nächsten BASTA!


"A highly recommended tool"

This is good to read – just feels good:

Was suprised at the lack of contract-first (from WSDL) support in WCF, but your tool came to the rescue. It allowed me to generate WCF proxies from a Java web service, getting all the attribute markup on the proxy correct first time. This saved me hours and hours of laborious manual trial-and-error. Thank you - a highly recommended tool

http://wscfblue.codeplex.com/releases/view/46259#ReviewBy-rob_levine

If you want to try out WSCF.blue be sure to download the latest version 1.0.10 here:
http://wscfblue.codeplex.com/releases/view/48529