We Keep Coding

What is the difference between RPC and calling web service

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.

What does it mean that Apache Sling "more REST" than Spring-mvc?

Sometimes vaguely I hear that
Apache Sling more REST than Spring-mvc
from my colleagues.
I don't have possibilities to know about it from them.
I have enough experience with Spring-mvc and I am novice in Apache Sling.
Can anyone explain the above quote?
P.S.
I want to see the list of non-REST features of these products.
for example:
Spring-mvc allow to use session attributes and it is contradicts REST principe - to be stateless.

I agree with others that it's hard to measure the RESTfulness of a framework ;-)
And my knowledge Spring MVC is very limited, so I cannot comment on that.
Apache Sling fosters a RESTful way of designing applications, due to its core design and concepts like resources being first-class citizens, default 1:1 mapping of URLs to the content repository, etc.
If you follow its design patterns and examples you're very likely to end up with an application that's RESTful, with clean URLs, no HTTP sessions, HTTP methods which do the right thing etc.
You can also do non-RESTful things with Sling but it's harder, you'd be fighting against Sling natural way of doing things.
So Sling naturally leads you to RESTful applications. Other frameworks might allow you to be RESTful or not, with equal weight. In Sling the emphasis is clearly on being RESTful, and all the core tools and techniques help you get there.

There's no such thing as a framework being more or less RESTful than the others. This is like saying the materials used to build a house make it more or less fitting to a particular architectural style. What will say if your application is more or less RESTful is how you design it, and how your clients access it. You can have a RESTful application using no framework at all, as long as it fills the REST constraints. And you can make an application that isn't RESTful at all if you disregard those.
What will dictate if your application is more or less REST than others isn't the framework you're using, it's:
Being stateless.
Being cacheable.
Clients don't require out-of-band information (HATEOAS).
Respecting the standards of the underlying protocol.
Respecting the client-server architecture.
Be aware that REST isn't an adequate solution to most problems people have. What most people call REST is simply any HTTP API that isn't SOAP, and your colleagues are probably just trying to appeal to REST as an authority in order to give weight to their personal preferences.

Apache Sling is specifically designed to facilitate applications that actually adhere to restful constraints - that is, that are designed to serve resources at URL locations without state change. Spring is more of a general purpose web application infrastructure.

What's the best way to communicate data between java services and .net clients?

We have what I think is a fairly typical client/server architecture, with a frontend written in .NET, displaying data sent from a backend written in Java.
Currently, we use a custom message-based framework for transmitting data snapshots and updates down to clients. This might be upgraded; although the basic java service/.net client setup is set in stone, we want to look at replacements for the message framework, for example WPF MVVM (with an eye on Sliverlight), with databindings to java web-services, or perhaps Coherence.
I was wondering what experiences others have had with this and other approaches (obviously there's no golden bullet for all situations...).
Our requirements are that the clients can show large, frequently updating and editable datasets, primarily in grids.
Update
I've accepted that REST/SOAP is the standard way to do it, but I'd still be interested to hear any other approaches, especially from a performance point of view.

Web services is the most common choice:
RESTful service - more flexible, no strictly defined schema
SOAP service - rigid schema, less flexible

Checkout protobuf, which is a good platform agnostic protocol.

Using Java server-side with PHP-generated front-end

Does anyone have a real-world experience in building such a project? I'd like to move away questions about "is it good idea or not", but focus on possible solutions. I see one simple way - HTTP GET/POST + xml/json - and one more elegant - AJAX/DWR. As for the first one - I understand that it is possible, but needs quite a lot coding. As for second way - is it possible to use Java DWR engine with PHP front-end? Is DWR language-independent for client side (as it uses just JavaScript)?
Would it be a problem, that client page was generated by one web server (for example, apache+php) and served on server-side by another (for example, tomcat)? I suspect, that Tomcat will complain about sessions. Can this problem be fixed with allowing cross-domain AJAX?
Thank you in advance.
Denis.

If what you want to do is (as I suspect) to use PHP to assemble your web pages while the "business logic" is written in Java, I would suggest using PHP/Java Bridge (LGPL and MIT licenses)

Both Java and PHP are server-side technologies. Your "front-end" will be written using HTML, CSS, and JavaScript - although you could certainly use PHP (or JSP) templates to render portions of the front-end.
If you are using PHP as the "front-end", then you would need it to act as a proxy, passing requests back to the Java web server.

I've worked on a project that uses a Java 'backend' and a mod_perl 'frontend'. For the naysayers, this is because the Java is providing service/API facilities, it's not and shouldn't be involved in dealing with UI, be they HTML, WAP, SMTP, SOAP, etc.
For historical reasons the mod_perl talks XML-RPC. It's not a route I'd recommend at this stage. Java, Perl and PHP can quite happily handle far more JSON type transactions due to lower encoding/decoding overhead. Also, in a mod_perl (though not PHP) environment it's possible to run JSON-RPC easily over a persistent connection, reducing the overhead even further.
There are plenty of benefits to this approach, including separate upgrades to the various UIs, stability of the service layer, and distinct responsibilities for each layer.
Downsides include delays getting service improvements live, more complicated development, staging and test environments, a taller barrier to entry for new developers, more documentation and management.
For the "Java front to back" guys, this is a similar type approach to using an OSGi container, only using more domain suitable languages; Java for heavy lifting, scripts for more fluid, text based interfaces.

Pros and cons of using BlazeDS or web services as the remoting and messaging technology between Flex view layer and Spring business layer?

In my company, we are going to use Flex3 for the presentation layer of a new financial web application and Spring for the business layer but a debate is still going on regarding the best messaging/remoting technology. Can you share your own experiences in terms of pros and cons of using one or the other technology?

In my experience, use BlazeDS unless you need to use web services which a variety of technologies can access.
BlazeDS
Pros: Less server intensive, less client parsing time, smaller data package (it's binary), meaning it's overall a faster call. Can do publish/subscribe as well as method invocation.
Cons: Not compatible with non-Flex front ends (although it's open source, so in theory, it could be.)
Webservices
Pros: Well established, pretty much cross platform. Easy to read and translate issues.
Cons: Much more verbose. If you use the internal translation of XML to AS Objects, the client has to do some intensive parsing. If you use the objects as XML, encapsulation will be weakened (objects outside of the call would have to know detailed information about the XML object, meaning refactoring can be problematic.)
For a good comparison on actual databases with actual numbers, see James Ward's Census application.

BlazeDS supports real-time message streaming over AMF and HTTP. But the limitations of the number of clients it can handle are lower than the more efficient RTMP of Adobe LiveCycle ES. You can always switch to LiveCycle later if you need the performance boost, but there is a price tag involved (don't know how expensive it is).