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.
Related
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).
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".
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.
I need to deploy a Delphi app in an environment that needs centralized data and file storage system (for document imaging) but has multiple branch offices with relatively poor inter connectivity. I believe a 3 tier database application is the best way to go so I can provide a rich desktop experience with relatively light-weight data transfer needs. So far I have looked briefly at Delphi Datasnap, kbmMW and Remobjects SDK. It seems that kbmMW and Remobjects SDK use the least bandwidth. Does anyone have any experience in deploying any of these technologies in a challenging environments with a significant number of users (I need to support 700+)? Thanks!
Depends if you are tied to remote datasets. If you aren't dataset bound then SOAP would likely be a good choice. Or, what I've done is write my own protocol that is similar to SOAP in nature. This was done before SOAP was standard and I'm glad I did - this gives you the ability to control more of the flow of data. It's given that if you have poor connectivity then you will be spending time supporting it. It's very nice if it's your own code you are supporting versus having to wait on a vendor. (Although KBM and REM are known to be pretty good vendors.)
Personal note: 700 users in a document imaging application over poor connectivity sounds like a mess. Spend the money on upgrading connectivity as it'll be cheaper in the long run.
Both kbmMW and RO SDK offer binary format, which is more compact than SOAP format,specially you are working with documents.
RO sdk seems to offer more GUI tools to help you doing your services.
Also give a RealThinClient SDK a look, it's a lightweight remoting framework.
But what ever framework you go with, your design of work will make it fast or slow, I have some applications working on slow 128kb lines, and it's working perfect without any user complain, but I don't do a large transfer for files.
One thing to remember...its not the number of users, but the number of them using the resources at the same time that will be the issue. Attempt to develop your application "server stateless" if at all possible, this will allow greater flexibility in the long term if you find you have to add more servers to the pool to support your customer base. The hardest thing about n-tier is scaling beyond the first server...plan on that from the start. Each request should not know anything about a prior request...or at the very least the request should have a way of passing the context so the server can look it up in a session table or something.
Personally, I would recommend RemObjects. I have used it with good results.
I don't know if it's the very best / most efficient (glad you asked this question!), but I've had good results w/RemObjects SDK + DataAbstract. The latter made much of the plumbing details less involved, which was helpful. Still implementing, but so far so good.
If you really wanna go "low-bandwidth" use BSD Sockets API - that'll give you full control over what's being sent and there you can send as little information as you want. Of course then you'll have to implement all the tiers yourself, but hey - that's still an option :D