I just read about rpc http://www.grpc.io/ remote procedure calling, other hand we have a webservice where client send a request to server and server responds.
Same things goes with rpc where stub calls a method which is at server end. I think same things can be implemented with the help of webservice.
What rpc can make a difference and where it is better to use ?
RPC is a protocol that one program can use to request a service from a program located in another computer on a network without having to understand the network's details. A procedure call is also sometimes known as a function call or a subroutine call.
Webservices foster loose coupling. You should prefer that. RPCs limit you to a certain programming language. When you use webservices, you can have different languages and even different operating systems, that can interchange pieces of information. When you think about connecting serveral kinds of devices you should use a webservice, but when you are building a distributed application with several modules, maybe RPCs are more suitable.
"A dear child has many names". RPC, Soap WS, REST, RMI and others are just different ways of communicating between computers, with plenty of similarities to make it possible to reach the same end result, no matter which one you choose. In this case (grpc), the RPC is just a generic "Remote Procedure Call" name, indicating its use.
When selecting one of the technologies you need to know the differences, so for example RMI being a Java-only technology isn't something you'd want to use when not in a full-Java environment (and even then I wouldn't go for it). If you really love SOAP and/or XML, you might want to go with regular webservices. If you prefer JSON over HTTP, then REST might be your choice. If you want to go for bleeding edge, you might want to choose the grpc or other similar technology.
More often than not the technology to use would be determined by existing codebase, so if you had SOAP webservices used previously, you'd continue to use that.
What rpc can make a difference and where it is better to use ?
Advantages of rpc
Main advantage I see is that you're forced to catch more errors at compile time.
This post on gRPC-Web: Moving past REST+JSON towards type-safe Web APIs says:
"
No more hunting down API documentation – .proto is the canonical
format for API contracts, just like in other teams
No more hand-crafted JSON call objects – all requests and responses are strongly typed and code-generated, with hints available
in the IDE
No more dealing with methods, headers, body and low level networking – everything is handled and abstracted away in the
grpc-web-client
No more second-guessing the meaning of HTTP error codes – gRPC status codes are a canonical way of representing issues in APIs
No more hand-crafted chunk-encoded streaming madness on the server – gRPC-Web supports both 1:1 RPCs and 1:many server-side
streaming requests
No more data parse errors when rolling out new binaries – backwards and forwards-compatibility of requests and responses is
guaranteed by protocol buffers
"
Advantages of protocol oriented architecture
Main advantage I see is that you have standard operations and common concepts that can be reused in different scenarios.
In Richardson Maturity Model - steps toward the glory of REST the concept of different levels is introduced. You can extract some advantages from there.
"
Level 1 tackles the question of handling complexity by using divide and conquer, breaking a large service endpoint down into multiple resources.
Level 2 introduces a standard set of verbs so that we handle similar situations in the same way, removing unnecessary variation.
Level 3 introduces discoverability, providing a way of making a protocol more self-documenting.
"
When to use what?
Maybe rpc is good for in-house usage when you have a team of domain experts that is not familiar with HTTP or other common protocols. It has also advantages in backend-to-backend communication where no browsers are involved. With technologies like gRPC one can support communication between multi languages/technologies.
In all other cases HTTP-like communication still seems the standard for most use cases in 2017?
Even if the question was asked long time ago, I would like to add my short answer with key differences and hope it will be helpful for future readers.
------------------------------------------------------------------------------
| Category | RPC | Web Services
------------------------------------------------------------------------------
|Operation's Location | On top of TCP | on top of HTTP Protocol
------------------------------------------------------------------------------
|Data format | Binary | Text, XML, JSON, ect.
------------------------------------------------------------------------------
|Speed | Slow (Marshilling) | Fast
------------------------------------------------------------------------------
I have not mentioned descriptions of RPC and Web Services, because you see them in others' answer clearly.
Related
I need to interact with a server over TCP/IP with a basic message/response protocol (so for each request I shall receive a defined response).
In the JVM ecosystem, I think Java Socket was the tool to use 15 years ago, but I'm wondering if there is anything more suitable nowadays in the JDK? For example, with Java Sockets one still needs to manually timeout a request if no answer is received, which feels really old fashioned.
So is there anything new in the JDK or JVM universe?
No, there are much better option nowadays which allow you to implement your client/server asynchronously without additional threading.
Look at SocketChannel from nio or even better AsynchronousSocketChannel from nio2. Check this tutorial
Especially the latter option will allow you to just start the connection listener and register callback which will be called whenever new connection is requested, data arrived, data was written etc.
Also consider looking at some high level solutions like Netty. It will take care of the network core, distribute load evenly to executors. Additionally it provides clears separation of the network layer and processing layer. For the processing layer it will provide you with lot of reusable codecs for common protocols.
You can try RMI which works on top of TCP/IP but hides all the hardwork with a convenient set of APIs.
Follow this tutorial post
Well, there are really a lot of other technologies to use, for example JMS has various implementations which work out of the box.
Sockets are low-level building blocks of network communications, like wires in the electricity network of your house. Yes, they're old fashioned, yes, we likely don't want to see them, but they're there and they will stay there for a good reason.
On top of Sockets, you can e.g. pick the HTTPUrlConnection, which implements most of the HTTP protocol. Still, setting timeout policies are in your hands, which I find quite useful, and extremelly painful at the same time.
http://www.mkyong.com/java/how-to-send-http-request-getpost-in-java/
You are free to move one abstraction level above, and use a ready-made REST library, such as this: http://unirest.io/java.html
The example above connects to a server, configures a HTTP query string, perform the request (timeout, encodings, all the mess under the hood), and finally get the response in Json format in a few lines:
Unirest.post("http://httpbin.org/post")
.queryString("name", "Mark")
.field("last", "Polo")
.asJson();
Nowadays a vast amount of web services are available using REST protocol, which is a simple command-response over HTTP. If you have a chance, I'd suggest using REST, as you can easily find available client and server side implementations, and you don't need to reinvent the wheel on the command-protocol layer either.
On client side, unirest is quite convenient. On the server side, we have had really great experience in the 1.2.xx series of Play! framework. But there are thousands of these things out there, just search for "REST".
Take a look to Netty Project, "Netty is a NIO client server framework which enables quick and easy development of network applications such as protocol servers and clients. It greatly simplifies and streamlines network programming such as TCP and UDP socket server."
This framework give us a lot of capabilities that simplify the programming process, allowing a big scalability.
Is used by Twitter and a lot of big companies in the tecnology industry.
This is a nice presentation from Norman Maurer.
So we have JAX-WS that is SOAP based and can be either RPC Style or Document Style. These are also called as Big Webservices
Also the above two have the options of using encoded or literal styles.
Then we have JAX-RS, the RESTful version of Webservices. As per my knowledge this style is used for building light web services and also webservices that don't generate dynamic data so the result can be cached. No WSDL required. This also does not support authentication(I think).
Do these styles differ in performance or speed of execution ?
I have an application that uses Webservices to access database that is behind the firewall.(Exposing data as a Service- I am using a tool called WSO2 ) The queries execute fast but the webservices take time in formatting the data in XML so my application slows down.
Will my performance improve if I use different styles of Webservices ?
RESTful webservices do support authentication, the easiest being HTTP Basic AUTH.
Naturally there are differences in performance, depending on what kind of things you're doing. However it's unlikely that the type of the WebService would be important in improving performance. It's more about what the WS is doing. The real hotspots are in your business code.
REST is more lightweight in terms of troughput compared to SOAP, because only a minimum of data gets transfered over HTTP. You can find more information in
this great thread.
For SOAP, and the difference between RPC/encoded, RPC/literal, Document/encoded, Document/literal and when to use each, you can check out this article. It touches on performance - it is mainly related to having type encoding vs not having.
You say that queries (and I assume business logic as well) are pretty fast. So if you want to optimize for performance in your case you should first analyze network connectivity - speed, latency, bandwidth and then maybe take a closer look at the message transformation logic in case you do something too heavy.
Few points to differentiate web services and REST.
SOAP/web services (SOA)
Strict contracts/service definitions such as WSDL/XSDs
Complex message formats - SOAP
Complex security protocols - WS-Security, WS-Trust/Federation etc.
REST-
- Loose contracts with simple message formats (JSON, XML)
- API definitions via simple standards such as Swagger . http://swagger.io/
- Lightweight protocols such as basic-auth/OAuth 2.0/OpenID Connect.
My recommendation is that you should select web services or REST based on business requirements but not based on the performance (Of course with strict validations in SOAP web services, there will be a performance hit)
It is also important for keep in mind that REST based business functionalities/services are the key driving force of the APIs and API-Management[1].
[1] http://www.slideshare.net/kasun04/api-integration-and-soa-convergence
I'm a networking newbie and have explored a few frameworks such as Jersey and CXF for building RESTful web services in Java.
I have a new application that requires sending large amounts of binary data over the internet (between client and servers), and it needs to be extremely fast. I'm wondering if there is such a thing as a pure "TCP/IP (non-)web service", and if there are any open source Java libraries for building such things.
If all network services have to sit on top of TCP/IP, then I guess I'm looking for something that still uses binary data, but that introduces extremely little overhead for speedy service.
I always associated REST with XML or JSON; if it can be configured to be super-fast and work with binary data, I'd even be into that since I'm already somewhat familiar with Jersey.
I thought RMI might be a good choice, but not sure if it's not appropriate for this use case.
I need speed and I need a binary protocol, and not sure where to start. Any ideas? Thanks in advance!
Can´t you go with Java Sockets?
That is how low level you can go.
http://docs.oracle.com/javase/tutorial/networking/sockets/
Yes RMI is way faster than any high level transport abstraction like CFX. You have two options, raw sockets or RMI, RMI is easier to work with.
REST is an architectural pattern whose distinctive trait is using the HTTP verbs for what they were originally intended to. Even if the majority of deployed REST services use JSON to serialize objects, the entire HTTP transaction looks like this:
PUT /user/foo HTTP/1.1
Host: example.com
X-Auth-Token: foobarbazanythingyouwanthere
{"fist": "Jeff", "last": "Atwood"}
And the response is:
HTTP/1.1 200 OK
So, there is no real "overhead". Instead, you exploit the capabilities of existing libraries to deal with routing, authentication, serialization, and so on. Since HTTP uses MIME-like envelops, it has no problem with binary content, and even if this adds some overhead, it's very difficult to come up with a super-efficient, yet effective protcol, not to mention that you need to design it, implement all the libraries and -well- nobody else will ever be interested in your work.
Since you state you are a "network newbie", and since you seem to use terms like REST and RMI in a random manner, my strong suggestion is not thinking about performance and just go with standard technologies. You can use HTTP, there are lots of pre-built framework, servlet containers, server stubs, you name it.
Come back when you measure real performance bottlenecks, so that we'll have the figures to better assist you.
I have 2 processes that need to communicate over the same PC and different PCs. In the local case the process communication is among different processes e.g Process A and Process B.
In the remote case it will be among 2 instances of Process A running in different PCs.
I will create them from scratch and I am wondering what is the best approach. I am aware of RMI and sockets but I was wondering for my case as described, and taking also into account that the messages exchanged are small and the number of APIs really small, if there is a standard approach/library for this.
Any suggesstions are highly welcome
Update after #EJP comments:
My interest is 1)to implement the requirement for communication in a light manner since the API exposed will be really small and the messages as well 2)use and learn a new popular framework if possible (I already know RMI and sockets)
If you are just looking for messaging frameworks, there's a bunch available out such as
RabbitMQ - http://www.rabbitmq.com/
ZeroC Ice - http://www.zeroc.com/ice.html
AMQP - http://www.amqp.org
OpenSplice DDS - http://www.prismtech.com/opensplice
But when you use a 3rd party framework, you are then adding an additional dependency to your application. If it is something very simple like your case, perhaps writing a TCP client/server would be sufficient for a client/server paradigm or if you are looking for publisher/subscriber paradigm then you can look into using UDP multicast. You just need your data class to extends Serializable if you want to be able to marshal and unmarshal your data to buffer and send it over to network using typical JAVA socket API.
I strongly suggest having a look at Thrift. From all the technologies I've used (web services, RMI, XML-RPC, Corba comes to mind) it is currently my favourite. Essentially the steps involved are:
Download the Thrift compiler.
Add the Maven dependency (make sure it is the same version as the compiler!) I currently use 0.8.0.
Write your Thrift IDL (incredibly easy, google for it as there are plenty of examples).
Compile it for Java.
Writer your server/client.
In general, you can whip together a server and a client in about 30 lines of code. In terms of speed and reliability it has never failed me before.
You might have a look at Versile Java (full disclosure: I am one of the developers), it satisfies at least your criteria #1. From the API documentation, here are some examples of writing remote-enabled objects, running a service, and connecting to a service.
If you want to learn something new then I'd look at OpenSplice. The reason is pretty simple, among the technologies suggested above is the only one that provides you with Data-Centric abstractions.
The cool thing about OpenSplice is that gives you the abstraction of a Global Data Space, yet the implementation of this global data space is fully distributed and very high performance.
Take a look at some of the slides available at http://www.slideshare.net/angelo.corsaro and I am sure you'll get in love with the technology.
Finally OpenSplice is Open Source.
Happy Hacking.
A+
JMX is a good alternative .
Example :
http://www.javalobby.org/java/forums/t49130.html
IMB JMX Example
http://alvinalexander.com/blog/post/java/source-code-java-jmx-hello-world-application
I have done some searching but haven't come up with anything on this topic. I was wondering if anyone has ever compared (to some degree) the performance difference between an RPC over a socket and a REST web service. If both do the same thing, which would have a tendency to be the better performer? I've already started building some socket code and would like to know if REST would give better performance before I progress much further. Any input would be really appreciated. Thanks indeed
RMI
Feels like a local API, much like
XMLRPC
Can provide some fairly nice remote
exception data
Java specific means this causes lock
in and limits your options
Has horrible versioning problems
between different versions of clients
Skeleton files must be compiled in
like CORBA, which is not very flexible
REST:
easy to route around firewalls
useful for uploading files as it can
be rather lightweight
very simple if you just want to shove
simple things at something and get
back an integer (like for uploaders)
easy to proxy security behind Apache
and let it take the heat
does not define any standard format
for the way the data is being
exchanged (could be JSON, YAML 1.0,
YAML 2.0, arbitrary XML format, etc)
does not define any convention about
having remote faults sent back to the
caller, integer codes are frequently
used, but method of sending back data
is not defined. Ideally this would be
standardized.
may require a lot of work on the
client side caller of the library to
make use of data (custom serialization
and so forth)
In short from here
web services do allow a loosely
coupled architecture. With RMI, you
have to make sure that the objects
stay in sync in all applications
RMI works best for smaller
applications, that are not
internet-related and thus not scalable
Its hard to imagine that REST is faster than a simple socket connection given it also goes over a Socket.
However REST may be performant enough, standard and easier to use. I would test whether REST is fast enough and meets your requirements first (or one of the many other existing solutions) before attempting your own Socket solution.