Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have some very basic doubts on this topic.
I have a legacy server written some 30 years ago in C, C++, that supports socket communication but it works great.
I am in the process of writing a new java based client to connect to this server basically the goal is to expose the services (REST etc) for enterprise applications.
1) Should i go for plain java socket based approach or use Netty or Apache-Mina, what benefits i may have by using these modern apis in this scenario.
2) When using NIO based IO, does the sever also need to be a NIO based to take advantage of it or a NIO client to a legacy server (non NIO) would just work as good as it does with a NIO server.
Thank you very much
1) Should i go for plain java socket based approach or use Netty or Apache-Mina, what benefits i may have by using these modern apis in this scenario.
I assume that you mean using plain Java sockets to implement HTTP / REST-ful APIs.
That is a bad idea. It is theoretically possible, but you will end up doing a large amount of unnecessary coding. And the chances are that you will not implement the HTTP 1.1 spec properly ... and that will lead to further problems.
As for the others, I'd take a look at them, compare their features against the features you need and decide based on that ... and how easy to use they look like to yout.
2) When using NIO based IO, does the sever also need to be a NIO based to take advantage of it or a NIO client to a legacy server (non NIO) would just work as good as it does with a NIO server.
What you do on the client and server sides (NIO versus non-NIO) is independent of each other. Indeed, if you do REST properly, the client and server sides shouldn't even need to be programmed in the same language!
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
So usually, to have get and set methods in networking Java I use an enum, for example:
public enum MyEnum {
GET_NAME,
GET_ADDRESS;
}
etc. which the client application and server application would send between each other as a string and the appropriate task would be carried out.
I wanted to know how applications do this usually? What data do they send through the socket to make the program work, do they use ObjectStreams? Do they send bytes?
Wanted to know what the best practice would be to have a client-server setup for my own messaging application.
EXTRA INFO:
The client / server network I'm designing is for a PLUGIN in a GAME and therefore has to be instant / speedy ;)
All of that. Or something else.
The "industry" standard can be many things, depending on the domain you are looking at, or the decade when the solution was designed.
In 2018, most "new" client/server communication that gets defined doesn't operate on socket level. You rather define a set of restful APIs that the server offers, and data flows as JSON strings for example.
In other words: the official answer here is: there is no such as an industry-wide standard. To the contrary: what you are asking about (sending individual comments on socket level) is probably the exception, and not something that is common for real world architectures. People don't think in sockets and single commands. They think in terms of protocols, abstractions, maybe "remote procedure calls".
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I were wondering what's the proper way to create a chat/communication software in Java for Android?
I guess it's a Socket (TCP/UDP).
If I do it my own way like using a web calls for PHP with backend scripts why it is not so appropriate way to create a chat? What's the difference between them? Using a calls instead of raw sockets? Does it use more battery or something? I just feel that sometimes it would be more easier to parse a JSON for messages and send data through web calls, but I feel that it's not a proper way to do so and application may have a critical issues like draining a battery or something which will make the project to be discontinued.
I would like to be sure is there any other ways to create a chat, than sockets and do every famous developers use a sockets as primary method for creating a communication software?
The protocol could be Socket or others such as XMPP
If you prefer using Socket, SmartFox might be one of the libraries that you can rely on. Smartfox offers SDK for a number of languages such as C#, Java etc.
Note however, that if you use socket for communication, usually json is NOT used, since most of the times, binary objects are used in the socket-based communications, say for example, SmartFox uses ISFSObject, which wraps all the data into a binary object.
Below posts might be useful for you to get started, though it is not written in java, but essentially the workflows are exactly the same.
Using SmartFox with C# (I) : Installations and 1st handshaking
Using SmartFox with C# (II) : Login and join room
Using SmartFox with C# (III) : Frequently used functions
Apart from the socket and xmpp appraoches, you can also opt to use WebRTC, where there is no such kinds of servers, and peer to peer communication is used. A good tutorial can be found here.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'am writing an android app that needs some data from the server. I am also writing the server side in Java.
What is the best way to pass data from the server to the android device: with REST or Sockets (like Kryonet)?
In what format: XML/JSON (for REST) or plain Java objects?
Thanks in advance.
"Best" is very subjective, I think a very good way to communicate with a RESTful api is via Square's Retrofit library, which can be found here:
http://square.github.io/retrofit/
There is also Volley from Google,
http://developer.android.com/training/volley/index.html
Agree with nPn, "Best" depends on lot of app and user considerations. That said,
REST is preferred as it is most widely used and you have access to stable and optimized client libraries. Most of the these libraries support all kinds of use-cases and customizations. Web Sockets are well suited for real time or live content. If you have a different use-case , REST is strongly recommended.
With Android, JSON is well supported. There is a core JSON API included with Android that you can use without any client libraries. XML can be helpful if you plan to expose your APIs for public consumption (some platforms eg: JAVA, windows have strong XML legacy).
REST + JSON seems to be most commonly used combination in recent times, and lot of client libraries usually enable this use-case.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am exploring various ways that allow Java to connect and communicate with NodeJS. An example of what I am trying to achieve, is for example call Java methods from NodeJS, while allowing the Java method to manipulate Javascript objects. I know the JSObject class is helpful for this purpose. I have also heard so far of Dnode and ZeroMQ. Have you heard of or do you have experience in doing something similar? Would you suggest a way on how this communication Java to NodejS can be done?
I would go with an agnostic implementation.
A rest server on node js, maybe using restify listening for messages
A http client on the java side as httpclient to send messages to node.
this will also make it dead easy to test node implementation with curl and static requests; will enable you to implement authentication later on using any standard mechanism from oauth to basic and will let you change the client and the dispatcher independently later on
also you will be able to put any kind of standard load balancer in between, should you need the node app to scale.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have two Java EE web apps that are going to be published on the same physical server, but on different network addresses.
APP A: Listens to a port on a public IP address and makes synchronous invocations to app B if necessary.
APP B: Listens to a port on a private IP address and makes synchronous invocations to app A if necessary.
For connecting APP A with APP B, I am considering the following alternatives.
RMI
Message Queue
Lightweight ESB
Please tell me if you see any clear advantage supported by facts on any of them, or if there's another technology I should consider.
Every integration method has its advantages and disadvantages, and its really hard to propose one based only on what you have provided, but here is some hints:
Quick and Easy: if you don't mind high coupling, and major changes in the applications are not expected (like DB engine, or replacing on with non-Java system), you can go with RMI or even DB Procedure calls.
Changes, Extendability and Scalability: if the applications are expected to be changing more than rarely -and they tend to do-, ESBs or Message Queues would be great, since they would produce a loosely coupled architecture. This would also make room for extendability (like if you would have a new application C, that would need to invoke A or/and B)
HTTP Availability: If HTTP communication is available between applications, Web Services is an excellent integration method.
Developers Knowledge: What technologies you/the team are familiar with.
These are actually small hints, if you wish to go further in your research, I strongly recommend reading Enterprise Integration Patterns the book.