3 ms·

I would encourage anyone who thinks that XML is strictly inferior to attempt integration with certain banking vendors without use of their official XSD/WSDL sou

by bob1029 9mo ago

I would encourage anyone who thinks that XML is strictly inferior to attempt integration with certain banking vendors without use of their official XSD/WSDL sources. I've generated service references that are in the tens of megabytes. This stuff is not bloat. There are genuinely this many types and properties in some business systems. There is no way you could hand code this and still get everything else done. The entire point of heavy-handed XML is to 1:1 the type system across the wire. Once I generate my service references, it is as if the service is on my local machine. The productivity gains around having strongly typed proxies of the remote services are impossible to overstate. I can wire up entirely new operations without looking at the documentation most of the time. Intellisense surfaces everything I need automatically as I drill into the type system. JSON can work and provide much of the same, but XML has already proven to work in some of the nastiest environments. It's not the friendliest or most convenient technology, but it is an extremely effective technology. I am very confident that the vendors I work with will continue to use XML/WCF/SOAP into 2030.

tomjen3 9mo ago
Openapi can do that too. But the real benefit is that it forces a simplification of the interface. XML has too many outs for architectural astronauts. JSON has close to none.
vee-kay 9mo ago
UAE Central Bank has launched its Digital transformation initiatives: AANI and Jaywan. UAE's AEP (Al Etihad Payments) launched AANI (It is actually based on India's phenomally successfully "UPI" - its technology stack was licensed to UAE) as digital payments platform. Jaywan is UAE's domestic cards scheme (in competition to Visa, MasterCard, etc.) (It is actually based on India's successfully RuPay technology stack, licensed to UAE). And Jaywan uses XML for its files! So these brand new banking initiatives in Middle East, use XML as the primary file format, because those Banks know that all the thousands of fields/columns in the CBS (Core Banking System) and upstream and downstream system, need a strict file format specification for file loading, processing, Reconciliations, Settlement, Disputes/Chargeback, etc.
unscaled 9mo ago
You must have been very lucky. Every SOAP service I had the (dis)pleasure to integrate with was a wholly different nightmare-ish can of worms. Even when we get to the very binding of WSDL, there are way too many variations on SOAP: RPC-Encoded? RPC-Literal? Document-Literal? Wrapped Document-Literal? The problem is part of the same myth many people (like the OP author) have about XML and SOAP: There was "One True Way™" from the beginning, XML schemas were always XSD, SOAP always required WSDL service definition and the style was always wrapped document-literal, with everything following WS-I profiles with the rest of the WS-* suite like WS-Security, WS-Trust, etc. Oh, and of course we don't care about having a secure spec and avoiding easy-to-spoof digital signatures and preventing XML bombs. Banking systems are mature and I guess everybody already settled and standardized they way they use soap, so you don't have to get into all this mess (And security? Well, if most banks in the world were OK with mandatory maximum password lengths of 8 characters until recently, they probably never heard about XMLdDsig issues or the billion laughs attack). But you know what also gives you auto-generated code that works perfectly without a hitch, with full schema validation? OpenAPI. Do you prefer RPC style? gRPC and Avro will give you RPC with 5% of the wire bloat that XML does. Message size does matter some times after all. All of the things that you mentioned are not unique to XML and SOAP. Any well-specified system that combines an interchange format, a schema format, an RPC schema format and an RPC transport can do the achieve the same thing. Some standards had all of this settled from day one: I think Cap'n Proto, Avro and Thrift fit this description. Other systems like CORBA or Protocol Buffers missed some of the components or did not have a well-defined standard[1]. JSON is often criticized by XML-enthusiasts for not having a built-in schema, but his seems like selective amnesia (or maybe all of these bloggers are zoomers or younger millennials?). When XML was first released, there was nothing. Yes, you could cheat and use DTD[2]. But DTD was hard to use and most programmers eschewed writing XML schemas until XSD and Relax-NG came out. SOAP was also very basic (and lightweight!) when it first came out. XSD and WSDL quickly became the standard way to use SOAP, but it took at least a decade to standardize the WSDL binding style (or was it ever standardized)? Doing RPC in JSON now is still as messy as SOAP has been, but if you want RPC instead of REST, you wouldn't be going to JSON in the first place. --- [1] IIRC, Protocol Buffers 2 had a rudimentary RPC system which never gained traction outside outside of Google and has been entirely replaced by gRPC after version 3 was released. [2] DTD wasn't really designed for XML, but since XML was a subset of SGML, you could use the SGML DTD. But DTD wasn't a good fit for XML, and it was quickly replaced by XSD (and for a while - Relax-NG) for a reason.

by bob1029 9mo ago

tomjen3 9mo ago

Openapi can do that too. But the real benefit is that it forces a simplification of the interface. XML has too many outs for architectural astronauts. JSON has close to none.

vee-kay 9mo ago

UAE Central Bank has launched its Digital transformation initiatives: AANI and Jaywan. UAE's AEP (Al Etihad Payments) launched AANI (It is actually based on India's phenomally successfully "UPI" - its technology stack was licensed to UAE) as digital payments platform. Jaywan is UAE's domestic cards scheme (in competition to Visa, MasterCard, etc.) (It is actually based on India's successfully RuPay technology stack, licensed to UAE). And Jaywan uses XML for its files! So these brand new banking initiatives in Middle East, use XML as the primary file format, because those Banks know that all the thousands of fields/columns in the CBS (Core Banking System) and upstream and downstream system, need a strict file format specification for file loading, processing, Reconciliations, Settlement, Disputes/Chargeback, etc.

unscaled 9mo ago

You must have been very lucky. Every SOAP service I had the (dis)pleasure to integrate with was a wholly different nightmare-ish can of worms. Even when we get to the very binding of WSDL, there are way too many variations on SOAP: RPC-Encoded? RPC-Literal? Document-Literal? Wrapped Document-Literal? The problem is part of the same myth many people (like the OP author) have about XML and SOAP: There was "One True Way™" from the beginning, XML schemas were always XSD, SOAP always required WSDL service definition and the style was always wrapped document-literal, with everything following WS-I profiles with the rest of the WS-* suite like WS-Security, WS-Trust, etc. Oh, and of course we don't care about having a secure spec and avoiding easy-to-spoof digital signatures and preventing XML bombs. Banking systems are mature and I guess everybody already settled and standardized they way they use soap, so you don't have to get into all this mess (And security? Well, if most banks in the world were OK with mandatory maximum password lengths of 8 characters until recently, they probably never heard about XMLdDsig issues or the billion laughs attack). But you know what also gives you auto-generated code that works perfectly without a hitch, with full schema validation? OpenAPI. Do you prefer RPC style? gRPC and Avro will give you RPC with 5% of the wire bloat that XML does. Message size does matter some times after all. All of the things that you mentioned are not unique to XML and SOAP. Any well-specified system that combines an interchange format, a schema format, an RPC schema format and an RPC transport can do the achieve the same thing. Some standards had all of this settled from day one: I think Cap'n Proto, Avro and Thrift fit this description. Other systems like CORBA or Protocol Buffers missed some of the components or did not have a well-defined standard[1]. JSON is often criticized by XML-enthusiasts for not having a built-in schema, but his seems like selective amnesia (or maybe all of these bloggers are zoomers or younger millennials?). When XML was first released, there was nothing. Yes, you could cheat and use DTD[2]. But DTD was hard to use and most programmers eschewed writing XML schemas until XSD and Relax-NG came out. SOAP was also very basic (and lightweight!) when it first came out. XSD and WSDL quickly became the standard way to use SOAP, but it took at least a decade to standardize the WSDL binding style (or was it ever standardized)? Doing RPC in JSON now is still as messy as SOAP has been, but if you want RPC instead of REST, you wouldn't be going to JSON in the first place. --- [1] IIRC, Protocol Buffers 2 had a rudimentary RPC system which never gained traction outside outside of Google and has been entirely replaced by gRPC after version 3 was released. [2] DTD wasn't really designed for XML, but since XML was a subset of SGML, you could use the SGML DTD. But DTD wasn't a good fit for XML, and it was quickly replaced by XSD (and for a while - Relax-NG) for a reason.