I've been in Boston for a couple of days to attend the WSEC workshop.  I'll avoid some of the interesting (but still inconclusive) discussion about the ultimate relationship of REST and WS-*.  But two of the emerging conclusions of the workshop are interesting.

First, my proposal for a WS-Core WG to continue the active maintenance of the raft of specs being completed in the W3C, and continuing to keep the pressure up on interoperability testing, was well received, and ended up being a primary area of agreement for the Working Group participants.  I don't think that's because it is a brilliant idea, rather because it's fairly obvious, modest, and concrete.

Secondly, one of the major pain points in WS-* remains the poor support of XML Schema that is being addressed in the understaffed XML Schema Patterns for Databinding Working Group. A renewed effort to address this customer pain point is essential.  I'm confident WSO2 can continue to participate and maybe even step up our work in this critical area, and I hope other vendors who wrongly dismissed the effort as irrelevant after Microsoft didn't show up will reevaluate their positions.

The consequences of not doing so are to weaken confidence in the description side of WS-* that remains in my mind one of the primary advantages of WS-* over REST.  If we can't do a better job, I think REST and REST description languages such as WADL will gain momentum.  That's not a bad thing in itself, but some healthy competition will keep the architectures competing on their merits rather than their execution.

Thanks to all the participants for some engaging and informative discussion.

Brother Jason's new company Acesis decloaks their pilot program in Electronic Health Record startup.  Attacking the problem at it's source - making the process of data capture better than paper, rather than pumping up the long-term benefits of electronic data, which are already well known but haven't had any appreciable impact on physician behavior.

First public reactions are quite positive.  Look at other news reports too.

Wish them rapid success!

Suffering for almost 10 years at a max speed of 112K is over!  I've been trying to get broadband wireless service from the local provider (Newcastle Broadband) for a couple of years, but depsite repeated surveys and exploring relays and so forth, they were never able to complete a proposal to get service to the house (the barn gets great signal!).

Last fall Coy and I played with some wireless technology ourselves after completing the solar array installation.  At last we found a combination that worked - a 24" dish at home and a cantenna at the barn (two dishes didn't work well - perhaps because of reflections off of the metal-clad side of the barn?

Then it took a couple of months of phone calls, web requests, and so forth before I reached the company CEO and was able to schedule an installation.  We mounted a 20' pole to the barn to clear the trees and allow them some more room to grow.

Coming out of the Motorola Canopy reciever, I go directly into a Linksys 54Mb Access Point hooked up to the cantenna.  At home the dish hooks up into another Linksys 11Mb Access Point I've had for years.  That one gets set to "Access Point Receiver" mode and the output of that goes inside to my Linksys 54Mb Router/Hub/Access point.

I still have one bit of trouble - though the Canopy has DHCP, and my access points can get an IP address easily, my laptop doesn't seem to get one very well.  That means I still have to have a router in the mix - which prevents me from getting directly to the Canopy's web admin console unless I drive up to the barn.

I got one of the cheaper plans - 600Kb down, 300Kb up, but if that isn't sufficient I can simply phone up and they'll dial me up to 1.5Mb. 

Five times faster - one third the cost.  I'm a happy camper so far!

WSO2 is hosting the WS-Metadata Exchange Interoperability Workshop, here in my hometown of Auburn, California.  After years of travelling to the far corners of the world to attend meetings, this is the first time I've hosted a meeting I myself didn't have to travel to (at Microsoft I hosted meetings at the Redmond and Silicon Valley campuses.)

If you've got a WS-Mex implementation, sign up and come along!  We expect to be testing WSO2's Mex implementation with the likes of Microsoft, and IBM.  We're sure to have a great time!

Laine was inspired by this story we came across in the Christian Science Monitor about hedgehog rescue in England:

This is St. Tiggywinkles - a wildlife hospital. It's where 500 hedgehogs are served meals in bed every day in the hope they'll put on enough weight to survive the winter.

...

The phone rang constantly with people who'd found ailing hedgehogs...  Stocker would give advice on hedgehog care, but sometimes he'd ask the caller to simply put the hedgehog on the train.

"I knew that the British Rail network used to carry racing pigeons," he says. "So I contacted British Rail and made the arrangement that if somebody had an injured hedgehog, they could put it on the train at their station [in a box] and they would go straight through to Aylesbury." Hedgehogs from as far away as Scotland made the free journey as a Red Star parcel.

Is that straight out of Beatrix Potter or what?  Gotta love the British, especially their flair at names.

Sadly, I can't guarantee Laine's hedgehog will be the one in this household putting on weight to make it through the wet season.  In fact it's unlikely to make it through the night in one piece.  Life's rough out here on the frontier!

Just posted a few photos from last weekend's trip to Tuscon for the Tuscon Gem and Mineral Show, a city-wide collection of gem, mineral, and fossil collectors and wholesalers from around the world.

Most of the shots are from a hike through Saguaro National Park, and a tour through the practically abandoned Biosphere 2.  Many curious stories behind that expensive experiment!  (I didn't say failed experiment!  You can't make me say failed experiment!)

The desert around Tuscon is a pretty lush ecosystem, with jumbles of desert flora everywhere - my photos attempt to make some visual sense of the landscape.  The colors, even in this season in-between hot and wet.

Enjoy.

As WSDL 2.0 approaches it's launch into Proposed Recommendation, Jacek has pointed out the apparently duplication between the wsdlx:safe annotation (and it's corresponding {safety} property) and the Semantic Annotations for WSDL sawsdl:modelReference="http://www.w3.org/2006/01/wsdl-extensions#SafeInteraction" annotation.  Both these annotations have essentially the same characteristics.  How should the existence of two ways to say the same thing be rationalized with the goal of standardization, which is how to agree on one way to say something so we have the best chance of understanding each other?

The issue has now found it's way to the TAG for their comment.  I already put in my two cents.  But part of my claim may benefit from some exposition.

Besides the spelling of the feature (wsdlx:safe="true" vs. sawsdl:modelReference="...#SafeInteraction") and the terminology underlying it ({safety} vs. {modelReference}), there is only one other significant difference between the two mechanisms.  That is, that the WSDL 2.0 HTTP Binding has a dependency upon the wsdlx:safe annotation.

If the HTTP Binding moved its dependency to SAWSDL, it might accidentally suck in the whole SAWSDL framework, overkill if all you really want to implement is the HTTP Binding, like a tapioca pearl drink when all you have is a regular size straw (wsdlx:safe is small enough to slip through a coffee stirrer).  So unless this dependency can be dislodged, our only reasonable choice is to discourage SAWSDL from competing with our wsdlx:safe extension.  That would be unfortunate because wsdlx:safety sticks out like the energizer bunny in a polar bear habitat.  Safety really describes "what does the service do" rather than "how do I use it" which is what WSDL is really about.  SAWSDL seems a much more appropriate home for the concept of safety.

The detail of the dependency is, that when an operation is marked as safe (wsdlx:safe="true"), and bound with the WSDL 2.0 HTTP binding, and there is no default HTTP method specified (whttp:methodDefault), and there is not explicit method on the operation (whttp:method), the operation will be bound to GET rather than POST.  Notice that:

1. Removing wsdlx:safe does not prevent someone from binding an operation to GET.
2. If you really want GET, whttp:method="GET" is much more straightforward than wsdlx:safe="true" and omitting the whttp:method.

Which came first, GET or safety?  GET is the poster child for why safety is interesting.  Safety is the abstract quality of GET that has proven so useful on the Web.  As an abstraction, it's by definition less concrete to users.  Most of the people I know that understand safety thoroughly understand GET thoroughly, so it's unlikely that anyone who asserts safety will be unable to figure out how to simply bind explicitly to GET instead.  And I think there are quite a few people who can use GET without understanding the subtleties of safety.  And indeed, that level of abstraction can be dangerous to those who don't know what safety is.  "Yes, it's safe to dereference the URL 'debit me $100' because I don't have a criminal record.  So I'll mark that operation as safe."  I don't think you have this understanding problem with GET.

So why is safe interesting at all if it's simply a synonym for GET?  Well, I think that's a bit backwards.  GET is often equated with safety, but POST can have the property of "safe interaction" as well.  Perhaps you want to invoke a safe operation with a bulky payload like a SOAP envelope for which POST is appropriate.  The knowledge that the POST was safe could be used by caching infrastructure with immediate benefits.  But the HTTP binding's dependency has nothing to do with this primary use case.  So sawsdl:modelReference is just as good for that usage as wsdlx:safe.

So why did safety end up in WSDL in the first place?  Well, it seemed like a good train to latch onto at the time, and we fought back many similar requests to hook cars to that train.  Eventually I think it became clear to the "hookers" that this train wasn't actually leaving the station for a while (this week marks the 5th anniversary of our first teleconference).  They mostly went looking for other trains.  I say let's unhook this caboose since once it's attached it can never really be unattached, even if our train is going somewhere different than the caboose wants to.

I suspect the decision will come down to whether SAWSDL is perceived to have enough momentum to become a common companion to WSDL 2.0.  I also suspect SAWSDL would like to keep this functionality because it might drive initial adoption.  I just implemented SAWSDL annotations in wsdl-xslt, showing that the extensions are rather trivial from the WSDL perspective.  Maybe that demonstration will also help drive SAWSDL adoption, and thereby allow us to restore safety to it's rightful family.