Here is a short reference table of WCF / mORMot SOA features and implementation patterns.

   

Feature WCF mORMot
Internal design SOAP RESTful
Hosting exe/service/ISS/WAS in-process/exe/service
Scalability/balancing up to WAS by dedicated hosting
MetaData WSDL none (only code)
Data contract class class/record
ORM integration separated integrated in the model
Service contract interface + attributes interface + shared Model
Versioning XML namespace interface signature
Message protocol SOAP/custom RESTful
Messaging single/duplex stateless (REST)
Sequence attributes on methods interface life time
Transactional fully transactional on implementation side
Instance life time per call/per session/single per call/per session/per user/ per group/single
Configuration .config file or code code
Operation synchronous/asynchronous synchronous (REST)
Session available (optional) available (optional)
Encryption at Service level at communication level
Compression at Service level at communication level
Serialization XML/binary/JSON JSON (customizable)
Communication protocol HTTP/HTTPS/TCP/pipe/MSMQ HTTP/HTTPS/TCP/pipe/GDI/in-process
HTTP/HTTPS server http.sys http.sys/native (winsock)
Security Attribute driven User group driven
Weight Middle Low
Speed Good High
Extensibility verbose but complete customizable
Standard De facto KISS design (e.g. JSON, HTTP)
Source code Closed Published
License Proprietary Open
Price Depends Free
Support Official + community Community
Runtime required .Net framework (+ISS/WAS) None (blank OS)

We may be tempted to say that mORMot SOA architecture is almost complete, even for a young and Open Source project.
Some features (like per user or per group instance life time, or GDI local communication) are even unique to mORMot.

Of course, WCF features its SOAP-based architecture.
But WCF also suffers from it: due to this ground-up design, it will always endure its SOAP overweight, which is "Simple" only by name, not by reputation.

Having no WSDL description may be an issue about service consumption. There is a probable axis of improvement in this direction.
On the other hand, there are several SOAP library access available for Delphi, including the one shipped with the product. So if you need WDSL / SOAP, use the existing one!
Then when performance, scaling, RESTful approach, JSON (therefore AJAX) and easy of use comes in mind, use our mORMot services.
From my little experiment, SOAP is great as a public gateway protocol, but fails into its heaviness and poor performance when it comes to scaling SOA design.

But IMHO the only missing feature of mORMot SOA is transactional process, which must be handled on server side, within the service implementation (e.g. with explicit DB commit or rollback).

Therefore, Event Sourcing design has been added to the mORMot road map, in order to handle transactions on the SOA side, relying on ORM for its data persistence, but not depending on database transactional abilities.
In fact, transactions should better be implemented at SOA level, as we do want transactions to be database agnostic (SQLite3 has a limited per-connection transactional scheme, and we do not want to rely on the DB layer for this feature).
Event Sourcing sounds to be a nice pattern to implement a strong and efficient transactional process in our framework - see http://bliki.abdullin.com/event-sourcing/why

We'll definitively include both CQRS (aka Command Query Responsibility Segregation) and Event Sourcing features within mORMot.
We have at hand all needed low-level stuff to include it very easily. We have even some bricks which may be it much more native to deal with than with the current .Net or Java implementation of those patterns (like our code for serialization of interface calls into JSON, or the direct creation of fake class types to implement a given interface).

Comments are welcome in our forum.