soap or the simple object access protocol has been a popular messaging
protocol in the early 2000s it uses XML as a format with a well-defined schema
and your choice of transfer protocol so that could be HTTP or TCP or whatever I
did this MTP despite is still being used people has been moving towards wrist
architecture and sinnin and recently toward the RPC and other protocols as
well in this episode we discuss why people moved from soap what was wrong
with it and what are their advantages and disadvantages of soap coming up
what's up y'all this is Hussein Nasser from IGeometry where we discuss
software engineering by example and let's just get into it yeah today we
will discuss soap and what is exactly why people have been moving towards Apso
but before we do that let's go back way way back in the 90s and even before you
know people have been writing apps right there wasn't anything with concept of
networking my people writing apps and their apps or their software were
sitting in the same box right so you would call a method or you called a
function call and this is exactly in the same machine right so then they wanted
hey you want it's working so that thus became the RPC
right the remote procedure or call right there protocol to call to call a method
on the network so people have been inventing their own thing
just randomly just making up protocols you know there were none standards or
soap can we say hey guys you can't we need to put some standard people I've
been writing their own apps and and for this networking we need a standard so
the w3c came and says you know what this is a standard guys let's use XML it's
extendable right because you can put your own tags it's really cool and we're
gonna make it flexible enough so you can write your own message in this schema
you have to use this scheme alright so you don't have to make up risk you don't
have to just send up week or or not strongly typed messages across the
network right so if the server receive same thing it knows the scheme I'd
always know how to interpret a message so they started to put it all these
restriction kind of in place and this is what happened right we had the soap so
by using XML that means pretty cool so it's a human readable people can read it
back then it was important for some reason right
to read the messages across the network not anymore and just that choice of
making XML actually hurt right and we're gonna talk about it today as well right
and that flexibility is hey you can use it on HTTP TCP SFTP just like just write
your own this simple soap server and write your own soap client and you're
done then you'll write your own client that consumes the soap client and then
the server that receives the soap server messages and started doing all this
stuff that so you can do the work right but then start there was a lot of
problems as a result of this like so we were thinking a lot about the schema and
and how to make this as dredge it and regimented as possible right and this is
what the result so what is wrong with that so let's move to the advantages and
do that well just for this advantages what did we get for the schema schema
right of the soap schema that's a very good thing right because if I Steve a
message if someone sent me a bogus message I just discard it right and
that's cool because now hackers can just send me stuff they have to send me that
if a client if I know the client they have to send me the exact same message
in this exact format and these tags has to be in place right and if there is a
specific a specific version I know right all this stuff right so there's a schema
that's that's an advantage which will be a disadvantage in a minute
extensible because XML right unlike HTML which is like a very specific tags XML Q
can just invent your own tags and as long as you write your sub server to
parse or know these tags then you're good right so it's still the same
protocol since the same I would but you have extensibility your application can
extend those messages it's not you're not just defined by this set of headers
right you can invent and add stuff as well ah flexible transport so that's
another beside the advantage I mean right so we have it you can put the soap
on HTTP or SMTP for example Simple Mail Transfer Protocol I think yeah and TCP
you can write your own protocol just thread the transfer doesn't matter as
long as the message it exactly looks this way all right all right let's go
let's get to it why it's bad why people have been moving it what's the
disadvantage of this right let's get to it
the cons or the disadvantage of this is actually the way the schema is
implemented right so if you think about it here the client makes a request to
this soap coin which is a thick client lets sits on top of your application and
then it transfers everything and deserialize or serialized everything
into xml sends it across HTTP or SMTP and then the soap server will
deserialize and then pass the message to the server so that's that's the carrier
architecture so having a schema a very rigid schema is actually a problem
because now people people who just want to write an ad they have to they have to
adhere to a schema which would which slows down adoption this is you know
what I don't want to just write a schema now I just I just wanted to send it like
a JSON format or something like that right I just want to send something and
I want to receive it and this could change it this could have like this the
my message could have these properties and next time it could I could lose a
property I get added property I don't want to be tied to a schema so people
did not like some people didn't like that although a schema some some people
prefer schemas on people their skin that's where we have sequel and no
sequel right the schema is still a debatable concept here so having
strictly a schema kind of slows down adoption and no people move to a more
open architecture which is the rest right which we had you can have your own
scheme and it doesn't really care we doesn't really have to have a schema per
se XML the choice of XML that means first it's
a very large bandwidth sucking protocol or or language right because now the all
these tags are just consuming bandwidth on the network and it's very slow to
process right you have to process these strings these are nothing but strings
and remember tags are nothing but strings are huge strings to send
something that is so simple I have to wrap it up with all this fancy tags
right which which slows down parsing so that's another yeah people being turned
off by that right fake clients why do I need to write
instead of my client I have to write something else to do the serialization
and that that made the the the so protocol not language agnostic because
ok if I'm using vb.net right then I have to write an aptly
myself client has to be obviously living in my client so it has to be written
vb.net and if I'm using I don't know JavaScript or any other language or PHP
or a c-sharp or C++ I have there must be a soap version of whatever I'm using to
add it the effect client that get added to by that with the service mission is
this now becomes much much I'm gonna make a video about service
which I love this technology whoever invented this is it genius
I'm sidecar contain and all that stuff we're gonna talk about it but yeah but
having me to be forced to use a language just because the sub client is written
in this language and it's written off again right so yeah because these
clients do the serialization and deserialization all that stuff and last
one is scaling is very hard right if I add if I add let's let's think of what
not not just one server let's just think about multiple servers or if I'm my
client is version 1 ok and then I decided to make it version 2 by adding
my enhancing my message to add in new fields right guess what right now by
adding that I just broke my compatibility
I can't just communicate with the server server will will have to upgrade to
version 2 as well right because otherwise if you send it an old message
then services what is that I don't know how to pray
hey this is a new stuff this is not the schema I am supposed to read fail right
so it doesn't scale easily right so scaling the server by upgrading the
client or upgrading the client I'm creating the server they cannot scale
and dependently right they have to scale together or you have to if you upgrade
this you have to upgrade the whole thing and I made a good video about this and
I'm gonna link it to the link here so it's like why your wrist is scalable
exactly right exactly because of this soap is not scalable because of this
rigid schema obviously this has been solved by protocol buffer and if there a
beautiful way I'm gonna make another video about protocol buffers it's still
using a schema bus very smart way so you can still change but you're all the
client won't break alright guys that's all for me that's why I people be moving
from soap to a newer technologies like rest and good Google protocol buffers is
because of all these reasons right I'm kinda passed the question
- you have been have you ever used soap do you still think it's it's a good
technology it's not I'm not I'm not dissing the technology was just pointing
the bad things about it and the choices right it's just
it could be enhanced but what do you think right Doody did you ever use soap
are you still using it have you moved to the to another protocol and why and I'm
gonna see you in the next one if you're new to this channel that's what we do in
this channel we discuss software engineering concepts and if you recheck
out the other content in my channel and we're gonna see you in the next one you
guys stay awesome bye bye