I have a client-server relationship between two apps: a web application and an OCX. What I want to do is communicate the client part of the web application, running on the local PC, with the OCX, also installed in the same PC. The server app (the OCX) is not mine (I can't change its source code) and offers 2 ways of communicating with client apps: through an intermediate file or through a socket. There are lot of restrictions in the PCs where the apps have to be executed (the users, for example, are not administrators of their own PCs) so it's even more difficult than it seems. My doubt is which technology would be better to handle this communication from the cliente app (JavaScript, Java Applets, another OCX, etc.) and which option could be handled easier (file or sockets) by this technologies. And also which would be the security and permissions settings that should be taken into account to make it all work properly. You must know that, in case of using an intermediate file, I must be able to write in specific positions of that file from the web app (I'm not sure if Javascript's FileSystemObject can do this, for example). Thanks in advance.
Working with Sockets is realy easy. I only don't know the security options of sockets. May be you can take a look here: Oracle Sockets
Related
I have developed a web application in node.js express framework. I have different systems that are used for various purposes.
When I call REST endpoints it should communicate with those systems and collect data. I want to know how can make my web application communicate to this system over a text file.
Not sure why do you need to use a text file, but if I understand correctly, what you need is basically something like Redis or Kafka. It would allow you to create kind of a "central" process where you can save/read information.
https://redis.io/
https://kafka.apache.org/
There're more options out there, just start with these ones and try to figure out if it's exactly what you need.
I have a very basic question. When I write REST services, there is a server on which your service runs. When I write my service in Java using dropwizard framework, it uses Jetty server to expose endpoints. But what is actually this server? Because server is just a machine on which we host. For example, in node js application, when we just write a createServer(), it creates the server locally on the machine. Does it also have some fancy names like Jetty or Tomcat that it uses internally? I am little confused, what exactly is meant by Jetty, Tomcat, etc? Are these some library which makes it easy to connect to the machine OS and all or its something else.
My question looks very dumb but I wanted to understand the concept of servers.
This is a little bit confusing, you're right, as server can mean the machine itself, or the software that actually creates the web server.
But software needs some hardware to run, isn't it ?
Server usually means the combination of both.
Node.js servers have also some fancy names like Express, or Sails, and many others that make setting up your app easier.
This is more about the context of the discussion than frameworks and languages.
I'm reading about architecture and found the following expression:
For instance, in a 2-tier Windows Forms or ASP.NET application, the machine running the interface code must-have credentials to access the database server. Switching to a 3-tier model in Which the data access code runs on an application server machine running the Means That code no longer the interface Needs Those credentials, making the system Potentially more secure. (Rockford Lhotka)
I can not Realize why i should use 3-tier app.
In a three-tier application, the middle tier (the application server) controls all access to data, so it is possible to specify very fine and specific access control rules (in code), much more than the database itself offers. Whatever an end-user wants to do, has to go through your code (in a two-tier application, the end-user "directly" talks to the database).
OTOH, if you stop using the database access protections, securing the data is now entirely up to your application and coding errors can create huge security holes.
I'm hoping someone can validate or correct my conclusions here.
I'm looking into writing a small side project. I want to create a desktop application for taking notes that will synchronise to a web-server so that multiple installations can be kept in step and data shared and also so that it can be accessed via a browser if necessary.
I've kind of been half-listening to the noises about CouchDB and I've heard mention of "offline functionality", of desktop-couchdb and of moves to utilise its ability to handle intermittent communications to enable distributed applications in the mobile market. This all led me to believe that it might be an interesting option to look at for providing my data storage and also handling my synchronisation needs, but after spending some time looking around for info on how to get started my conclusion is that I've got completely the wrong end of the stick and the reality is that:
There's no way of packaging up a CouchDB instance, distributing it as part of a desktop application and running it in the context of that application to provide local storage and synchronisation to a central database.
Am I correct here? If so is there any technology out there that does this sort of thing or am I left just rolling my own local storage and maybe still using CouchDB on the server?
Update (2012/05): check out the new TouchDB projects from Couchbase if you are targeting Mac OS X and/or iOS or Android. These actually use SQLite under the hood (at least for now) but can replicate to/from a "real" CouchDB server. Another clientside alternative that is finally starting to mature is PouchDB, which runs in IndexedDB capable browser engines. Using these or using them to inspire similar port to another desktop platform is now becoming a better-trod path.
Original answer:
There's no way of packaging up a
CouchDB instance, distributing it as
part of a desktop application and
running it in the context of that
application to provide local storage
and synchronisation to a central
database.
At this point in time, your statement is practically correct although it is possible to include CouchDB in an app — for an example see CouchDBX.app which is a thin wrapper around a prefixed bundle of CouchDB and all its dependencies.
The easiest way to build a CouchDB app is to assume that the user will already have a CouchDB server running. This is easier than it sounds, especially with Couchone's hosting or a prebuilt app like CouchDBX on OS X or DesktopCouch on Ubuntu. This latter is especially interesting, because if I understand correctly it is included by default with Ubuntu these days, and automatically spins up a CouchDB server per-user when you query its port via D-Bus. Something similar could (and should) be done on OS X using launchd and Bonjour.
So as you write, you either would design your app to store data in a local format and optionally sync with a CouchDB service you provide or you'd have to build and bundle all of Erlang, SpiderMonkey and CouchDB together with your app along with some scripts to make sure it was running when needed. This is possible but obviously neither of these are ideal, and believe me you're not the only one wanting a simpler solution for desktop-oriented apps!
I am currently devising 3 database desktop applications for different users in a manufacturing company (one for the accounting department, sales department, production department). All applications have different functions but they should be able to access the data of the other department to reflect business transactions. What is the best programming language and database to use for this kind project? The three computers are not physically connected so I was thinking of having them to access a remote database. The language I am most familiar with is Java but I am very open to learning others if it would be more beneficial to the company. I was also thinking of having to use Adobe Air as I am adept with web programming but could still run as a desktop app but I can't seem to find sufficient resources of distributed systems using Adobe air. Any ideas would be very much appreciated. Thanks!
Lots of languages will do this just fine, including Java. You're familiar with that so my advice is stick to it with one caveat: depending on your requirements I would seriously suggest examining the possibility of making it a Web app instead. Desktop database apps are somewhat... old-fashioned. More to the point they'll create a bunch of headaches for you such as installation, Swing is annoying and tedious, etc.
As for what database, barring requirements you haven't specified, anything will do so pick something free like MySQL.
So for a desktop Java app I would:
Put the database on a remote server;
Put an application server or Web container on that same server;
Create a Webapp on the app server for handling RPC;
Pick a method of RPC, be it Web services or whatever, and use Spring to implement it;
Create a desktop Java app in Swing and distribute it to clients from the app server via Webstart (JNLP).
If it's a Web app:
Put the database and appserver or Web container on one server;
Pick a Java Web framework and create a bunch of Web pages that do what you want.
In all cases, have it be the same app but just act differently on the user type. This is much better than maintaining three different apps.
Also if you do a Web app, you might want to consider using PHP as it's a fast and proven way of knocking up Web pages and probably sufficient for the kind of internal application that you're doing.