Our application provides a REST API. However, a client can communicate only over TCP.
Is it possible in WSO2 ESB to make a proxy which would listen to TCP internally, then send the request to a REST API and send out the response as TCP?
The TCP request contains a message ID, which must be sent out in the response in order to be able to couple on the client-side.
You can use TCP transport receiver. Please refer the documentation for more details
Related
If I were to send out a HTTP GET request to e.g. the Shodan REST streaming API, is this implemented on the server side by periodically sending out HTTP Keep-Alive messages to the client in case there is no new data to be sent out?
Or are there other options/techniques available for implementing REST streaming API endpoints?
There is no such thing as an http keepalive message.
The API you link to simply doesn't tell the client in advance how long the response body is, so a client can keep reading the newline-separated messages from what counts as one response until either side decides they're done.
I read the Pika doc, but I am not quite understand why it says "AMQP a two-way RPC protocol, where the client can send requests to the server and the server can send requests to a client...". Can anyone give me an example please ?
Does it mean when we create a exchange.
client sends: exchange.declare
server replies: exchange.declare-ok
Are these two method requests?
In your particular example exchange.declare is client request and exchange.declare-ok is server response.
Though, there are some methods that server can send to client, e.g. basic.deliver, basic.return, connection.blocked (RabbitMQ-specific extension).
I have a very basic question about wcf service with basicHttpbinding:
When client calls a wcf service(basichttpbinding) synchronously how the request and response is received between two? Does a socket connection established between 2 and port on server tied up till response is received on client? How the response is sent back to the waiting client? IF port on server is unusable for long running operation then will it hinder service ability to accept request from other client? Also, how communication happens in can of asynchronous call to wcf service? I read that channel and hence port/socket should remain open at both ends.
With basichttpbinding, it's much the same as normal http communication between a browser and a web server. If you hit a link on a web page, a request from the browser is sent to the appropriate web server, which processes the request and returns the content, as a response, to the waiting browser.
It's the same with WCF basicHTTPBinding. The WCF client sends a post or get request to the designated web service (http: //webservice:port/ServiceObj/MethodName) and waits for a response. When the web service finishes gathering the data, the data is sent back to the client in the response on the open connection, which is then closed by the host. There's no persistant connection. Thus, basichttpbinding is stateless. Once the web service sends the response, connection is recycled and the service is ready to go for the next request.
If the client is finished with its communication, it can close its connection explicitly; that's best. But if it doesn't close its connection, it won't make any difference to the host.
We have a solution that consists of a WCF webservice on one side and a smart client on the other side.
Typically, we set up HTTPS on the webserver for the webservice so that communication between client and server happens over HTTPS.
One of our customers however has a proxy server in between that strips incoming HTTPS request from their SSL payload and forwards a plain HTTP request to the webserver:
Client > HTTPS > Proxy > HTTP > Webserver
The problem is that we are using WsHttpBinding to allow us to communicate with WCF over SSL. Typically we use that binding both on client and server and there's no issue.
But since the webservice actually receives an HTTP request, we cannot use WsHttpBinding (requires HTTPS). But we MUST use HTTPS from the client.
But of course, WCF requires the bindings between client and server to match. So we're a bit stuck and I can't find a good way to solve this issue:
We cannot set the client up to use HTTP for security reasons
We can set the service to accept HTTP requests, BUT the client won't be able to communicate with it.
Is there a certain setup that could cover this requirement?
use the wcf binding converter to get a custom binding from your wshttpbinding. then change in the custom binding from https to http element.
I'm trying to understand the difference between the standard bindings in WCF. As part of this, I'm reading WCF Bindings in Depth. Figure 2 shows that there are bindings whose transport is HTTP and some which are TCP. I'm confused b/c I thought HTTP was an application-level protocol, not a transport protocol -- and that HTTP ran on top of TCP. So by calling it an HTTP binding, are we to understand that it's actually running on HTTP on top of TCP?
So by calling it an HTTP binding, are we to understand that it's
actually running on HTTP on top of TCP?
Yes, exactly. But that's implicit. Because HTTP runs on top of TCP.
The binary bindings (such as netTcpBinding) run directly on TCP. They do not use HTTP at all.
tcp/ip contains 4 layers:
application
transport
network
data link
you can use any layer, but wcf has binding which use transport and application layers, f.e. netTcpBinding and wsHttpBinding
tpc/ip does not same tcp layer
application layer protocols f.e.: HTTP, RTP, FTP, DNS
transport layer protocols f.e.: TCP, UDP, SCTP, DCCP
so http can be based at UDP protocol and it will be wsHttpBinding
or if you choise tcp it will be netTcpBinding, this layer in below than http, and application is redundant