ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Francis" <andrew.fran...@mail.mcgill.ca>
Subject RE: Support for REST-based services
Date Fri, 18 Jan 2008 17:30:31 GMT
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 one’s WS-BPEL processor’s 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.


View raw message