What is SOAP?
SOAP is an acronym for Simple Object Access Protocol. It is an XML-based messaging protocol for exchanging information among computers. SOAP is an application of the XML specification.
· SOAP is a communication protocol designed to communicate via Internet.
· SOAP can extend HTTP for XML messaging.
· SOAP provides data transport for Web services.
· SOAP can exchange complete documents or call a remote procedure.
· SOAP can be used for broadcasting a message.
· SOAP is platform- and language-independent.
· SOAP is the XML way of defining what information is sent and how.
· SOAP enables client applications to easily connect to remote services and invoke remote methods.
Although SOAP can be used in a variety of messaging systems and can be delivered via a variety of transport protocols, the initial focus of SOAP is remote procedure calls transported via HTTP.
Other frameworks including CORBA, DCOM, and Java RMI provide similar functionality to SOAP, but SOAP messages are written entirely in XML and are therefore uniquely platform- and language-independent.
SOAP ( Simple Object Access Protocol) is a message protocol that allows distributed elements of an application to communicate. SOAP can be carried over a variety of lower-level protocols, including the web-related Hypertext Transfer Protocol (HTTP). SOAP defines a header structure that identifies the actions that various SOAP nodes are expected to take on the message, in addition to a payload structure for carrying information. The concept of routing a message through a string of nodes that perform different functions is how SOAP supports things like addressing, security and format-independence. Essentially, the headers identify roles, which in turn provide the SOA features which SOAP then routes to. Stringing messages through a sequence of steps is uncommon in today’s microservice-centric development environments.
SOAP is an integral part of the service-oriented architecture (SOA) and the Web services specifications associated with SOA. Because it allows the sender to create a message route based on the logical services that have to be applied to the message on the way to its destination, it lends itself to providing secure and compliant connections, controlling access, offering reliable delivery and failure recovery, and supporting dynamic service discovery. SOA without SOAP is difficult to imagine.
SOAP’s messages are defined at a high level in XML, but most SOAP applications use Web Services Definition Language (WSDL), which is authored in XML. The XML structure of SOAP makes it handy for applications that expect their information to be provided in XML form, and the fact that SOAP can ride on a variety of network protocols, including HTTP, means it’s easily passed through firewalls, where other protocols might require special accommodation.
The data structure of SOAP is based on XML, which is similar in many ways to the HTML used to define web pages. Like HTML, XLM is largely human-readable, which makes it fairly easy to understand a SOAP message, but also makes the messages relatively large in comparison to the Common Object Request Broker Architecture (CORBA) and its Remote Procedure Call (RPC) protocol that will accommodate binary data.
The biggest disadvantage of SOAP (and SOA overall) is that it’s a heavyweight protocol for a heavyweight architecture. The notion of a message passing through a string of nodes to be processed by each seems to mix protocols and service bus architectural models for software, and neither of those two are considered optimal for microservice-based development as popularly used today.
SOAP is a protocol that’s almost always used in the context of a Web Services/SOA framework. As such, it’s application programming interface (API) is typically hidden by the higher-level interface for SOA. There are SOA API middleware tools available for nearly all modern programming languages, and Microsoft offers a variety of .NET SOAP/SOA tools.
SOAP is designed to break traditional monolithic applications down into a multi-component, distributed form without losing security and control. In contrast, REST is a model of distributed computing interaction based on the HTTP protocol and the way that web servers support clients. REST over HTTP is almost always the basis for modern microservices development and communications. RESTful APIs uses HTTP requests to GET, PUT, POST and DELETE data.
REST/HTTP is simple, flexible, lightweight, and offers little beyond a way of exchanging information. SOAP can ride on HTTP as well, but it connects the elements of a complex set of distributed computing tools (the Web Services and SOA framework) as well as application components, and this forms a part of a total service-oriented framework.
SOAP was the first widely used protocol for connecting web services in a Service Oriented Architecture (SOA). Today, nearly all modern development of distributed applications is based on RESTful principles. SOAP is almost always confined to legacy applications and projects, and over time its use is declining