Some more of my thought regarding the abomination dubbed Binary XML.

Wouldn't the world be a better place if we could use SOAP, WSDL, WS-*, without angle brackets?

Yes? Yes!

In the current distributed applications field, we are living with the situation that a number of different protocols basically share the same space. No matter if you are looking at .NET or Java, you have the choice between a number of different protocols:

On one hand, you have low-fuss APIs like .NET Remoting or Java RMI which enable you to easily build distributed applications without any major external dependencies. Built upon these - or maybe even built upon different protocols, like DCOM or IIOP - you'll find service-supported layers. In the .NET space this is COM+/EnterpriseServices, and on the Java side it's the EJB framework. These layers don't just facilitate RPC-style communication, but come with a number of different services like security, transactions, messaging, pub/sub events, and friends.

But of course, no matter which platform you prefer, you'll also find a number of SOAP implementations. Web services based on SOAP started out as simple means to wrap XML documents and channel them from one service to another and vice verse. Today however, vendors are mostly planning, specifying or implementing additional services extending the core basics of SOAP.

These new services include security, transactions, messaging, pub/sub events, and friends. Sounds familiar? Well yes, it is. The fundamental difference however is that nowadays, we are interoperable. You can - or will be able to - for example span security contexts and transactions between .NET and Java.

But wait! The big hangover comes as soon as you realize that the programming models are largely different. If you want to create a web services security context using WSE 1.0 on the .NET platform, you have to work completely different than when sharing a security context using .NET Enterprise Services. The pieces of code hardly resemble each other.

To create the relatively best compromise regarding interoperability, performance, scalability, security, and maintainability, you might end up with using Enterprise Services based components inside your intranet and use web services as soon as a message leaves your trust domain. Doesn't sound too scary, does it? We are doing this all the time, right?

True. But nowadays, architects and developers have to learn two different toolkits: Web Services and Enterprise Services. Each of them comes with its own issues and the usual bag of tricks which have to be learnt and "experienced". And what for? Speed. If it wasn't for performance, XML would win hands-down in all cases. [1]

But wouldn't it be easier if there was just one programming model which relied on the XML Infoset, SOAP, WSDL, UDDI, and WS-* to provide all these Enterprise Services? Wouldn't it be great if this model supported XML in the way it's supposed to be: with angle brackets as an implementation detail. This way, we could use all these great services, wrap them in binary messages and live happily ever after. Without the performance implications of angle brackets.

No, I'm not telling you that XML 1.0 + Namespaces is a bad thing - it just has some negative implications in the limited environment in which we have the luxury of dealing with the same platform at client and server. My only request is for an optimization in the form of Binary XML to better support these environments.

[1] This is a look into the future as most second generation web service specifications are unfortunately not yet fully implemented and supported. But suppose they were ...