Groovy wslite library support for http connection pooling - soap

I am using groovy wslite library(https://github.com/jwagenleitner/groovy-wslite) for consuming SOAP service, it is so simple and very effective but i didn't see any connection pooling while creating http conections under the hood.
Isn't creating a new connection everytime is expensive? trying understand whether it is good practice or not?

Related

Websocket Manager with Playframework and Scala

I want to use web sockets because I need to notify my users when there is a new message for them. And I’ve done a lot of research and I’m pretty sure I need to use WebSockets for this problem.
I was able to connect to my backend with the following steps: https://www. playframework.com/documentation/2.2.x/ScalaWebSockets
This allows my frontend to connect to my backend and has received the answer from the backend.
But how is it possible to manage all currently active web socket connections? Is there a method that I can use to find all active connections? Or do I have to implement all this from scratch?

How to use http2 in Feign for better performance RPC?

A new project consider use Spring Cloud build micro service. But we have many inner RPC call within services.
For performance, how to upgrade Feign support http2?
There are gRPC has give a great example for high performance by http2 but our project based on JVM and Feign and relative annotation is good enough for interface definition.
So, I'm first consider Feign support http2 without SSL to speed up RPC.
Hope there are benchmark on http2 if someone has done.
Thanks.
To use http/2 with feign you just need to replace the Http client Bean with a client that prefers http/2.
With default HttpClient (as opposed to OkHttp), you can just add this as a bean, and feign should use it, or you can build it into the feignClient:
HttpClient client = HttpClient.newBuilder()
.version(Version.HTTP_2)
.build();
ref: https://openjdk.java.net/groups/net/httpclient/intro.html
The OkHttp Client may have http/2
I think you would also have to enable http/2 on the server with:
server.http2.enabled: true
This should allow it to receive incoming requests with http/2.
https://docs.spring.io/spring-boot/docs/current/reference/html/application-properties.html#application-properties.server.server.http2.enabled

Exe as Webservice Endpoint

I got a webservice endpoint and I stumple upon how to correctly implement it.
It seems to be an parameterized exe-file which returns an XML Reply.
There is no documentation.
I am used to soap, wcf and rest but this is completely unknown to me, has anyone a guide or a best case how to implement such a service?
I can consume it with a HTTP GET but there are some questions left to me:
I know the questions are quite broad... But I could not find anything about it in the interwebz.
Is there a secure way to publish exe files as webservice?
Are there any critical downsides implementing such an interface?
Make I myself a fool and this is just an alias?
Example Url:
http://very.exhausting.company/Version/SuperStrange.exe?parameter=String
Web servers
What you call a webservice endpoint is nothing else than a web server listening on some host (normally 0.0.0.0) and some port on a physical or virtual machine and responding with some HTTP response to HTTP requests sent to that host, port and URIs that the web server cares to process.
Any web server is itself an application or a static or dynamic component of an application as the following examples illustrate:
JBoss, Glassfish, Tomcat etc. are applications, known as application servers, into which containers/servlets/plugins implementing web servers and corresponding endpoints are deployed. These listen on some port exposing generic web servers routing requests to those containers and their servlets;
a fat jar started with java -jar on a JVM which deploys a vert.x verticle featuring a vert.x HttpServer listening on some port is nothing else than a web server;
an interpreter such as node.js parsing and executing JavaScript code based on the express module will most likely deploy a web server on some port;
finally, a statically or dynamically linked application written in languages such as C++ or Go can expose a web server listing on some port.
All of the above cases feature different deployment mechanisms, but what they deploy is essentially the same: a piece of software that listens for HTTP requests on some port, executes some logic based on request and returns HTTP responses to the caller.
Your windows exe file is most likely a statically linked application that provides a web server.
Protocols
So we know you have a web server as it reacts to an HTTP GET. How does it relate to REST, SOAP etc? Effectively, REST, SOAP etc are higher level protocols. TCP is the low level, HTTP is based on top of that and your server supports that. REST, SOAP and everything else that you mention are higher level protocols that are based, among others, on HTTP. So all you know is that your application (web server) supports HTTP, but you do not know which higher level data exchange protocol it implements. It definitely implements some, at least a custom one that its author came up with to exchange data between a client and this application.
You can try to reverse engineer it, but it is not clear how would you find out about all possible endpoints, arguments, payload structures, accepted headers etc. Essentially, you have a web server publishing some sort of an API, but there is no generic way of telling what that API is.
Security
The world around you does not have to know how the API is published. You can put any of the above 4 web server implementations behind exactly the same firewall or a reverse proxy with SSL termination exposing just one host and port over SSL. So there is no difference in security, with respect to the world, whether you deploy it as exe or as a war into JBoss. This is not to say, that your exe file is secure: depending on how it is implemented it may allow all sorts of attacks, but again, this is equally true for any mechanism.

How to test connectivity to couchbase server using .NET sdk?

I'm trying to test connectivity to couchbase server using the .NET sdk.
I've tried to get a test key in order to do it, but I'm getting "null" (instead of getting an exception mention that couchbase server is done).
I've also read this:
http://www.couchbase.com/docs//couchbase-manual-2.0/couchbase-getting-st...
But it doesn't say anything about testing connectivity from an application code.
Is there any way of testing connection to couchbase server via code ?
The couchbase client sdk manages the connections for you, whatever node urls you pass to it during construction it attempts to authenticate to, if the client can't authenticate to one of the nodes then it throws ConnectException (I'm using the JAVA sdk but I imagine .NET is very similar).
So really you don't have to test the connectivity, the smart client handles that. After construction you can ask the client to list all the available servers
client.getAvailableServers();
Or for a more detailed status of your nodes and statistics do:
client.getStats();

Node.js and wss://

I'm looking to start using javascript on the server, most likely with node.js, as well as use websockets to communicate with clients. However, there doesn't seem to be a lot of information about encrypted websocket communication using TLS and the wss:// handler. In fact the only server that I've seen explicitly support wss:// is Kaazing.
This TODO is the only reference I've been able to find in the various node implementations. Am I missing something or are the websocket js servers not ready for encrypted communication yet?
Another option could be using something like lighttpd or apache to proxy to a node listener, has anyone had success there?
TLS/SSL support works for this websocket implementation in Node.js, I just tested it: https://github.com/Worlize/WebSocket-Node/issues/29
Well you have stream.setSecure() and server.setSecure().
I'm guessing you should be able to use one of those (specially the last one) to use TLS in websockets since in the end a websocket is just a normal http connection "upgraded" to websocket.
Using TLS in the normal http server object should theorically also secure the websocket, only by testing this can be confirmed.