CQRS with WCF

[Jose Fernandez]

Hello my people!

So, i want to create a project where i use CQRS behind a WCF web service.

My first approach would be the following.

1. Create the WCF

2. Add void OperationContracts, ex; RegisterNewStudent(RegisterNewStudentCommand command)

3. Create a Command with DataContract attribute to send thru the wire.

4. In my implementation of RegisterNewStudent(RegisterNewStudentCommand command), then call directly the handler for that Command.

4.1 The reason not to have a generic ExecuteCommand<T>(ICommand) is just to provide a better web service self description of all its capabilities.

In my Controller, i would basically call WebService.RegisterNewStudent(new RegisterNewStudentCommand(){Name=model.Name}).

Is that a good approach?

Thanks

[Alexander Pletnev]

My opinion is, you have double names.
RegisterNewStudent , and RegisterNewStudenCommand, imho it's better to
have ExecuteCommand(RegisterNewStudentCommand). Much more self
descripted than yours.
Thanks.

> --
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dddcqrs+u...@googlegroups.com.
> For more options, visit [1]https://groups.google.com/groups/opt_out.
> �
> �
>
> References
>
> Visible links
> 1. https://groups.google.com/groups/opt_out

[Jose Fernandez]

That's why I said I can do that, BUT I want to offer a self descriptive API to the users, other than 20 overloading of the ExecuteCommand(whatever).

To put in perspective. Imagine you add a web reference in your project to my webservice. In your intellisense, you're going to have 1 method with 20 overloads. Wouldn't be easier to have explicitly 20 self descriptive methods. At the end of the day you must implement each one of these overloads individually. The effort is the same. You see my point?

The laziest way would had been to create 1 generic method ExecuteCommand(ICommand command) where all I have to do is call a command handler bus and pass the command... But from the outside world is totally inefficient. Imagine to have 1 magic method with 20 possible implementations of a ICommand interface in a webservice??? I know the purist would yell YAY!!! :)

Sent from my iPhone

> You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/iCcLZp6T1Lc/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to dddcqrs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Kijana Woodard]

Your public api doesn't need to conform to the implementation.

For more options, visit https://groups.google.com/groups/opt_out.

[João Bragança]

If you already have a bunch of command dtos you can use a little bit of reflection and generate the wcf contract.

--

Sent from my regular computer

http://twitter.com/thefringeninja

http://www.thefringeninja.com/

[Ben Kloosterman]

+1 on creating separate methods..

This avoids a number of problems and has some benefits.. Creating 40 methods
would take less time than it has taken to write the emails or to wire up
some Reflection.

Using KnownType and inheritance/ interfaces on the wire is fraught with
issues which can quickly cost a week or month trying to get it to work
especially when someone wants to add a non C# client to talk to the server .

Some benefits
- You can generate integration tests with the appropriate WCF call and
then get a break down of the method type with WCF diagnostics ( perfmon
counters etc) ,eg 1 method is called 98% of the time and has a high
serialization cost or is very big on the wire ( which your unit tests wont
discover and are critical to a well working distributed system)
- In WCF environments you can get complex call chains each adding latency
knowing which methods are high latency over the whole operation can be very
useful.

Ben

[Jose Fernandez]

Thanks Ben,

After reading your response, I actually feel I shouldn't even expose the command as a datacontract, but just plain native types to facilitate the life of non C# / Windows consumers. After all commands tend to be very simple DTOs with a very few properties.

Then in my implementation I can simply construct the command and send it to a message bus. Simple.

I believe in simplicity. Sometimes out colleagues chase too hard fancy code implementations and trends and forget about simplicity. They rather go for a 5 lines super complex webservice than a 40 methods easy to understand one.

At the end of the day all you are adding is simply a web service interface.



Sent from my iPhone

[Ben Kloosterman]

The easiest way to shoot yourself with Distributed systems is complex
message architectures. I remember 1 guy who I had to help who had
IList<Ilist<IConnote>> and tried to push that into a WCF message with
knownType .. he ran into some obscure C# compiler bug after a week trying to
get it to work .. and blamed MS.

My thoughts are first do you really need this ? I Always ask this for
distributed / cross process systems after you have a shared service ( which
you need ) . Note WebApi is built on WCF and can make it easier. I don't
think I would try to wrap the BC in a separate service until I found the
system cant handle it.

The WCF front end is a fascade which can provide security but in a CQRS
system it can also do a lot of work for you ..eg security , since clients
are really not trusted ideally they should not be the creators of the
command , that should be done by the logic in the Fascade..
. If you want a quick and dirty then I would simply mark the commands with
data contract but I would create many separate methods to send those
commands. For a better system as you state then create a new light API get
it to validate ,authenticate and create the commands for the write model .
However your normally going to hit some business requirement that will
require more data to be sent ..plan for that . eg if you need to upload an
order with a list of order items with widgets will these be arrays of
strings or will the Fascade have its own light types or will you share
these DTOs with the commands and domain.

Also note a bus has multi threading implications , WCF has a lot of work so
it manages all the incoming requests , schedules then , ensures there is
little contention etc ie WCF is like a message bus , by then sending it on
a bus you increase contention significantly . Queues and busses look simple
but the real life implications are quite complex as has been discussed
before. Instead of sending to a bus have you considered processing the
command directly in the WCF fascade (* note I am using a bus at the moment
but that's because its single threaded anyway)

[Damian Hickey]

WebAPI is not built on WCF. It doesn't even depend on the 'legacy' asp.net bits (System.Web).

> WCF is like a message bus

No, it isn't.

[Damian Hickey]

If you believe in simplicity, then don't use WCF. Seriously. 

If you need SOAP over HTTP, use ServiceStack. 

If you are going to do plain HTTP or, dare I say it, REST (which will be much more palatable to non C# / Windows devs), then use WebAPI, ServiceStack, NancyFX or Simple.Web. My personal preference is Nancy.

On Message vs Methods, messages will allow your system / application to expand. http://ayende.com/blog/159969/design-patterns-in-the-test-of-time-command-redux 

[Ben Kloosterman]

 

WebAPI is not built on WCF. It doesn't even depend on the 'legacy' asp.net bits (System.Web).

 

WCF doesn’t depend on System.Web either… I’m not 100% but  I seem to remember the guys saying they use WCF under the covers though that might for the latest version under development. .. Ok checking  it is less dependent now ..  System.Web.Http  was dependent on WCF but has been rewritten in the latest version .   System.Web.Http.SelfHost  is still dependent on System.ServiceModel

 

 

> WCF is like a message bus

 

No, it isn't.

 

Note “like “ not is …. You don’t thinking reading the byte stream  of the network card , serializing them into MessageContract and then dispatching them is like what a message bus does ? You can even do pub sub or order them in a queue.

 

 

Ben

[Ben Kloosterman]

I disagree  , WCF can be very simple , use a basic binding , methods and your off creating productive code. You can also do Json Rest style service

 

http://www.codeproject.com/Articles/167159/How-to-create-a-JSON-WCF-RESTful-Service-in-60-sec

 

WCF is very flexible.. you want high performance switch to tcp/ip binary channel ( for WCF to WCF only) in just a few clicks. The really nice part of WCF is you offer Soap , Rest , Shared Memory  and Tcp/ip channels so people can choose what they want ..  And Soap is really good for quickly adding a client , yes there are interop issues with Java in Soap but it’s their choice they can use Rest. What you don’t want to do is reinvent the wheel   , use basic types string, int , DateTime? ( instead of DateTime)  don’t try to push inheritance / interfaces / enums onto the wire and your off and productive within a few hours.  Datetimes are painful in json with javascript as well.

 

On Message vs Methods , there is overlap you can also expand with Methods eg DoThis(int value , Data options) , use judgement uploads should be a complex type , getbyId (int id) is ok  uploadData ( param1… param20) is not .. What’s should only be in special cases is  ReceiveMessage(MessageContract message) where you do your own dispatch into ICommand.

 

The best thing about Soap / WCF is you automatically get strongly typed proxies. Someone changes the API/Schema on the server and an expected exception will tell you the version has changed – great for early in a project . You then go update proxy via right click and hit F6 and all the information is there with intellisense to correct. No coordination or distribution of schema documents needed.

 

Rest tends to work better with lots of small amounts of data at internet scope , Soap tends to work better within an organization.

 

I will add one thing more relevant to CQRS with ES and that is normally REST results in  lots of little calls it’s a bit chatty = SQL style  .. SOAP tends to have a style where you receive or send all the information needed in 1 get or post “chunky calls”   . However in CQRS with ES your projected read model will give you all the information , it just looks non Rest ie instead of normal REST  /Customers/12 and then get other relevant information   its  /TodayCustomerDetailForm/12 .

 

Ben

 

 

 

Ben

[Greg Young]

I'm a bit boggled by "rest causes lots of little calls" where as soap "has chunky calls" designing resources poorly might cause this but I don't believe it is intrinsic. I have actually seen lots of reasons to avoid things like soap (eg frameworks make a poor abstraction over http and you end up with as example everything making a post).

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

[Damian Hickey]

From someone who knows more about the topic than the two of us combined:

http://www.infoq.com/articles/interview-servicestack

http://www.infoq.com/articles/interview-servicestack-2

[Ben Kloosterman]

Who says he knows more ... Do you know me and what I have done , do you
know him well ? While I agree with some points I disagree with others.
He seems to be saying oh we don't have the resources to do WCF so we do this
and this but looking at it , its just a subset , the same ( POCO , auto
creation of services etc etc ) .. he is delivering SOAP , wsdl , and I
don't think adding a few extensibility interfaces ( abstractions) in WCF
make any difference unless you are modifying it ( speaking of which I did a
UDP and a multi cast transport channel for WCF and it was not big deal , now
to use 2 UDP channels to create a reliable transport in Service Stack would
be much much harder) ... All in all like most things he is flogging his
own service stack.



Sure you can spend your life in WCF and read books but why ? You DON'T need
to .. You click add a service in the GUI . On the client add a proxy , and
you got your strongly typed proxy that is it , nothing else needed and it
works for 90% of the cases.. Few systems can do that . Ok you can read the
stream direct and get presented with Message Contracts whose byte[] contents
you can manually serialise into ICommands ( or have WCF dispatch them)
but there is a level of technical debt (complexity) in doing this .



When WCF was released there were almost no complaints on complexity or
bloat.. The big ones I remember

1. You can't binary serialize ( bad idea anyway in 90% of cases note
BinaryXML is allowed)

2. you can't serialize an interface or put inheritance on the wire (
yes you can use KnownType but its not worth it)

3. Other serialization issues





For those interested in another SOAP debate ...



While SOAP is complex ( and should have been done differently ...as should
TCP and HTTP and UNIX etc ) it is completely for the framework to deal with
, when you build SOAP systems you never deal with SOAP . It probably
represents like 1% of the traffic . Do you worry about TCP SYNC or FIN flag
in the header etc when using TCP as the underlying transport for http ?
Rarely - It's a non-issue.



Note I'm using REST for my read model , as that's what it is extremely well
suited for but I have done many SOAP systems . SOAP works better with
commands , services and when you have many people working together. REST
doesn't do many things SOAP based systems do eg pub sub easily to have
an easily accessible bus ( WS-Eventing is very nice) ,custom encryption /
compression , strongly typed proxies are just so useful to hit the ground
running and to promote services within an organization and to reduce stupid
bugs, by the time you throw a REST Json schema document at them , or
introduce json to C# class generators ( or XML XMI /xsd to classes for that
matter) the eyes glaze over and they stick to do it yourself / not invented
here.



REST Is very little ...all it is , is a URL mapping schema , which often
maps directly to relational data creating a very chatty interface ( less so
for CQRS read model as its denormalized ) .. it throws that on top of a Json
+HTML +TCP stack . You can do a similar mapping with SOAP but there are so
many more things SOAP can do and in many cases you need to ...



Ben

From: ddd...@googlegroups.com [mailto:ddd...@googlegroups.com] On Behalf
Of Damian Hickey
Sent: Monday, 17 June 2013 10:10 PM
To: ddd...@googlegroups.com
Subject: Re: [DDD/CQRS] CQRS with WCF

[sventevit]

We are talking about he Command part of the CQRS. What about the Query - would you put query methods in the same WCF class as command methods or different class? Do you use any naming conventions?

[Greg Young]

By definition there would be two objects not one. One would have the commands the other would have the queries.

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Alessandro Melchiori]

Hi everyone

With WCF, using KnownTypes concept, you can expose a "single endpoint" that dispatch rigth command to the right handler.

Look at Agatha (https://github.com/davybrion/Agatha) implementation for example