Opinion: Is XML really the silver bullet for EAI?


News: Opinion: Is XML really the silver bullet for EAI?

  1. Opinion: Is XML really the silver bullet for EAI? (32 messages)

    John Davies, CTO and co-founder of C24 has proposed an interesting solution to the problems of XML complexity and bloat. It questions the position of XML in today's EAI projects, specifically in the banking market. The whitepaper goes on to look at ways of using GRID technologies like JavaSpaces to achieve performance gain of orders of magnitude. The solution is cheap, scalable and performant while reamining simple and easily deployable.

    "XML data interchange is the equivalent of the fax machine of contemporary software architecture. "Fax?"
    I hear you say, "surely XML is up to date and leading edge, not like the outmoded technology of fax
    which has been superseded by email". Let?s backtrack for a moment and look at how XML got to its
    position as the jewel in the crown of data interchange architecture that it is today, then see if I can
    justify this analogy.

    Read on... http://www.c24.biz/download/highperformanceXML.pdf

    Threaded Messages (32)

  2. XML Beans is a similar opensource solution from BEA.
    BEA has submitted XMLBeans to Apache and the source and binaries
    can be found at


    XMLBeans is a tool that allows you to access the full power of XML in a Java friendly way. It is an XML-Java binding tool. The idea is that you can take advantage the richness and features of XML and XML Schema and have these features mapped as naturally as possible to the equivalent Java language and typing constructs. XMLBeans uses XML Schema to compile Java interfaces and classes that you can then use to access and modify XML instance data. Using XMLBeans is similar to using any other Java interface/class, you will see things like getFoo or setFoo just as you would expect when working with Java. While a major use of XMLBeans is to access your XML instance data with strongly typed Java classes there are also API's that allow you access to the full XML infoset (XMLBeans keeps full XML Infoset fidelity) as well as to allow you to reflect into the XML schema itself through an XML Schema Object model.
  3. Nice...but[ Go to top ]

    The article definately points out many of the challenges with XML. EDI is not rapidly going away as was predicted by mavens.

    Where the article is a little light on is the replacement proposed by C24 - there have definately been some momentum in this area in the past few quaters. The artile leads to many questions that CIOs would want answered.

    First of all, is the track history record - the eternal chicken/egg conundrum. Second, it is hard to commit to data exchange as such a deep code level in a EAI heavy infeastructure. It is tough enough getting the various SAP components to communicate - never mind a PeopleSoft/SAP environment.

    Third, this proposal will require tremendous amount of work around for all involved. For those who have worked in EAI projects where there is a strong stakeholder, say WalMart, know the challenges that can occur even if the technical dictates are authocratical. In a more partnership level, say the finance industry, technical dictates are even more challenging.
  4. SAP you say....[ Go to top ]

    SAP is implementing such a solution using Javaspaces to integrate it's own modules internally why would we not do the same externally?
  5. SAP you say....[ Go to top ]

    > SAP is implementing such a solution using Javaspaces to integrate it's own modules internally why would we not do the same externally?

    I'm not sure I understood the question here. We have never worked with SAP so I really have no idea what they're up to. If they have their own JavaSpaces based core then great, why do you need it externally? I've no idea, I haven't got a clue what it does externally.


  6. True, XMLBeans is similar, but there are Other advantages to the IO approach:

    - a graphical editor for working with the data models
    - the models are version controlled, the GUI integrated with CVS
    - it can support extended semantic validation over and above that offered by XML schema
    - it is not confined just to XML
    - there is a whole set of pre-built libraries corresponding to commonly used FS standards.
  7. WebService on Wall Street[ Go to top ]

    Bugger all to do with this I know but I will be speaking at WebServices on Wall St. in New York on Tuesday 3rd. If anyone's there it would be good to meet you.

    -John Davies-
  8. JavaSpaces & versioning[ Go to top ]

    The power of JavaSpaces and the various Jini-related technologies is that you are passing around objects, which encapsulate both data and behavior. This makes for very (academically?) interesting architectures. However, the devil is in the details, and the devil in this case is object versioning.

    It has already been mentioned in prevous news that .jar versioning is becoming a problem (jakarta-commons.jar, etc.), and really requires one to be on top of things in order to avoid problems. This problem *really* multiplies when you start talking about JavaSpaces since you now have to worry about which versions of the libraries/classes are being used by the processes that are interacting with the JavaSpace. For example, the reader could be using a completely different version of the class and/or dependent library than the writer. Yes, you can work around these issues, but it takes a lot of effort to do so, and in my opinion does not give you the bang for the buck that would overcome such an effort.

    Yes, document versioning is an issue too, but isn't nearly the issue that class and/or object versioning is...

    However, Jini and JavaSpace technology is "sexy", and I continue to follow it closely (especially the v 2.0 of the spec which contains a very robust security model), and so I'm wondering how many people are actually using this type of technology, and what they've done to ease the object versioning issues...
  9. JavaSpaces & versioning[ Go to top ]

    > [ref: Jini/JavaSpaces] This makes for very (academically?) interesting architectures

    I totally agree that for the last 4-5 years Jini has remained very much in the "oh that's nice" box of the academic world. I know a lot of the Jini vendors very well, in fact most of them and up until now I have not changed my mind about it being "nice".

    What has changed, IMOHO, is that we now have boxes of machines (Blades) with decent amounts of memory (several GBytes each) a 2GB network all in a 3U rack. This rack has more memory and CPU power than a room full of machines with RAID disks from just 4-5 years ago when Jini came out. Jini/JavaSpaces has finally come of age.

    We used JavaSpaces technology in MarketConnect, we've seen the "devil's" details and it works incredibly well.

    As for versioning, if I understand you correctly, we have a deployment option that produces interfaces to abstract the deployed implementation. You can on deployment provide a previous interface (i.e. version) to be extended, this was implemented for a large London based Clearing House who use C24-IO to manage their internal XML schema and instances. We can also version package names, and (there's more...) the deployed ANT build file is version aware so it can also version the jar.

    What you get with "IO" is something that's deployed and working in banks across the world, it has been tried and tested. Apache's XML-Beans are excellent, we had a lot of problems trying to get anything usefull out of JAXB and Castor but XML-Beans is definately better. If we get time I'll see if I can get someone to run our Schema unit test suite through XMLBeans, it will definately give it a run for it's money, OK it's free! :-)

    Thanks for the feedback!

  10. JavaSpaces & versioning[ Go to top ]

    "However, the devil is in the details, and the devil in this case is object
    versioning. "

    You will always have a devil on your shoulder, the issue is how which you
    listen to it, or how much you let it influence you. We've deployed a complete
    back-office architecture with transactions between Oracle and CICS, using Java
    spaces to provide reliable transmission for systems that don't natively
    support transactions, like EDM, and Workflow; distributed error logging,
    distributed configuration and auto-updates of configurations using remote
    events. Potentially we're looking at developing a logic container that can be
    spread across multiple systems, ala Grid
    .....and it's all using Jini, and we've been using it in production for nearly
    three years.

    Yes it's cool, it's different, and it's been entrenched in academia for a
    while, but it is also gaining traction, and it's damn effective. We don't need
    a £20k per CPU (or whatever they're going for nowadays) app server, we've got
    what we want, we can cluster it, we have built in fault tolerance, load
    balancing and failover - and that didn't cost us either. Alright the cost is
    in the development, but for J2EE you have training, support etc
    When it comes to versioning we don't really get that much of a problem, it
    does all depend on how much change you're going to get during the lifecycle,
    if you know change is going to happen a lot - you;ll develop entries that are
    loosely grouped, and there is a Javaspce implementation where versioning and
    object evolution is automatically handled for you.

  11. JavaSpaces & versioning[ Go to top ]

    If you are interested in versioning issues when using JavaSpaces, www.intamission.com offer a JavaSpace that automatically evolves entries where clients have different versions; each client 'sees' the version it knows about, but can exchange that entry, through the space with clients who have different versions.
  12. JavaSpaces & versioning[ Go to top ]

    If you are interested in versioning issues when using JavaSpaces, www.intamission.com offer a JavaSpace that automatically evolves entries where clients have different versions; each client 'sees' the version it knows about, but can exchange that entry, through the space with clients who have different versions.

    We actually use Intamission and GigaSpaces and I'm hoping to be able to test out Blitz soon too.

    I can highly recommend Both Intamission and GigaSpaces for JavaSpaces.

  13. XML Message Payload Size[ Go to top ]

    Very interesting article. I've always been rather surprised that the XML meta information bloat is so non-controvertial. The noise-to-information ratio is so large. Normally your meta data (tag names) will be several times larger than your data. Do we rally need end tags as in: <stock_price>12</stock_price>? I see the meta/data ratio as 13+14=27 chars for begin+end tag vs. 2 chars for the data! Surely we could use an attribute and at least dispense with half the meta noise! It all adds up big-time eventually.

    Interestingly, I just came across the new revisions to the Financial Information eXchange (FIX) protocol that explicitly address these well-established inefficiencies that have been noted in production time.

     - Eliminate elements that were used as holders for repeating groups
     - Convert from elements to attributes where sensible

     - Use contextual abbreviations
     - Standardized abbreviations using a mechanical dictionary
     - Contextual means
        - removing prefixes, such as "Trd" from fields on the Trade message for instance
       - Permitted manual overrides to the mechanical abbreviation
       - Choices were based upon experience of other organizations that have successfully deployed XML in production messaging applications

     - Goal was not to necessarily have "human readable" XML
     - Surprise: optimized version was viewed as more readable
     - Message size reduced from ~3200+ bytes to ~850+ bytes per trade record
     - Message File Size was reduced from 25 MB to 9MB as a result of the optimization for a firm's daily trade file

    Sounds rather compelling empirical experience, n'est pas?

    See: http://www.fixprotocol.org/cgi-bin/Spec.cgi?menu=4
  14. XML Message Payload Size[ Go to top ]

    I find Andre's posting very interesting - particularly where he says the result was actually easier for humans to read!

    In general terms I recommend against the over use of attribute-based XML constructs. All too often the result is a message element whose attribute values are co-dependent. XML Schema cannot constrain one attribute's value based on another attribute's value - although given the thread of this discussion I would not be surprised to hear that IOs can accommodate such validation constraints - John?

    e.g. <Person name="Sarah" sex="female" marital-status="married" maiden-name="Jones"/>

    is fine, but the construct allows a maiden-name attribute to be specified for non-married or non-female Persons. [I took this example from the old Western traditions since that domain is well known to most readers, but I acknowledge that in modern society such a simplistic and sexist view of name changes after marriage no longer holds.]

    Another specific risk is the over use of boolean-typed attributes. Some XML designers always notate boolean conditions with a boolean attribute.

    e.g. <Person name="Robin" jdo-expert="true"/>

    At some stage it may be necessary to record additional - perhaps optional - information about a Person's membership in the jdo expert group, and the schema could evolve along the lines of:

    <Person name="Robin" jdo-expert="true">
        <JDOExpert process="2.0">

    The danger with this subtle extension is that the same schema can validly constrain the following (only the boolean value has changed).

    <Person name="Robin" jdo-expert="false">
        <JDOExpert process="2.0">

    What does that snippet mean? Is Robin a member of the JDO 2.0 process or not? The xml is valid, and could be interpreted differently by different applications.

    My preference is to notate the boolean with an embedded empty element in those cases where further information may later need to be notated,

    e.g. <Person name="Robin><JDOExpert/></Person>

    When, and if, this additional content is required, it naturally fits into the JDOExpert element and there is no ambiguity in the resulting document.

    e.g. <Person name="Robin><JDOExpert process="2.0"/></Person>

    1. This approach does not help you to store additional information about "false" conditions.
    2. If the information added to the previously empty element is mandatory then existing instance documents will all be invalid - but presumably that is the intention.
    3. It is EXTREMELY difficult to convince people that the empty element is justified, even though the additional content it may one day contain is unknown at the time of the initial design.

    I see this 3rd point as analogous to the difficulty of introducing <
    In conclusion, don't make everything in your XML designs into attributes just to save the space taken by enclosing tags - consider the domain carefully first.

    Kind regard, Robin.
  15. XML Message Payload Size[ Go to top ]

    Ah - TSS does not like chevron-chevron notation for stereotypes, so the second-last paragraph paragraph of my previous posting was truncated. Here it is with asterisks instead:

    I see this 3rd point as analogous to the difficulty of introducing *Role* classes into object models when the introduced *Role* carries no state; it too is a placeholder for the state that may later be identified, and adding state (attributes) to a class is much easier than interposing classes between existing associations.

    Thanks, Robin.
  16. Compression[ Go to top ]

    I see the disadvantages of XML in the following categories: bandwidth, storage, and processing. Bandwidth and storage can be solved with exotic solutions, but what about simple GZIP compression? These things shrink really well. I'm sure the guy who went from 25MB to 9MB could have done a lot better just compressing the thing and without bastardizing the Schema.

    I developed a store and forward architecture for XML messaging using Sonic and Hibernate. I have a custom Hibernate User Object for persisting XML docs to an Oracle Blob that uses the JDK zip libs for compression. The same could be done for the messaging side, but Sonic has great flow control so I just let the instances flow through uncompressed. Now compressing takes processing time, but with flow control from Sonic things don't crawl and clustering is simpplified. I just add a new host server. Each host is in the same subscriber group and has N number subscribers (threads) running in that JVM. The flow is controlled by the host and not the clients. Sonic just queues the information up gracefully. Monitoring will tell me when I'm not keeping up. Increase CPU and memory or just add a new box. I think SOAP is what makes XML based Web services slow. Not XML.
  17. Compression[ Go to top ]

    Bandwidth and storage can be solved with exotic solutions, but what about simple GZIP compression?

       My main point is not so much the bloat of the XML but the fact that it needs parsing every time. If you compress it it is smaller and it does in fact compress very well in general but when it gets to its destination and you decompress it you still have several tens of "k" of very in-efficiently encoded data to parse. This is where we are saving huge amounts of time not just in the fact that the serialized Java version is smaller but there's no parsing and schema validation to be performed.

    We can also compress the serialised Java Object and achieve the same result, now we have a very efficient data packet and only a handed optimised Externalization method to read back the full body of data.

    XML is slow on its own, SOAP is the nail in the coffin. :-) Sadly though we need it to talk to our Microsoft friends and SOAP's great at doing that. If only they understood JRMP or IIOP, I can see our next project coming along.

  18. Sonic integration works fine with Microsoft using the Sonic C++/COM client. We are using the C++ client on Solaris in my current securities trading project. Not to be a Sonic sales person, but I haven't thought about distributed enterprise communication in about 3 years. I use JavaGroups for shared cluster memory and that pretty much is where the guess work stops. IMHO, when SOAP is finally done, the best implementation will look exactly like one of the MOM providers that already exist now. How many ways have we had in the last 6 years to pass a String around.

    Additionally if you can't afford Sonic you can take a look at OpenJMS and implement a JNI wrapper around its client libs. The biggest problem it has right now is that its not clustered. I'm personally hope they get cracking again with JBoss/JMS. Seems like it hasn't been moving for a while. JBoss team, please implement Topic Subscriber Groups -- Only one member in group comsumes a message on topic, easiest and robust way to implement load balancing, failover, and scalability in a client server setup.
  19. I should add we fully support Sonic, we spent a long time working with Sonic UK but at the time we weren't really concentrating on XML and they have never really taken Financial Service (FS) seriously. We also worked with SpiritSoft who were seriously into FS but we found OpenJMS far too slow. Given the choice, I'd go for Sonic, they've got the right idea and a good product.

    Finally in our most recent project (Market Connect), we needed even higher performance. We tried Tibco RV, Sonic and SpiritSoft but the serialization of the object was the problem. We then went on to use Embedded JavaSpaces, it retains the API but doesn't require serialization.

  20. XML Message Payload Size[ Go to top ]

    although given the thread of this discussion I would not be surprised to hear that IOs can accommodate such validation constraints - John?

    Yes, there's virtually no limit to the constraints you can put into "IO's" version of Schema. From a simple XPath constraint implying that one attribute must have a particular value if the other is present to a full Java based method that looks up a value in a database and performs a complex operation to validate the value (on Fridays only).

    Of course it's not going to export back to Schema too well but the code's got to be written anyway so you might as well put it in the right place with the rest of the data validation.

  21. Dream[ Go to top ]

    It's a real world and there are a lot of firewalls there which allow only Http protocol. That's why Jini's dream of worldwide object web becomes an illusion. Sun realized that and started working on JXTA throwing away the code and just passing XML. However, it seems too distributed to have a transaction service to manage it&#65288;by last time I checked it). Come back to the topic, Jini/JavaSpace is nicely used within Intranet. I've seen some JavaSapce solutions aimed to replace EJB server as a more extensible storage service. Wa, yet another "old" framework. Nowadays we have more and more next-generation lightweight containers while sill good supporting most popular web-dev and O/R mapping tools. How could JavaSpace solution stand out?
  22. Dream - No, wake up, it's real![ Go to top ]

    > It's a real world and there are a lot of firewalls there which allow only Http protocol.

    With all due respect I don't think you've understood the paper. Once you need to pass through a firewall you are going outside, I wrote...

    "Note that XML/SOAP still has its place in inter-company messaging; it just makes more sense to use Java objects in many internal scenarios."

    Also, if we're talking about the "real world", i.e. where out customers are, I have to disagree, most companies have firewalls which they say only allow HTTP but in the 10 plus banks I've worked in in the last year, non of them actually block everything other than the port. They restrict to port 80 and 8080 if you're lucky but you can push anything you like through port 80 and I have in most cases.

    I made no suggestion that we use serialised Java Objects for inter-company messaging, in fact I have every belief that this will be the best place for XML messaging, not internally though.

    I think you are getting confused with your technologies, using JavaSpaces does not stop you using O/R mapping tools or for that matter EJBs. Why is it everyone seems to think every technology has to be used at the exclusion of all the others? I simply proposed the replacement of "intranet" based XML with Java Objects. It works with EJBs, JDO, JMS and other technologies. We have customers using C24-IO as a replacement for XML with EJBs, JDO and most in fact with JMS.

    > How could JavaSpace solution stand out?

    I (IMOHO) believe JavaSpaces will stand out because it's well established (since the 90s) and very simple. It fits beautifully with several other technologies, in particular Servlets, JSPs, WebServices and JDO etc.


  23. Dream - No, wake up, it's real![ Go to top ]

    Inter-company messaging vs. inter-company is a far to unpresise criteria. As mentioned before, XML provides an integration paradigm for lously-coupled systems. There are many good reasons for having lously-coupled systems whithin the company.

    The obvious reason beeing independance of technology: Java vs. something else.
    Integrating systems with binary contracts like Java objects also requires a tight cooperation beetween the organisational units that maintain the systems.

    I personally think that it is good architecture to seperate the contract from the implemetation language. After all, a good interface is one that completely hides implementation issues. Programming language is an implementation issue.

    I'm not saying that XML is the best, but Java Objects is not a choice for the future. Java Objects is only a good choiche as long as we love Java as a programming language. There might come a day when we start to love somthing else, XML can stick around anyway.

    - fred
  24. I enjoyed this article, one which dares to suggest that XML is not the be-all and end-all of data exchange. John should be credited for his courage! I also currently use C24 IO - in two separate contexts: to define internal and external message flows for an investment bank, and as an XML Schema editor to define the JO 2.0 object relational mapping descriptor.

    I've often seen Java architectures based around XML for data interchange. Some of these were well thought out, and others weren't. Some work in production, some didn't work in production, and still others never made it to production.

    XML is a very good markup language, although personally I find it to be eXtensible for the author of a schema, but not very eXtensible for users wishing to extend an existing schema. I don't think namespaces really solve that one very well, but perhaps they have more to offer than I realise.

    XML lets well-structured data be a decoupling point from the producer and consumer technologies and is especially useful when the two technologies might be otherwise incompatible now or in the future. However I tend to disagree with the interposition of an XML-based boundary between two components which are (a) both internal to the same system, and (b) both presently written in Java.

    This is one area where C24 IOs (or equivalent Java-XML binding techniques) come into their own. The objects understand how to format themselves into XML and to parse XML into new instances of themselves. In the case of IOs, they know how to enforce all the validation semantics of the XML Schema - and other validations which cannot be expressed in an XSD, such as database lookups - with the speed of Java execution and none of the formatting/parsing round trip expense.

    This gives architects a great opportunity to pass Java objects between systems, taking advantage of the performance characteristics offered thereby, and yet to drop down to and XML-based stream if ever the requirement to do so arises. By "requirement" I mean a real and immediate need - not a distant view that one day in the future it might be necessary.

    Finally our IOs can be formatted to XML very easily. We do this if we ever have need to record the contents of a message in a human-readable log - beats serialized form any day! ;-)

    Kind regards, Robin.
  25. "JO 2.0" in the first paragraph above should, of course, have been "JDO 2.0".
  26. Marketing[ Go to top ]

    ...XML for messaging is bad. Java messaging is good. Hey, guess what: We just happen to sell a product that uses Java messaging. Want to buy it now?
  27. Marketing - yup![ Go to top ]

    Yes John, it's marketing. Welcome to the real world. :-)

    It doesn't however stop you or anyone else from posting your opinions about the idea. With very few exceptions most of what you see here is some form of marketing. Even the open source projects are frequently supported by companies, the people working on them have an interest in keeping their line of expertise going and TSS is marketing for The Middleware Company

    I unashamedly admit that this is marketing but rather than push some sales bollocks down your throat via spam email I take the slightly more intellectual approach.

    Comments welcome of course.

  28. Tim Bray interview, news.com article[ Go to top ]



    The first wave of attention for XML focused on Web services, but it seems that it's really coming into play as a sort of lubricant for allowing data exchange between heterogeneous systems. Is that what you expected?

    There is no doubt whatsoever that if you go into an environment where XML is really, truly being used right now, it's that lubricant role you described. It's lightweight, quick and dirty enterprise application integration. The world is a heterogeneous place. Given the pace of mergers and acquisitions and the desire to centralize in the enterprise, there's a lot of big, hard, ugly integration problems everybody faces. And it suddenly became apparent at some point that almost every application, no matter how old, had a Web server on it. And you could achieve remarkably acceptable results in enterprise application integration simply by binding a set of XML messages to ship back and forth. There's just an immense amount of that happening right now.

  29. Hi John.
    So, to summarize, passing XML around tightly coupled systems is bad, XML should only be used for edge type communications. But, XML provides a nice schema description language which can be used to make XML and native representations of the data. IO generates a Java object representation of the schema with optimized serialization routines. Anybody can use it for high performance systems with coupled subsystems where it can trade standards on the wire for performance so long as there are only Java consumers of these objects.

    The main benefit of IO is that it generates the Java representation from the schemas and provides hooks to adding enhanced validation and it's probably very cool and a big time saver in this regard.

    The drawback is that not every system talks Java and we don't want to use XML to talk to these legacy systems because of the problems John speaks about in the paper. John, have you thought about generating a C version from the model also or do you do it already? There is quite a bit of C code lying around these places as you know. We all jumped off the Corba bridge when that was sexy and that base won't disappear over night.

    I haven't seen where you address versioning on the wire, CVS won't help here for obvious reasons, it's a development time technology. How does IO support on the wire versioning so that if a producer uses a new version, all consumers don't have to move up at the same time, a scenario all too familar I'd imagine :)

    Nice stuff.
  30. Good point Billy. I have had clients try to Serialize Java between different applications, and the biggest issue was the applications used a different version of the JVM. Not only do you have to deal with multiple languages, but you have to deal with passing Java Objects to JVM's of the same version.
  31. We have written our own serialization in the form of externalization. We have so far not had problems with JVM versions but so we've never had a client with less than 1.3. In fact we had to retro-test for 1.3 when working with Tibco's BusinessWorks, until then we had only worked with 1.4 and BW was 1.3 max.

    I'm not sure what you mean by multiple languages, this is Java only. We could look at using something like IIOP rather than standard serialization but Java's JRMP/custom has proved fine for the moment.

  32. Hi Billy,
        Thanks for the comments, you seem to have summed it up quite well.

    > John, have you thought about generating a C version from the model also or do you do it already?

    Yes, and no. Basically as soon as we have a requirement for C, C++ or C# then it's definitely on the books. We knocked up a demo for a customer a while back to demonstrate than it can indeed generate C++ but it all comes down to commercial imperatives in the end of the day. We have numerous customers using XML, SWIFT, FIX, Omgeo, SwapsWire, FpML etc. in Java not C#/C++. Given the right carrot and modified priorities then it would be available in a few weeks in beta, in reality I would hope to see something by the summer.

    As for versioning, we take a schema (say the base version) and generate a binding (*Impl.java) with interfaces (*base.java). When the schema changes say version 2 we generate the new binding (*Impl.java replacing the original) that implements interfaces *base_01.java which extends *base.java. This is all in the deployment options. You can now mix base versions with base_01 with the obvious restrictions. The old consumers use "base" and the new consumers use "base_01".

    This was designed at the specific request of a client and has been part of the core for some time now. The request was based on the classic problem of having two versions of essentially the same message running at the same time.

    I'm not sure if I've explained it too well so if you're still left confused please let me know and I'll try harder (without the beer might help :-))

  33. Ehmmmz, silver bullet?[ Go to top ]

    Since when does a silver bullet exist...?
    I've seen alot of things being introduced as a silver bullet (both in software engineering and in the "outside world"), and nothing has ever lived up to the promise.
    I'm just wondering, what happened to the "old and awfully ugly" things like ASN.1, TLV, etc. Not human readable (but hey, who has to read it; you or the computer?), as proprietary as XML, etc.
    I'm not saying that we should all switch back to TLV for example, I'm just wondering why we would need yet another "standard", etc. (or a human readable data format to send between computers ;-) )?