What is the difference between the RMI Service Exporter and the HttpInvoker?
I know that the RMI uses RMI as underlying communication technology and the invoker standard http post. Any other differences worth noting?
RMI is a standard Java technology, portable in principle. You can easily interact with other Java applications.
Spring HTTP invoker is a proprietary technology. They, just like RMI, use Java serialization, but use standard HTTP protocol as the underlying network layer. On one hand this is less portable as you are limited to other Spring applications. On the other hand using standard HTTP protocol might be viewed as more portable, compared to binary RMI protocol.
Choose:
RMI if you need portability across Java applications
HTTP invoker if you need transparent network transport, working nicely with firewalls, etc.
SOAP/REST web services if your API should work across different platforms/clients and it needs to work using standard HTTP protocol
Thrift or protobuf if you need efficient and portable binary protocol
Related
Recently I am working with along with IOT department, right our project is on discussion and creating core architecture of an application. client specification is we must use MQTT protocol to communicate between device and java application (eclipse paho client).
its a web application based on spring boot and microservice architecture. but I an not able to find any good solution for API gateways that provide MQTT support.
I found zuul is good but do we have any alternative like kong..
MQTT is a TCP stream based protocol, so API Gateways that operate on the HTTP / Layer 7 are not going to fit the bill.
There are extensions to commercial API Gateways available, such as the Axway MQTT Proxy described here.
While not an API Gateway, Confluent also have a MQTT proxy that allows simple integration with Kafka, however if you have already written an application that implements the backend then Kafka is going to require some re-architecting.
The other options are really going for a simple TCP stream reverse proxy like nginx or HAProxy.
If I was asked to build something like this, I'd go straight to Kafka. It and MQTT are a very neat architectural fit and also operate very well together but it really depends on your requirements.
I am new to JMS.
I am little aware of RabbitMq and now trying to find the difference in rabbitMQ with JMS. How it is used and why it should be used?
Thanks in advance.
JMS is a Java API (part of JEE).
JMS Vendors use a proprietary protocol to talk to the broker; they are not wire-compatible.
You can generally talk to any JMS broker by just changing vendor-specific configuration (connection factory etc).
Vendors provide a JMS client library to talk to their brokers.
AMQP is a wire protocol, not an API.
Vendors provide a Java client API.
You can use Spring AMQP, which sits on top of RabbitMQ's amqp-client library and its API.
You can use Spring JMS, which talks to any JMS broker (including RabbitMQ with the plugin) using the JMS API.
If you need to be compatible with any JMS vendor, use spring-jms; if you only intend to use RabbitMQ, I would recommend using Spring AMQP.
Or, use Spring Integration on top of either one, and you can switch between AMQP and JMS by just changing configuration.
I'm not sure what you mean by RabbitMQ for JMS. But, i'll list out the differences below.
RabbitMQ
Works on AMQP protocol and it is not a J2EE specification
Applications written in several languages can produce and consume messages(Python, Ruby, Java, C#, Perl etc.,)
Does not work with J2EE specs, so you cannot use XA Transactions, bean pools, connection factory pools which are all provided by J2EE container by default
Community is not so mature, but, if your organization needs to communicate with a lot of different types and languages of applications you can sacrifice all the beautiful features that are provided by J2EE/JMS spec.
JMS
It is J2EE specification, any application server that provides JMS support should follow the guidelines mentioned in the spec.
Only the Java/J2EE applications can produce and consume, it can be made to work for other languages but with use of adapters
J2EE container provides XA Transaction, Bean pooling, Connection pooling etc., out of the box with little configuration at your end.
If your organization only uses Java based applications, you need not look in RabbitMQ way as you have JMS support which works well.
we're developing standard Java SE application and it is necessary to implement some logic on remote server (using Java EE running on OpenShift PaaS). My question is, what is the best way to remote call classes/methods between the SE client and EE application?
My tips:
EJB remote call: however, is the communication encrypted (or possibility to do that)?
Expose EBJs through JAX-RS: looks line nice one, with possibility to use SSL encryption
Thanks for any suggestions.
Title of this question indicates that the Java SE client is in Spring. If the PaaS provided allows, you can even choose Spring. That will help you in long term as the skillset to maintain your application will be small. It'll also improve efficiency.
JAX-RS is features provided by Spring and EJB are almost same.
Assuming you are bound to use EJBs, I'd suggest to go with 'Expose EBJs through JAX-RS'.
Pros -
It avoids tight coupling of client and service. Remote calls will make client aware of EJBs.
In future, you can choose to change your technology from EJB to something else, then client will be minimally impacted.
If you think to write client in any other technology than Java, then it'll be smooth.
Saves time related to JNDI setup
Cons -
Additional time for marshalling and un-marshalling.
Request-response convertes on client and server sides
I'm developing a messaging system and I used JBoss Netty + Google protobuf for the POC. protobuf was chosen for its swiftness of serialization/deserialization, relatively low traffic cost and availability in several languages.
Still, when it comes to production under heavy load a self-coded server application can never be as good as well-established and tested frameworks.
The problem is, I can't find such a framework that would allow me using protobuf as a transport protocol. Apache ActiveMQ and ActiveBlaze are the closest things I could find but the documentation is nearly absent.
I stumbled upon something that is ActiveMQ protobuf implementation but there is no reminding of it in official ActiveMQ documentation (its not among the supported protocols).
So my question is whether AMQ supports protobuf and if it does how it can be integrated?
No, ActiveMQ uses its own OpenWire protocol or the Stomp protocol. The protobuf bits are used for the underlying KahaDB Message store not the wire level portion. You can store your protobuf data in a BytesMessage and transmit it that way to allow you to marshal and unmarshal the data on either end.
It seems that xmpp is used as protocol in chat application, but JMS also support multiple receiver mode.
It seems that JMS is used in financial messaging system, but xmpp may also support persistence and reliable delivery.
Can someone give an overview of these two protocols?
JMS is an API that you can use to send various types of messages to one or many other J2EE clients whereas streams XML elements as the means of communications.
JMS provides a loosely-coupled interaction between modules so you can send any object. XMPP is a network protocol that enables you to transfer any XML structure.
XMPP's most popular usage is instant messaging via Jabber, but it isn't constrained to that domain. JMS' most popular usage is abstract communication between applications.
I guess, JMS is more centralized as everything should pass through the JMS provider. However, XMPP is not centralized like that.
JMS supports both one-to-one and one-to-many interactions, but XMPP is used mainly for one-to-one.However, this can be done through joining all these clients in a chat-room type of interaction.