7 ms·

XML Appliance

63 points by runlevel1 4y ago

lloydatkinson 4y ago
Do you think there's any of these still in use?
- dporter 4y ago
  Probably. I bet maintaining it is someone's personal hell.
  - anongraddebt 4y ago
    Hell is others’ XML.
  - pjmlp 4y ago
    I will take XML over YAML any day.
  - zmix 4y ago
    It's not. It's much more simple, than anything else I know. XPath, and its higher-up XQuery make it a breeze! XSD, while not perfect, can be easily displayed as a graphical diagram. What you, however, need, and there is no way around it, is a specialized XML IDE or an IDE, that has "understood" XML.
- dwaite 4y ago
  Absolutely. Putting an intelligent intermediary in front of an API is an age-old pattern, and moving that logic into the backing system itself may have its own logistical challenges. Working on a product in an adjacent space, we translated WS-Security-protected SOAP interactions to OAuth JSON request/responses. The responses had omitted information based on the authorizations given in the OAuth access token scope. In some cases you would have to replace the XML gateway with an alternative system, for instance when it is combining information from multiple sources which aren't allowed access to one another (say, for PII separation/auditing reasons).
  - lloydatkinson 4y ago
    I was asking specifically about if this "XML hardware" was still in use
    - fgonzag 4y ago
      And he specifically gave examples of where it is used... Search for IBM Datapowers and the like
- runlevel1 4y ago
  I think you can still buy them. DataPower is still operating at IBM, but they put less emphasis on XML as a selling point and more on it as a general WAF. I actually came across this wiki page when searching for the backstory behind JSONx, IBM's standard for representing JSON as XML.[^1] [1]: https://www.ibm.com/docs/en/datapower-gateway/7.6?topic=jsonx-conversion-rules https://www.ibm.com/docs/en/datapower-gateway/7.6?topic=json...
awithrow 4y ago
Oh god this is a flashback. One of my earlier jobs (circa 2010 or so) was working as a defence contractor doing operations for a system using an IBM/Weblogic/J2EE SOA stack. Part of this stack involved the XI50/XI52 and eventually an XG45. I inherited these devices from someone leaving the program and it became my niche. Administering the thing was a giant PITA. Lots of GUIs, clicking, and (shocker) more XML. I recall some sort of pipeline interface where you could manage all the various steps a requests could pass through with various components for doing SAML auth XSLTs and similar operations. Since leaving that roll, I've seen absolutely nothing about these devices or anybody else who'd ever used them.
- craigmcnamara 4y ago
  AFRL couldn't get enough XML in the 2000s.
  - runlevel1 4y ago
    Were they doing a lot of CORBA before that? If so, I might have run towards XML/SOAP too.
    - craigmcnamara 3y ago
      They did whatever could drive more dollars to deliver nothing contracts, but there was a particular hard on for getting XML in to anything. It was the solution to everything for a decade at least.
donatj 4y ago
I have talked about this on here before, but the utter fervor around XML in the late 90s/early aughts is somewhat forgotten and unlike anything else I have seen in my career. Honestly, the current AI boom comes the closest. It’s hard to explain and harder to justify if you weren’t there to see it with your own eyes; “it does XML” was literally a major selling point on so many products. If you weren’t working with XML, what were you even doing with your career? You’re a dinosaur. Every single day someone was inventing new uses for XML. It was talked about like some sort of savior of the software industry. It’s really bizarre looking back. There was something in the water. It lead to a lot of XML centric products like “XML Appliances”.
- daniel-s 4y ago
  Is the reason because it made data exchange basically universal between languages? Before XML you had random binary or text formats, so APIs were a lot of work? Everything is Json now, but XML->Json is not that remarkable. Why was it such a big deal?
  - donatj 4y ago
    I think you’ve hit the nail on the head. It was the new hot universal structured way to transfer data over this newfangled internet and interop between applications and even operating systems. It even uses Unicode(!) which was a very big deal at the time.
  - chiph 4y ago
    Prior to XML the way a lot of data got transferred was via comma-separated-value files. They have a number of limitations (to put it mildly), like how to store strings (single quotes? double quotes? no quotes at all?), what character to use to separate values (it wasn't always a comma - sometimes semicolons and pipes were used), and how to escape the in-band control characters (commas, quotes if used, newlines). If you had to share a file with another party there was a negotiation that happened ahead of time on how all that was to be done. Example: You have to send the name of customer Finley O'Conner. Do you send it as: ,Finley O'Conner, ,"Finley O'Conner", ,'Finley O''Conner', ,'Finley O\'Conner', And so on. But with XML the process of escaping control characters was well defined, and the receiver would commonly publish a schema definition that detailed what all the values were like (types, sizes, etc.) You could be up and running fairly quickly and with some confidence that the integration would work.
davewritescode 4y ago
Back in the 2010s these things were all the rage in systems where you used XML in combination with technologies like WS-Security (i.e. signed SOAP requests). I suspect these things are still all over the DoD. I remember all sorts of fun issues with different vendor stacks not interoperating a together well so it was useful to have a standard layer to validate messages before they got to the backend. The reason all these XML based protocols failed is that 1. XML is extremely space inefficient to begin with so all messages are bloated 2. The promise of interoperability between systems never really materialized. Finding a common set of configurations that would work across the multiple Java stacks, .NET and whatever else was out there at the time was a nearly impossible task. It turns out simple JSON and API specs were more than enough.
- bzzzt 4y ago
  There's still a lot of SAML and SOAP being spoken on the Internet, so I wouldn't call it a failed protocol. Interoperability between Java and .NET was a solved problem somewhere around 2008. Most important reason XML was replaced by JSON for the majority of use cases was the parser had a lot of complexity and wasn't implemented as well for other languages that were considered 'less serious' at the time. If you built with Rails or PHP you probably had to deal with badly implemented XML and SOAP libraries.
  - boole1854 4y ago
    > Most important reason XML was replaced by JSON for the majority of use cases was the parser had a lot of complexity and wasn't implemented as well for other languages... I think it had more to do with: 1) An advantage of XML was supposed to be that it was human-readable, which meant it would be easier for developers to work with and debug. The problem was that many XML documents were so bloated with tags within tags within tags and redundant attributes all over the place, that in practice it was extremely painful for a human to read. JSON is better, in practice. 2) For better or for worse, JavaScript became ubiquitous, and there is a simple, clean isomorphism between JSON to in-memory JavaScript objects (obviously, since that's what the JSON name means).

XML Appliance

63 points by runlevel1 4y ago

lloydatkinson 4y ago

Do you think there's any of these still in use?

dporter 4y ago
Probably. I bet maintaining it is someone's personal hell.
- anongraddebt 4y ago
  Hell is others’ XML.
- pjmlp 4y ago
  I will take XML over YAML any day.
- zmix 4y ago
  It's not. It's much more simple, than anything else I know. XPath, and its higher-up XQuery make it a breeze! XSD, while not perfect, can be easily displayed as a graphical diagram. What you, however, need, and there is no way around it, is a specialized XML IDE or an IDE, that has "understood" XML.
dwaite 4y ago
Absolutely. Putting an intelligent intermediary in front of an API is an age-old pattern, and moving that logic into the backing system itself may have its own logistical challenges. Working on a product in an adjacent space, we translated WS-Security-protected SOAP interactions to OAuth JSON request/responses. The responses had omitted information based on the authorizations given in the OAuth access token scope. In some cases you would have to replace the XML gateway with an alternative system, for instance when it is combining information from multiple sources which aren't allowed access to one another (say, for PII separation/auditing reasons).
- lloydatkinson 4y ago
  I was asking specifically about if this "XML hardware" was still in use
  - fgonzag 4y ago
    And he specifically gave examples of where it is used... Search for IBM Datapowers and the like
runlevel1 4y ago
I think you can still buy them. DataPower is still operating at IBM, but they put less emphasis on XML as a selling point and more on it as a general WAF. I actually came across this wiki page when searching for the backstory behind JSONx, IBM's standard for representing JSON as XML.[^1] [1]: https://www.ibm.com/docs/en/datapower-gateway/7.6?topic=jsonx-conversion-rules https://www.ibm.com/docs/en/datapower-gateway/7.6?topic=json...

awithrow 4y ago

Oh god this is a flashback. One of my earlier jobs (circa 2010 or so) was working as a defence contractor doing operations for a system using an IBM/Weblogic/J2EE SOA stack. Part of this stack involved the XI50/XI52 and eventually an XG45. I inherited these devices from someone leaving the program and it became my niche. Administering the thing was a giant PITA. Lots of GUIs, clicking, and (shocker) more XML. I recall some sort of pipeline interface where you could manage all the various steps a requests could pass through with various components for doing SAML auth XSLTs and similar operations. Since leaving that roll, I've seen absolutely nothing about these devices or anybody else who'd ever used them.

craigmcnamara 4y ago
AFRL couldn't get enough XML in the 2000s.
- runlevel1 4y ago
  Were they doing a lot of CORBA before that? If so, I might have run towards XML/SOAP too.
  - craigmcnamara 3y ago
    They did whatever could drive more dollars to deliver nothing contracts, but there was a particular hard on for getting XML in to anything. It was the solution to everything for a decade at least.

donatj 4y ago

I have talked about this on here before, but the utter fervor around XML in the late 90s/early aughts is somewhat forgotten and unlike anything else I have seen in my career. Honestly, the current AI boom comes the closest. It’s hard to explain and harder to justify if you weren’t there to see it with your own eyes; “it does XML” was literally a major selling point on so many products. If you weren’t working with XML, what were you even doing with your career? You’re a dinosaur. Every single day someone was inventing new uses for XML. It was talked about like some sort of savior of the software industry. It’s really bizarre looking back. There was something in the water. It lead to a lot of XML centric products like “XML Appliances”.

daniel-s 4y ago
Is the reason because it made data exchange basically universal between languages? Before XML you had random binary or text formats, so APIs were a lot of work? Everything is Json now, but XML->Json is not that remarkable. Why was it such a big deal?
- donatj 4y ago
  I think you’ve hit the nail on the head. It was the new hot universal structured way to transfer data over this newfangled internet and interop between applications and even operating systems. It even uses Unicode(!) which was a very big deal at the time.
- chiph 4y ago
  Prior to XML the way a lot of data got transferred was via comma-separated-value files. They have a number of limitations (to put it mildly), like how to store strings (single quotes? double quotes? no quotes at all?), what character to use to separate values (it wasn't always a comma - sometimes semicolons and pipes were used), and how to escape the in-band control characters (commas, quotes if used, newlines). If you had to share a file with another party there was a negotiation that happened ahead of time on how all that was to be done. Example: You have to send the name of customer Finley O'Conner. Do you send it as: ,Finley O'Conner, ,"Finley O'Conner", ,'Finley O''Conner', ,'Finley O\'Conner', And so on. But with XML the process of escaping control characters was well defined, and the receiver would commonly publish a schema definition that detailed what all the values were like (types, sizes, etc.) You could be up and running fairly quickly and with some confidence that the integration would work.

davewritescode 4y ago

Back in the 2010s these things were all the rage in systems where you used XML in combination with technologies like WS-Security (i.e. signed SOAP requests). I suspect these things are still all over the DoD. I remember all sorts of fun issues with different vendor stacks not interoperating a together well so it was useful to have a standard layer to validate messages before they got to the backend. The reason all these XML based protocols failed is that 1. XML is extremely space inefficient to begin with so all messages are bloated 2. The promise of interoperability between systems never really materialized. Finding a common set of configurations that would work across the multiple Java stacks, .NET and whatever else was out there at the time was a nearly impossible task. It turns out simple JSON and API specs were more than enough.

bzzzt 4y ago
There's still a lot of SAML and SOAP being spoken on the Internet, so I wouldn't call it a failed protocol. Interoperability between Java and .NET was a solved problem somewhere around 2008. Most important reason XML was replaced by JSON for the majority of use cases was the parser had a lot of complexity and wasn't implemented as well for other languages that were considered 'less serious' at the time. If you built with Rails or PHP you probably had to deal with badly implemented XML and SOAP libraries.
- boole1854 4y ago
  > Most important reason XML was replaced by JSON for the majority of use cases was the parser had a lot of complexity and wasn't implemented as well for other languages... I think it had more to do with: 1) An advantage of XML was supposed to be that it was human-readable, which meant it would be easier for developers to work with and debug. The problem was that many XML documents were so bloated with tags within tags within tags and redundant attributes all over the place, that in practice it was extremely painful for a human to read. JSON is better, in practice. 2) For better or for worse, JavaScript became ubiquitous, and there is a simple, clean isomorphism between JSON to in-memory JavaScript objects (obviously, since that's what the JSON name means).