April 28, 2005

Modifying the state of a resource

Elements of state (aka properties) of a resource (such as WSDM properties, the properties of a CIM class or the attributes of an MBean) are a common component of management meta-models. They provide a way to expose information related to the resource. They are usually readable and sometimes also writeable. Reading the value usually means that the returned value is what the manageability representation believes reflects the state of the resource at the time the request is served. You generally can’t be sure that what the manageability representation sees is the actual state of the resource and that the state will not change one microsecond later, but within these usual restrictions, the semantics of a read are pretty clear. The semantics of a write are trickier as properties may represent an observed value, not one directly controllable (sometimes called a configuration value). For example, one cannot just “set” the GPS coordinate of a car and expect the car to be instantly teleported there. Does this mean that the GPS coordinate should not be writeable, or does it mean that setting them should be interpreted as an instruction to the car to do the best it can to drive itself to the location corresponding to the coordinates? Either is ok, as long as the contract is clear. Here are possible ways to handle this:

  • One approach is to make ALL properties (that is, the entire state of the resource) read-only and any change goes through operations. The state only changes as a side effect of operations, each of which has clear semantics. So instead of setting the GPS coordinates, one sends a DriveTo message containing the coordinates. The semantics are those of “DriveTo”, rather than reusing some generic semantics applicable to a class of “set” or “write” requests.
  • A variation on this is to explicitly select some elements of state as configuration elements that can be set by a generic “set” operation and leave aside non-configuration elements to be modified only as side-effects of operations. For example, threshold levels and ownership contact information can usually be written directly by the manageability implementation.
  • Another approach is to clearly acknowledge the difference between observed state and desired state and model all interactions as modifications to the desired state, leaving the manageability representation in charge of doing its best to reconcile the observed state with the desired state. In this case, a “set” or “write” operation is clearly a modification of the desired state, not necessarily the observed state.

1 Comment

Filed under Everything, Tech

April 8, 2005

Greg Papadopoulos on “collaborating” with Microsoft

Greg Papadopoulos (Sun’s CTO) recently posted a blog entry to tell us, a year after, what’s it’s been like working with Microsoft. For those who forgot, a year ago Microsoft sent a $2 billion check to Sun to settle some legal disputes and turn Sun into a technical partner. So what kind of technical partnership is that? Well, according to Greg they’ve been making “some real architectural progress”. And he gives us four examples: WS-Addressing, WS-Management, WS-Eventing, WS-MetadataExchange. The funny thing is that for each one of these specifications Microsoft had written and publicized the specification before Sun became a partner and just put out a slightly updated version with Sun and other companies added as authors. Go ahead and check for yourself:

  • WS-Addressing: the “before Sun” version (March 2004) and the “after Sun” version (August 2004)
  • WS-Management: the “before Sun” version was called WMX but I can’t find a URI for it, only an overview document so on this one you’re on your own to find the “before Sun” document to compare (hint: call Microsoft, not Sun for this doc). Here is the “after Sun” version (October 2004)
  • WS-Eventing: the “before Sun” version (January 2004) and the “after Sun” version (August 2004)
  • WS-MetadataExchange: the “before Sun” version (March 2004) and the “after Sun” version (September 2004)

There might be a lot of in-depth technical collaboration going on between Sun and Microsoft that we are not allowed to see, but the only examples Greg has for us in his “one year later” piece make it sound a lot more like a business deal than technical collaboration. Maybe they have the CTO write about it because the CFO doesn’t have a blog?

In that same piece, Greg also tells us that “the ‘interoperate’ message is louder than even the ‘standardize’ one”. This is probably why 3 of the 4 specs he brings up are proprietary specs. This explains a lot about what to expect from Sun in terms of standard support. I agreed when Sun used to say that standards are the best way to provide specifications that can be safely implemented, including by small companies and open-source projects (in financial terms, legal terms and control terms) and that this is a key promise of Web services. Simon Phipps (Sun’s chief technology evangelist) explained it well. But this was in year 1BC (Before Check). How things change.

Comments Off on Greg Papadopoulos on “collaborating” with Microsoft

Filed under Business, Everything, Standards

March 18, 2005

Kolkhoz to jungle

In a recent post on his blog, Mark responded to the critics who think that making WSDM 1.0 an OASIS standard was premature. Go read his entry for the point by point refutation of the arguments against WSDM standardization (which, based on this entry, doesn’t seem to quite convince Savas). The key point I take away from Mark’s reply is that it is ok for people to say that they think a condition for being a standard it to be entirely based on approved standards, but this is not the only view of the world. As Mark pointed out, it’s doubtful that the OASIS organization would have just “forgotten” to mention this in its bylaws and process if that was its intent. Those of us who welcome WSDM as a standard take the view that this requirement is too strong and the real requirements are that the spec is implementable in an interoperable way, that it is royalties free and that it addresses an industry need.

I respect the opinion of those who would have rather waited for WSRF, WSN and WS-Addressing to be standards for WSDM to ship as a standard. The thing is, if this is very important to them they do not have to implement WSDM right now. They can wait. And the fact that WSDM 1.0 was released ahead of WSRF, WSN and WS-Addressing doesn’t mean that the version of WSDM that the “wait and see” crowd wants to see won’t arrive. In fact, the WSDM TC is committed to updating the specs when these dependencies reach standard status. It will just be called WSDM 1.1 or WSDM 1.5 or WSDM 2.0 or WSDM IsOracleHappyNow Edition (yes I should be in marketing). People who don’t have an urgent need for a Web services-based management infrastructure can very reasonably decide to wait until then. The fact is, many people have this need now and they need the best standard they can get. DMTF is not waiting to provide Web services access to CIM-modeled resources. GGF is not waiting to manage Grid resources. Devices vendors are not waiting to Web services-enable their products. The JCP is not waiting to provide a Web services interface to JMX for app management (see JSR 262). And those are only broad industry segments, not specific customers who want to build an adaptive infrastructure. These are the people that WSDM 1.0 is trying to help. If you don’t have the need then yes you might rather wait for a better later solution. But let’s respect those who have the need. We worked hard in WSDM to come up with the best compromise for the present time.

Which takes me back to the title of this entry. The Kolkhoz approach to standard is what I see as the claim that the entire stack accross all standards organization has to be completly clean at any point in time. Nice but really hard to do in the environment we live in. And with a high risk to result in proprietary solutions taking over long before anything useful comes out as a standard. On the other side of the spectrum, there is the jungle approach, where de-facto standards rule or where specifications are written by a group of people who are only looking for rubber-stamps from standard organizations. What we are trying to do with WSDM is find the right balance between kolkhoz and jungle. This is why for example we make use of specs that are not yet standards but being standardized but we stay away from specs that are not even in the standard process even though sometimes it might be technically tempting to use them (think policy and metadata). To the jungle people, we are too slow and too committee-driven which they love to sneer at. To the kolkhoz people we are barbarians who trample the rules and processes and they love to stone us for it. We don’t try to be heroes to either, we try to be heroes to the customers.

1 Comment

Filed under Everything, Standards

March 16, 2005

The documents that compose the WSDM 1.0 OASIS standard

Before writing about the final approval of WSDM 1.0 as an OASIS standard I was waiting for all the documents to be posted at the official and final URLs on the OASIS web site. But this seems to be taking a long time for the OASIS webmaster to do, so here are the links to the documents in the OASIS repository. These are the exact documents that have been approved as standards and these links are not going to stop working, it’s just that they are not the nice and user-friendly URLs at which the specs will eventually be available. For example, http://www.oasis-open.org/committees/download.php/11819/wsdm-muws-part1-1.0.pdf (the URL corresponding to MUWS Part 1 in the OASIS repository) is not as nice as http://docs.oasis-open.org/wsdm/2004/12/wsdm-muws-part1-1.0.pdf (the official URL at which the same document will soon be available).

Anyway, here are the documents that compose the WSDM 1.0 specification:

In order to help implementers, stand-alone versions of the XSD, WSDL and event XML files are available at the URLs that correspond to their namespaces:

A great source of information about WSDM is the WSDM page on HP’s Dev Resource site, including the “WSDM wisdom” articles (the first article is about discovery of resources) by Bryan who is also the editor of the WSDM primer so you can look forward to more clear explanations and examples when the primer comes out. Our fearless and inspiring TC chair Heather also provides a very good introduction to WSDM on the IBM developerworks site.

More about the discussions that took place during and after the vote in the next post…

Comments Off on The documents that compose the WSDM 1.0 OASIS standard

Filed under Everything, Standards

March 2, 2005

Resource discovery with WSDM MUWS

Bryan has just published an article describing options for discovering resources using WSDM MUWS. A highly recommended read.

2 Comments

Filed under Everything, Standards, Tech

February 25, 2005

The mnot standard geek index

Sometimes Amazon scares me. Last night I was browsing the site looking at some novels (nothing whatsoever to do with technology) and here is what I see on the left side bar: a suggestion for an advice list called “So you’d like to… be a standards geek” by an Amazon user called mnotting who of course turns out to be Mark Nottingham. The scary part is that I know for a fact that I wasn’t logged on the Amazon site and there was no Amazon cookie on my disk. So either this was a complete (and unlikely) coincidence or Amazon uses the not-so-dynamic IP address provided by my DSL provider to try to recognize me. And even then, my Amazon profile clearly flags me as someone interested in technology among other things, but I don’t see how it would flag me as a standards person unless it reads my email…

In any case, this tempted me to measure my level of standard geekiness and the result is that I rank a 3 out of 8. To get to this ranking, I only looked at the list of books. I ignored the travel gadgets such as battery chargers and cell phones because there are so many of these that the chance of having a match is pretty slim (my personal recommendation for those who work a lot in airplanes is a Tablet PC).

So, focusing on the books, my three points on the mnot standards geek index come from:

  • Machiavelli’s “The Prince”. I read it in French but I assume it still counts.
  • Robert’s Rules of Order. I can’t say I read every single page but I’ve browsed it enough to know where to looks for things. I received my copy (in a different edition than Mark’s) from the hands of OASIS’ Jamie Clark when the WS-Notification Technical Committee was created that I co-chair with Peter Niblett.
  • TBL’s “Weaving the Web” of which I talked in a previous blog entry (BTW Mark you might want to check the URL you provided for this book in your list, it is incorrect and causes Amazon to not list this book in the recap of all products you recommend).

I don’t really know what to think of my score of 3/8. So I’d like the other standards geeks out there (Chris, DaveC, DaveO, Glen, Jeff, Marc, Mark, Gudge, Sanjiva, Jorgen, Tom and many others) to take the test and report their results so I know how serious my case is.

2 Comments

Filed under Everything, Off-topic, Standards

February 17, 2005

Services vs. Resources: the WSDM case

In an SOA, a service should not be tied to the resources that allow the service to be delivered. WSDM MUWS closely ties services with resources and in doing so it does not violate any SOA principle. I will show in this entry that these two sentences do not contradict each other.

Resources come and go and creating information systems that directly connect resources to one another results in brittle systems that don’t scale. Service-orientation, when well used, addresses this problem. Many have said this better than me before, like Jim: “Web Services are about hiding resources and exposing processes which operate on those resources”.

WSDM MUWS exposes a ResourceId property and manageability capabilities that are specifically tied to a given resource. But this “resource” is not the resource that makes it possible to deliver the MUWS service. It is the resource that the service has been created specifically to represent. Let’s illustrate this by contrasting two examples:

Service1 is a storage service. The “operational value” of this service is to store data. The right way to represent Service1 is in a way that is separated from the resource (in this case a storage array) that is used to provide the service. The service should expose its capabilities in terms of reading and writing data, not in terms of what SCSI disks are used. So that tomorrow I can replace the storage array with another one (or maybe with two smaller ones) and, assuming I replicate data correctly, the users of my service will not notice the change. A basic example of service-orientation. Now let’s look at Service2. Service2 is a management service (in MUWS terms, a “manageability endpoint”) used to manage the storage array from the previous example. The “operational value” of this service is not to store data in the array, it is to manage the array. And not any array, this specific array seating in my machine room. The resource used to provide the service is the Web services engine in which Service2 runs and whatever mechanism allows it to manage the storage array. In this case too, Service2 should be exposed in a way that is independent from the resource(s) that it relies on (like the Web service engine it runs on). But having it not be tied to the storage array makes would negate the very value this service provides, namely to manage a given storage array.

Of course in some cases it makes sense to embed the manageability endpoint inside the resource being managed in which case the resource being managed is also the resource that provides the service. But this is a corner case and in no way something requested by MUWS.

Separating the service from the resources that compose it is a good thing, but when the operational value of the service is exposed in terms of specific resources it is fine to explicitly attach the service to the resource. When deciding whether it is ok to let a resource show through a Web service, one needs to clearly understand whether it is a Service1 or Service2 type of situation.

Comments Off on Services vs. Resources: the WSDM case

Filed under Everything, Standards, Tech

February 16, 2005

Vote for approval of WSDM 1.0 as OASIS standard

The vote has now started to approve WSDM 1.0 (both MUWS and MOWS) as an OASIS standard. The vote will close at the end of the month and this is a short month, so don’t waste any time to make sure your company casts its vote.

Comments Off on Vote for approval of WSDM 1.0 as OASIS standard

Filed under Everything, Standards

February 9, 2005

WSDM and WSRF progress in Apache

The Apache Muse and Apollo teams put out their first releases today:

Congratulations to the teams! Looking forward to the interop sessions.

Comments Off on WSDM and WSRF progress in Apache

Filed under Everything, Implementation

February 4, 2005

First we think the Web is HTML; then HTTP; then we realize it’s URL.

As I was sitting in my car listening to KQED on the way back from work and I recently remembered an interview of Tim Berners-Lee by Terry Gross on Fresh Air that took place in 1999. TBL was promoting his book, Weaving the Web. At that time I was very familiar with Web technologies (first Web site in 1994 and I had been writing Web applications as CGIs more or less non-stop since 1995) but I hadn’t realized that the URL was the key building block of the Web, way ahead of HTTP and even more ahead of HTML. I don’t think I had ever asked myself the question, but if I had I would probably have sorted them backward. Hearing TBL in this interview describe how, before the Web, people would create small files that described where to find information in a human-readable way (I assume it must have been something like “telnet to this machine, use this logon/pwd, go to this directory, start this application, load this file”) really made me understand the importance of this URL thing I had taken for granted for many years. To this day I vividly remember this interview and the Eureka feeling when I realized the importance of URLs as an enabler for the Web.

I don’t know if the fact that this interview, which was targeted at the general audience of Fresh Air (more used to hearing Jazzmen interviewed than geeks), taught a Web-head like me something important is a testament to TBL’s vision, Terry Gross’ skills as an interviewer or my stupidity for not having grasped such a basic concept earlier.

Going back to WS-Addressing EPRs for a minute, what I was thinking recently is that these EPRs look a bit like the old “do this, do that” files that TBL talked about and that were replaced with URIs. Where “do this” becomes “put this header in your SOAP message”. Unlike the “do this” files, the instructions in the EPR can be machine-processed and that’s a key difference. But still, I can’t help getting this deja-vu feeling. Not that I have ever encountered these “do this” files myself but TBL made me see them one day in 1999.

[UPDATED 2011/9/27: Before pointing to this piece on Twitter (in response to this post by Joe Hewitt) I just have to change the awful title (for the record, the original title was “Thinking about EPRs like Proust”; yeah, I know). Whenever someone uses “la petite madeleine” (or Schrödinger’s cat for that matter) to illustrate a point you know it’s going to suck, so I removed it. And while I’m at it, I am replaced all the references to “URI” by “URL” which is less pedantic (and more accurate in this context). There. I usually don’t like to edit old entries, but this one was so bad it made almost no sense (not to mention the fact that no-one cares much about EPRs anymore).]

1 Comment

Filed under Everything, Standards, Tech

February 3, 2005

Identity crisis averted

As reported by Marc, the current draft of WS-Addressing has been cleaned by removing the suggestion that EPRs are meant to identify endpoints rather than just “convey the information needed to address” them. As I wrote earlier, Part 1 of the WSDM MUWS specification offers a fine mechanism for identity to anyone who needs one.

Comments Off on Identity crisis averted

Filed under Everything, Standards

February 2, 2005

WSDM moving towards OASIS standard

WSDM 1.0 has been submitted to become an OASIS standard. As Jamie explains in his email, this means that OASIS members have until the middle of the month to familiarize themselves with the specs (MUWS Part 1, MUWS Part 2, MOWS). The vote will start on February 16th and if all goes well WSDM will be an OASIS standard by the end of this month. So make sure to read the specs and talk to your OASIS representative if your company is a member. For this small effort, you get to tell your grand children in 30 years “I was one of those who made the world a better place by making WSDM 1.0 an OASIS standard” and watch they eyes widen in amazement and pride.

Comments Off on WSDM moving towards OASIS standard

Filed under Everything, Standards

January 28, 2005

To prevent intrusion, pull the plug on your server

There is a new WSDL validation tool on IBM’s AlphaWorks site: the Web Services Interface Definition for Intrusion Defense. This is an Eclipse plug-in that checks out your WSDL and flags “any interface feature that could open a door to hacker attacks”. What does it mean in practice? Well, it flags any usage of xsd:any (or xsd:anyType or xsd:anySimpleType) anywhere in your schemas. It also complains if you have elements with maxOccurs=”unbounded”. And more of the same. The result is that this excludes pretty much any existing schema definition. And most of the useful ones one can think of.

The payload of XML messages should reflect the business logic of the service and not the convenience of the implementer. Go tell the line of business manager that the “checkout” operation should be modified so that the number of items in the shopping cart has a hard-coded limit. Go tell the print shop that they can’t accept XHTML documents as input. It is the implementer’s job (and by that I include the runtime, IDE and tools) to make sure the message processing code (be it at the plumbing level or the business level) doesn’t expose security holes.

Comments Off on To prevent intrusion, pull the plug on your server

Filed under Everything, Security

January 24, 2005

Reference properties are gone. Yawn…

The removal of reference properties (see WS-A issue #1) from the WS-A specification is a non-event. Today, most implementations and specs that use WS-Addressing are based on either the March 2003 or the March 2004 version, both of which have only one echoing mechanism, called “reference properties”. And, if they use it right, these specs and implementations don’t use the reference properties for identification, they just use the EPR as a pointer which happens to use an echoing mechanism (most of them don’t even care about the echoing mechanism and whether it is used). For these people, there is no change resulting from the removal of reference properties, other than just replacing the name “reference properties” with “reference parameters”.

The only place where there is a choice between two mechanisms (properties and parameters) is in the August 2004 version, the one submitted to W3C. Newer specs (like WSDM MUWS 1.0) reference this version because it has a few clarifications and because it feels more comfortable to use a reference residing on the W3C’s site (even though it doesn’t mean anything in the case of a member submission). But I am not aware of any implementation or spec that uses the August 2004 version and takes advantage of the difference between reference properties and reference parameters. For example, WS-Management makes use of both constructs but I don’t see how anything in WS-Management would stop working if all its reference properties were transformed into reference parameters and/or vice-versa (for example, why does wse:Identifier need to be a reference parameter rather than a reference property?). Once again, the removal of reference properties is not a change to WS-Addressing, it is just the end of a little escapade into the exciting world of inventing unnecessary semantics.

Comments Off on Reference properties are gone. Yawn…

Filed under Everything, Standards, Tech

January 22, 2005

@wsa:type=”parameter” instead of

Eager to prove wrong those who have a hard time picturing a January face to face meeting in Australia as little more than an excuse for some scuba diving, the WS-A working group is cranking through its issues list. One of the outcomes is that issue #8 is now resolved. The issue is about identifying which headers in a SOAP message are there because the EPR used to address the SOAP message required it. This problem is familiar to anyone who has ever been the victim of the common joke that consists in tricking someone who doesn’t speak a certain language into memorizing and later repeating a sentence in that language while misleading them on the meaning of the sentence. And waiting for them to embarrass themselves in public at the worst time.

The group closed this issue by introducing an attribute that can be added to these headers (wsa:type). Yes, the world really needed another type of “type”. BTW, the resolution will need to be tweaked as a result of another decision: issue #1 was resolved by getting rid of reference properties, leaving only reference parameters. More on this in a future post, but at least this gives an opportunity to replace wsa:type=”parameter” with wsa:parameter=”true” and avoid yet-another-type.

Going back to issue #8, I am glad the group somewhat acknowledged the problem but this doesn’t solve it. For two reasons:

  1. The schema of the header element might not allow this attribute to be added
  2. Even if the attribute is present, the recipient of the SOAP message can pretend to not understand it (“I don’t care about this attribute and all the other WS-A crap, all I know is that you sent me the ‘I owe you $1,000’ header and you signed it so now pay up!”)

    The way to solve both of these problems was to create one additional SOAP header (in the WS-A namespace) that could be marked mustUnderstand=”true” and points to all the headers in the message that are there because “the EPR told me so”. I proposed this (the wsa:CoverMyRearside approach) in the one and only message I have sent to the WS-A WG, but obviously I wasn’t very convincing. Since I don’t participate in the WG I might never understand what is wrong with this approach. What really surprises me is that it wasn’t even considered. The issues list shows only 3 proposals but the minutes of the face to face show that there was a 4th option considered, which comes a bit closer. Basically, it is the same as the adopted solution with the addition of a WS-A-defined header (that could be marked mustUnderstand=”true”) which states that “by processing this header you agree that you understand the wsa:type attribute when present in other headers”. This is not very elegant in my mind and doesn’t solve (1) but it does solve (2).

    Interestingly, even though the wsa:CoverMyRearside header approach was not chosen by the WG, nothing stops me from using this approach: I can defined and use a header in my namespace that I’ll mark mustUnderstand=”true” and that will point to the headers that are there only because “the EPR told me so”. The problem of course is that my namespace is not going to be nearly as well-known as the WS-A namespace and most people will fail on processing my messages because it contains a mustUnderstand=”true” header they do not understand. So in practice I can’t do this. That being said, I wouldn’t be surprised if some spec somewhere one day decided that the mechanism in WS-Addressing is not good enough and that they should take on the task to define such a header because they need this protection.

    Comments Off on @wsa:type=”parameter” instead of

    Filed under Everything, Security, Standards, Tech

    January 21, 2005

    IBM roll (of eyes)

    Maybe the reason why IBM is getting out of the PC business is to focus on the next growth opportunity: sushi. This week, the WSDM face to face meeting was hosted by IBM in Boulder, CO. We had lunch at the cafeteria there and discovered that they sell an “IBM roll” in the sushi stand (Richard if the picture with you camera phone works out please email it to me). In case you are wondering, an “IBM” roll is made of eel, cucumber and avocado. And yes, it is the most expensive of all rolls ($3.49 for 4 instead of $3.19). Insert your own joke about the sushi coming with high-priced IBM consultants to help with the chopsticks…

    [UPDATE: Turns out the IBM cafeteria is not the only place where you can get an “IBM roll”. If you are a visitor without a knowledgeable host in the Bay Area you might end up at Miyake in Palo Alto where you’ll see floating boats boasting Miyake’s version of the “IBM roll”. Not sure if this is coincidence or not, but the composition is actually very similar to the one found in the IBM cafeteria: “unagi, crab stick, avocado, cucumber”. They just add crab (and bad music I was told).]

    Comments Off on IBM roll (of eyes)

    Filed under Everything, Off-topic

    December 22, 2004

    From UPS to EPR

    A packaged was shipped to me through UPS. As usual, I received an email message informing me that it had shipped and giving me a URI to track its progress. This is what the URI looked like (after changing the tracking number and inserting a few line breaks):

    http://wwwapps.ups.com/WebTracking
    /processRequest?HTMLVersion=5.0&Requester=NES
    &AgreeToTermsAndConditions=yes&loc=en_US
    &tracknum=123123123123

    The interesting thing to notice, is that there is a parameter in the URI, called “AgreeToTermsAndConditions” and its value is set to “yes”. If you do a GET on this URI, you will receive, as expected, the description of the status of the shipment. On the other hand, if you go to the UPS Web site armed with just the tracking number you have to check a box that reads “By selecting this box and the ‘Track’ button, I agree to these Terms and Conditions” before you can track the shipment. It seems pretty clear that the “AgreeToTermsAndConditions” parameter is in the URI in order to plug into the same Web application from the email link as from the Web page and this application was designed to check that the parameter is present and set to “yes”.

    This has several similarities with some of the discussions around WS-Addressing. First, it illustrates the need to plug into an application in a place where the application might not have been designed to allow you to do so. In this case, we can imagine that the tracking application was designed with the assumption that people would only invoke it from the UPS web site. One day UPS decided it would be nice to send in email a link that takes people directly to the status of a particular shipment rather than just tell them to “go to ups.com and enter your tracking ID in the tracking form”. One important reason for pushing back on the idea of wrapping reference properties is that it would prevent such a scenario in a SOAP world. For this reason I agree that a wrapper for reference properties is a bad idea and if reference properties remain in WS-Addressing the way to fix this mechanism is to leave them as SOAP headers but add a WS-Addressing-defined SOAP header to list headers that were added to a message only because an EPR requires it, with no implication that the sender stands behind any semantic that might be attached to them.

    When I write about “fixing” reference properties in the previous sentence, I am referring to the fact that the current version of WS-Addressing creates a lot of confusion as to the implications of sending SOAP headers and whether I can be held liable by anything that is in a SOAP header I send (and potentially sign). This is the second thing that this UPS URI illustrates by analogy. As a human I get a sense of what a parameter called “AgreeToTermsAndConditions” corresponds to (even though the URI doesn’t tell me what these terms and conditions are). But what if the parameter name was shortened to its acronym “ATTAC”? In any case, I am not expected to understand the composition of this URI, I should be able to treat it as opaque. Just like resource properties. And for this reason, when I do a GET on the URI I am not bound by whatever the presence of this parameter in the URI is assumed to mean by UPS. This means that I can NEVER be bound by the content of a URI I dereference because how can one prove that I understand the semantic of the URI. Even when I fill a form on a Web site, I don’t know (unless I check the HTML) how the resulting URI (assuming the form uses GET) will come out. There might well be a hidden parameter in the form.

    In a SOAP world, this can be fixed by meaningful, agreed-upon, headers. If people agree that by sending (and signing) a SOAP header you are making a statement, then you can build systems that can rely on the ability to make such statements as “I understand and agree to the set of terms and conditions identified by a given QName”. But this breaks down if people are able to say “I didn’t understand I was saying this, I was just echoing what you told me to say”. This is what the current WS-Addressing spec does, and what needs to be fixed. Let’s see how the UPS URI could translate to an endpoint reference. For this, we need to consider two scenarios, both of them equally valid.

    Scenario 1: legacy integration

    In this scenario, the UPS people decide they do not require the invoker to actually make a statement about the terms and conditions. They just need a SOAP header called “I agree to the terms and conditions” to be set to true because this is how their application is currently programmed (it will fail if it doesn’t see it). In this case, it is perfectly reasonable to put a “I agree to terms and conditions” element as a reference property and this element will be sent as a SOAP header, preventing the application from failing. But in order for SOAP headers to be used to make a statement in some cases, there needs to be a way to expressed when, as in this scenario, the invoker is not making a statement by including it. Thus my earlier proposal of a wsa:CoverMyRearside header (that points to all the headers I include for no reason other than because an EPR asks me to). The other option, as written down by Dims is to add an attribute in each such header. But there are two main drawbacks to this approach: (1) unlike a new SOAP header, I can’t mark an attribute “mustUnderstand=true” (Dims’ initial proposal actually had a SOAP header with “mustUnderstand=true” for this very reason) and (2) some elements might not allow arbitrary attributes to be added at the top level.

    Scenario 2: meaningful header

    In this second scenario, the UPS people want to make sure, before they return the tracking information, that the invoker has made a statement that it understands and agrees to the terms and conditions. In this case, it makes no sense to put a “”I agree to the terms and conditions” element as a reference property as what is intended is not for such an element to be echoed blindly but to be used to make an explicit statement. In this scenario, the EPR sent by UPS would contain all the opaque elements, those sent for the benefit of the UPS application but by which the invoker is not making a statement (from the look of the URI, this would be “HTMLVersion”, “Requester”, “loc” and “tracknum”). But the “agree to terms and conditions” header would not be specified as a reference property, it would be listed in the WSDL description of the service. And when the invoker sends this header, it would not be included in the wsa:CoverMyRearside header because the invoker is indeed making a statement by sending it.

    Comments Off on From UPS to EPR

    Filed under Everything, Security, Standards, Tech

    December 12, 2004

    WSDM open house

    Jamie’s email marks the start of the public review for WSDM MUWS 1.0 and WSDM MOWS 1.0. Note that when the OASIS webmaster gets around to it, the XML files will also be available at the URIs that correspond to their respective namespaces and the specifications will be available at consistent URIs (e.g. http://docs.oasis-open.org/wsdm/2004/12/muws/cd-wsdm-muws-part1-1.0.pdf for MUWS Part 1). But the links in Jamie’s email will keep working.

    Comments Off on WSDM open house

    Filed under Everything, Standards

    December 11, 2004

    Natural selection favors Tablet PC owners

    When I got my Tablet PC (an HP tc1100) I was interested in the form factor, the ability to take hand-written notes and the ease of reviewing documents in cramped spaces, like an airplane seat. But I just learned that the fact that the keyboard stays cold (because the disk and the CPU are behind the LCD screen) has an additional advantage I hadn’t thought of.

    Comments Off on Natural selection favors Tablet PC owners

    Filed under Everything, Off-topic

    December 7, 2004

    WSRF/WSN overview

    For those who would like a short introduction to WSRF and WSN, there is a new one on HP’s DRC site based on presentation I gave a few months ago. Thanks Chris and Kathleen for putting this up.

    Comments Off on WSRF/WSN overview

    Filed under Everything, Standards, Tech