Remembering the Future

But unfortunately, it gets worse.

I've come to recognize that we're still looking to XSD and WSDL to be a sort of "IDL for interoperability", and the problem is that both Schema and WSDL allow for things to be defined that don't fit our existing programming languages. Facets on schema types, in particular, create a particular brand of Hell for the Schema-to-class automatic translators, and fact is, most tools (xsd.exe and all of the Java-based toolkits I've tried thus far) basically punt on them. Which leads us to a nasty discipline problem all over again: Not only do you have to be disciplined enough to avoid the styles or notions or idioms of a particular programming language into your service, but you have to be disciplined enough to avoid the styles or notions or idioms of the wire-level representation, as well, or the consumers of the message on both sides will find it awkward to work with.

How do we avoid this? At the moment, there's less concern for the latter than the former, but as people start to go with a more "contract-first" approach, we either have to bury the angle brackets behind a subset of what schema can offer (and thereby piss off the angle-brackety crowd), or else we have to just publish mounds of texts and patterns [1] to describe to people what to avoid and when.

Neither one sounds truly appealing, which leaves a third option, one far more radical but infinitely more satisfying: just ratify and stamp with approval the current programming practices, and introduce XML and schema types as first-class citizens into our programming languages.

Dare Obasanjo

It is actually much easier to make an uninteroperable Web service if one starts with the service contract instead of with object oriented code. The reason for this is quite simple and one I've harped on several times in the past; the impedance mismatch between XSD and objects is quite significant. There are several constructs in W3C XML Schema which simply have no counterpart in traditional object oriented languages which cause current XML Web service toolkits to barf when consuming them. For example, the XmlSerializer class in the .NET Framework supports about half the constructs in W3C XML Schema. Most XML Web Service toolkits support a similar number [but different set] of features of W3C XML Schema.

. . .

This isn't theoretical, more than once while I was the program manager for XML Schema technologies in the .NET Framework I had to take conference calls with customers who'd been converted to the 'contract first' religion only to find out that toolkits simply couldn't handle a lot of the constructs they were putting in their schemas.Those conversations were never easy.

. . .

The main thing people fail to realize when they go down the 'contract first' route is that it is quite likely that they have also gone down the 'XML first' route which most of them don't actually want to take. Folks like Tim Ewald don't mind the fact that sometimes going 'contract first' may mean they can't use traditional XML Web Service toolkits but instead have to resort to SAX, DOM and XSLT. However for many XML Web Service developers this is actually a problem instead of a solution.

Ted Neward

As for me, I'm talking about Effective Enterprise Java again, but also some new .NET taks on Indigo and C-Omega, among others. I'm looking forward to both a lot, particularly C-omega, since I think XML and relational integration into the language is the Next Big Thing for programming languages; should draw some interesting comparisons to Groovy.

Topics: Contract First | C-Omega

Here’s the rub. One of every three dollars of Microsoft revenue comes from Office. What if, from a purely disinterested perspective, the way to achieve savings and accelerate productivity was not to use Office at all, but rather shift to another architecture–say one that supports lightweight routing of XML fragments around the network in a highly accelerated virtualized kind of digital dial tone infrastrucure? Let’s call it RSS, flowing through an attention-based inforouter.

In this alternate universe, user interfaces would be plastic in nature, morphing as data types trigger template switching that routes packets of information through transformation engines based on metadata-driven signals. Charting services are overlaid with ticker text treaments, then piped to handheld devices as a stream, and cached on terminal screens to be called up on demand. Color-coded expert opinions are syndicated to executive information feeds to provide real-time "gut decisions" from consultants and rating data from affinity groups.

Topics: RSS | Predictions

Remember there are three Split functions in .NET:

Use Microsoft.VisualBasic.Strings.Split if you need to split a string based on a specific word (string). It is the Split function from VB6.

Use System.String.Split if you need to split a string based on a collection of specific characters. Each individual character is its own delimiter.

Use System.Text.RegularExpressions.RegEx.Split to split based on matching patterns.

Topics: Regex

It is extremely hard to make the transition from one paradigm to the next. When I was employed by a mainframe software company, it was clear to me that the client-server guys were going to kick our butts. It was equally clear that the application service guys were going to win over the PowerBuilder types. And yes, to me, it is once again clear that the service network guys will win over the application server companies.

Topics: Architecture | Predictions

Using the Christensen playbook, we should consider whether WS specs and tools are being commoditized by disruptive technologies. If so the natural progression for them and the software based on them is to move up the value chain. When the mass market for enterprise technology is either over-served by technology, quality or the price is too high that leaves an opportunity for disruptive technology to take hold at the bottom end of the market. I worry this may put out some people who feel that WS are a disruptive technology, but when you see RSS usage figures doubling twice a year, you stop and think about what's really disrupting what. But, REST as it appears in the HTTP Web seems to have a broader potential set of uses than was originally imagined by WS proponents, especially in conjunction with simple formats like RSS or Atom.

Topics: Rest Disruptive