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.
Related
I am developing a ASPNET web app which uses interop for different tasks. In order to make the app faster I was wondering if I can run Excel on the background while the view is loading. I tried the following approach:
enter image description here
However, every time you go into the view the app is initializated so you have the app running many times in the background. Is there a way of doing it?
Thanks!
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
As a workaround, you may consider using the Open XML SDK for open XML documents or third-party components designed for the server-side execution.
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.
I am thinking of developing a website using the ASP.Net MVC framework on Linux. I would like to know:
what are the best practises for developing such a site (are they any different for mono/ Windows)?
any gotchas I should be aware of
any (material diffeences) - e.g. missing/proprietary libraries/componenst between Mono and .Net
are there any special directives, modules required to run Mono with Apache?
Are there any performance differences between a site hosted on Windows/IIS and Linux/Apache?
I intend to do most of my development using VS Studio - can the site be developed using VS and then deployed on Linux?
I am aware that this question has been asked several times here on SO. However, most of the questions date back to 2008 or 2009 - which is a very long time in internet time. Things may have moved on since those answers - so those answers may no longer be relevant.
I have to state that I am NOT interested in hosting the site on a Windows server - so I am only interested in what works for a Linux server deployment.
I'am currently working on a MVC 4 app and we are using Mono. If you are just planning to have a basic website, you should go for it. But for more complex flows, honestly, I think you should do a little bit of research first, to see if the features you want to implement are supported in Mono. Things you should consider:
only a set of restricted libraries are supported on mono ( for example, right now we are having some issues due to the fact that the mono libraries (Novell and DirectorySearcher) for LDAP do not support pagination)
the developing environment will be different than your server env ( I am using Visual Studio, we managed to pass this limitation by adding a lot of logs)
we do our publish using FTP, so yes, you can deploy it from VS, using a publish profile set up for FTP
it's free, but it will take a lot of time to research & do special thinks just for the sake of Mono
not a lot of documentation available, because not a lot of people use it, so if you have a specific problem, it will be more difficult to solve
My experience is from 2011, but I am pretty sure you will have to experiment to see works and what doesn't - that's my experience with Mono.
Most of your questions are extremely broad and I think your question will be soon closed.
As for your last question this was the way I did it and it worked (develop in VS->deploy to Linux), but you must be aware that:
just because your code will work in the VS debugger it doesn't mean it will work when deployed;
there is no one-to-one mapping between Mono and .Net. Even when things work it doesn't mean they will work the same way. For example the implementation of the encryption code used for http cookies was very different between mono and .net.
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.
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".