Catching Up

So much for practicing writing - well, at least not here. I have, however, been doing quite a bit of writing at work lately, some of which is the basis for this position paper for the W3C Workshop on Web of Services for Enterprise Computing. If I'm lucky, maybe I'll finally get to meet fellow RESTafarian Mark Baker who's also presenting something.

Although I contributed to the position paper (somewhat unwittingly), at this point I'm not sure I'm looking forward to going to the workshop. In fact, if you'd asked me before our paper was submitted whether I was interested in attending such a workshop, my response would have been something along the lines of "why would I want to work to improve something (WS-*) that I'd prefer to see fade away?"

The project I'm on now is a research-oriented project for a military customer where we're looking at SOA, ESBs and Web Services (among other things). In a nutshell, we're supposed to help our customer figure out whether or not this SOA stuff and its corresponding technologies (which in their eyes is WS-*) will actually work and be useful for their purposes. The downside is that I'm working with stuff that I don't really believe in (the WS-* part, not the SOA part). The upside is that I have the opportunity to point out the failings as I see them (and the customer actually seems willing to listen).

Our team pretty much covers the spectrum from WS-* on one end to REST on the other (that's me), so we occasionally have some spirited debates.

For the last few months, we've been looking at service discovery, trying to really focus in on what service discovery is and why you might need it. You see, the military is in the midst of an effort to get themselves some SOA goodness and they're cranking out the architectural guidelines and building themselves some infrastructure to support all these new services that'll be part of their SOA. One piece of that infrastructure is discovery.

Apparently, there's some debate as to what discovery is. If you ask one group (apparently the majority), they claim it means content discovery - being able to discover information (i.e., search) - and that if you squint the right way, services are just information sources whose output can be treated as content. However, there's another group that believes there's a fundamental distinction between services and content and that the two require different approaches for discovery.

So we've been looking at service discovery and asking lots of questions - like what's the difference between design-time and run-time discovery, and is there really a need for such a thing? It's been kind of frustrating, because any time we talk to people about it, they either just point to UDDI, or they start talking about all the cools things you could do if you could discover arbitrary services at runtime. Unfortunately, there are never any real details as to how any of this would actually work. And worse, when we ask for real-world scenarios where this would be useful, we either get more hand-waving, or something that would require a whole lot more AI than the industry's currently able to muster.

We've managed to make some progress - to the point where I've managed to formulate a somewhat coherent picture of service discovery in my head; and over the last month, I've tried to put some of it on paper. Mind you, none of it's earth-shattering; just a healthy dose of reasoning about the needs of design-time discovery and run-time discovery and some thoughts about the sort of environment in which run-time discovery would actually make sense.

One conclusion we've drawn is that (assuming run-time discovery is actually a useful thing), what's currently out there in terms of tools, technologies, and specifications probably isn't sufficient - especially not in the military world. Problem is, at this point, I have no idea what would be needed. My esteemed colleague (author of our position paper, and solidly in the WS-* camp) has decided this gap should be addressed by the W3C - and thus the position paper. Me - I'm not so sure. I'm not even convinced there's a real need for run-time discovery - at least not as an infrastructure service.

Thus, my conundrum - I may have make a case for something I'm not even sure is a problem, and I have to do it at a workshop that I'd otherwise have no interest in. Oh well, if I do go, at least I'll finally get to meet a bunch of cool people - like Mark, Noah and Dave - whose writings I've followed in such august places as the W3C TAG mailing list or the REST-discuss group.


(Let's see if I can do another one of these without waiting another two years.)