What precisely are they useful for? Honest question, I have not had a job yet, let alone the "enterprise" one.
XSD (Schema) - lets you describe the format of your XML document. Useful if you need to tell other parties about your format. You can use XSDs to programmatically validate that a given XML document is "correct" as per your schema. IDEs can use XSDs file to do intellisense on XML files as you type. You can also include documentation within XSDs and have an external tool auto-generate documentation (e.g. in HTML) to describe your Schema in a more user-friendly way.
XSL - These are XML docs that define how to transform 1 XML format into another. Can use combine this with XSDs to ensure that the result of the transformation is valid.
SOAP + WS-* - WS-* is a set of standards on top of SOAP (which just defines a web-service interface). E.g. WS-Security can define that your web-service must encrypt the contents of the message, WS-Addressing makes SOAP less dependant on HTTP.
If you do not, then you will guaranteed run into schema differences of common objects (ie, SAP "Customer" <> Oracle "Customer <> Salesforce "Customer" etc etc). XML w/ XSL/XSD wins here.
XSL is an umbrella for a few things, most interesting is XPath which is a super fast query language for xml documents.
SOAP is just worthless.
WSDL is nice though, it compiles a web service API to source code so you get a nice layer of abstraction around what you're writing to.
Before XML we had CORBA, and before that EDI, and before that ASN.1... Just reinventing the wheel and each time a little worse.
For example (AFAIK) XML webservices tend to be less tightly coupled than CORBA's IDLs (though you can tight-couple in any language):
- XML using its own format specification language (DTD; XML Schema) helps keep the external data format independent from the application's internal data structures (until some bright spark realizes they can avoid duplication! by deriving one from the other... thus re-coupling them. Because of this, SOAP is CORBA all over again).
CORBA's IDL produced an interface for every object. This is fine for methods of the top-level object (that represents the main actions of the application/service), but when applied to objects that form the internal data structures (the nested object tree/graph that is received/sent as an argument/return value), it forces the external format to have the same structure as the internal data structure, thus tightly-coupling them. [And, CORBA tried to do "distributed objects", which just didn't work very well - though it sounds like a good idea.]
REST seems to be making a big difference. It explicitly uses "representational state", meaning that the external format is independent of the sender and receiver's internal representation. By defining the format independently of an end-point, it seems you escape tight-coupling. In practice, devs will often derive internal object definitions from the external format - but then they do the loose-coupling themselves, internally, and so tight-coupling is still avoid. [It's seeming to me that deriving internal-->external is bad; but external-->internal is OK.]
In a way, I think this progression can be seen as realizing the concept of information hiding in greater and greater depth as time goes on.
Does that seem right? What do you think? Can you point me to any references that address these issues (esp about tight-coupling between internal/external representations)? Many thanks for any help!
I don't disagree with you about bloated middleware products, but you don't have to use them to use soap,xsd,xsl,xpath etc.