Hello Assaf et al: >There are a lot of services out there that are interesting to support, some >more RESTful than others, although many people lump them all in the REST >category. I prefer to use the term Web Architecture Services. Web >Architecture Services[1] are good netizens, they take from the Web >(principles, technology) and give back to the Web (resources).
... >So while it's true that we can identify coding patterns that will make HTTP >resources accessible in WS-BPEL 2.0, and work hard to retrofit BPEL and WSDL >abstractions to the simplicity of URLs and HTTP, I think that would be doing >a disservice to the community at large. Our duty is to tune WS-BPEL to the >best practices and compelling advantages of the Web Architecture. Yes, we don't live in a one-size-fits-all Web Architecture" universe - there will be a variety of web service approaches for the foreseeable future. In terms of implementation, this will mean ones WS-BPEL processors architecture will need to accommodate multiple (for lack of a better term) message-exchange-passing systems. I am interested in supporting RESTful messaging systems to allow my WS-BPEL implementation to consume a wider range of web services. I am interested in using service-ref because: 1) This is the mechanism in WS-BPEL for incorporating different MEP systems. I view service-ref as a design requirement. 2) I believe a partnerlink EPR is sufficiently abstract so it can readily represent a URL (your concern about verbosity notwithstanding). 3) I believe using service-ref, as opposed to extending activities, offers a greater chance at the programmatic level, to treat partnerLinks in a uniform and hence, cleaner manner (this remains to be seen). 4) In testing scenarios that involve sticking close to the specification, there is a better chance of exposing problems in the WS-BPEL 2.0 specification. 5) Other WS-BPEL implementers will probably be much more willing to incorporate REST support, and collectively develop ( between themselves and web service producers) best practices if they see a successful implementations that remains faithful to the specification. Perhaps prototyping may reveal that it is a tough hack to put REST into WS-BPEL without twisting the WS-BPEL 2.0 specification out of shape. A part of the price of admission - prototyping - is seeing how the specification gets bent out of shape. Cheers, Andrew
