On 1/12/08, Andrew Francis <[EMAIL PROTECTED]> wrote: > > Hello Alex et al: > > >Looking into my crystal ball and speaking just on behalf of resources > that > >Intalio supports, I would say it would materialize sometime during the > >summer of 2008. If more people want to join the party and/or provide > >additional financial support, we could get it out faster! > > >Related to that, technical feedback on the specs that have been posted > would > >be most welcome: > >http://ode.apache.org/restful-bpel-part-i.html > >http://ode.apache.org/restful-bpel-part-ii.html > > I originally brought up the possibility of REST support in WS-BPEL with > Assaf in I believe, early November. I started preliminary prototyping in my > Stackless Python WS-BPEL engine. My main concern with Assaf's approach is > that I do not feel it is necessary to change the signature - rather the > service-ref element should be used. I think it is important to figure out a > general approach to supporting REST in WS-BPEL. > > I will be in a better position to comment after I test a few scenarios. > > Cheers, > Andrew > > 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).
I'm particularly interested in these RESTful, or Web Architecture Services, because they make development easier, whether its the simplicity of exposing and using these services, or the ability to tap into the vastness of the Web, that I just don't have the time to re-invent. Specifically, what I'm looking for are these three qualities: 1. Simplicity. They use simpler standards and eschew complex abstractions. For example, URLs are easy to work with, they're simple types that you can manipulate as strings (varchar in SQL); by comparison, WS-Addressing are complex types that require a WS-* stack to process (by dependency on WSDL). I'm a sucker for simplicity. 2. Consistency. They use common mechanisms instead of inventing ad-hoc solutions that are never implemented the same way. For example, using HTTP methods to distinguish between safe (GET), idempotent (PUT, DELETE) and neither (POST); or using status codes to distinguish between end-states like creating a new resource (201) and updating an existing one (200). Have a look at SaleForce's SOAP API and NetWeaver WS for two examples that re-invent the same functionality in two different and non-interoperable ways. 3. Scale. They use hypermedia to link resources together into a Web of infinite size. And in doing so, they favor a large collection of resources dispersed across servers, rather then overloading functionality into a small set of endpoints. A decade of SOAP will not yield a network of services as large as the Web was in its formative years, two decades ago. WS-BPEL was designed around WSDL, and WSDL itself was architected around the endpoint/RPC model, for good reason I would say, but it doesn't encourage or support these practices. In my experience, partnerLinks are only suitable as an abstraction for endpoints, but I would give them credit for being an exceptionally good abstraction for endpoints. On the other hand, I'm no fan of service-ref. I've seen it being rushed out without due technical consideration, the result of vendor politics to avoid discussing WS-Addressing at the WS-BPEL TC. In my opinion, it's not even an adequate technical solution for dealing with SOAP service composition, and should be a high priority bug to fix in WS-BPEL 3.0. By design, service-ref goes against everything I find appealing about the Web Architecture, adding unnecessary complexity(1) that is only used in one implementation (2), placing these services outside the hypermedia Web (3). Ironically, if you try and adapt service-ref to use resources, you end up going against the very nature of WS-BPEL. The most common hypermedia scenario is taking the URL provided by one resource and using it to act upon the resource denoted by that URL. That's what Representational State Transfer embodies. Doing so with WS-BPEL 2.0requires assigning an empty service-ref to a variable, assigning a URL to that service-ref, and assigning the result to a partnerLink, before invoking on that partnerLink. And all that just to deal with something as simple as a string (xsd:uri). Boilerplate code like this is painful to write, introduces new places for bugs to hide, obfuscates the process itself, and is clinically proven to induce change/maintenance nightmares in test subjects. WS-BPEL is a language for expressing processes, at a higher level of abstraction than Java or C. That is it's main benefit. It does that by being declarative, allowing you to articulate what the process does, not how it does it. Things like, "I will use the result of Foo to do something against Bar", are good BPEL. Complex patterns of pointer arithmetic is bad BPEL. And I didn't even touch on the issues surrounding HTTP method selection, tuning the process to different status codes, handling caching and redirects, or for that matter all the richness embodied in HTTP headers. All of that is elemental to the Web Architecture, but never dealt with in the confines of the WS-BPEL TC. 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. Assaf [1] http://www.w3.org/TR/webarch/
