According to literature on the web, I can see that there are two specifications related to Web Services Eventing:
WS-BaseNotification - submitted by OASIS in 2004
WS-Eventing - submitted by W3C in 2006
To me, both seem to have the same functionality. What is the most acceptable specification in the industry now?
You can't compare SOAP (message encoding part of webservices stack) with AMQP or JMS (also transfer protocol). With SOAP 1.2 you can use JMS transport binding (only for RPC). AMQP builds on TCP, so you can use "SOAP over AMQP" as well as "SOAP over TCP". You can see this paper to see where SOAP in webservices stack relies.
To the question.
Two competing standards:
WS-Eventing W3C Public Draft
WS-Notification 1.3 OASIS-Standard (replaced WS-Events), which grew to family of 3 specs:
WS-BaseNotification (very similar to WS-Eventing)
WS-BrokeredNotification (optional)
WS-Topics (optional)
are also converging in each version update.
There is no "leader" in the industry.
WS-Eventing is simpler sister of WS-Notification, which can be advantage in some cases. For example WS-Eventing doesn't define Pause/ Resume Subscription (but you can unsubscribe/subscribe), broker intermediary (but there is a way to do it), etc.
Implementation which can intelligently switch between these ws-* specifications can be found here.
The way, how to add message queuing, isn't defined by any. This is where AMQP binding or websocket subprotocols binding will play the role in the future of webservices stack, I think.
I think most people these days would not use SOAP but rather rely on simpler protocols (AMQP/JMS in this case) but if you do need/want to use SOAP WS-Notification (which is the parent standard for WS-BaseNotification) is the more widely supported protocol (e.g. by ServiceMix or IBM WebSphere)
Related
I am new into these topics. JMS and web services seem to have same purpose but I feel there is lot more differences? Can someone provide the differences? And when are these technologies applied?
Depending on your requirements and your architecture you can use both, they can even be used together.
JMS is a messaging standard specifically for Java EE. So it is better to compare Message Passing and Web Service.
A good idea is to read on wikipedia
http://en.wikipedia.org/wiki/Message_passing
http://en.wikipedia.org/wiki/Web_service
A similar discussion took place here: Difference between JMS and Web Service
As an example, in the case my architecture was exposing to the world an interface, I would most likely offer web services. If however my architecture was to connect with a fast producing events module over a secure connection, I would use message passing.
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++.
Every description on the Message Bus architecture seems to describe a centralised intermediary for routing messages:
Each application has a single connection to the message bus instead
of multiple dedicated connections to each of the other applications.
http://msdn.microsoft.com/en-us/library/ff647328.aspx
Structure the connecting middleware between these applications as a
Message Bus that enables them to work together using messaging.
http://www.eaipatterns.com/MessageBus.html
Service Bus is messaging infrastructure that sits between applications
allowing them to exchange messages in a loosely coupled way for
improved scale and resiliency.
http://www.windowsazure.com/en-us/home/features/messaging/
The descriptions seem identical to the Message Broker architecture; leading me to believe the following:
The term 'Message Bus' is effectively the same as 'MoM' - a generic term for referring to a messaging infrastructure without explicitly mentioning a topology. I.e. Message Broker is a type of Message Bus.
This seems like a controversial topic, and whilst there's a few similar questions on SO, none have (IMO) definitive answers.
P.s. I am aware that Enterprise Service Bus is entirely different, and is effectively a 'feature rich' MoM.
You are right, this area of terminology is very messy and there are no definitive answer, but this is my view from my professional life:
The first thing is to do is to think about this in different levels of abstractions - architectural concepts vs products.
A message bus (http://www.eaipatterns.com/MessageBus.html) is often referd to a as an architectural princip to decouple applications often together with canonical data formats (http://www.eaipatterns.com/CanonicalDataModel.html), much regardless of technology. Often implemented using MoM products.
A MoM typically refers to a family of middleware products that implements asynchronous message passing. Often built supporting standards such as JMS and AMQP (typically WebSphere MQ, ActiveMQ, Azure messaging, hornetQ, RabbitMQ, etc.etc.).
A message broker is often a MoM, and both terms are used for the same messaging product. There might be confusion here, since the main ESB product of IBM is called WebSphere Message Broker while it rather an ESB used side by side with the MoM product - WebSphere MQ. Usually most MoM call themselves brokers, such as RabbitMQ, ActiveMQ, QPid etc.
Hope this did not cause more confusion :)
The differences are mainly different vendors trying to differentiate themselves in the Market and increase their mind-share. Since vendors typically defined their own terms, there will usually be a slight differences in what each vendor means by the terms they use.
However in general they are the same class or type of system. They organise and manage the transport, queueing and persistence (storage) of messages from one software service to another, beyond that, you need to be looking at vendors specific feature lists for their product.
WebSphere Message Broker belongs to the ESB layer of an SOA and it is also MOM. WebSphere MQ is also MOM. I think a lot of the confusion is around abstract architecture concepts and actual software products. SOA and ESB are abstract concepts. The whole enterprise architecture industry IBM, Microsoft, Oracle, TIBCO etc. are always vying for market share. Software companies often pretend they invented something new and better in order to get attention from their customers. They make a lot of wild promises about their products when in reality they create a whole new set of expensive problems (e.g. XML transformations cause serious performance and security issues). Because it is corporate greed driven and "get to market fast" there is always an abundance of confusion and IT problems and much stress for IT workers.
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.