Category Archives: Everything

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

    December 3, 2004

    Let’s try it, if all goes well it will fail

    I am a bit confused about the attempt of the credit report companies to “protect the link” to the new site where one can get free credit reports (see the bottom of this article). I understand the problem of phishing and I agree that this site will be a very tempting target for phishing. The “solution” the people at annualcreditreport.com came up with is that links to their site won’t work unless the link is either on the FTC web site or one of the three credit report companies. For example, try clicking here and it should give you an error. This is presumably done by checking the “Referer” HTTP header. Yes, it’s “referer”, not “referrer”, an example of how authors of Web browsers are normatively required to make spelling mistakes, this should keep all of us spec editors on our toes (which, as a side note, happens to be literally the case for me this week because I slammed my heel on the edge of the swimming pool by doing an aggressive flip turn a bit too close to the wall during a Master’s swimming training session).

    Anyway, back to the “protect the link” story. Let’s see how this would work. I have in front of me a hypertext link to their site. If I know that the site has this “protection” then why would I click on it? If it works then it’s a fake and I don’t want to use it and if it’s not a fake then it won’t work. In any case I know I’ll have to enter the URL by hand so I’ll do it right away. And if I am not aware of this behavior then I will click on the link. If it works (because the link is a fake), then I have no reason to suspect anything fishy and I’m in trouble. If it doesn’t work (because the link is real) then I’ll see that I have to enter the URL by hand and I will be out of trouble but I wasn’t in trouble to start with since the link was correct. In either of these four permutations this system doesn’t do any good.

    The scary thing is that when people learn about this system, they might actually be more trustful with sites that implement something like this. But what stops a phishing site from doing the exact same thing, giving people an error message unless they type the URL by hand? Nothing. This reminds me of an email I once got from my bank to “educate” me about phishing. With “helpful” advice such as “we will never request personal information from you until after you are logged into our site using your username and password”. Hello? I give them my credentials and this supposedly authenticates them to me?

    Comments Off on Let’s try it, if all goes well it will fail

    Filed under Everything, Security

    December 2, 2004

    Just on time for the Christmas tree

    I must admit I was embarrassed to link to a copy of MUWS which was (1) a Word document and (2) covered with change tracking annotations in my previous post. Kind of like having friends or neighbors drop by when your laundry is spread out on the living room floor for folding. Well, now there are better links available to clean PDF versions of WSDM MUWS Part 1 and WSDM MUWS Parts 2. Note that these are still working drafts, they haven’t been approved by the technical committee yet. But the vote is currently open (for a week) and these are the versions that the committee is expected to promote to Committee Draft. Next step, OASIS standard…

    Comments Off on Just on time for the Christmas tree

    Filed under Everything, Standards

    December 1, 2004

    That’s not an identifier. THIS is an identifier (say it with a Crocodile Dundee accent)

    I already explained that I agree with Paco’s view that EPRs are not identifiers. Pankaj also provided a concrete example of why confusing references and identifiers causes problems. Paco just sent a new, better explanation of his earlier point, in the format of a formal proposal to the WS-Addressing WG. His proposal and its justification are a must read. He starts with a “what is required from an identifier” paragraph, which reads:

    An identifier to be useful must allow meaningful comparison for identity or “sameness”. This requires them to overall unique and unambiguous, otherwise no meaningful comparison is possible. Moreover one could argue that to be really useful identifiers should not be reused once they’ve been made invalid.

    Compare this with the specification for the ResourceId property defined in MUWS Part 1 (note: this is a link to the current working draft as a Word document, not yet a committee draft). Some highlights that match very well with Paco’s expectations for a *real* identifier:

    • Globally unique: A manageability endpoint MUST create the ResourceId URI in a way that ensures that the ResourceId is unique to the resource managed through the manageability endpoint and globally unique.
    • Uniqueness in time: A ResourceId MUST NOT be reused by the implementation of a manageability endpoint for another resource, even after the original resource no longer exists.
    • Consistency across endpoints: An implementation of a manageability endpoint SHOULD use a ResourceId that is suggested by the characteristics of a resource.

    And the spec goes on to define in more details why/how implementers should ensure that difference manageability endpoints for the same resource return the same ResourceId, persistence of the ResourceId in time and how to establish “sameness” when for some reason different manageability endpoints for the same resource are unable to return the same ResourceId (correlatable properties). Go ahead and read it or wait a couple of weeks if you want to see a committee draft as a clean PDF rather than a Word document with change tracking turned on.

    Comments Off on That’s not an identifier. THIS is an identifier (say it with a Crocodile Dundee accent)

    Filed under Everything, Standards, Tech

    November 24, 2004

    Feeds and feedback

    I got a few requests for syndication URLs for this blog, so here is where you can find them: http://devresource.hp.com/blogs/vambenepe/viewFeeds.action. Four of them to choose from! But I have to agree that one URL that can be found on the page beats four that can’t be found… No good reason why this wasn’t on the page by default and it should be fixed soon. In the meantime, you now know where to find them if you hadn’t yet guessed (like many did and Bloglines seems to do by default) that adding “rss.xml”, “rdf.xml” or “atom.xml” at the end of the blog URL was worth a try.

    The sad thing is that there wasn’t really a way to let me know of that problem (lack of feed URL) either since this blog doesn’t currently support comments (should be fixed soon) and doesn’t even provide my email address. Not that my address is hard to find on Google since my last name is not common. But, in the interest of rich metadata it should still be available on this blog (doesn’t this fit well in the much-quoted discussion between Adam “just Google it” Bosworth and Marc “give me metadata or give me death” Canter?). So, until it is available permanently on the page, here is where to send feedback: vbp@hp.com.

    The paint is still fresh…

    [UPDATE: the blog has since moved and these URLs are not correct anymore. The RSS feed is now at https://stage.vambenepe.com/wp-rss2.php]

    Comments Off on Feeds and feedback

    Filed under Everything, Off-topic

    November 24, 2004

    Globus toolkit in Apache?

    As Savas already noted (and commented on), Globus seems to intend to contribute all of their toolkit to Apache (warning, this is a link to a Word doc). This follows an earlier co-submission, between HP and Globus, of the WSRF and WSN implementation. It will be interesting to see how the Web services project at Apache scales up with all these contributions.

    Comments Off on Globus toolkit in Apache?

    Filed under Everything, Implementation

    November 23, 2004

    Whose policy is it anyway?

    Greg recently posted an interesting article on what’s ahead of us in terms of really using policies in conjunction with Web services. I agree with him that the interesting question is not in “features and properties” versus WS-Policy. Whether you use one, the other, or a combination of the two you’ve still barely scratched the surface. I also agree that policies should not be tied with WSDL descriptions (a problem of F&P). But a key thing I would add to Greg’s list of what people need to be able to do with policies is define more precisely what “components” of the architecture policies are attached to. Yes, the “service” component is not sufficient as policies can be attached to more granular or less granular levels. But what are these levels? Who defines them? How do we come to agreement on them?

    WSDM MUWS 1.0 Part 1 (coming in December) will define such basic components as “property”, “operation” and “event” that can have policies attached to them. These are components that are more granular than a “service” or an “endpoint”. Then you have relationships (defined in MUWS Part 2) that can also have attached policies. And you can have policies applied at a higher granularity level than the service, for example at the level of a business process made up of several services. Who will define these components?

    Once we have these policy-capable components defined, we can go back to Greg’s question about attaching policies to them. “Multiple methods of association”, as he suggests, is one possible approach. Another way is to make more daring (shall we say) usage of existing addressing methods. For example the way WS-Management does it in its section 3. But this comes at the cost of throwing down the drain the benefits associated with opaque reference properties in WS-Addressing. Is it worth it? Any other alternative?

    Comments Off on Whose policy is it anyway?

    Filed under Everything, Standards, Tech

    November 22, 2004

    32K ought to be enough for everyone

    A couple weeks back I had to spend time moving my Outlook local folder file (the *.pst) from where it was by default (somewhere like “c:documents and settingsusernamelocal settingsapplication datamicrosoftoutlook”) to “c:mail”. And I also had to rename my rules (e.g. from something like “WSDM mailing list” to “w1”). And to merge several rules into one (so for example now all emails from ws-i.org go to the same “WS-I” folder, I can’t have one subfolder per working group anymore). That took some time (both to figure out what I needed to do and to make the changes) and left me less productive than before (non-descriptive rule names make them harder to manage and I have lost some granularity in the filtering by consolidating filters). Aren’t outlook rules supposed to make you more productive rather than less?

    So why all the trouble? Simply because Exchange says all your rules have to fit in 32K. So it’s ok to have a endless signatures with quotes form other people (that somehow prove that you’re smart) or contact info for your kid’s favorite party clown. But rules, despite being vital to managing the flood of incoming email when you subscribe to several mailing lists, only get 32K.

    The most infuriating aspect is that I can’t figure why that is. The rules I use are stored on the server but executed on the client. Clearly it can’t be a matter of storage space on the server. It stores dozen of megabytes of email for me. Turning 32K into 1MB would make little difference. And I’d be happy to settle for a tiny bit less email space for some badly needed rule storage space. It can’t be because of computing resources to execute the rules either. They run on my client machine, not on the server. And my 32K turn into less than 20 rules. Surely, 20 simple rules (the typical rule is “if this comes from mailing list foo put it in the foo folder”) can’t overwhelm my machine. And if they do, let me decide whether it’s worth it to me or not.

    Of course this is all the fault of the WS-Addressing WG. I had postponed making the needed changes because of lack of time, but the crazy traffic on the Ws-Addressing mailing list forced me to make room for another filter. So emails could be properly dispatched to the right folder. Ironically, this is for an addressing specification. My take-away is that if Microsoft is only going to give us 32K to dispatch SOAP messages with WS-Addressing header (like they decided to do for email) then I don’t understand why they are so fond of reference properties and reference parameters. Hopefully Don won’t let the Exchange architects anywhere near Indigo. ;-)

    Comments Off on 32K ought to be enough for everyone

    Filed under Everything, Off-topic

    November 21, 2004

    WS-Management feedback workshop

    The tireless Jorgen is organizing another feedback workshop. Actually, this time they’re packing two in one session. There will be one for WS-Management and one for WS-Transfer and WS-Enumeration. All that in one day, it’s going to be hard if there is a lot of feedback provided. Which may or may not be the case… But in any case, this session is good news for everybody.

    While I’m at it, I thought I’d mention that WSDM holds a “feedback workshop” every Thursday from 9AM to 11AM Pacific time and 24/7 on the mailing list of the technical committee…;-)

    Comments Off on WS-Management feedback workshop

    Filed under Everything, Standards

    November 17, 2004

    More on WS-Addressing EPRs

    After an email exchange with Anish about my previous blog entry I would like to clarify what I wrote on Sunday. I agree that EPRs can be used as identifiers. Just like phone numbers. For example, a specification could require that the Reference Properties be constituted of the element, in effect making the EPR an identity representation by virtue of containing one. And this is fine.

    My point is not that this should not be done, it is that the WS-Addressing working group does not need to concern itself with, or even acknowledge this usage of EPRs. The Ws-Addressing working group should concentrate on producing an XML element to package the information necessary to invoke a Web service endpoint. This is what is asked of it. Considering whether and how this can be used for identity consideration is at best a waste of time and at worst a source of unneeded complexity and formalism. Keep it simple.

    Note: the most alert readers will have noticed that the prefix of the namespace for the MUWS ResourceId element has changed between my entry on Sunday and this entry from “muws-xs” to “muws-xs-1”. Looks like a detail but this is a sign of an important and very cool improvement that was decided by the WSDM TC today. I am implementing this change in the MUWS spec right now (this blog entry is my little “pause” from the editing work, scary as it sounds). Stay tuned for more. WSDM 1.0 is coming soon to a printer (and a JVM) near you.

    Comments Off on More on WS-Addressing EPRs

    Filed under Everything, Standards, Tech

    November 14, 2004

    WS-Addressing EPRs are not identifiers

    I haven’t yet decided whether to join the WS-Addressing working group at W3C and I must say that the deluge of emails going on over there doesn’t do anything to alleviate my main fear about joining the group, i.e. that it will suck a lot of time. Just as I am trying to free more time to work internally on architectural issues related to the MAE (Management for the Adpative Enterprise) effort rather than externally, in standards bodies. But I am monitoring the mailing list of the WS-Addressing working group as what happens to the EPR concept is important to many specifications I am involved with, such as WSDM, WS-Notification and the WSRF patchwork. And it’s always interesting to read what the smart people involved in this discussion have to say. It feels like the Web services communitty has been waiting for an opportunity to have this discussion for a long long time.

    One thing that is clear to me after using EPRs for a while is that they are not meant to be identifiers, just references. Their only goal is to tell you how to talk to an endpoint. Francisco Curbera hits the nail on the head in this email message. Identifying endpoints and whatever it is that they represent is a different thing altogether and not in scope for WS-Addressing. It is in scope for management applications of Web services and this is exaclty what WSDM MUWS (Management Using Web Services) provides through the muws-xs:ResourceId property, along with (optionally) the “correletable properties” capability.

    Other issues that the WS-Addressing group now has to deal with include usage of Reference Properties (and especially how they get mapped to SOAP headers) and what Reference Parameters are good for. Those got slipped into the version of the spec submitted to W3C and were not available to us when designing WSDM, WSN and WSRF. Not that we would necessarily have used them anyway. Another issue that hasn’t yet showed up on the WS-Addressing mailing list is whether it is appropriate for someone to modify EPRs it receives if there is some “out of band” understanding of how they are built. My guess is that the group will punt on that one (which is reasonable) but I am looking forward to the discussion and will raise this question if no group member does. I might write more on some of the topics in this last paragraph in later entries.

    Comments Off on WS-Addressing EPRs are not identifiers

    Filed under Everything, Standards, Tech

    November 9, 2004

    Building blocks of an “adaptive enterprise”

    Call it “laziness” or “smart reuse”, here is a pointer to a Web services journal opinion piece I wrote a few months back in an attempt to explain how the different efforts going on in the industry around Web services, grid, SOA management, virtualization, utility computing, <insert your favorite buzword>, fit together to provide organizations with the flexibility and efficiency they need from their IT in order to thrive. This is how it starts:

    Enterprise services are created by combining infrastructure services, applications, and business processes. To be able to adapt quickly to business changes, enterprise IT must evolve from management of individual resources to management of interrelated services. [more…]

    1 Comment

    Filed under Articles, Business, Everything, Tech

    November 9, 2004

    Can you hear the muse?

    Check out this proposal. It brings three new incubator projects to the Web services activity in Apache. And they come with working code.

    The projects are:

    • Muse, an open source implementation of WSDM MUWS. With existing code contributed by HP.
    • Apollo, an open source implementation of the WS-ResourceFramework (WSRF) specifications. With existing code contributed by HP and Globus.
    • Hermes, an open source implementation of the WS-Notification specifications. With existing code contributed by HP and Globus. You’ll also notice in the description of this project that it includes support of WS-Eventing (but this is not included in the contributed code).

    Comments Off on Can you hear the muse?

    Filed under Everything, Implementation