Like so much of our computer industry, the ecosystem around SOA has many acronyms, buzzwords, and phrases that are supposed to mean something. Likewise, this jargon may be poorly defined or ambiguous. The posts that I have made over the past few months are slowly building up a common vocabulary that will be used when discussing SOA on ThinkMiddleware.com and with my clients. Likewise, I’m lazy and like to send out links to existing material rather than rewriting it from scratch.
The term “Wire Protocol” is used in some literature, but not all to describe the application layer protocol (think OSI network model) that sits on top of TCP. For SOAP & REST web services, the single most common Wire Protocol is HTTP(S). For REST traffic, by definition, HTTP(S) is the only protocol. For SOAP, while HTTP(S) may be the most common, it is by no means the only option. Wire Protocol may also be called the Transport Protocol, but I view this phrase as ambiguous (think TCP).
In the SOAP world, it is possible to pass SOAP messages via
- SMTP(wouldn’t recommend it, but it can be done)
- NFS(think file drops)
- MQ Series (WMQ, proprietary, though popular, IBM protocol)
- Secure Smoke Signals (S3 Protocol)
Anytime a protocol can be passed over SSL/MASSL (which is pretty much any TCP-based protocol, we will describe the unencrypted and encrypted versions of the protocol via PROTOCOL( S)). For example, HTTP(S) for HTTP & HTTPS.
Don’t confuse Wire Protocol with Data Format. For example, SOAP is a data format; JSON is a Data Format. Likewise, XML is a data format. HTTP is a protocol. FTP is a protocol.
Wire Protocols can be broken down into two general categories:
With a synchronous wire protocol, the Service Consumer will block while waiting for a response. In an asynchronous protocol, the Service Consumer will perform a send or put operation of a request message, do other work, and then either periodically check back or receive an event in order to obtain the response.
To make things confusing, you can generally simulate synchronous behavior over asynchronous protocols and asynchronous behavior over synchronous protocols. Though, either of these approaches will have a certain amount of overhead. We’ll explore this more in the Message Exchange Patterns (MEPs) post.
Sometimes, especially with custom and proprietary technology, messages are simply sent over a TCP socket. This can be quite fast, but if the message boundary is defined by an open & close of a TCP socket, there is a certain level of overhead involved. Ideally, persistent TCP connections would be maintained and either a well-defined boundary can be built into the message format or the message length can be defined at the “front” of the message.
A primary function of an ESB is Protocol Transformations-converting form one Wire Protocol to another. Generally, an ESB will support many protocols to provide maximum flexibility and interoperation.