Wednesday, September 10, 2003

Layer Six and AOP. I finally found someone making the link between Aspect-Oriented Programming (AOP) and SOAP: Carlos E. Perez! I repost my comments here: Hurrah! Someone is at least mentioning the conceptual unity of AOP and SOAP. Just as AOP software architectures enable "separation of concerns" based on the concept of interceptors, so too the SOAP envelope-processing architecture is based on "SOAP intermediaries" processing SOAP headers. Each header (or set of related headers) deals with a distinct set of concerns. Thus the WS-Security header deals with security concerns, while the WS-Coordination header deals with state management concerns. No question that aspect-oriented architecture (or should the more general term be "separation of concerns -SOC- architecture") is emerging in various domains to deal with the dramatic increase in complexity driven by the increasing number of "first-class" concerns. Concerns such as security, performance, extensibility, availability, deployability, monitorability, which are dealt with by different software architectures in different ways, but which can be unified by SOAP's ability to deal with federated separation of concerns. Is anyone else discussing how AOP and SOAP are just different "aspects" of architecting for SOC? I mentioned my inability to find such discussion in blog back in July. See http://radio.weblogs.com/0126951/2003/07/11.html . 10:09:48 AM

Binary XML Standard Considered Harmful --NOT! Omri Gazitt has a thoughful piece on Binary XML, but I disagree with his conclusions. I repost my comments here: (Thanks for the pointers to the work underway on Binary XML.) I completely agree with your argument against one universal binary standard, but "not one" does not imply infinite. That is, I think it would be useful to have a handful of "binary XML" standards which more or less cover (80/20 rule) the major scenarios within the three major axes. Of course, the market will eventually discover such "standards" on its own, but standards work could speed things up a bit. Certainly standardizing a compressed, but simple to deserialize, XML for portable devices makes sense? Another standard would be the gzipped XML 1.0 serialization. All that's needed here is to standardize the nitty gritty details of using the two standards in conjunction; something that WS-I should probably tackle. I also think an XML to ASN.1 standard would be useful, just to cover interoperability between the two standards (a lot of management protocols use ASN.1). A few other serialization standards probably make sense as well, but you get the idea. In my experience, the hugely successful standards all share the hourglass shape of a "spanning layer" (see http://radio.weblogs.com/0126951/2003/08/12.html#a33 or google the term). That is, they map down onto diverse implementations (in this case serializations) and map up into diverse applications (seemly infinite for XML Infosets). The Internet, Ethernet, SCSI, etc. standards have this shape. Currently, the XML set of standards lack this hourglass shape because they must serialize into the XML 1.0. Instead, they look like an inverted triangle (narrow base and wide top). Such an hourglass shape enables a standard to adapt both to new implementation technologies and new applications. I believe the heart and soul of the XML family of standards is the Infoset, NOT the XML 1.0 serialization. XML 1.0 was the ladder we all needed to climb to get to a universal agreement on a universally interoperable data structure, the Infoset. Now that we have such a level of agreement, we don't need the ladder anymore--at least not it exclusively. 6:40:55 AM