is have been studying rsocket and reactive programming for a while and quite often spring webflux is mentioned i wanted to ask whats the difference between the rsocket and spring webflux or are they same things.Thanks
RSocket (https://rsocket.io) provides a protocol for Reactive Streams semantics between client-server, and server-server communication. It allows you to use Flow (Flux), or a single response (Mono) over a network with various semantics and bidirectionally.
Spring Webflow (https://spring.io/projects/spring-webflow) is a way to build a webapp with reactive stream semantics for non blocking operations.
Typically you might combine these, such as your backend connecting to other services using RSocket, or you might choose for some clients (e.g. Javscript running in the browser) to talk to the server using RSocket over WebSockets for streaming events.
There are some major differences between the two.
Webflux supports HTTP request-response
RSocket is a protocol (Uses TCP/Websocket) for reactive streams it supports below
request & response
fire & forget
request & streaming
Bi Directional streaming
Another major difference is that in Webflux the data is transferred as JSON but in RSocket it is transferred as Binary.
In short, RSocket is more advanced, faster, has more modes and supports Reactive Stream programming better. The downside to it compared to Webflux is the lack of tools to test.
Related
Hi according to this the API is deprecated and considered legacy. It is not specific about when it will be removed. They recommend using Network, though it doesn't have a low-level API for alternative transports/physical layers.
I plan on using it for securing Bluetooth communications (like a BLE Uart thing), which means the API should not be dependent on network transports. Secure Transport fits this bill.
Is it okay to use this for future-safe developments?
Is there an alternative that will support something with an obscure transport layer (like BLE)?
I've looked at Swift-nio and its children, and it looks like it may work when overriding Channel etc, though it is more geared toward network transports.
I am studying SOA architecture and I am bit confused, googling there are many definition of that, many technologies are involved and here my doubts start:
If I got correctly these are the principles for a system to be SOA:
Use Open Standard: XML, WSDL, WS Security. About WSDL, it is important because integrating different services (typically Web Services must expose them contract? Then If I got BPEL usage is just a process that uses contract of services to permit communication between them.
Be Modular
Use ESB : (This seems to be a must, even for services that don't
need to communicate via it.. This introduces my first doubts.. if a
service is exposed as Web Service expose his own WSLD that enables
interoperability, why the ESB should be used as a must?
Then comes BPEL, is BPEL a language to orchestrate services
interaction each other? Something like Orchestration in Saga
Pattern?
Increase interworking between services as much as possible
(different than the principles of Microservice Architecture)
Adopting previous (old) enterprise application that usually are very
old, a SOA is frequently based on services using
traditional relational database
Maybe point 5 and 6 are consequences than rules to follow...
Tks
I can try to answer to my question:
About the usage of ESB: In theory it could be possible to avoid the usage of ESB, but without an ESB application owners would each have to find their own unique way to expose service interfaces, which is a lot of work (even if the interfaces are eventually reusable) and creates a significant maintenance challenge in the future, that's why it is considered essential part of a SOA and considered such a de facto element of any SOA implementation.
BPEL: yes, it is used to orchestrate and coordinate different exposed API, maybe from different Web Services to create a new application.
I am totally new to Solace, your ideas will be grateful. building a system that will integrate with Solace Messaging bus. the system will have a service layer which will communicate with Solace Messaging bus to pull messages from external systems and in future, it also will be integrate with internet based messages.
So I have two options in front of me, 1) JMS 2) .NET 3) REST
Could you please let me know which is the best option above, when the service layer has to connect with .NET Business layer. considering, extensibility, performance, message transformation, scalability etc.,
Thanks
Messages are generally inter-operable between the different APIs.
For example, a JMS message can be consumed by a .NET consumer.
You can pick whichever API is the most convenient for your use case.
Since your service layer is communicating directly with your .NET Business layer, perhaps it might make sense to have the service layer use the .NET API.
Alternatively, you might feel that it makes sense to make use of the REST API, which is an open protocol, without the need for Solace provided libraries.
From all the NMS(network management solutions) I've looked into,
only Zenoss has a daemon to process AMQP messages (meaning my prefered one, Zabbix, is oblivious to it.)
Why is that?
Is AMQP that far away from production ready?
From a glance RabbitMQ 2.0 (or even ØMQ) seem to have solved most problems still standing from the Reddit May 10' test.
)
AMQP scalability and generic design stand to me as an obvious choice for an efficient and agnostic NMS feeder.
Is being agnostic its main flaw?
Is it being ignored by existing NMS solutions because having a proprietary communication protocol makes it harder for enterprises to switch from one NMS to another?
So far, AMQP is an "unrealized potential" for a simple reason : there are several non interoperable versions of the protocol, which makes it very difficult for an ecosystem to emerge.
For instance, RabbitMQ is supporting versions 0.8 and 0.9 of the protocol, Qpid C++ is implementing 0.10 so you've got no way to connect them. Hopefully, the situation should evolve positively in 2011 because the working group is closed to releasing version 1.0 of the protocol and implementers are working together to make sure that interoperability is achieved (it's a condition for marking the current version 1.0 proposal as "final"). When this happens, it should make a lot more sense for third party products to support AMQP.
Also, you should note that having an open messaging protocol doesn't solve all the problems. In the case of a monitoring solution, it would allow various applications do communicate but it wouldn't say what are the expected information in each message or where they should be sent. That's why Qpid has developped it's own monitoring and management protocol on top of AMQP (See Qpid Management Framework)
I am in trouble finding API for the "local Erlang client" for Riak.
Here is what Riak wiki says:
The local Erlang client is a tightly-integrated part of Riak and the Riak REST interface uses the Erlang client internally. You can find more information about the Erlang-native driver in the edoc API.
The link redirects to the main wiki-page. There is plenty of information on PBC Client though.
How do both clients compare and what are the pros and cons in using one or another?
The API for the native erlang client or edoc is found here
But I would second what Dan says. However, note that the PBC is still very much at the alpha stage of development and as far as I know does not yet have map reduce capabilities.
I would recommend using the PBC client. The performance is comparable to the native erlang client. It is also easier to decouple your application code from Riak. The native erlang client requires the entire Riak code base as a dependency.
From Riak 2.0 and on, it is highly recommended to use PB (Protocol Buffers) APIs over HTTP APIs. They have become a primary APIs, have more functionality and also is faster than HTTP APIs.
Getting Started with Erlang client
GitHub repo for official Riak Erlang client