87

Is there any clear definition of RPC and Web Service? A quick wikipedia search shows:

RPC: Remote procedure call (RPC) is an Inter-process communication technology that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction.

Web Service: Web services are typically application programming interfaces (API) or web APIs that are accessed via Hypertext Transfer Protocol and executed on a remote system hosting the requested services. Web services tend to fall into one of two camps: Big Web Services[1] and RESTful Web Services.

I am not quite clear what the real difference between the two things. It seems that one thing could belong to RPC and is kind of web service at the same time.

Is Web Service a higher level representation of RPC?

Mr Matrix
  • 1,128
  • 2
  • 14
  • 28
xiao 啸
  • 6,350
  • 9
  • 40
  • 51

4 Answers4

67

Is Web Service a higher level representation of RPC?

Yes, it is. A web service is a specific implementation of RPC. At its lowest level, Web Service connects to the Socket, using the HTTP protocol, to negotiate sending a payload that is executed in a remote space (remote space can be the same computer). All these remote call abstractions, at its core, are RPCs.

Giorgi Tsiklauri
  • 9,715
  • 8
  • 45
  • 66
Wayne Hartman
  • 18,369
  • 7
  • 84
  • 116
  • 1
    Further attributes of a Web Service in addition to what Wayne wrote: allows a platform independent way of a RPC, is discoverable and self describing (compare that with a Win32 RPC). – Alex Jun 12 '10 at 14:11
  • 8
    No, that is not correct. RPC is an architectural style of a Web Service. An alternative would be REST. Reference: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5339611 – schlamar May 09 '12 at 05:40
  • @schlamar Does web service have anything to do with RPC? If yes, do we have client & server stubs in web service environment? – overexchange Dec 30 '17 at 07:47
10

I see this question. The question has been asked long time ago, but I think anyone's answer in this community, giving more information and clarity on this topic, will be helpful for the future questioners. So, I would like to add my enhancement pointing out key differences and I hope, it will be helpful for future readers.

------------------------------------------------------------------------------
| Category             |    RPC              |    Web Services
------------------------------------------------------------------------------
|Operation's Location  | On top of TCP       | on top of HTTP
------------------------------------------------------------------------------
|Data format           | Binary              | Text, XML, JSON, ect.
------------------------------------------------------------------------------
|Speed                 | Slow (Marshalling)  | Fast
------------------------------------------------------------------------------

I have not mentioned descriptions of RPC and Web Services, because you see them in others' answer clearly.

questionto42
  • 7,175
  • 4
  • 57
  • 90
Doston
  • 579
  • 6
  • 15
  • 1
    This is not accurate. RPC has Interface Definition Language as the data format, XML and JSON are binary during transmission too. There is no difference. Marshalling is just decoding, nothing fancy at all. Is HTTP on top of TCP? – zeejan Jan 18 '21 at 15:15
  • 1
    Why is it slow since its binary? – testing_22 Jun 06 '22 at 21:39
  • Unclear, why such differences if the main answer states that there aren’t any? Can anyone comment whether this is even wrong? – questionto42 Feb 21 '23 at 17:29
  • @questionto42 what do you mean "such differences"? which difference are you talking about? – Doston Feb 21 '23 at 20:27
  • Like the first comment above. You show a table with clear differences, although the main answer says that a Web Service is just an implementation of RPC, with RPC at its core (or a comment says that it could be REST as well). Since it is about RPC at the Web Service "core", your table might still make sense, but then, it seems strange to me that the higher abstraction (Web Service) is fast while the RPC is slow. Without knowing anything about it, I fear that there is something wrong in this answer, or that the reader might misunderstand it. – questionto42 Feb 22 '23 at 11:59
5

Remote Procedure Call (RPC) and WebService, in the sake of Functionality both go parallely. But there is a subtle difference in their way of invoking. An Web Service can be invoked by any application, using XML format over HTTP protocol for proceedings and its interoperable in nature, whereas in case of RPC the function can be Invoked by multi applications so it follow the path of Serialization to store the object data. It supports Binary Format over TCP protocol. In a better approach we can brief RPC workflow, like we are executing a function through proper Socket and proper format of message, but don't know the actual existence of the particular function in client server.Even the provided socket might not be in the same server in which the function resides. But every time it give a feel like the function is located in the local. In Remote Service, the Function resides in remote machine and it can be invoked by proper format and Protocol and it allows Scalability.

BenMorel
  • 34,448
  • 50
  • 182
  • 322
fak33r
  • 1
  • 1
  • 1
1

• Data is formatted for transfer using XML, improving or eliminating marshalling, unmarshalling, and various other translation-related requirements normally coded by a developer. • Data is passed using standardized protocols such as HTTP or SMTP, which have published well-defined standards. • The underlying exposed service is well-defined using a known accepted mechanism, WSDL. • Services are found using a well-defined standard, UDDI, and the more advanced ebXML.

Specifically WSDL provides a number of key pieces of information:

• A definition of the format of the messages that are passed between two endpoints using its and elements and appropriate schema definitions. • The semantics of the service: how it might be called to make a synchronous request/reply, synchronous reply-only or asynchronously communicate. • The end point and transport of the service via the element: that is, who provides the service. • An encoding via the element, that is how the service is accessed.