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.
Related
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'm looking for options that would allow a client to receive messages (push notifications) from a server. The client is an ARM/Linux embedded device similar in capabilities to a Raspberry Pi.
Because the client could be behind a firewall, I'd like to use message-oriented middleware (MOM) that can transport on top of HTTP. I think that rules out MOMs that are based on AMQP.
The MOM server should support the Linux platform. The MOM should also provide a C or C++ client library that can be compiled on an ARM/Linux platform.
I am aware of the HTTP long polling technique, as well as HTML 5 WebSockets and Server-Sent Events. But I'd prefer a higher-level (yet lightweight) solution that takes care of transporting messages between point A and point B over HTTP. It doesn't matter much if the messages have to be formatted as XML, JSON, plain text, or binary.
Two that I have used successfully are XML-RPC and gSOAP.
XML-RPC:
It's a spec and a set of implementations that allow software running on disparate operating systems, running in different environments to make procedure calls over the Internet.
It's remote procedure calling using HTTP as the transport and XML as the encoding. XML-RPC is designed to be as simple as possible, while allowing complex data structures to be transmitted, processed and returned.
gSOAP:
The gSOAP toolkit is a C and C++ software development toolkit for SOAP/XML Web services and generic (non-SOAP) C/C++ XML data bindings. The toolkit analyzes WSDLs and XML schemas (separately or as a combined set) and maps the XML schema types and the SOAP messaging protocols to easy-to-use and efficient C and C++ code. It also supports exposing (legacy) C and C++ applications as SOAP/XML Web services by auto-generating XML serialization code and WSDL specifications. Or you can simply use it to automatically convert XML to/from C and C++ data. The toolkit supports options to generate pure ANSI C or C++ with or without STL.
According to my research, these are the available MOM technologies that use HTTP as a transport, and which feature a C/C++ client library:
XMPP
Extensible Messaging and Presence Protocol (XMPP) is a communications
protocol for message-oriented middleware based on XML (Extensible
Markup Language).The protocol was originally named Jabber, and
was developed by the Jabber open-source community in 1999 for near
real-time, instant messaging (IM), presence information, and contact
list maintenance. Designed to be extensible, the protocol has also
been used for publish-subscribe systems, signalling for VoIP, video,
file transfer, gaming, Internet of Things applications such as the
smart grid, and social networking services. (from Wikipedia)
ActiveMQ
Apache ActiveMQ is an open source message broker written in Java
together with a full Java Message Service (JMS) client. It provides
"Enterprise Features" which in this case means fostering the
communication from more than one client or server. Supported clients
include the obvious Java via JMS 1.1 as well as several other "cross
language" clients. The communication is managed with features such as
computer clustering and ability to use any database as a JMS
persistence provider besides virtual memory, cache, and journal
persistency. (from Wikipedia)
Zerogw
Zerogw is a http to zeromq gateway. Which means it listens HTTP,
parses request and sends it using zeromq socket (ZMQ_REQ). Then waits
for the reply and responds with data received from zeromq socket.
Starting with v0.3 zerogw also supports WebSockets. Websockets are
implemented by forwarding incoming messages using ZMQ_PUB socket, and
listening clommands from ZMQ_SUB socket. Each WebSocket client can be
subscribed to unlimited number of topics. Each zeromq message it
either control message (e.g. subscription) or message to a specified
topic which will be efficiently sent to every WebSocket subscribed to
that particular topic. (from the GitHub zerogw page)
There's also the HyperText InterORB Protocol (HTIOP), but TAO seems to be the only CORBA ORB that supports it. There doesn't seem to be anyone using it (please correct me if I'm wrong).
There is work in progress to make OMG's Data Distribution Service (DDS) web-enabled.
I'm also warming up to the idea of using WebSockets for bidirectional communications, despite their "low level" nature. For those interested, available C/C++ libraries include:
libwebsockets
websocket++
QWebSockets
Wt (C++ web development toolkit which includes support for WebSockets)
There is an open Websocket Application Messaging Protocol (WAMP) that provides asynchronous messaging patterns for remote procedure calls and the publish-subscribe pattern. There are a number of implementations for WAMP, but none of them are written in C/C++.
I am trying to learn different web services to understand what they are used for. But, I am confused as these terms overlap frequently. I would appreciate if someone can tell me briefly what are the differences between these terminologies. I came across some sources such as http://java.sun.com/developer/Books/j2ee/jws/ch07.pdf, however I am not able to distinctly differentiate them.
Web Service: a standards-conforming invocable service, might be written in Java, might be written in some other technology, e.g. .NET. Key point is that there is a standard language, WSDL, that describes the service. The WSDL contains information about the transport, protocol, where the service is running, the available operations and the payloads flowing to and fro.
Most Web Services you will encounter use SOAP messages (a particular XML format) over an HTTP protocol, and so the WSDL will contain the URL of where to invoke the service. More generally other message formats and protocols are possible - we'll come back to that point in a moment.
Suppose you have the WSDL for a service that you wish to invoke from a Java program, then in principle you can write Java to format a suitable XML payload and squirt the message down an HTTP connection. Perfectly doable, but very tedious, almost all the code is boilerplate code, which can be generated from the the WSDL.
Equally, if you want to create a Web Service in Java then you might begin by writing the WSDL, but once again there's lots of standard boilerplate code for reading HTTP, parsing XML etc. So in both cases you benefit from standard Java APIs for doing all that work. There have been several such APIs, JAX/RPC and JAX/WS are two such, and JAX/WS is the more recent and easier to use.
An alternative integration technology is to use messaging, there are many vendors who provide message queuing products, so it's perfectly possible to send messages from (say) Java to (say) C++, you just need to agree on the message format (no standard WSDL there to tell you).
JMS is a Java programming API that provides an abstraction about specific vendors' messaging products. If working in Java, JMS gives you portability across messaging products. The Java EE standard requires that Java EE App Server vendors provide a messaging infrastructure - I believe that as business systems get large, they nearly always need some asynchronous messaging facilities.
There are various possibilities for applying WSDL-like approaches to messaging. For example it is possible to write a Web Service using SOAP/JMS rather than SOAP/HTTP. JAXM is an emerging API in this space. Frankly I'm unclear as to its relationship to SOAP/JMS and standards such as WS-ReliableMessaging.
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.
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.