Can WCF service hosted as TCP IP or Named Pipes on windows server be consumed by Java based application hosted on linux server?
I have a wcf service which requires low latency and very high calls per day. Hosting the service on IIS is not an option due to performance issues and HTTP overhead. This service needs to be consumed by java based client hosted on linux server. Can it be consumed by Java client if it is hosted on TCP end-point? Looks like Named Pipes are only allowed within the same machines so it wont fit the requirements too.
Only binding that assures "interoperability" in WCF is BasicHttpBinding.
If you need minimum overload don't use WCF.
Write your own tcp based protocol, use sockets or whatever you like.
Here is answer to very similiar question.
Related
We are using in some project WebSockets for asynchronous communication between Java client and Java server, but we have to replace it with something less modern (we cannot use Websphere liberty profile and it must run on Websphere). Connection can be made only form client to server, not reversely and it should be HTTP(s) as it has to traverse a reverse proxy. Is it possible to use JMS to push messages to client in this situation? (we tried atmosphere-wasync as well but rejected it due to instability).
What are the possible ways in which Java Swing Application which is running on client side can communicate with server?
I've read that JSP can be used in web pages to communicate between server and client.But, is it possible to use JSP with Swing application? if so, how? It would be helpful, if it is demonstrated with simple login form. Thanks.
Any client-side application, whether it be a java swing app or otherwise, can certainly communicate with any server (assuming no network limiting architecture -- firewalls and whatnot). Your options are numerous
Raw sockets
Any one of the myriad of network protocols.
HTTP/HTTPS
FTP
SCP
et. al.
It depends on what protocol, services and applications are available on the server to connect with.
HTTP/HTTPS is very common. You'll need to manually create HTTP requests and send them to the server (assuming the server is a web server).
I'm trying to build a Java web app that will let me browse a remote file system behind my NAT router. The client can talk outbound HTTP only.
I've got my Java client on the remote machine talking to my Tomcat server, which is then serving the data back up as web pages. Something like this:
File Server (java client) -> Web Server <- Browser
What I can't figure out is how to have the Tomcat server talk back to the remote Java client.
What I want to happen is:
User clicks on a folder in their browser.
Browser ajaxes to the server.
The Tomcat server contacts the remote java client.
The remote java client responds with the directory listing.
The Tomcat server sends back the new data formatted as HTML to the user.
I've looked at Comet and Tomcat 7's asynchronous stuff but I'm struggling!
If you need full-duplex communication over HTTP, than I strongly recommend using Atmosphere and Web Sockets. It simplifies server push a lot, and it's container agnostic (the framework).
You can use Async Http Client library for your remote java client in that case.
If you want to implement a PUSH behavior, then Commet is the way to go.
If there are few clients, perhaps you could solve your requirements by allowing the client to continuosly PULL changes from the server each few seconds.
I'm new to Heroku, and I was thinking about building a java RESTful web service that spins up TCP/UDP servers/clients to handle streams of data based on the RESTful calls. Aka, the RESTful calls are the triggers of TCP/UDP server creation for streaming data. Is that possible?
Heroku can only handle traffic over HTTP. I'm not completely clear on your use case, but if you want the servers that you spin up to handle incoming UDP traffic then you won't be able to do it on Heroku.
This answer comes long after the question was asked, but I can confirm that today you can host a UDP server on Heroku, having just built a little proof of concept Node WebRTC app.
I would like to have the clients query each other through the server without delay ( = no polling interval ).
Example: Server S, clients A and B
Client A wants to request Client B.
Client A will make a request to the server S, no problem there.
Then Server S needs to be able to request Client B but how to do that without polling?
All the node.js/APE (for PHP) technos are designed for the web, however I don't use a web server for that. Does Java has something close to a push technology/framework that is not web?
I would really prefer a solution that doesn't require each client to use their own reserved port (I don't want to end up with 1 WebService per client for example)
Note: all the clients are on the same machine.
A couple of options...
Plain socket communication. java.net.Socket, java.net.ServerSocket. Maximum flexibility but requires knowledge of low level TCP/IP API/concepts.
The good old RMI. Java based RPC layer on top of TCP/IP. Works good when client and server are both in Java and generally in same subnet. May give problems when client and/or server are natted.
Spring Remoting, it's actually pretty decent.
Bi-Directional Web Services. i.e. clients host their own WSes which the Server calls when it needs to do a callback.
JMS as someone already mentioned.
Distributed Data Structures, Check out http://www.hazelcast.com/
Lots of options to chose from, no need for webserver.
If you really don't want to use a web server then I would check out JMS. That being said, all the cool kids are using web servers these days since the protocols are so ubiquitous.
Your use case requires a messaging protocol. We don't really know the scope of your problem but you already said you want a server to exchange requests between clients, so I would go with an existing solution rather than a roll your own approach.
JMS has been mentioned and is certainly a viable Java based solution, another would be XMPP which is a real time communication protocol commonly used for instant messaging.
It is an open standard that has both server and client support in every major language and platform. This would allow you to have standalone apps, web based ones and apps for mobile devices all being able to communicate with each other. The only potential gotcha for your use case is that it is text based. Since you haven't said what requests you want to pass back and forth, I don't know if this will fit your bill or not.
You can use Smack for client side development in Java and any OS server you want.