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?
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.
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.
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.
• 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.
Related
I am working with web services right now. We have two types of services, one over HTTP and other over TCP. when Trying to understand the difference between these two, as per my understanding, services over TCP work at the transport layer i.e they transmit data over two ends. So in that case services over TCP will directly transfer data between two ends. But i am not so much clear on services over HTTP. I know we have a Client server model, REST, SOAP and HTTP is the protocol that transmits data but i am not able to properly relate the concept of services over HTTP!
Can anyone please help with an analogy which explains the difference between the two ?
As John Saunders is trying to allude to, I would agree that it is more important to understand the abstractions these protocols provide, rather than specific "Layer" they may be called in certain model (OSI). While the general model helps and applies, it doesn't provide specific details for actual protocols.
Having said that, the difference between so called Transport Layer Services using TCP vs Application Layer Services using HTTP, IMHO boils down to the comparisons between TCP and HTTP itself.
I'll start be saying that I hope it is known to anyone even vaguely familiar with these protocols, that HTTP is higher level abstraction than TCP and in fact it relies on TCP/IP itself. Hence HTTP clearly inherits certain feature like reliability from TCP/IP.
Now the contrast -
TCP Service
Design your own application level protocol - You design your own application level protocol.. For example, how will Client request operation to add an employee? How will Client request to find a given employee? etc... How do you indicate the format in which data can be exchanged between client and server? How will you even distinguish metadata (like request information) from data?
Efficiency - Can be efficient and compact in transmission of data. Since you define your own application layer protocol, Can be anything from binary to string to XML to anything else you can dream of.
HTTP for example, is built on top of TCP, in layman terms, mostly using Key Value pair style request headers.. vs SOAP, where much of information is passed as message envelope and message body (Which is why SOAP can be over HTTP as well as other protocols like Message Queues)
Performance - Given the possibility of having very compact application layer protocol, it can be relatively fast as well. For really high throughput, high performance, latency sensitive intranet applications, this can be a deciding factor.
Development Effort - Along with the flexibility, you certainly end up writing more code, as you attempt to define and implement your own application layer protocol.
HTTP Service
Larger parts of application protocol are defined for you - You design your application over well defined HTTP protocol. Typically HTTP Get would mean querying for a resource. Query filters in request url can be used for searches. HTTP POST, PUT and DELETE similarly have specific, well defined semantics.
Error / Fault handling - Even error are indicated using standards defined in HTTP protocol.. Like Status Code 200 (Success) vs 400 (BadRequest).
Efficiency - Can be quite verbose. Protocols defines almost every aspect of how the request must be defined.. and is typically text based..
Development and Tools support - HTTP can make it easier to use existing, vast variety of tools to send, receive and debug requests (Fiddler or Charles Proxy are famous HTTP debugging tools).
Internet / Firewall Friendly - HTTP is typically used at port 80 (although in theory can be other port as well). Which makes it more suitable not only for intranet applications, where you may have more control over firewalls and ports you open.. but also for accessing those services over Internet, because port 80 is typically open on almost every machine in the world...
Co-existence of multiple services - HTTP is so widely used, that it is expected multiple applications / services on a given machine to use it.. OS typically have special support built into the OS to handle this (http.sys on Windows) and you don't have to worry about one application / service stepping on another, by accidentally using the same port (one will fail in such case). Port negotiation between client and server is typically not an issue in this case, because HTTP is expected to be at port 80.
Securing the communication channel - When it comes to securing the communication, again there is well defined way to establish the same.. i.e. HTTPS. Unlike TCP/IP based service, you don't have to invent your own scheme to encrypt the communication between client and server.
Hosting the service - In theory, there are more ways to host an HTTP service, than a TCP service, again due to HTTP web applications already being a common scenario, which web servers like IIS already cater to. Your HTTP service can take advantage of countless out of the box features which web servers like IIS already have.. Recycling, Authentication, Resource Management, Request Filtering, Caching, Dynamic Compression and Logging etc etc etc.. you get for free with HTTP services hosted on any of the mature web server products.
Interoperability Across Platforms / Technology stacks - With HTTP, it would be far easier to use a mix of any technology stack, again because the implementation of the Protocol will be typically supported on various platforms.. from Linux / Unix to Windows.. or from .Net to Java to Ruby.. You'll get benefit from existing tools and technologies present on these platforms which support HTTP.. Hence Http can be the de facto choice, if, for example, you expect server to be in .Net on Windows, but clients to be in Java on Unix.
I could go on.. This is by no means an exhaustive list, and I am sure that many others could add plenty more to this.. But hopefully this gives you a good idea for what you were looking.. One can clearly see, that this can be a very deep topic.. Based on your response and time, I may edit this answer in future.. or encourage others to update it, as they see fit.
Side note - It is interesting to note, that even though HTTP adds plenty over TCP/IP to make it a great and ubiquitous choice for application protocol.. There is always scope for more / higher level abstraction.. So much so that, there are other, newer service protocols, which are built on top of HTTP. For example - Odata. Look at OData if you are curious..
And of course, in todays world of services, the discussion will not be complete without the mention of REST.
EDIT: Another interesting side note - If you are building on Windows platform, and using .Net framework, there are frameworks like Windows Communication Foundation a.k.a. WCF, which try to provide such abstractions, that you can swap out your choice of communication protocol (Client and Server choice must still match), from HTTP to TCP to MSMQ to IPC etc, with mere configuration changes, or host same service over multiple communication protocols by creating multiple endpoints. Refer to Understanding various types of WCF bindings for high level overview and comparison of various, out of the box, options WCF provides.
When working with TCP/IP and protocols layered on top of it, I would take the 7-layer model with a grain of salt. The true number of layers will differ, and will not match up with the classic OSI model.
For instance, HTTP is built on top of the TELNET protocol, which is layered on top of TCP. Does that make TELNET a Presentation-layer protocol? No, it's an Application-layer protocol that happens to have another Application-layer protocol built on top of it.
And then we run SOAP over HTTP. Or, if we want, we can run SOAP over TCP/IP. So what layer is SOAP? Is that layer 8 or is that layer 9?
As You asked, I'll try to explain by analogy, while not repeating previous answers too much.
Let's say we have helpdesk (service) reachable by phone call (TCP) and by SMS (HTTP). From Your (application) point of view You should get the same information independent of which communication method You chose. But there are differencies how this communication will be going, because phone call (TCP) is statefull channel, while SMS (HTTP) is stateless:
once phone call is established, information exchange will continue until hang'up;
SMS message must contain all relevant information to get a usefull response.
To introduce state into SMS channel, additional steps at helpdesk level are required, for example, You'll be assigned ticket number, which You must send with each related SMS (HTTP cookie/session) - this won't be handled authomatically by GSM network. This state is handled by helpdesk's and Your (service and application) logic.
Both service types have advantages and pitfalls. And both should work - preferance depends on actual use-case.
There is no too much difference what means are used to exchange data (You can even exchange mails using post office, if latency is acceptable). In practice it means You can use ping (ICMP) or DNS queries, or emails to exchange data - as long as Your application knows how to use/decode such channel.
I think John Saunders in his answer refered to 7 layer OSI model, an I think his point is correct.
This analogy is not 100% correct, I tried to explain the idea: the difference is how the state is preserved (by protocol itself, or by application/framework).
I learned about service oriented architecture yesterday, and I have a question about it.
in order to talk to web service provider the initial communication has to be started by a service consumer. Then does it mean that a web service provider cannot talk to another web service directly (because it is not a consumer)?
I do not have enough information to grasp a full scope of what you're getting at exactly. However, I can say that this statement:
Then does it mean that a web service provider cannot talk to another web service directly (because it is not a consumer)
Isn't really true. A program can (programmatically) access data provided by a web service. The web service has no real awareness as to what a 'consumer' is. It only sees (programmatically) the data provided by the client (typically browser data, cookies, cache, etc..). But that doesn't stop anyone from opening a bash shell and curling the website.
This will retrieve any data statically provided by the server. Note that the data may obfuscated using JavaScript as to take measures to prevent any programs outside of a browser environment to access their critical data.
So the answer to that question, is yes and no.
You should ask this question on https://softwareengineering.stackexchange.com/ as it is more relevant to questions regarding programming concepts.
Both from technical and architectural points of view service of course can call another one. Simply, it is changing its role to behave as a consumer for the second service. Just be aware that things may become messy if both services are calling each other both ways to finish their task for a single client request. Though there are often valid scenarios for such behaviour, if both services are managed by the same entity, its worth looking if tasks shouldn't be moved or services merged as this may be a sign of a bad design decisions.
Any piece of software can talk to a web service as long as it can reach it.
A quote from Java Web Services: Up And Running, Second Edition book :
"At present, the distinction between the two flavours of web service is
not sharp,
because a SOAP-based service delivered over HTTP can be seen as a special case
of a REST-style service;"
How ?
How?
I believe the writer's statement is incorrect.
What is SOAP?
According to wikipedia:
SOAP can form the foundation layer of a web services protocol stack,
providing a basic messaging framework upon which web services can be
built. This XML based protocol consists of three parts: an envelope,
which defines what is in the message and how to process it, a set of
encoding rules for expressing instances of application-defined
datatypes, and a convention for representing procedure calls and
responses. SOAP has three major characteristics: Extensibility
(security and WS-routing are among the extensions under development),
Neutrality (SOAP can be used over any transport protocol such as HTTP,
SMTP, TCP, or JMS) and Independence (SOAP allows for any programming
model).
As you can see, there really isn't anything in this description of SOAP that takes any ideological stance over what the structure of your API calls (url wise) must adhere to. Of course, soap uses XML, and XML can have a data structure that essentially works as the rule-set of your API call... thats cool.
In contrast, we have REST.
What is REST?
According to wikipedia:
The REST architectural style describes the following six constraints
applied to the architecture, while leaving the implementation of the
individual components free to design:
Client–server: Servers are not concerned with the user interface or user state, so that servers can be simpler and more scalable.
Stateless: The client–server communication is further constrained by no client context being stored on the server between requests.
Cacheable: Responses must, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients reusing stale or inappropriate data in response to further requests.
Layered system: A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches.
Code on demand (optional): Servers can temporarily extend or customize the functionality of a client by the transfer of executable code.
Uniform interface: The uniform interface between clients and servers, discussed below, simplifies and decouples the architecture, which enables each part to evolve independently. (i.e. HTTP GET, POST, PUT, PATCH, DELETE)
Comparison
In my mind, it shouldn't be described as SOAP vs REST, it should be RPC vs REST. RPC is remote procedural call, which basically means that every single functionality of your API gets 1 distinct API endpoint, and so on. so, REST can do with 1 url what RPC does with 7. SOAP is RPC (right?)
Yes, both are web services.
But saying that an RPC API is RESTful-ish because its transmitted over HTTP is hardly grounds to say they are similar... from the detailed information above, you can see that REST takes a much more ideological approach to the structure, transfer, purpose, scalability, and state of your service, whereas SOAP doesn't really talk about those things, and presumably the developer can choose to do, or not do, those things.
In conclusion, more context is needed for me to really understand what point the author was trying to make. An RPC API can be similar to REST if you make it do RESTful things.. but that is really circumstantial, isn't it?
I am currently thinking about Integration styles. Following Gregor Hohpe and Bobby Woolf (http://eaipatterns.com/) the basic integration styles are
File Transfer
Shared Database
Remote Procedure Invocation
Messaging
which I understand. But which of these styles do WebServices generally apply to?
Would REST for example be a File Transfer style as it is be used to transfer resources over HTTP?
SOAP RPC applies to Remote Procedure Invocation I guess, but what about non-RPC SOAP?
WebServices could even apply to Messaging, i.e. SOAP over MQ, right?
REST calls are fundamentally Remote Procedure Invocations, as they are a lightweight way to perform method calls.
Messaging such as SOAP over MQ means looking at REST as a transport, the same way that a binary protocol over TCP is a transport.
File Transfers over HTTP, where the files are ordinary files (not XML or JSON) are no considered to be REST calls.
This question already has answers here:
JMS vs Webservices
(9 answers)
Closed 7 years ago.
I need to develop a system which accepts orders and returns confirmation. Orders could come from java or non java clients.
Not sure whether to go for web service implementation or JMS.
Any suggestions ...
JMS is an API which abstracts messaging middleware, like ActiveMQ or IBM MQSeries.
Messaging middleware has a store-and-forward paradigm and asynchronous message passing, while web services tend to promote a synchronous procedure calling paradigm. In distributed systems where a lot can go wrong, dealing with things asynchronously tend to focus the mind better to the things you need to do when part of the system is not available or poorly performing and the code needed to deal with that tends to be a lot less complicated.
Clustering parts become trivial if you have multiple servers listening on the same queue, parallelism and load balancing is for free in this case.
Personally I find JMS much easier to work with and more robust and reliable than web services, but the messaging middleware must support all platforms you want to use. If all the components who need to talk to each other are under your control, I would give a messaging middleware with a JMS interface serious consideration.
If the other party is external then probably Web Services rule, and in that case you could think of a using thin layer to convert the external web service to an internal message passing infrastructure so you still have the most of the advantages.
If it is "just slapping an remote API on a webapp" then of course it does not pay either to setup asynch messaging.
You can use both depending on your interoperability, scale, distribution and integration requirements.
Web service approaches utilising SOAP, XML RPC and REST provide something quite interoperable given the use of HTTP as the protocol. From a service side, you might receive a web service request and then marshal it into a message. Your message could then be delivered to a messaging bus.
JMS is a reasonable API for interfacing with a messaging bus and I've found that Active/MQ very good here. Active/MQ supports JMS across many languages.
With messaging you can utilise the Request/Reply Enterprise Integration Pattern to receive responses and return them via your web service. However think about the merit of providing immediate feedback as to whether the order has been processed vs feeding back the fact that an order has been received; you might not need to implement request/reply to acknowledge that an order has been received.
The benefits of messaging can be found here: http://www.eaipatterns.com/Messaging.html
You may even want to look at Apache Camel to simplify the development of highly scalable and distributed service layers.
check the links
difference between using JMS/Messaging Middleware versus Web services
Messaging, JMS and Web Services
Web Services HTTP vs. JMS
Choosing among JCA, JMS, and Web services
Java Message Service
Web service
So if communicating Applications are Java based use JMS and if may be different then Web services... thats what which I follow.
For interoperability sake, use a web service. JMS is little used outside the Java world.