Joe McKendrick: There are voices within the industry that say there are more lightweight alternatives to the verbosity of the XML meta language for designing services, such as JSON (JavaScript Object Notation). Will use of XML, long regarded the lingua franca of Web services and messaging, begin to fade?
Recently Commented On
-
Will case management eclipse BPM in importance this year? (12)
Dave Duggal wrote: Good question to start the New Year... [more]
-
What are your BPM predictions for 2012? (15)
Christopher Taylor wrote: With a new Gartner Quadrant out for... [more]
-
What modeling techniques should be used for capturing case management processes? (5)
Dave Duggal wrote: Hi Peter - Thanks for raising the p... [more]
-
What was the biggest development for the cloud for 2011? (2)
John Michelsen wrote: The biggest development for the clo... [more]
-
How big of a role does BPMN play in today's projects? (18)
Theo Priestley wrote: Depends where you're starting from ... [more]
Tag Cloud
Blogs
- Agilization
- All Things Social
- Anatomy of Agile Enterprise
- Andre Yee's Security Insider
- Anne Stuart’s BPM in Action
- BI in Action
- BPM and the Social Enterprise
- BPM from a Business Point of View
- BPM in the Cloud(s)
- BPM Insights
- BPM: Theory to Practice
- Business Ecology Initiative & Service-Oriented Solution
- Business IT Buzz Blog
- Business Transformation in Action
- Business-Driven Architect
- Cloud Talk
- Column 2
- Data at Your Service
- Dion Hinchcliffe's Next-Generation Enterprises
- ebizQ Mobile CRM Enterprise Integration
- ebizQ's Business Agility Watch
- Enterprise Architecture Matters
- Enterprise Mashups in Action
- First Look
- Governing the Infrastructure.
- Ground-Floor BPM
- Information Architected for Business
- Integration Innovation
- Integration on the Edge: Data Explosion & Next-Gen Integration
- IT as a Catalyst for Optimal Business Outcomes
- IT Directions
- James Taylor's Decision Management
- Kiran Garimella's BPM Blog
- Leadership BPM
- Leveraging Information and Intelligence
- Making Sense of Business Information.
- Manage Tomorrow's Surprises Today
- New Frontiers in Business Intelligence
- Open Source Software Up the Stack
- Pragmatic Software Design
- Process Makes Perfect
- Process POV (Process point of View)
- Putting the ‘M’ back in BPM
- Ronan Bradley's FinanceTech Directions
- SaaS Week
- Security Matters
- SMA's Insurance Transformation, Where Strategy Meets Action
- Smart Systems in Business
- SOA - Integration Industry Pulse
- SOA Visionaries
- Software Infrastructure for Business Value
- Software Test Management and Metrics
- Tech Blog
- Tech for Tomorrow
- Technology Management Insights
- Ted Cuzzillo's BI
- The Architect Insider
- The Connected Web
- The Healthcare Blog
- The Mike Rothman Security Report
- The Performance Principle
- Twenty-Four Seven Security
- Where SOA Meets Cloud
| ADVERTISEMENT |



Personally, I think it's a mute question really. Optimization and interoperability are the key elements to any of these technologies regardless.
They've all been around for years and will be around in different evolving guises for many more. I remember my first introduction to "similar" tech 30 years ago and most of that's the same today!
My 2 cents.
I really don't believe so. At the end of the day, it's clunky and can be expensive to process but CPUs are getting faster and available memory is still increasing. I have been told many times there are alternatives but I have yet to find something that can be parsed to get 'meaining' as easily on a mainframe as it can on a PC whether you are using Java, C++ or assembler ! JSON gives us a hint in the name....it's geared towards JAVA IMHO and as such is only appropriate when using Java which is simply not appropriate for all development scenarios.
XML is at the foundation of many, if not most, integration efforts, Web services, and SOA projects. We finally have something that’s bringing together all the world’s systems and data. There will be a lot of XML around for a long time to come.
Well, in fact JSON is language independent and is based on the ECMA Standards – that apart I guess one way to put it in perspective would be drawing a parallel with Java and PHP. If you want something up and running quickly then PHP is a great way to go whereas if you want something sustainable, reusable at the enterprise level then you go for Java or Microsoft based technologies.
Both, XML as well as JSON will co-existence but the usage will depend on the intent – Long term or Short term!
Is SOA dead? surely it is not. It is now mainstream. The same thing is true about XML: it is not fading. It is De-facto standard for many years to go.
The trade of of XML Platform independence for its less than optimal resources consumption is reasonable.
Lets face it, XML is here for the long term. In essence its nothing that new at all, and as an early post stated, many "technologies" can find their roots some 30+ years ago. XML facilitates integration and SOA, unless there is something really revolutionary round the corner regarding computing, then I dont see these 2 dissapearing for a very very long time...
Also XML is now being used as a starting point for other technologies, just look at WPF and Silverlight XAML, its basically XML with some add ons, and there is nothing wrong with that....
Different problems lend themselves to different technologies. JSON came about because AJAX developers found that working with XML in JavaScript--the X in AJAX--was a lot of work. JSON cleverly used functionality in the language to effectively bind wire protocol automagically to objects. Problem solved. JSON turned out to be a nice succinct notation that then found application elsewhere, where the bloat of XML wasn't needed.
But there will always be problems that require the richness of XML ("richness" is just bloat viewed from the other side). Schema validation, transform, linking--these are incredibly valuable capabilities and have an essential role to play in many sophisticated applications.
XML isn't going anywhere, but it will need share the stage with alternatives like JSON. This is identical to the REST vs SOAP debate. Smart developers eschew religion and ask themselves what problem they are solving. The answer usually suggests the most appropriate technology.