Here is a short reference table of WCF / mORMot SOA features and implementation patterns.
|Scalability/balancing||up to WAS||by dedicated hosting|
|MetaData||WSDL||none (only code)|
|ORM integration||separated||integrated in the model|
|Sequence||attributes on methods||
|Transactional||fully transactional||on implementation side|
|Instance life time||per call/per session/single||per call/per session/per user/ per group/single|
|Session||available (optional)||available (optional)|
|Encryption||at Service level||at communication level|
|Compression||at Service level||at communication level|
|Security||Attribute driven||User group driven|
|Extensibility||verbose but complete||customizable|
|Standard||De facto||KISS design (e.g. JSON, HTTP)|
|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.
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
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
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
Comments are welcome in our forum.