ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Support for REST-based services
Date Sun, 13 Jan 2008 02:22:04 GMT
On 1/12/08, Andrew Francis <andrew.francis@mail.mcgill.ca> 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

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.


[1] http://www.w3.org/TR/webarch/

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message