I'm toying around with Delphi. Most of my desktop development is done in .Net, and embedded systems with C. I've done some web development in RoR & Python (Django, CherryPy) I am interested in taking a crack at a project that would be a web service (REST or SOAP) with a native client and a web client.
Because I've recently been re-inspired to learn Delphi, I'm curious what the options are to build the web service and web client with Delphi. Most of the Delphi documentation is a little dated but so far I've found these choices:
DataSnap
WebSnap
WebBroker
IntraWeb
Data Abstract and RemObjects SDK from RemObjects
I get the impression that WebSnap is dead, but the other technologies are still being developed. Is there any guidance about which technology to investigate?
p.s. I realize that Delphi isn't a wildly popular choice for web development, but I'm curious to try since I've been having fun learning the VCL.
You could perhaps add our Synopse SQLite3 Framework to your list.
There is some interresting features:
ORM approach to manage your data (i.e. define and access your data as regular Delphi classes), on both Server and Client Side - similar to ActiveRecord in RoR ;) ;
Multi-tier architectured;
no database or dll to deploy (uses embedded SQLite, without any external dll) - you can even not use SQLite, but a simple and fast in-memory database written in pure Delphi (I've begun a fork of Zeos, to be database independent);
Very optimized HTTP/1.1 multi-threaded Server (but you can communicate via other protocols, or even purely locally within the same process, without any Client/Server);
Data transmission uses standard JSON, so you can receive the same data in either a Delphi client, either an AJAX client;
Client/Server is RESTful and written in very optimized Delphi code (some part were even written in asm after profiling, for speed and low memory use);
Can also be used to define DataSnap-like Client-Server JSON RESTful Services, if the RESTful approach is not enough for you;
Full Open Source, compiles and work from Delphi 6 up to XE (with full Unicode support for all versions, because it's based on UTF-8 from the engine core).
Web Service Toolkit is a web services package for FPC, Lazarus and Delphi; “Web Service Toolkit” is meant to ease web services consumption and creation by FPC, Lazarus and Delphi users. Better check out from svn as the 0.5 release is actualy outdated.
RESTful server side method calls hosted as an ISAPI dll or just use the Indy HTTP Server component. It's really a quite simple and powerful approach and lets you get started quickly without a big learning curve.
DelphiMVCFramework is a powerful RESTful framework used also for website development
https://github.com/danieleteti/delphimvcframework
DMVCFramework features
RESTful (RMM Level 3) compliant
Fancy URL with parameter mappings
Server side generated pages using Mustache templates
Messaging extension using STOMP and Apache ActiveMQ or Apache Apollo (beta)
Can be used in load balanced environment using Redis or MySQL as state server
Integrated RESTClient
Works with DelphiXE3 or better
Integrated Logging System
It is really simple to use. You can be productive in minutes!
Here's the DMVCFramework Developers Guide
https://danieleteti.gitbooks.io/delphimvcframework/content/
If you need support, there is the official facebook group with more than 600 users https://www.facebook.com/groups/delphimvcframework/
I'm the main developer but there are more than 6 active contributors.
WebHub is another well established, though lesser known third party Delphi web framework.
Couple other choices that can be used to build a webservices server, somewhat simlar to datasnap or remobjects/dataabstract, are below. I did some work years ago with kbmMW and it's a solid library. I think both kbmMW and RealThinCLient have free and/or open source versions:
RealThinClient
kbmMW
We have a web front end for our Delphi server app written in Delphi Prism/ASP.NET. It works great and allows us to leverage our Delphi language skills in a .NET environment.
This one is very old,but a lot of things have changed,I myself had left Intraweb and gone to UNIGUI,since its based on EXTJS and produces single page applications.
Well Its been two years since I left my last message on this posts,
although uniGUI is still the only solution already made for creating SPA in Delphi,it seems that IW17 will be a real cutting edge,an waters divisor in the history of Delphi.Client side rendering without needing server communication,Wordpress integration,no need to write a single line in javascript like other frameworks,websockets,fibers,our "Delphi React".
Related
I need to take a huge Delphi XE application (backed by proprietary SQL server NexusDB) and begin providing my clients the ability to access the system in new ways:
Thinner Windows client for slow/VPN connections
Mobile/Tablet
Web
DataSnap appropriate for this or is introducing a middle tier the wrong way about providing remote/mobile access? Other solutions/ideas welcome.
(I have XE2 Enterprise but am stuck on XE Enterprise for awhile.)
DataSnap is being aggressively positioned by Embarcadero as a Multi-platform connectivity solution, where servers are written in Delphi, and mobile connectors are available (in XE2 and later) for a variety of mobile device platforms. So the quick answer is yes, it is suitable in general.
Is it suitable for you? You haven't said much that would help me answer that question; You are willing to buy Enterprise or Architect SKUs of Delphi, so I would guess yes.
If it was me, I'd look for a solution that implements a pure simple REST architecture that is available to every system out there, mobile or otherwise, no matter what language or platform, but I haven't got a suggested alternative because it seems to me that SOAP is nearly dead and that there is no universal replacement technology out there that does everything that soap client/server systems do. I'd be tempted to consider "roll your own REST+json" or evaluate Remobject's product offerings too, and select a path that makes sense for you, from a business and technical point of view.
Datasnap is fine, but it's not the only option. It's probably the simplest and most easy to roll out option currently available, and the only one "out of box" ready to go in XE2 if you want apple, android, and a few others, right away.
That depends on your security needs, and the way you're providing data to clients. As I often pointed out, dbExpress-Datasnap has big security flaws (while the DCOM version is not well suited outside a LAN, and does not offer out of the box mobile devices support).
A web application would have less issues because the datasnap-web server connection would be probaby internal, it would be up to the web application to ensure data protection.
First of all what I want is quite complex, at least for me, but on the other hand it sounds exciting.
I have a software written in delphi, and I want a real time web based client for it.
The requirements:
On the client side pure Javascript
Shiny interface ( GWT, SmartGWT )
Asynchronous connection between the server and the client. Ajax push, Long Polling, Comet, WebSocket?
On the server side
scale-ability
On the delphi side I think I could use ICS from Overbyte, to handle the requests. I know that THttpAppSrv from ICS pack can easily serve simple content, but what about Websocket, or how can I do long polling with it?
What do you think, is it a good combo ( GWT, SmartGWT on the client side, and ICS on the delphi side ), is there any sample project out there, or is there any other solution?
Update
Thanks for the useful comments, I think I get closer to the solution. It's good to know that GWT can use a custom server, however I think Arnaud is right, GWT with it's own Jetty server is a complete solution, but unfortunately not for me. :) I think I need a server written in delphi, which can communicate with GWT RPC.
Update 2
I accepted Arnaud Bouchez's answer which looks me the best for the original question, however I think there's a better solution (if you change the requirements a little) for creating a client running in the browser for a delphi application. I just make a little comment here, to share the idea. Finally I used a node.js server, and connected it to my delphi app with the help of ZMQ.
About the HTTP server on the Delphi side, consider using the kernel mode http.sys server provided by Microsoft since XP. Should be faster than ICS.
For the AJAX part, take a look at Op4JS or up to come ElevateDBBuilder.
What is great with those solutions is that you can write object pascal code, and that this code will be translated to JavaScript. Not yet finished, but worth waiting a little for their release time.
Of course, more classic AJAX solutions do exist, like IntraWeb or ExtPascal. Both implement their own web server.
About GWT, AFAIK they are java libraries, deeply linked to the Java world. You won't be able to make it work with Delphi.
Edit about GWT:
GWT is a full Client-Server framework.
If you go with GWT, I suspect you'll end with a full Java rewrite of the application at some point. Or you'll miss most interest of GWT as a framework. It's your choice.
I'd rather rely on some more standard approach, using JSON for communication for instance as we do with our framework.
Have you checked out Intraweb? I have not used it extensively myself - but it seems to be quite popular for Delphi web apps.
I have made several Web Apps using TWebBroker with either IIS or Apache. It is Asynchronous, and allows you to easily port/share Delphi code with your other application. And it would support Ajax calls.
Delphi, pure javascript on client side and shiny interface? You're talking about Unigui!
I worked on PHP, ASP and Cold Fusion before, and wanted to do (almost) the same with Delphi. I started xxm. It has Delphi and HTML code in the same files, and (re)compiles a library when you hit refresh in a browser. I've made handlers for these libraries so you can run them in IIS, Apache, InternetExplorer, Firefox, or straight from a Delphi-based HTTP implementation. (I started work on a http.sys handler also, but that'll take a lot more work.)
Also, in relation to your question, I wanted streaming, I wanted that what I output would get transferred ASAP to the listening client, so you could do long running pages, long polling, and the like. As for GWT and other client-side script, I've successfully used prototype and jquery.
I read this question but was somehow not satisfied with the answers.
I also quickly read (as suggested in that question) the last chapter of Marco Cantù 2010 Handbook, from which I quote the following (I think I can quote such a short text):
I [Marco Cantù] do have a lot of
investment in server side web and REST
applications written in Delphi, and in
the recent years I've started playing
with and introducing at conferences a
Delphi Web Application REST
Framework119 (that is, DWARF), which
at this time is still not publicly
available... simply because it is too
sketchy and unfinished to be
published. I've seen other ongoing
efforts to clone Rails in Delphi and
offer other REST server architectures.
I think that if you want to build a
very large REST application
architecture you should roll out your
own technology or use one of these
prototypical architectures.
Considering that I own Delphi XE Professional and DataSnap is not in there and I would like to consider to write large applications too according to the above comments it seems DataSnap is not an option.
Is there even a commercial solution for this? I don't want to consider "my own implementation of REST", I would like to create a webserver that uses some of my datamodules where I use the DAC I choose (Devart in this case).
Final note: my goal is to write the backend for a large web application, on the client I would like to use Ext JS 4.0, but I want to do all the client work in javascript, to take full advantage of EXT JS, so basically I need a webserver just for the data and tracking the state, not for serving webpages.
To create your REST services, try our Open Source mORMot project. Now it is a well known and stabilized project, used world wide in production.
You can use any DAC with the current state of the framework by implementing a custom TSQLRestServerStatic class (similar to the TSQLRestServerStaticInMemory class, but calling your DAC): so you'll benefit for the ORM and the JSON RESTful architecture, together with the high-speed http.sys kernel-mode server.
The SQLite3 engine is NOT mandatory with our framework, even if it was designed to work better with it.
If you will start an application from scratch, I think the mORMot is a good option if Delphi is your only option. If you choose datasnap you'll have to live with the problems of performance and stability.
I wrote an article on my blog talking about performance and stability with DataSnap (and mORMot) in large applications, you can see it on the following link:
DataSnap analysis based on Speed & Stability tests
I think you should have a look at kbmMW, there is a way to implement a basic REST server based on an event driven HTTP server.
Check news.components4developers.com news groups, there you will have a lot of documentation.
FireHttp is a high-performance Web server based on Delphi/Object Pascal language. It supports HTTP 1.1, HTTPS (SSL/TLS), WebSocket, GZip, Deflate, IOCP, EPOLL. It adopts multi-process+multi-threading model, has good stability and concurrency performance, and provides SDK source code. Developers can use SDK to quickly build high-performance cross-platform Web applications.
What is the best way to write a client-server application under delphi? I know there's a DataSnap technology, but it's not in Professional version. Do You have any experience that You can share?
This is fairly wide open question, as it can depend on your database decision.
DataSnap really allows for N-Tier solutions, if your looking for Client Server you have
most everything you need in the professional version depending on the Database Choice.
For Client Server:
Client Server Architecture is when the Client communicates directly with the server.
There are several frameworks available they all follow the same pattern.
DB Connection -> Query -> (Optional Provider -> TClientDataset) -> TDataSource -> Visual Control
DBX
TSqlConnection - Connects to the Database
TSqlQuery - Query against DB producing uni-directional Dataset
TSqlStoredProc - Executes Stores Procedures against DB
ADO
TAdoConnection - Connects to Database
TAdoQuery - Query against DB producing Bi-Directional Dataset
Common Components
TClientDataSet - In Memory dataset that is bi-directional
TDatasetProvider - Takes other datasets and ties the data to TClientDataset
TDataSource - Ties a Dataset to a data-aware visual control
There are several other options available depending on Database Choice.
However, you seem to be asking about N-Tier (Middle-Tier) type solutions
For N-Tier
N-Tier architecture is when the Client communicates with Middle Tier that then communicates with the Server. It's referred to N-Tier as you have option to have multiple Middle Tiers or Application Servers.
Commercial Options (Required additional $$ to be spent)
DataSnap
DataAbstract
RemObjects SDK (Part of DataAbstract but can be used by itself)
KBMMw
Midware
I personally don't know of any free or open source options, although I suspect some exist.
Two options:
DIY (Do It Yourself). Write a communications layer and protocol yourself using Indy and/or ICS internet components. A lot of hard work and needs a lot of testing to get right.
Use a ready made framework such as kbmMW: http://components4developers.com/ or RemObjects: http://www.remobjects.com/ Both are not free but well worth the money you pay even if only measured by the development time/costs that you spare.
You can use
WST is a free and open source toolkit for web services consumption and creation with support for SOAP and XmlRPC and JsonRPC (the JsonRPC support is available only for FPC). It is compatible with Delphi. Better check out from svn as the 0.5 release is actualy outdated.
With Delphi Professional it is possible to write simple (no WS-* standards, no Soap 1.2 servers) SOAP client and server applications.
In many cases, Soap offers advantages regarding cross-platform / cross-language integration, standardization, design-by-contract and mature implementation guidelines, best practices and patterns.
For Soap there are great (and free) tools like SoapUI and IDE editors for Web Service Description Language (WSDL) documents like NetBeans.
Take a look at our Open Source Client/Server ORM.
It's multi-tier compatible, and you can have ORM at both Client and Server level.
ORM is used everywhere, and JSON is the format chosen for the Client/Server transmission.
You can start your application as local application, then just by changing the class type used to access to the data, it will become a Client/Server application communicating via Named Pipes, HTTP/1.1 or GDI messages.
It was designed to work with SQLite3 as a small but efficient database engine on the server side, but you can use the ORM without SQlite3. There is a pure Delphi in-memory engine provided, if you prefer.
This framework try to implement N-Tier architecture from the bottom up.
The upcoming 1.13 version will have a powerful filtering and validation mechanism, perfect for N-Tier architecture. There is some User-Interface units, with full reporting (and pdf generation), able to create most of the User Interface from code, using the ORM layout of the data.
It's based on the RESTful paradigm to access the data from the Client, via JSON. And there is a easy way of implementing Client/Server Services if the RESTful approach is not enough, just like DataSnap.
It's Unicode ready (uses UTF-8 at all internal level), and works with every version of the IDE, from Delphi 6 up to XE (even the Starter edition).
Since a few months ago I stopped to implement new projects with this kind of architecture (n-tiers, 2-tiers) Based on Delphis and specific DB technologies. I believe these architecture are not future prof. The architecture i'm using now is a 2-pier one. The server is a normal HTTP server. It works as app server* and optionally provides a web client. Developing clients in Delphi it's harder but worth it. Since specif tools are not available as the ones offered for DB connections, I use indy to send and receive data from the HTTP server. I do a GET request to fetch data and then parse it to show it on the GUI. Then a POST request to update or insert new data. The HTTP server handle all business logic :-)
Apart of being future prof, this architecture is cheaper and platform independent. And if you analyze it, this is the same architecture used by most mobile apps. So, if you plan to write a mobile client in the future, consider developing the app server with script languages (Python, PHP, Ruby, etc.).
That's my recommendation. Don't forget: Great things require great commitments!
An App Server is a service which provides your application (thin client) with with an interface to get and send data. Also it control the business logic. Your application don't care about DB's or controlling record relations and data constrains. That's all is transparently done by the app server.
For general-purpose client-server communication you can use our lightweight MsgConnect product. This is a cross-platform MOM (message-oriented-middleware).
First off, the little voice inside my head is screaming that this is a bad idea and it shouldn't be done, but my pragmatic side is asking "How bad could it be?"
The stark fact is most of my company's day to day "business" happens in one MS Office tool or another. Data is exported out of our custom tools as *.tab, *.csv, manipulated in Excel and imported back in with variying degrees of success.
Most of these custom tools are ASP.NET MVC web applications whose usability could be enhanced by more interoperability with Office.
I've fought the good fight for many years saying Office on a web server is a terrible idea. Lately I've been thinking that the enhanced usability outweighs the potential risks.
Am I going crazy?
You don't say what version of MS Office you are using in your workplace or what type of interoperability you are after.
If you want to generate Office documents 'on the fly' directly from the web application, then if you are using Office 2007 or 2010, the default document formats (.docx, .xlsx) are based on the Open XML SDK. This means that it is possible to generate documents dynamically without having to install MS Office on the web server.
If you are using Office 2003 or earlier, it is generally considered bad practice to install MS Office on the server - it is an unsupported configuration.
This Microsoft article outlines many of the possible issues you may face if you decide to go down this route.
Microsoft Office is not designed to work in a server which could be a highly distributed, multithreaded environment. It is a client application which by the way is mainly unmanaged code. So installing it and using it from a web server could hide potential problems: leaking handles, GDI objects, marshaling between managed/unmanaged memory, STA COM objects, etc. I would recommend you using only tools which have been designed to be used in a server environment.
You can create good office documents without installing office on the web server. Options include SpreadsheetML, components from aspose.net, and even just changing the file extension and content type on html responses to fool office itself.
If you do not want to install the full Office suite, then you can just install the Microsoft Office Primary Interop Assemblies?
http://msdn.microsoft.com/en-us/library/aa159923(office.11).aspx
I've seen this work in environments with very low loads...but as soon as the load increases the issues start to creep up. This has even be documented by Microsoft as the article pointed by Jazza clearly shows. Notice that this article is quite recent (July/2010).
The issues that I've seen are memory leaks, instances of Word/Excel not being stuck in memory, weird registry issues, and so on.
Another thing to consider is that Microsoft will not support you if you call them with issues related to Office on a server environment.
Again, if you only have a few users this might not be a problem for you initially but be prepared for scale issues.