Synopse

To content | To menu | To search

Tag - SOA

Entries feed

2016, Thursday November 10

EKON20 mORMot Conferences

EKON20 is now over, and there was a lot of people, great speakers, beautiful T-Shirt, and fresh beer!

I've published the slides of my mORMot conferences on SlideShare...

The "classic" Synopse/mORMot slides have also been uploaded to their latest revision, so don't hesitate to check what's new!

The PDF are also available for direct download from our server.

Enjoy!

2016, Tuesday September 6

Ride the mORMot at EKON 20 in Dusseldorf!

There are still a few days for "very early birds" offer for EKON 20 conference, and meet us for 3 sessions (including a half-day training/introduction to mORMot)!
Join us the 7-9th of November in Düsseldorf!

Our sessions are not restricted to mORMot, but will use mORMot to illustrate some concepts and design ideas:

You can contact me if you want to join, so that I may give you an additional discount password!

Hope we can meet for a chat and (a few) beers!

2015, Friday December 11

Audit Trail for Services

We have seen previously how the ORM part of the framework is able to provide an Audit Trail for change tracking.
It is a very convenient way of storing the change of state of the data.

On the other side, in any modern SOA solution, data is not at the center any more, but services.
Sometimes, the data is not stored within your server, but in a third-party Service-Oriented Architecture (SOA).
Being able to monitor the service execution of the whole system becomes sooner or later mandatory.

Our framework allows to create an Audit Trail of any incoming or outgoing service operation, in a secure, efficient and automated way.

Continue reading...

2015, Saturday November 21

Try to avoid RTTI (ab)use

There is a very trendy move, since a few years, to value so called "meta-programming".
In short, it is about the ability to treat programs as their data.
It is a very powerful paradigm in functional languages, and it was also introduced to OOP languages, even in SmallTalk a long time before this concept was trendy in Ruby, C# or Java.

In OOP compiled languages, reflection is used to achieve a similar behavior at run-time, mainly via RTTI (Run-Time Type Information).
Delphi supports RTTI since its version 1, as it was heavily used e.g. for all UI streaming.
In our framework, we rely on RTTI for its main features: ORMSOA and MVC - and even in some other parts, like Desktop UI generation.

But RTTI could easily be abused.
Here are some thoughts, started as a comment in a good old Mason's blog article about how RTTI performance may be a bottleneck.
My comment was to get rid of RTTI, and follow a SOLID implementation with explicit OOP code, like use of interface.

Continue reading...

2015, Tuesday November 17

Benefits of interface callbacks instead of class messages

If you compare with existing client/server SOA solutions (in Delphi, Java, C# or even in Go or other frameworks), mORMot's interface-based callback mechanism sounds pretty unique and easy to work with.

Most Events Oriented solutions do use a set of dedicated messages to propagate the events, with a centralized Message Bus (like MSMQ or JMS), or a P2P/decentralized approach (see e.g. ZeroMQ or NanoMsg). In practice, you are expected to define one class per message, the class fields being the message values. You would define e.g. one class to notify a successful process, and another class to notify an error. SOA services would eventually tend to be defined by a huge number of individual classes, with the temptation of re-using existing classes in several contexts.

Our interface-based approach allows to gather all events:

  • In a single interface type per notification, i.e. probably per service operation;
  • With one method per event;
  • Using method parameters defining the event values.

Since asynchronous notifications are needed most of the time, method parameters would be one-way, i.e. defined only as const - in such case, an evolved algorithm would transparently gather those outgoing messages, to enhance scalability when processing such asynchronous events. Blocking request may also be defined as var/out, as we will see below, inWorkflow adaptation.

Behind the scene, the framework would still transmit raw messages over IP sockets (currently over a WebSockets connection), like other systems, but events notification would benefit from using interfaces, on both server and client sides.
We will now see how...

Continue reading...

2015, Friday October 23

Letters of Hope

As we already notified in this blog, Embarcadero has been finally bought by IDERA.

Delphi users received a letter from Randy Jacops, IDERA CEO.
Written in my mother language, in perfect French. Nice!

The letter states that they have 20,000 customers...
It sounds more realistic than the numbers usually given for Delphi "users".
Even if it counts for all their tools.
:)

In our forums, we have 1,384 registered users (real humans: we do not accept bots via a Turing test during registration).
It sounds like if Open Source projects are able to gather a lot of users.
And certainly because we maintain support from Delphi 6 up to Seattle (and even Delphi 5 for some part of our libraries)... we have for sure users using FPC/Lazarus (which we also started to support), and others which did not upgrade to the latest Delphi version!

In Randy's letter, the community has a special place.
I hope future of Delphi would see Open Source projects brought by the community as a chance, not as competition.

I'm currently working on a cloud of mORMot servers, serving content coming from high numbers of connected objects.
Object Pascal powered servers, under Windows or Linux (with FPC), are working 24/7 with very low resource use.
A lot of BigData stream is gathered into MongoDB servers, following the CQRS pattern.
It is so easy to deploy those servers (including their high performance embedded SQlite3 database), that almost everyone in my company did install their own "cloud", mainly for testing purpose of the objects we are selling...
Real-time remote monitoring of the servers is very easy and integrated. You could even see the log changing in real-time, or run your SQL requests on the databases, with ease.
When I compare to previous projects I had to write or maintain using Java or .Net, I can tell you that it is "something else".
The IT administrators were speechless when they discovered how it worked: no need of containers, no need of virtual machines (but for infrastructure needs)...
The whole stack is SOA oriented, in an Event-Driven design (thanks to WebSockets callbacks). It follows DDD principles, thanks to the perfect readability of the object pascal language.
Delphi, and Open Source, could be great to create Internet Of Things servers...

2015, Saturday August 15

Breaking Change in mORMot WebSockets binary protocol

Among all its means of transmission, our mORMot framework features WebSockets, allowing bidirectional communications, and interface-based callbacks for real time notification of SOA events.
After several months of use in production, we identified some needed changes for this just emerged feature.

We committed today a breaking change of the data layout used for our proprietary WebSockets binary protocol.
From our tests, it would increase the performance and decrease the resource consumption, especially in case of high number of messages.

Continue reading...

2015, Saturday June 6

GetIt "Spirit" Concerns

I'm confused by the GetIt Submitting official blog page.
Reminds me the darker ages of Delphi licensing change of XE3.

GetIt is the new XE8 package manager for RAD Studio. Information about how to submit your libraries to GetIt has just been made available by Embarcadero. The idea behind GetIt is really to make is easier and faster to discover, install, and keep updated some of the best open source libraries for Delphi and C++Builder.

When you look at the approval conditions, it sounds like if mORMot would not find its way in this package manager:

Replacing key capabilities that are part of the core platforms definitions such as Client/Server FireDAC pack or the DataSnap/EMS Enterprise middleware, would be less likely to be accepted.
The different SKUs are meant for different types of developers, and multi-tier capabilities with strong client/server RDBMS integration require an Enterprise edition license.
We will bias acceptance toward GetIt libraries that respect the spirit of our licensing and editions, not just use the letter of the license and the technical boundaries. If you are unsure about your submission please check with us first. 

What is this "spirit of our licensing and editions"?
Why is it not part of the official license terms?
Where does this assumption comes from?
Would the licensing conditions change in the close future, as with the XE3 "episode"?
Would Marco's interpretation become the new rule?

It clearly reminds me the XE3 time where there was an attempt from Embarcadero to modify their licence terms, so that third party vendors or Open Source libraries would not be allowed to create multi-tier frameworks with Delphi!
Is it true that "strong client/server RDBMS integration require an Enterprise edition" ?
Last time I checked the licence terms, it was not stated.
Why on earth would we have to pay for the Entreprise edition, if the Professionnal edition is all that you need?

Still the same "closed" spirit.
It is like if they know their own n-Tier solution weaknesses, so they try to avoid any other possibility, but to use their own.
They clearly do not understand the benefit and dynamic of Open Source.

I guess our little mORMot falls directly into this "unwelcomed" category.
I did not make the submission yet. But should I?
Perhaps sub-part of the framework may find its way in: SynPdf, SynCrypto, SynGdiPlus, SynCommons...
But the main ORM/SOA/REST/MVC/StubMock features would certainly be rejected.

Our Open Source project is sometimes preferred to DataSnap/EMS (or even FireDAC), not only for licence cost, but also about features, documentation, stability, compatibility with older versions of Delphi, performance, and Linux compatibility.
I have encountered several companies which are still using Delphi because of mORMot: if they did not have found it, they would have moved to C# or Java, just to be able to use a full SOA/MVC stack, which was not available, even in the "Enterprise" version of Delphi.

Story repeats itself.
I just wanted to ensure that the licensing terms would not change in that direction.
I - as many Delphi users - would not let this GetIt "spirit" become the new rule.
We have to react, as we did for XE3, otherwise we may all suffer!
IMHO Embacardero should better focus on the compiler and IDE, not cutting the branch on which they are seated...

What do you think? Comments and feebacks are welcome!

2015, Monday June 1

Updated Slides about ORM SOA MVC SOLID DDD

One year ago, we published a set of slides about the main concepts implemented by our framework.
Mainly about ORM (and ODM), NoSQL, JSON, SOA, MVC (and MVVM), SOLID, DDD, CQRS and some patterns like Stubs, Mocks, Factory, Repository, Unit-Of-Work.
Worth a look, if you want to find out the benefits of the latest software development techniques.
They try to open the landscape of any Delphi developer (probably with a mostly RAD and OOP background) to some new areas.

I just updated the slides from our public GoogleDrive folder.
They now reflect the latest state of the framework (e.g. ORM real-time synchronization, asynchronous callbacks, DDD CQRS services...).
They have also been polished after several public presentations, since I used them as base for trainings I made for some European companies.

If you want to go further, or have some more enlightenment, ensure you took a look at our framework Documentation, which would detail all those patterns, and how mORMot may help implementing them for your projects!

Feedback is welcome on our forum, as usual!

2015, Sunday May 3

SOLID Design Principles

I've just updated the documentation part about the SOLID Design Principles.
The former blog article (almost 4 years old!) sounds like a bit deprecated now...
This is why I would extract here an updated version of this material.

Ensure you checked the corresponding part of the mORMot documentation, which is the updated reference, and probably the easiest to read - including links to all the other documentation.

The acronym SOLID is derived from the following OOP principles (quoted from the corresponding Wikipedia article):

  • Single responsibility principle: the notion that an object should have only a single responsibility;
  • Open/closed principle: the notion that "software entities ... should be open for extension, but closed for modification";
  • Liskov substitution principle: the notion that "objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program” - also named as "design by contract";
  • Interface segregation principle: the notion that "many client specific interfaces are better than one general purpose interface.";
  • Dependency inversion principle: the notion that one should "Depend upon Abstractions. Do not depend upon concretions.". Dependency injection is one method of following this principle, which is also called Inversion Of Control (aka IoC).

If you have some programming skills, those principles are general statements you may already found out by yourself. If you start doing serious object-oriented coding, those principles are best-practice guidelines you would gain following.

They certainly help to fight the three main code weaknesses:

  • Rigidity: Hard to change something because every change affects too many other parts of the system;
  • Fragility: When you make a change, unexpected parts of the system break;
  • Immobility: Hard to reuse in another application because it cannot be disentangled from the current application.

Continue reading...

2015, Sunday April 12

Why Transmitting Exceptions in SOA services is not a good idea

Usually, in Delphi application (like in most high-level languages), errors are handled via exceptions. By default, any Exception raised on the server side, within an interface-based service method, will be intercepted, and transmitted as an error to the client side, then a safe but somewhat obfuscated EInterfaceFactoryException will be raised on the client side, containing additional information serialized as JSON.

You may wonder why exceptions are not transmitted and raised directly on the client side, with our mORMot framework interface-based services, as if they were executed locally.

We will now detail some arguments, and patterns to be followed.

Continue reading...

2015, Monday April 6

Asynchronous Service - WebSockets, Callbacks and Publish-Subscribe

When publishing SOA services, most of them are defined as stateless, in a typical query/answer pattern - see Service-Oriented Architecture (SOA).
This fits exactly with the RESTful approach of Client-Server services via interfaces, as proposed by the framework.

But it may happen that a client application (or service) needs to know the state of a given service. In a pure stateless implementation, it will have to query the server for any state change, i.e. for any pending notification - this is called polling.

Polling may take place for instance:

  • When a time consuming work is to be processed on the server side. In this case, the client could not wait for it to be finished, without raising a timeout on the HTTP connection: as a workaround, the client may start the work, then ask for its progress status regularly using a timer and a dedicated method call;
  • When an unpredictable event is to be notified from the server side. In this case, the client should ask regularly (using a timer, e.g. every second), for any pending event, then react on purpose.

It may therefore sounds preferred, and in some case necessary, to have the ability to let the server notify one or several clients without any prior query, nor having the requirement of a client-side timer:

  • Polling may be pretty resource consuming on both client and server sides, and add some unwanted latency;
  • If immediate notification is needed, some kind of "long polling" algorithm may take place, i.e. the server will wait for a long time before returning the notification state if no event did happen: in this case, a dedicated connection is required, in addition to the REST one;
  • In an event-driven systems, a lot of messages are sent to the clients: a proper publish/subscribe mechanism is preferred, otherwise the complexity of polling methods may increase and become inefficient and unmaintainable;
  • Explicit push notifications may be necessary, e.g. when a lot of potential events, associated with a complex set of parameters, are likely to be sent by the client.

Our mORMot framework is therefore able to easily implement asynchronous callbacks over WebSockets, defining the callbacks as interface parameters in service method definitions - see Available types for methods parameters.

Continue reading...

2015, Saturday January 10

mORMot under Linux thanks to FPC

You can use the FreePascal Compiler (FPC) to compile the mORMot framework source code, targetting Windows and Linux.

Linux is a premium target for cheap and efficient server Hosting. Since mORMot has no dependency, installing a new mORMot server is as easy as copying its executable on a blank Linux host, then run it. No need to install any framework nor runtime. You could even use diverse operating systems (several Linux or Windows Server versions) in your mORMot servers farm, with minimal system requirements, and updates.

We will now see how to write your software with Linux-compiling in mind, and also give some notes about how to install a Linux Virtual Machine with Lazarus on your Windows computer, compiling both FPC and Lazarus from their SVN latest sources!

Continue reading...

2014, Wednesday December 31

2015: the future of mORMot is BigData

How would be 2015 like for our little rodents?
Due to popular request of several users of mORMot, we identified and designed some feature requests dedicated to BigData process.

In fact, your data is the new value, especially if you propose SaaS (Software As A Service) hosting to your customers, with a farm of mORMot servers.
Recent Linux support for mORMot servers, together with the high performance and installation ease of our executable, open the gate to cheap cloud-based hosting.
As a consequence, a lot of information would certainly be gathered by your mORMot servers, and a single monolithic database is not an option any more.

For mORMot solutions hosted in cloud, a lot of data may be generated. The default SQLite3 storage engine may be less convenient, once it reaches some GB of file content. Backup becomes to be slow and inefficient, and hosting this oldest data in the main DB, probably stored on an expensive SSD, may be a lost of resource. Vertical scaling is limited by hardware and price factors.

This is were data sharding comes into scene.
Note that sharding is not replication/backup, nor clustering, nor just spreading. We are speaking about application-level data splitting, to ease maintenance and horizontal scalability of mORMot servers.

Data sharding could already be implemented with mORMot servers, thanks to TSQLRestStorage:

  • Using TSQLRestStorageExternal: any table may have its own external SQL database engine, may be in its separated DB server;
  • Using TSQLRestStorageMongoDB: any table may be stored on a MongoDB cluster, with its own sharding abilities;
  • Using TSQLRestStorageRemote: each table may have its own remote ORM/REST server.

But when data stored in a single table tends to grow without limit, this feature is not enough.
Let's see how the close future of mORMot looks like.

Continue reading...

2014, Saturday October 25

Are "Micro Services" the proper way of writing SOA?

I just wanted to share a great article by Martin Fowler, about Micro Services.

IMHO such "Micro Services" are the proper way of defining a SOA project, following SOLID principles.
If we follow the "Single Responsibility" principle, we will define small uncoupled services, which do one single task. This will fulfill the "Interface Segregation" principle, and since we rely on abstractions, the "Liskov Substitution" will also apply. By definition, the SOA catalog/publish mechanism will perform "Dependency Inversion".
All this sounds just like the definition of "Micro Services".

Worth reading, and a nice illustration of how to build mORMot applications!

2014, Friday October 24

MVC/MVVM Web Applications

We almost finished implementing a long-standing feature request, introducing MVC / MVVM for Web Applications (like RubyOnRails) in mORMot.
This is a huge step forward, opening new perspectives not only to our framework, but for the Delphi community.
In respect to the existing MVC frameworks for Delphi, our  solution is closer to Delphi On Rails (by the convention-over-configuration pattern) than the Delphi MVC Framework or XMM.
The mORMot point of view is unique, and quite powerful, since it is integrated with other parts of our framework, as its ORM/ODM or interface-based services.
Of course, this is a work in progress, so you are welcome to put your feedback, patches or new features!

We will now explain how to build a MVC/MVVM web application using mORMot, starting from the "30 - MVC Server" sample.
First of all, check the source in our GitHub repository: two .pas files, and a set of minimalist Mustache views.

This little web application publishes a simple BLOG, not fully finished yet (this is a Sample, remember!).
But you can still execute it in your desktop browser, or any mobile device (thanks to a simple Bootstrap-based responsive design), and see the articles list, view one article and its comments, view the author information, log in and out.

This sample is implemented as such:

MVVM Source mORMot
Model MVCModel.pas TSQLRestServerDB ORM over a SQlite3 database
View *.html Mustache template engine in the Views sub-folder
ViewModel MVCViewModel.pas Defined as one IBlogApplication interface

For the sake of the simplicity, the sample will create some fake data in its own local SQlite3 database, the first time it is executed.

Continue reading...

2014, Wednesday October 8

Meet in Belgium!

Just a small message to let you know that I was invited, as a speaker to the BE Delphi 2014 event.
This year, the sessions will focus on n-Tier development, so our little mORMot does make sense in the landscape!

If you are in Belgium or in Europe, we would be very pleased to meet you there!

Thanks to the BE-Delphi team to let our little Open Source project be part of this great gathering!

2014, Friday September 12

Legacy code, mORMot, and database sharing

It is pretty much possible that you would have to maintain and evolve a legacy project, based on an existing database, with a lot of already written SQL statements - see Legacy code and existing projects.

For instance, you would like to use mORMot for new features, and/or add mobile or HTML clients - see Cross-Platform clients.
In this case, the ORM advanced features - like ORM Cache or BATCH process, see BATCH sequences for adding/updating/deleting records - may conflict with the legacy code, for the tables which may have to be shared.
Here are some guidelines when working on such a project.

To be exhaustive about your question, we need to consider each ORM CRUD operation.
We may have to divide them in three kinds: read queries, insertions, and modifications of existing data.

Continue reading...

2014, Monday August 11

Cross-Platform mORMot Clients - Smart Mobile Studio

Current version of the main framework units target only Win32 and Win64 systems.

It allows to make easy self-hosting of mORMot servers for local business applications in any corporation, or pay cheap hosting in the Cloud, since mORMot CPU and RAM expectations are much lower than a regular IIS-WCF-MSSQL-.Net stack.
But in a Service-Oriented Architecture (SOA), you would probably need to create clients for platforms outside the Windows world, especially mobile devices.

A set of cross-platform client units is therefore available in the CrossPlatform sub-folder of the source code repository. It allows writing any client in modern object pascal language, for:

  • Any version of Delphi, on any platform (Mac OSX, or any mobile supported devices);
  • FreePascal Compiler 2.7.1;
  • Smart Mobile Studio 2.1, to create AJAX or mobile applications (via PhoneGap, if needed).

This series of articles will introduce you to mORMot's Cross-Platform abilities:

Any feedback is welcome in our forum, as usual!

Continue reading...

Cross-Platform mORMot Clients - Delphi / FreePascal

Current version of the main framework units target only Win32 and Win64 systems.

It allows to make easy self-hosting of mORMot servers for local business applications in any corporation, or pay cheap hosting in the Cloud, since mORMot CPU and RAM expectations are much lower than a regular IIS-WCF-MSSQL-.Net stack.
But in a Service-Oriented Architecture (SOA), you would probably need to create clients for platforms outside the Windows world, especially mobile devices.

A set of cross-platform client units is therefore available in the CrossPlatform sub-folder of the source code repository. It allows writing any client in modern object pascal language, for:

  • Any version of Delphi, on any platform (Mac OSX, or any mobile supported devices);
  • FreePascal Compiler 2.7.1;
  • Smart Mobile Studio 2.1, to create AJAX or mobile applications (via PhoneGap, if needed).

This series of articles will introduce you to mORMot's Cross-Platform abilities:

Any feedback is welcome in our forum, as usual!

Continue reading...

- page 1 of 4