We are building an application that will have clients installed in many sites. Each client work on its own, has its own database and workflows. However, each client has to submit some data to the main application installed at a central position. The application at a central location must receive updates (e.g stock levels) from the distributed units. All applications are done in Java. Which is the best way/technology of sending the updates from the distributed units to the central application? JMS, jdbc, ...?
I'm going to assume that the servers at client sites have network access, and that you are able to configure the central server so that other clients can connect to it. This could either be over the internet or an internal WAN.
In this case, it's simply a case of finding a mechanism to submit some correctly formatted data, which is received and handled by the central server. This gives you a large number of options, I'm going to list just a few:
Create a web service with something like Apache Axis
Use an ESB - something like Mule or JBoss
Use a simple web Servlet on the server, and submit data using HTTP POST. You could use a simple embeddable Java web server like Jetty to do this.
Use a messaging protocol like Kryonet or Google's protocol buffers
Use a more general network application framework such as Netty
All of these will work, so it really depends on working out which is the best fit for your architecture. I suspect the simplest would be something like Kryonet, the most comprehensive would probably be something like a full JBoss ESB/application server stack.
Related
I am currently studying how to make cross-platform mobile apps (with xamarin forms), and I have heard that the "correct" way to connect to a database in a non-locale server (in my case located in Azure) is by using Rest Services (or rest APIs, or however is called), instead of connecting directly to the database with the server explorer option of VS like you would do in windows forms for example(using the SQL connection, dataset, etc. Which I think they are not necessary in the first case, I am not sure).
The only answer that I have received about this is that in mobile apps "They are not permanent connections. It connects, gives you data and disconnects. They are Asynchronous connections.", and that this is done "For optimization of connection resources. The mobile is suspended or the user passes the App to the background.".
But I still don't know if this is the actual reason, and if it is I don't understand how it optimizes the connection resources. So if someone has time to explain this I would appreciate it.
Thank you for your time, I hope I have explained myself correctly, and that you all have a great day.
As Jason said,the Security issues，with proper authorization having mediator is definitely much more secure than giving a user direct access to the database, because you restrict him to the end points which run only the queries you want to.And from the platform independence and maintenance,if the apps are developed in different languages and on different platforms,it may have benefit to create a common REST interface to allow sharing of data model, caching etc.For performance and scalability，that HTTP layer of your REST API provides another valuable caching mechanism. Your servers for your REST API can put caching headers on their responses, and these responses can be cached at the network layer, which scales exceptionally well.
you could read this link Why do people do REST API's instead of DBAL's?,I think the answers are pretty good
I already working on AppEngine which is my android backend but I have to create chat system for my app so I cannot figure out how to do that.
I'm using spring boot
please help. sorry for any kind of mistake.
You can use google compute engine on google cloud to write down your WebSocket server.
Also, you can use apache thrift for a seamless design of communication protocol between different language. It saves lots of repeated effort while designing communication protocol.
From Quora
There's a lot of repeated work you have to do when you're writing a server - primarily designing a protocol and writing code to serialize and deserialize messages on the protocol, but also dealing with sockets and managing concurrency, and writing clients in many languages. Thrift automatically does all of this, given a description of the functions you want to expose from your server to clients. It's also useful for serializing data on disk or into shared memory (where many of the same problems come up).
I'm not sure if the title I used is good, but hopefully my question will be better.
I have an java application that tracks data on PennyAuction sites(such as beezid.com), and will eventually upload all of the data to a database. Clients will download a java application and run it on their local machine, but this local machine application will have to be able to access the database and obtain all of the data.
All I have ever done is java applications programming, so this is all very new to me. Can anybody help me with a solution that will be able to accomplish this?
This is all I can think of:
Server that will run Backend application 24/7, and use JDBC to upload data to database.
Separate server for database alone.
I have no idea how the client application should connect to the database though.
Any help/links to tutorials on stuff like this would be appreciated.
You could actually let your clients connect to the database directly if the database is on a public IP.
An architecurally much better way of doing this is with webservices. This would make your system much more safe, robust and scalable.
Web services are client and server applications that communicate over the World Wide Web’s (WWW) HyperText Transfer Protocol (HTTP). As described by the World Wide Web Consortium (W3C), web services provide a standard means of interoperating between software applications running on a variety of platforms and frameworks. Web services are characterized by their great interoperability and extensibility, as well as their machine-processable descriptions, thanks to the use of XML. Web services can be combined in a loosely coupled way to achieve complex operations. Programs providing simple services can interact with each other to deliver sophisticated added-value services.
I am building a silverlight app and would like to add p2p capabilities - allowing users to send each other data.
Is it available out of the box?
Should I wait for silverlight 4.0?
Do I need a p2p server?
The key problem is actually opening the client-side socket to accept connections from another machine, and Silverlight doesn't support this, even in out-of-browser mode, and even in Silverlight 4. If you wanted to do something like this, as the other folks have mentioned, you need a common server that both clients can connect to and which will proxy the messages back and forth between clients. And of course, the fact that Silverlight sockets are limited to ports 4502-4532 also means that you're somewhat limited by firewall policies.
What we've done with our applications (using Silverlight 4) is to try to connect with the new support for Net.TCP (which scales much better), and then if that fails, fallback to the HttpDuplexBinding (which runs over HTTP and hence is more likely to make it through a firewall). We then wrote a WCF service which receives messages from one client and submits them to other subscribing clients. It's not P2P, but it allows for a similar result (apart from all the actual benefits of P2P connections).
If you move to WPF, you give up on the portability of Silverlight, of course, but you get full server socket support, along with the ability to code various NAT traversal strategies like STUN and TURN.
I don't think you could make this work in Silverlight with a serverless environment.
You could probably do whatever you're looking to do with a server and a web service, although this technically wouldn't be a peer-to-peer application anymore. You'd have to send your messages to the server, and the server would then send to the appropriate client(s). If you follow this route you might also want to look into WCF RIA Services for Silverlight as it has built-in support for things like authentication.
EDIT -- I don't know if this is an option but it looks like someone has come up with a way to do P2P in Silverlight. However, it requires that you run the app in Windows Live Messenger:
http://www.codeplex.com/SilverlightP2P
I wanna build a Win32 app of Client/Server (or 3-tier) type with follow features:
When the "A" client does a modification (update,insert, etc) into a database, the rest of clients viewing the same record set can get almost "instantly" a fresh view of this data
a client can be notified when a connection to database get lost
could someone help me? Thanks in advance
Pdta: My Database is MySQL 5.1
Note that by doing this, and having lots of clients, you will potentially get a lot of network traffic.
This is exactly the reason that most client-server applications do not do this.
If you really want to do this, then the proper was is to implement the 'observer pattern'; a basic example on that design pattern in Delphi has been described by Joanna Carter in her blog.
Then you need to extend that pattern so it works over a network.
So at least you need some server process that handles the "subject" interface.
You can use anything for that: WebServices, DataSnap servers, RemObjects SDK, etc.
Most people wanting a solution like this, go from the traditional client/server application into a multi-tier application. Then the middle-tier can handle all the notifications for you.
My answer depends on your network architecture but I tend to use IP for this type of thing. Something like Multicast is an ideal way to notify all clients on the Network of an event. Simply multi-casting or broadcasting (UDP) the ID of the updated record may be all that is required. If another client is interested in the record, it can then refresh it from the Database.
The Indy Multicast Client/Server components will provide a simply way to implement this in your app.
If you have a three tier type application, the client communicates with the aplication server. This connection could use callbacks to the clients to notify them about important events. DataSnap supports callbacks (afaik also data change notifications).
If you build your own application server. the client could open a socket connection to the server (in a thread) and listen for event notifications. The Indy Telnet client example in Protocols/IdTelnet.pas is a good starting point to create a very simple notification implementation. It uses the TIdTelnetReadThread class to listen for the server responses to key input and protocol negotiations.
If your application needs to run in Terminal Server environments, where Ports will not be virtualized AFAIK, it is safer to connect from the client to the server (instead of opening client socket ports for peer-to-peer communication).
If MySQL doesnt support somekind of pushing info or attatching clients you would need to use a middle tier running on a server.
That server keeps track of connected clients. But it would probably be a heck of a job.
I know that the "bigger" edititions of Delphi has somekind of support of building this kind of client/server software.
I know it has nothing to do with your application, but Firebird has a nice feature to do exactly this. You can read more about them here (link to a PDF).
Now, if you need to do this with MySQL and Delphi, the easiest way I can think of is doing something "AJAX LIKE" on your Win32 app. That is having a server side app (you could use a WebServer with PHP, Java, .NET or whatever you want) that will serve your requests asking for data updates. On the server side app, just do a query asking for modifications into your MySQL Database.
Hope it helps.