SOAP - Time to redefine the acronym?

Discussions

News: SOAP - Time to redefine the acronym?

  1. SOAP - Time to redefine the acronym? (13 messages)

    SOAP officially stands for the Simple Object Access Protocol. Aside from the official acronym definition, it's most commonly used to access remote web services. With the maturation of SOAP and the various extensions to the protocol (WS-Security, Addressing, Trust, etc etc etc), SOAP-based web service endpoints are becoming increasingly complex - both in the available API methods, data types, and modes of communication. Truly, for the increasingly common case of accessing enterprise web services, SOAP is no longer a protocol for accessing simple objects. In the coming years, as secure and scalable interoperability between disparate server platforms and client systems becomes even more important, SOAP's definition should probably change also. I would propose that a more appropriate definition is the Service Operation Access Protocol. Let's break down the two most important words in the new name, Service and Operation. Service: While currently a SOAP-based service is commonly grouped under the "web service" umbrella, the increasing popularity of enterprise service buses, which many times wrap legacy systems with a SOAP wrapper for the convenience of other systems, seems to take away the point behind the word "web". Indeed, with the development of SOAP/TCP, SOAP/JMS, and even SOAP/SMTP transports, "web service" no longer itself applies. However, the common identifier remains - the protocol is being used to access some form of remote service. Operation: The protocol is used to access a remote service, and perform some type of operation on it. Whether that is a modification-type operation, or a read operation, inevitably it is an operation. Additionally, the name ignores the debate between whether SOAP endpoints should be designed more towards document transfer, or object-method-parameter type transfer. In reality, that debate is more architectural, in the manner that REST is a design paradigm. But regardless, somewhere within the SOAP message is an operation that is performed on the service. With this redefinition, SOAP could become a more-easily understood acronym, for those in the world that actually care about what the acronym stands for, and people trying to start out and learn about what SOAP is.
  2. Not an Acronym Anymore[ Go to top ]

    As of the SOAP 1.2 spec, SOAP is no longer an acronym at all. See the note at the bottom of the introduction section: http://www.w3.org/TR/soap12-part1/#intro
  3. good spot =) besides, would a rose by any other name... not that SOAP is rosey of course ;) i think most people presume it to be synonymous with SOA these days anyway.
  4. Yeah..... Right...... And JDBC is also not an acronym.
  5. So, what SOAP is ??[ Go to top ]

    Declaring SOAP as not an acronym will confuse more people. Service Operation Access Protocol would match what it offers. With over empahsis on XML inputs & outputs, the 'Object' has lost its meaning, unless people want to consider data structures without behavior as objects. So, I agree with the suggestion that we give a new meaningful definition to SOAP. Madhu
  6. Too late[ Go to top ]

    SOAP has alreay been broken in two parts: a totally wrong one and an absolutely generic one. The wrong one is SO because it is not Simple and has nothing to do with Object. Access Protocol is obviously too generic to mean something useful. Guido. P.S. Is it sufficient to change a definition to turn a wrong thing into a right one ? Nothing else to change ?
  7. @ Stephen: *grumble*. Lovely. Another word that *was* an acronym, but isn't now, even though it's still capitalized like an acronym. And they didn't even explain why it's no longer one. Kinda like NT and XP. Honestly, I don't know what's worse. For that matter, it'd probably be better to say Soap instead of SOAP. At least then, us grammatical nutcases wouldn't get confused. :) @ Guido: ??? You're suggesting changing the name altogether, or something as such?
  8. @ Guido:

    ??? You're suggesting changing the name altogether, or something as such?
    Suggesting something here is out of scope. I was just saying that SOAP was a wrong name (because it did not represent the reality) for a wrong thing (XML protocol and not only). Changing the name would not turn the remaining stuff right. Guido.
  9. Changing the name would not turn the remaining stuff right....Guido.
    I would keep the initial definition. I hope it will remain good reminder to new generation of ignorant newbies that complex problems do not have simple solutions.
  10. Changing the name would not turn the remaining stuff right....Guido.


    I would keep the initial definition. I hope it will remain good reminder to new generation of ignorant newbies that complex problems do not have simple solutions.
    Well, a renaming might be appropriate: the 'S' stands for simplistic. Guido
  11. Sorry the poster seemed to be about 2-3 years behind when SOAP was still an acronym. Funny, we had someone chiming in that SOAP was too hard around here recently. I had to point out what the interoperability blog recently pointed out: SOAP redux: <!--?xml version="1.0" ?--> // Put message metadata here // Put message body here Simple enough, I'd say. Looks like something I could have invented myself. Probably is very similar to what the SOAP detractors reinvent over and over again. What about all the WS-* stuff - that's hard isn't it? Yeah, well you use as much as you need. At least there are standards available. Yeah, but all that SOA stuff is all hype and smoke and mirrors! Well, if it isn't right for you our your company then don't go down that road.
  12. Sorry the poster seemed to be about 2-3 years behind when SOAP was still an acronym.

    Funny, we had someone chiming in that SOAP was too hard around here recently. I had to point out what the interoperability blog recently pointed out:

    SOAP redux:

    <!--?xml version="1.0" ?-->


    // Put message metadata here


    // Put message body here



    Simple enough, I'd say. Looks like something I could have invented myself. Probably is very similar to what the SOAP detractors reinvent over and over again.

    What about all the WS-* stuff - that's hard isn't it? Yeah, well you use as much as you need. At least there are standards available.

    Yeah, but all that SOA stuff is all hype and smoke and mirrors! Well, if it isn't right for you our your company then don't go down that road.
    Yeah the way you put it, but the complexity is all in the messages. And it's good to hear its no longer Simple ...
  13. 1. SOAP is not an acronym anymore (as of Version 1.2) 2. WS-* protocols are not extensions to SOAP, rather SOAP is most commonly used as a binding 3. Web Services have nothing to do with "Web" in the sense of using HTTP; Web was rather a marketing buzz word. As you might know SOAP can be used with many bindings. The simple definition of a Web service is "something that is defined as a WSDL". So to be a Web service neither SOAP nor HTTP (as protocol of the "Web") are needed. You could have a WSDL with a binding for RMI-Java calls (as "transport") and Java objects (as "encoding"). 4. SOAP is not restriced to accessing service. Although you might commonly use it this way, SOAP is much more generic. SOAP is a messaging framework, thus you can use it to establish any type of messaging pattern. E.g. you can use - and it is actually used this way - to have document-style conversation between peers. Nevertheless I agree that having an acronym which actually is none, is not really helping anybody. But often enough when you ask someone "What is XYZ anyway?" - the answer is the meaning of those letters in that context. In this way renaming SOAP to "Service Operation Access Protocol" does not help anybody, as it clearly misses at least two points: - any type of document-style conversation - the whole SOAP processing model (nodes, intermediaries, must-understand, roles etc.)
  14. The change in what SOAP means parallels the change in thinking in the industry. Back when SOAP was an acronym it really was an attempt to mimic distributed objects. It was seen as a way of bridging technologies. SOAP was developed, as I recall, by Microsoft and Userland based on Userland's XML-RPC protocol. The style they pushed was RPC/encoded which is not a service style. My guess is that Microsoft did not want to be shut out of the enterprise distributed applications space. IBM and BEA sort of own that space and as long as they could keep companies wedded to a technology specific protocol - one their product(s) used, then they could keep that control. Microsoft was out of Java and never did CORBA. J2EE's RMI/IIOP seemed ready to dominate. In order to get IBM, BEA and others to back their new standard as a W3C Note, Microsoft had to compromise and relinquish control. SOAP morphed. SOA and the services style came into greater prominence as an alternative to more fine grained distributed objects and remote procedures. If SOAP was going to be the protocol everyone was going to use, then it would have to do a better job at supporting the service style. The industry saw that document/literal, a true service style, was the way to go. WS-I.org and their member vendors dropped RPC/encoded from their profile and pushed document/literal. Services are not objects; they realize use cases. They may be implemented as object/component collaborations, but what is exposed is derived from the use cases and not the underlying objects (if any). So SOAP was no longer about accessing objects and the acronym no longer made sense.