ROA is not SOA - (was Alternatives to WS Standards)

I agree completely, Paul. POX is clearly the significant alternative to
SOAP, and REST only has as much mindshare as it does because people
mistakenly consider any use of XML over HTTP as REST. AFAIK anything
that involves URLs with a bunch of parameters at the end is not REST
(because it's not identifying a particular resource, it's effectively
exposing a method call). Do you disagree with this, Stefan?

I've yet to see any examples of using REST for real service
applications. The big problem here is that almost any reasonable service
is going to involve coordinated state changes to many different
"resources". REST appears incapable of dealing with this type of
requirement.

- Dennis

Post by Paul Fremantle
Stefan
My favourite internet Irish tin whistle music website uses SOAP to
link to Google, and Yahoo uses SOAP to power its email client, so I
don't think you can say SOAP on the internet is dead. I give the music
website as an example of a small organisation that isn't "enterprise".
Anyway, that wasn't my main point!
It is perhaps a little bit wrong to talk about REST as an option for
a Service Oriented Architecture. Most existing services don't cleanly
map into REST, except those directly backed by a resource model such
as a database. Even a layer of stored procedures over the data is
likely to mean that you cannot map it into REST.
Really you should be talking about Resource Oriented Architecture (ROA).
I actually think ROA has a number of attractive aspects, but I don't
think its the solution to everything. I think that a POX (Plain Ole
XML) or SOAP approach is going to be required because not everyone
thinks in a resource oriented way.
I think its time to call the Rest-ians on their distinctions. There
are plenty of RESTians taking a hard line on what is "REST" and what
isn't, and at the same time willing to say that REST is the only good
solution for an SOA. Well, if you analyze most "services" and SOA they
aren't based on state transitions of resources. Trying to have your
cake and eat it?
Paul

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/service-orientated-architecture/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:service-orientated-architecture-digest-***@public.gmane.org
mailto:service-orientated-architecture-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
service-orientated-architecture-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Stefan Tilkov

2006-11-24 22:48:28 UTC

Again, I'm unsure what definition of POX you're using here - POX can
be RESTful or not.

Post by Dennis Sosnoski
AFAIK anything
that involves URLs with a bunch of parameters at the end is not REST
(because it's not identifying a particular resource, it's effectively
exposing a method call). Do you disagree with this, Stefan?

Absolutely, yes - that's why Axis2's REST support is in fact nothing
of the sort.

Post by Dennis Sosnoski
I've yet to see any examples of using REST for real service
applications. The big problem here is that almost any reasonable service
is going to involve coordinated state changes to many different
"resources". REST appears incapable of dealing with this type of
requirement.

That's funny because I actually believe that's pretty much what it's
built and being used for :-)

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Post by Dennis Sosnoski
- Dennis

Post by Paul Fremantle
Stefan
My favourite internet Irish tin whistle music website uses SOAP to
link to Google, and Yahoo uses SOAP to power its email client, so I
don't think you can say SOAP on the internet is dead. I give the music
website as an example of a small organisation that isn't
"enterprise".
Anyway, that wasn't my main point!
It is perhaps a little bit wrong to talk about REST as an option for
a Service Oriented Architecture. Most existing services don't cleanly
map into REST, except those directly backed by a resource model such
as a database. Even a layer of stored procedures over the data is
likely to mean that you cannot map it into REST.
Really you should be talking about Resource Oriented Architecture (ROA).
I actually think ROA has a number of attractive aspects, but I don't
think its the solution to everything. I think that a POX (Plain Ole
XML) or SOAP approach is going to be required because not everyone
thinks in a resource oriented way.
I think its time to call the Rest-ians on their distinctions. There
are plenty of RESTians taking a hard line on what is "REST" and what
isn't, and at the same time willing to say that REST is the only good
solution for an SOA. Well, if you analyze most "services" and SOA they
aren't based on state transitions of resources. Trying to have your
cake and eat it?
Paul

I agree with the notion that business is more important than IT, and
many, many IT folks should work to learn a lot more about the actual
business value and their part (or lack of) in it.
Whether or not REST vs. WS-* or Java vs. Ruby or C++ vs.
Smalltalk or
Windows vs. Linux vs. OS X is relevant or not depends very much on
the topic of the discussion we're having. When we're talking about
business strategies for a telecommunications company, Java vs. Ruby
doesn't play a big role. That doesn't mean that they're the same
even if they're both "just programming languages".
Similarly, I refuse to agree with the assertion that when I look at
the technical, architectural properties of a system landscape, it
doesn't matter whether its architecture is built around DCOM/MTS,
J2EE, WS-* or REST.
But that's all beside Steve's original point, which IIRC was
"even if
it's cool, it doesn't matter because the vendors don't do it". I
disagree: Witness the inclusion of (admittedly bad) REST support in
Indigo/WCF and Axis2, or the Systinet 2 repository's REST interface,
or the fact that Google's Nelson Minar now asserts he'd never choose
SOAP and WSDL over REST again on the Internet, it seems to me that
SOAP/WSDL has clearly lost, and this does not bode well for its
future in the enterprise.
I will continue to help build good WS-based architectures I'm not
as principled as Mark Baker :-) Whenever I can get someone to listen,
I will try to convince them of the REST alternative, though, and I
expect this to get easier over the course of the next few years.
Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Yahoo! Groups Links

Dennis Sosnoski

2006-11-25 06:44:48 UTC

So as sort of a base case we've got at least three different sets of
1. The flight itself, which is under the control of the airline; the
reservation information here needs to include passenger
information (name, address, contact information, passport #, date
of birth, etc.) as well as a reference and identifier for the
entity that originated the reservation. The reservation may or may
not include a specific seat, or general seat preference (e.g.,
window).
2. The agency system, which needs to have the reservation associated
with a particular customer account, and linked with the identifier
used by the airline for the reservation.
3. The passenger's credit card, which needs to be debited for the
amount of the reservation with funds transferred to the agency.
How would you go about structuring this as a RESTful service?

Or more precisely, as at least three separate RESTful services - one for
the airline, one for the credit card bank, and one for the agency, with
the latter controlling the interactions with the first two.

- Dennis

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/service-orientated-architecture/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:service-orientated-architecture-digest-***@public.gmane.org
mailto:service-orientated-architecture-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
service-orientated-architecture-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Sanjiva Weerawarana

2006-11-25 06:56:27 UTC

Again, I'm unsure what definition of POX you're using here - POX can
be RESTful or not.

And that's why POX is what matters and not REST. POX is a useful way to
invoke services. REST is a religion.

Absolutely, yes - that's why Axis2's REST support is in fact nothing
of the sort.

Yes, its actually POX support. And using your own words above, such POX
support can be used to write RESTful applications and non-RESTful
applications. Its not up to us middleware authors to dictate how people
will write applications. If they want to write RESTful apps, great. If
they want to write non-RESTful SOA app, great. We support both camps.

Sanjiva.

--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/

Stefan Tilkov

2006-11-25 12:33:06 UTC

Sanjiava,

Post by Dennis Sosnoski
I agree completely, Paul. POX is clearly the significant
alternative to
SOAP, and REST only has as much mindshare as it does because

people

Post by Dennis Sosnoski
mistakenly consider any use of XML over HTTP as REST.

Again, I'm unsure what definition of POX you're using here - POX can
be RESTful or not.

And that's why POX is what matters and not REST. POX is a useful way to
invoke services. REST is a religion.

I don't understand that statement. What's religious about REST? It's
a well-defined and pretty clearly described architecture. You may
consider it crap, or non-fitting for your problem, but how is it a
religion?

Post by Dennis Sosnoski
AFAIK anything
that involves URLs with a bunch of parameters at the end is not

REST

Post by Dennis Sosnoski
(because it's not identifying a particular resource, it's

effectively

Post by Dennis Sosnoski
exposing a method call). Do you disagree with this, Stefan?

Absolutely, yes -

I was a little quick in my answer here; of course a resource can be a
collection and the parameters could be those to a query (which would
be perfectly RESTful AFAICT.) My agreement was that if the URL
includes an operation - especially an unsafe one - it's definitely
non-RESTful.

Post by Dennis Sosnoski
that's why Axis2's REST support is in fact nothing

Post by Stefan Tilkov
of the sort.

I don't believe that Axis2's REST/POX can be used to implement a
RESTful solution; let's try once we have a design proposal for
Dennis's problem.

--
Stefan Tilkov, http://www.innoq.com/blog/st/

Post by Dennis Sosnoski
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://
www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/

Sanjiva Weerawarana

2006-11-25 17:59:18 UTC

Post by Stefan Tilkov
I don't believe that Axis2's REST/POX can be used to implement a
RESTful solution; let's try once we have a design proposal for
Dennis's problem.

I'd be shocked if there is any RESTful scenario that cannot be
implemented with Axis2's REST/POX support. In the default case it does
nothing and hands the application the URL and says "here you go- do what
you want with it".

Let's see how it works when Mark comes up with a solution for Dennis'
problem!

Sanjiva.

Dennis Sosnoski

2006-11-25 01:19:14 UTC

Again, I'm unsure what definition of POX you're using here - POX can
be RESTful or not.

POX *can* be RESTful, but rarely is. The vast majority of POX-type
services I'm aware of (going back to well before SOAP) are based on
exchanging XML documents and don't really care much about the transport
(though most use HTTP for this purpose, with POST to send the data to
the service and get back an XML response irrespective of whether there's
any state change on the server at all). In particular, the only use they
make of URIs is a URL to identify the service endpoint (a servlet in
Java, or a .aspx in .Net).

Post by Stefan Tilkov
...

That's funny because I actually believe that's pretty much what it's
built and being used for :-)

Then let me ask you how to structure an example as a REST service,
Stefan. Many of my clients are in travel-related fields, so one example
I've used in the past is an airline flight reservation. When making a
reservation there are a number of different resources involved. First
off there's the flight itself, which changes state in terms of the
number of seats booked. There's also associated information about who
has booked the seat, and some form of identifying number. Separately,
there's the reservation itself, which is typically in the realm of a
travel agency or some other form of agent. This includes payment
information, and as part of the reservation service processing there may
need to be a charge processed against the customer's credit card.
There's also often (but not always) a specific seat that's been reserved
(which is perhaps the most concrete example of a resource in this example).

So as sort of a base case we've got at least three different sets of
resources involved in a reservation service:

1. The flight itself, which is under the control of the airline; the
reservation information here needs to include passenger
information (name, address, contact information, passport #, date
of birth, etc.) as well as a reference and identifier for the
entity that originated the reservation. The reservation may or may
not include a specific seat, or general seat preference (e.g.,
window).
2. The agency system, which needs to have the reservation associated
with a particular customer account, and linked with the identifier
used by the airline for the reservation.
3. The passenger's credit card, which needs to be debited for the
amount of the reservation with funds transferred to the agency.

How would you go about structuring this as a RESTful service?

- Dennis

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/service-orientated-architecture/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:service-orientated-architecture-digest-***@public.gmane.org
mailto:service-orientated-architecture-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
service-orientated-architecture-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Stefan Tilkov

2006-11-25 12:26:59 UTC

Hi Dennis,

Again, I'm unsure what definition of POX you're using here - POX can
be RESTful or not.

POX *can* be RESTful, but rarely is. The vast majority of POX-type
services I'm aware of (going back to well before SOAP) are based on
exchanging XML documents and don't really care much about the
transport
(though most use HTTP for this purpose, with POST to send the data to
the service and get back an XML response irrespective of whether there's
any state change on the server at all). In particular, the only use they
make of URIs is a URL to identify the service endpoint (a servlet in
Java, or a .aspx in .Net).

Right, there's a vast number of POX implementations that are non-
RESTful. But so what? I'm not religious (in any sense) and I don't
expect things to follow the ideal all the time. I do claim that the
more REST principles are being followed, the better - e.g. it's
better to use GET as a "safe" operation, it makes sense to expose
resources through URIs, I believe using links in representations is a
great idea ... I what problem you see here. Are you arguing that e.g.
using a single endpoint URI, or tunneling everything through POST, is
*better*? If so, I disagree - this is akin to serializing objects to
BLOBs in an RDBMS.

Post by Stefan Tilkov
...

That's funny because I actually believe that's pretty much what it's
built and being used for :-)

Then let me ask you how to structure an example as a REST service,
Stefan.

[snip]

Interesting example, although I'll need a little more time than I
have right now to come up with a decent proposal.

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Mark Baker

2006-11-25 13:48:21 UTC

Post by Dennis Sosnoski
I agree completely, Paul. POX is clearly the significant alternative to
SOAP, and REST only has as much mindshare as it does because people
mistakenly consider any use of XML over HTTP as REST. AFAIK anything
that involves URLs with a bunch of parameters at the end is not REST
(because it's not identifying a particular resource, it's effectively
exposing a method call).

If you mean that one of the parameters is an operation, that is
actually RESTful if you're only using GET.

Mark.

Stefan Tilkov

2006-11-25 17:23:07 UTC

Post by Dennis Sosnoski
I agree completely, Paul. POX is clearly the significant

alternative to

Post by Dennis Sosnoski
SOAP, and REST only has as much mindshare as it does because people
mistakenly consider any use of XML over HTTP as REST. AFAIK anything
that involves URLs with a bunch of parameters at the end is not REST
(because it's not identifying a particular resource, it's

effectively

Post by Dennis Sosnoski
exposing a method call).

If you mean that one of the parameters is an operation, that is
actually RESTful if you're only using GET.

I agree, but only because URIs are opaque from a REST perspective,
and only if the operation is "safe". Right?

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Dennis Sosnoski

2006-11-25 22:13:59 UTC

... AFAIK anything
that involves URLs with a bunch of parameters at the end is not REST
(because it's not identifying a particular resource, it's effectively
exposing a method call).

If you mean that one of the parameters is an operation, that is
actually RESTful if you're only using GET.

This seems like one of those having-your-cake-and-eating-it-too points.
But perhaps I'm misunderstanding the principles of REST. My
understanding was that each resource is supposed to be exposed as a URI,
and that operations are supposed to be done using the URIs. If you
instead use a generic URI and string on parameters to say what you want
done, how is that RESTful?

Here's an example, using the much-lauded "REST" API for Amazon:

http://xml.amazon.com/onca/xml3?mode=books&AsinSearch=0079132480&type=heavy&page=1&f=xml&t=AssociatesIDwebservices-20&dev-t=XXX

(where XXX is the appropriate Amazon associate id). This returns
information about a particular book in a particular format. Of course,
changing the order of the glob of parameters at the end:

http://xml.amazon.com/onca/xml3?mode=books&type=heavy&page=1&f=xml&t=AssociatesIDwebservices-20&dev-t=XXX&AsinSearch=0079132480

returns almost the same result (only almost, in the case of Amazon,
because they embed a RequestID in the result).

Now where is the resource here? I guess it would have to be Amazon
itself, since nothing else is actually identifiable. One might think
that an individual book would be a resource, but it's not - at least in
this "REST" interface. Interestingly, in the normal HTML Web view of
Amazon it actually is, at least to a degree - a search on this ISBN
takes you to:

http://www.amazon.com/Inside-Java-Virtual-Machine-Masters/dp/0079132480/sr=11-1/qid=1164491543/ref=sr_11_1/103-4485742-1843022

Ignoring the query-dependent garbage at the end, the first part of this
is a reasonable resource identification. You can even strip off the
garbage and get the same page, using only the resource identification
part of the URL:

http://www.amazon.com/Inside-Java-Virtual-Machine-Venners/dp/0071350934/

So if the Amazon GET-based XML interface is indeed RESTful, it certainly
seems much less RESTful than the conventional HTML Web interface. Both
interfaces are structured in a way which by default negates one of the
major claimed benefits of a REST approach, that of being able to cache
results, but the HTML one at least allows you to access resources
directly. The only RESTful part of the GET-based XML interface seems to
be that it *does* use "GET" rather than "POST" - but I can't see any
advantage provided by this, aside from making it easier for users to
generate requests as text strings (which is not one of the claimed
benefits of REST, AFAIK).

- Dennis

Mark Baker

2006-11-27 06:01:20 UTC

Thank for having such an in-depth look at the issue, Dennis, but I
could have saved you some time; you're making inferences about the
intent of Amazon's software based on how the URIs look, and while you
may very well be right, it doesn't matter because it's irrelevant to
the architecture; GET returns the data whether there's query
parameters, operation names, misuse of hierarchy, or whatever good or
bad practice you might care to name.

There's one comment you made that I wanted to respond to though ...

Post by Dennis Sosnoski
The only RESTful part of the GET-based XML interface seems to
be that it *does* use "GET" rather than "POST" - but I can't see any
advantage provided by this, aside from making it easier for users to
generate requests as text strings (which is not one of the claimed
benefits of REST, AFAIK).

There are many advantages depending upon what angle you're looking at
it from - caching, security, reliability, etc.. In general though, I
think the big one is that any HTTP client anywhere can turn that URI
into data using GET. If POST were used, then clients would also have
to know *what* to POST, removing that benefit. Coordination costs are
less (effectively zero) using GET.

Mark.

Mike Glendinning

2006-11-27 10:39:48 UTC

Post by Mark Baker
There are many advantages depending upon what angle you're looking at
it from - caching, security, reliability, etc.. In general though, I
think the big one is that any HTTP client anywhere can turn that URI
into data using GET. If POST were used, then clients would also have
to know *what* to POST, removing that benefit. Coordination costs are
less (effectively zero) using GET.
Mark.

But how do I know what to do with the data that is returned by GET?

The content type probably just says "application/xml" or perhaps "text".

Are there not significant coordination costs in delivering (in advance)
to every REST client enough information to decode and make sense of all
possible data formats, both current and future?

-Mike.

Mark Baker

2006-11-27 16:13:19 UTC

Post by Mike Glendinning

But how do I know what to do with the data that is returned by GET?

How would you know what to do with the data returned from a Web
service endpoint that you invoked getStockQuote() on? Same answer.
The *only* difference between the two situations is that you're using
a more general operation when you use GET. Everything else is
*identical*.

Mark.

Mike Glendinning

2006-11-27 17:58:18 UTC

Mark,

Well, I didn't mention WS-Everything and didn't want to get into a
sterile debate over the merits of various technical approaches.

I was just trying to challenge your statement that coordination costs
for the GET operation in REST are effectively zero.

What you now seem to be saying is that the coordination costs for GET
are the same ("identical") as for a custom-designed interface with WS-
Everything.

This sounds more plausible and I tend to agree with you.

-Mike.
Baker"

Post by Mike Glendinning

Post by Mark Baker
There are many advantages depending upon what angle you're

looking at

Post by Mike Glendinning

Post by Mark Baker
it from - caching, security, reliability, etc.. In general though, I
think the big one is that any HTTP client anywhere can turn that URI
into data using GET. If POST were used, then clients would also have
to know *what* to POST, removing that benefit. Coordination costs are
less (effectively zero) using GET.
Mark.

But how do I know what to do with the data that is returned by GET?

Mark Baker

2006-11-27 21:04:45 UTC

Post by Mike Glendinning
What you now seem to be saying is that the coordination costs for GET
are the same ("identical") as for a custom-designed interface with WS-
Everything.

That's not what I'm saying, Mike. By "identical" I was referring to
other issues you have to deal with, such as processing the data. But
simplifying coordination is most definitely a big part of what
generalization gives you.

As I say, the knowledge required to use POST is *more* because it has,
in effect, an extra "parameter" that the caller has to know about, and
know the value of; the HTTP body. The GET has no such parameter in
order to be used; you just need a URI (which you also need for POST).

It all comes down to reusing existing agreements; the more you are
able to reuse, the easier things are to coordinate with those who also
follow those agreements. GET already means "get me data", while POST
does not.

Mark.

Stefan Tilkov

2006-11-28 12:59:51 UTC

Post by Mark Baker
There are many advantages depending upon what angle you're

looking at

are

Post by Mark Baker
less (effectively zero) using GET.
Mark.

But how do I know what to do with the data that is returned by GET?
The content type probably just says "application/xml" or perhaps "text".

You are right that application/xml is a bad choice for a content type
in a RESTful design. The Atom Publishing Protocol, for example, uses
application/atom+xml.
But even if application/xml is used, you can take a look at the XML
root element and its namespace -- at least with a GET, you know it's
safe to retrieve an example message using curl or wget :-)

Post by Mark Baker
Are there not significant coordination costs in delivering (in
advance)
to every REST client enough information to decode and make sense of all
possible data formats, both current and future?

Not more than with any other approach ...

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Post by Mark Baker
-Mike.

Mark Baker

2006-11-28 14:26:52 UTC

It sounds like your view of REST comes down to "use GET whenever you
can".

Well, whenever you're requesting data from some other party, sure;
that's what GET is for. If you're sending them data though, GET's not
suitable.

There's nothing wrong with that, and it does indeed offer the
advantage that a browser can be used to view the result. It doesn't seem
to have much to do with Roy Fielding's thesis, though, which most people
seem to regard as the foundation of the REST approach. Hmmm... do we
need to rename this thread to "GOA is not ROA"? :-)

Rest assured that, to the best of my ability, all of my arguments are
firmly grounded in Roy's dissertation.

For simple Web services, exposing a method call as a bunch of parameters
passed via GET does make it easy for all types of clients to access the
service. But this is just another form of RPC,

It's not. If a server publishes a URI that includes the string
"getFoo", and somebody stumbles upon that URI and passes it to curl
(or wget, or their browser bar, or ...), they are not invoking the
getFoo operation as would be the case with RPC. No, the architecture
is significantly different; by wrapping the operation in the URI,
they've hidden it from clients, and the operation thats invoked across
the network is GET, not getFoo. getFoo might still be invoked by the
server on its own objects, but it's not part of the *contract* that
exists between that person's browser and the publisher's server.

Mark.

Steve Jones

2006-11-28 20:40:22 UTC

It sounds like your view of REST comes down to "use GET whenever you
can".

Not from the perspective of the consumer, when I see a URI that
includes something like "drawGraph?xData=fred&yData=pointless" then
I'm calling drawGraph with those parameters.

I don't care whether its "GET" or whatever, its drawGraph that I am
calling. In the same way as when I call www.google.com/analytics I am
calling analytics not "GET". This is one of the things I like about
REST in that it explicitly encodes the method within the URI making it
simpler to read directly in the code (as opposed to in tools as with
WS, which I also like), at no stage ever when I'm using REST things am
I thinking "GET", I'm thinking about what the URI describes.

Post by Mark Baker
From a consumers perspective they don't care a rats arse what the

server magically does, all they care about is the request that they
are making, this means GET is irrelevant and its the request in
totality that matters.

Mark Baker

2006-11-28 21:39:50 UTC

Post by Steve Jones
Not from the perspective of the consumer, when I see a URI that
includes something like "drawGraph?xData=fred&yData=pointless" then
I'm calling drawGraph with those parameters.

And if the publisher of the *same* functionality used this instead;

http://example.org/kdjfalkjdfnawkflaudfnakjsdnfalufh

then what would the operation be there?

Post by Steve Jones
I don't care whether its "GET" or whatever, its drawGraph that I am
calling. In the same way as when I call www.google.com/analytics I am
calling analytics not "GET". This is one of the things I like about
REST in that it explicitly encodes the method within the URI making it
simpler to read directly in the code (as opposed to in tools as with
WS, which I also like), at no stage ever when I'm using REST things am
I thinking "GET", I'm thinking about what the URI describes.

No Steve, REST doesn't encode the method within the URI. With all due
respect, that statement shows me that you don't yet understand it.

REST is an architectural style. It has constraints that you have to
follow in order to realize its benefits. One of these constraints is
that operations be uniform. On the Web, that means in effect, that
the operation has to be an HTTP operation (or an extension therefore,
e.g. WebDAV).

Mark.

Steve Jones

2006-11-28 22:40:30 UTC

Post by Steve Jones
Not from the perspective of the consumer, when I see a URI that
includes something like "drawGraph?xData=fred&yData=pointless" then
I'm calling drawGraph with those parameters.

And if the publisher of the *same* functionality used this instead;
http://example.org/kdjfalkjdfnawkflaudfnakjsdnfalufh
then what would the operation be there?

Incomprehensible to any rational person?

No Steve, REST doesn't encode the method within the URI. With all due
respect, that statement shows me that you don't yet understand it.

Quite clearly, because I thought that the major idea was that the URI
was in itself documentation of the action. Okay so drawGraph should
possibly be just "Graph" and viewing Graph as a resource, but what is
wrong from a REST perspective with a resource of
http://somewhere.com/maths/graph?x=mypoints&y=mypoints ?

GET will be idempotent and is considering graph to be a complex resource.

If you are saying that REST isn't that simple then I'm suprised. I
was sure that choosing the right URI name was a key part of REST.

Yup not getting it....

Post by Mark Baker
REST is an architectural style. It has constraints that you have to
follow in order to realize its benefits. One of these constraints is
that operations be uniform. On the Web, that means in effect, that
the operation has to be an HTTP operation (or an extension therefore,
e.g. WebDAV).

So you are saying that it is _bad_ practice in REST to have sensibly
named URIs? I'm really missing which bit of REST I've violated by
having a sensibly named URI, and which bit of the "web" doesn't use
URIs to split different areas of functionality (ala the google
example).

If REST doesn't consider www.google.com/analytics differently to
http://www.google.com/trends then I've definately missed something
around the lack of importance of URI design in REST.

Steve

Post by Mark Baker
Mark.

Stefan Tilkov

2006-11-29 10:30:01 UTC

Post by Steve Jones
So you are saying that it is _bad_ practice in REST to have sensibly
named URIs? I'm really missing which bit of REST I've violated by
having a sensibly named URI, and which bit of the "web" doesn't use
URIs to split different areas of functionality (ala the google
example).

No, it's of course not bad practice. It's just very tempting to start
adding meaning to URIs that doesn't belong there - like for example
an "action". In HTTP, a URI identifies a resource, and *every*
resource supports the same methods (or a subset thereof): GET, PUT,
POST, DELETE. This means that instead of coming up with a set of N
services that expose some unspecified number of operations, you have
to come up with M resources that support 4 operations when you follow
REST conventions.

See here for an attempt at a graphical explanation: http://
www.innoq.com/blog/st/2006/06/30/rest_vs_soap_oh_no_not_again.html

The HTTP verbs have defined semantics, and as long as your design
doesn't violate them, it doesn't matter whether your URIs are of the
http://.../draw?x=5&y=4 or the http://.../alskdjalkjd1928e1928e variety.

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Steve Jones

2006-11-30 06:59:46 UTC

So which bit of REST was I actually not understanding? If I have something like

http://www.bollocks.com/invoice?customer=fred&date=1/1/01&orderId=4
or
http://www.bollocks.com/invoice?customer=fred&startDate=1/1/01&endDate=1/1/06&reportType=Summary

Then is this valid REST, and if not why not, and if so why isn't this
just a parameterised request as I said earlier? If it is valid rest
then to me this is two clearly different operations that are being
invoked. Or should each report type have a separate identity, even
though they are all clearly related to the same resource (invoice).

Post by Stefan Tilkov
See here for an attempt at a graphical explanation: http://
www.innoq.com/blog/st/2006/06/30/rest_vs_soap_oh_no_not_again.html
The HTTP verbs have defined semantics, and as long as your design
doesn't violate them, it doesn't matter whether your URIs are of the
http://.../draw?x=5&y=4 or the http://.../alskdjalkjd1928e1928e variety.

Yes it does, but then I was brought up on Ada where I learnt that
names actually do matter and that using poor names was a bad
thing(tm). I can't see how alskdjalkjd1928e1928e can be RESTful in
that it doesn't describe a clearly identifiable resource.

Post by Stefan Tilkov
Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Mark Baker

2006-11-29 14:22:12 UTC

Post by Mark Baker
And if the publisher of the *same* functionality used this instead;
http://example.org/kdjfalkjdfnawkflaudfnakjsdnfalufh
then what would the operation be there?

Incomprehensible to any rational person?

8-) It would still be GET.

Consider that you'd still receive the data you expected, but without -
using your argument - knowing the operation! How is that possible?
An essential aspect of distributed computing is that client and server
share a *contract*; if the client doesn't know the whole contract - in
this case the operation - then it isn't shared. Something else must
be going on!

Post by Steve Jones
Quite clearly, because I thought that the major idea was that the URI
was in itself documentation of the action. Okay so drawGraph should
possibly be just "Graph" and viewing Graph as a resource, but what is
wrong from a REST perspective with a resource of
http://somewhere.com/maths/graph?x=mypoints&y=mypoints ?
GET will be idempotent and is considering graph to be a complex resource.
If you are saying that REST isn't that simple then I'm suprised. I
was sure that choosing the right URI name was a key part of REST.

It is, but it doesn't identify the operation, it identifies the
"thing" the operation is to be invoked upon. It's an object id.

Mark.

Steve Jones

2006-11-30 07:03:23 UTC

Post by Mark Baker
And if the publisher of the *same* functionality used this instead;
http://example.org/kdjfalkjdfnawkflaudfnakjsdnfalufh
then what would the operation be there?

Incomprehensible to any rational person?

8-) It would still be GET.

So?

Post by Mark Baker
Consider that you'd still receive the data you expected, but without -
using your argument - knowing the operation! How is that possible?
An essential aspect of distributed computing is that client and server
share a *contract*; if the client doesn't know the whole contract - in
this case the operation - then it isn't shared. Something else must
be going on!

I wouldn't receive the data I expect as I would have no clue as to
what data to expect via such a badly named element. You appear to be
arguing that the client must know everything about the server, which
means the two are tightly coupled which is a bad thing. I must be
missing something here as you can't be suggesting that surely.

It is, but it doesn't identify the operation, it identifies the
"thing" the operation is to be invoked upon. It's an object id.

So "graph" isn't a resource? But "GraphId452354" would be? I have to
say in my reading of REST so far its the former that I've understood
(and sometimes liked) while the later would just be rubbish as you'd
have one resource per object instance (i.e. you are arguing that REST
is on objects, my reading of the subject was that it was on classes).

Post by Mark Baker
Mark.

Stefan Tilkov

2006-11-30 11:14:17 UTC

That's the misunderstanding, then: REST indeed uses URIs (at least in
general and conceptually) to identify objects (instances), not
classes, via URIs.

For example, if your "application" (to avoid the term service)
manages customers, you'd very likely have a distinct URI for every
customer (in REST) as opposed to a single endpoint for the
CustomerManagementService (which is the common WSDL/SOAL/WS-* approach).

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Mark Baker

2006-11-30 13:27:23 UTC

That's the misunderstanding, then: REST indeed uses URIs (at least in
general and conceptually) to identify objects (instances), not
classes, via URIs.

Right. Before REST was so named, it was actually called the "HTTP
Object Model".

I'm not sure why that's rubbish though.

Mark.

Steve Jones

2006-11-30 17:51:13 UTC

So as a follow-up question ( I'm learning something today!) . Would
the prefered approach be

http://www.frood.com/customer1
http://www.frood.com/customer2

or

http://www.frood.com/customer?customerId=1
http://www.frood.com/customer?customerId=2

Or are both considered the same? The former could be quickly created
from a URI re-write of the latter of course, but I'm just wondering
what was the difference, I'll be honest the REST bit I'm writing at
the moment is using the later approach, so it would be good to know if
it isn't REST.

Steve

That's the misunderstanding, then: REST indeed uses URIs (at least in
general and conceptually) to identify objects (instances), not
classes, via URIs.
For example, if your "application" (to avoid the term service)
manages customers, you'd very likely have a distinct URI for every
customer (in REST) as opposed to a single endpoint for the
CustomerManagementService (which is the common WSDL/SOAL/WS-* approach).
Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Stefan Tilkov

2006-11-30 18:35:37 UTC

Actually, my preferred approach would be

http://www.frood.com/customers/1
http://www.frood.com/customers/2

(supporting GET and PUT) and

http://www.frood.com/customers/

returning a list of customers (on GET) and accepting new customers
via POST.

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

So as a follow-up question ( I'm learning something today!) . Would
the prefered approach be
http://www.frood.com/customer1
http://www.frood.com/customer2
or
http://www.frood.com/customer?customerId=1
http://www.frood.com/customer?customerId=2
Or are both considered the same? The former could be quickly created
from a URI re-write of the latter of course, but I'm just wondering
what was the difference, I'll be honest the REST bit I'm writing at
the moment is using the later approach, so it would be good to know if
it isn't REST.
Steve

So "graph" isn't a resource? But "GraphId452354" would be? I

have to

say in my reading of REST so far its the former that I've

understood

(and sometimes liked) while the later would just be rubbish as

you'd

have one resource per object instance (i.e. you are arguing

that REST

is on objects, my reading of the subject was that it was on

classes).

Post by Stefan Tilkov
That's the misunderstanding, then: REST indeed uses URIs (at

least in

Post by Stefan Tilkov
general and conceptually) to identify objects (instances), not
classes, via URIs.
For example, if your "application" (to avoid the term service)
manages customers, you'd very likely have a distinct URI for every
customer (in REST) as opposed to a single endpoint for the
CustomerManagementService (which is the common WSDL/SOAL/WS-*

approach).

Post by Stefan Tilkov
Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Stefan Tilkov

2006-11-30 18:36:26 UTC

I just noticed that I might come across as evading the question ... a
good discussion of different styles is here:

http://rest.blueoxen.net/cgi-bin/wiki.pl?PathsAndQueryStrings

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

So as a follow-up question ( I'm learning something today!) . Would
the prefered approach be
http://www.frood.com/customer1
http://www.frood.com/customer2
or
http://www.frood.com/customer?customerId=1
http://www.frood.com/customer?customerId=2
Or are both considered the same? The former could be quickly created
from a URI re-write of the latter of course, but I'm just wondering
what was the difference, I'll be honest the REST bit I'm writing at
the moment is using the later approach, so it would be good to know if
it isn't REST.
Steve

So "graph" isn't a resource? But "GraphId452354" would be? I

have to

say in my reading of REST so far its the former that I've

understood

(and sometimes liked) while the later would just be rubbish as

you'd

have one resource per object instance (i.e. you are arguing

that REST

is on objects, my reading of the subject was that it was on

classes).

Post by Stefan Tilkov
That's the misunderstanding, then: REST indeed uses URIs (at

least in

approach).

Post by Stefan Tilkov
Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Mark Baker

2006-11-30 19:06:38 UTC

Post by Steve Jones
So as a follow-up question ( I'm learning something today!) . Would
the prefered approach be
http://www.frood.com/customer1
http://www.frood.com/customer2
or
http://www.frood.com/customer?customerId=1
http://www.frood.com/customer?customerId=2
Or are both considered the same? The former could be quickly created
from a URI re-write of the latter of course, but I'm just wondering
what was the difference, I'll be honest the REST bit I'm writing at
the moment is using the later approach, so it would be good to know if
it isn't REST.
From a REST POV, they're basically equivalent. But there are other

considerations. For example, using the first option you couldn't
direct a client to those resources using an HTML form, since HTML
forms only parameterize using "?".

As an architectural style, REST is limited in the kinds of constraints
it can define; if it's not a constraint on a relationship between
software architectural elements (data, connectors, components), it's
not in play. That leaves lots of room for best practices which have
nothing to do with REST.

Mark.

Steve Jones

2006-12-01 02:55:40 UTC

From a REST POV, they're basically equivalent. But there are other
considerations. For example, using the first option you couldn't
direct a client to those resources using an HTML form, since HTML
forms only parameterize using "?".

Thank god for that (and I take Stefan's point as well about /1) a bit
of URL rewritting in Apache should be able to support all of the
approaches.

Post by Steve Jones
As an architectural style, REST is limited in the kinds of constraints
it can define; if it's not a constraint on a relationship between
software architectural elements (data, connectors, components), it's
not in play. That leaves lots of room for best practices which have
nothing to do with REST.

So as a question (and back to the idea of method invocation v
resource) how would an invoice summary for a series of dates be done
in rest world? Would it be done by having (in Stefan's URI)

http://www.frood.com/customer/invoice/summary

and passing in an XML document that contains the dates, or would a
parameterised approach that enables an HTML style submission be
allowed (i.e. ?startDate=10/10/01&endDate=10/10/06). If the later
then could a full parameterisation of
customer?type=invoice&request=summary be classed as being REST.

The reason I'm asking is that requesting a summary of invoices is a
pretty common thing that requires calculation and aggregation on the
server. My, naive, view on REST would be that the parameterised
approach is acceptable, and even the fully parameterised element seems
to be okay. The problem I'm wrestling with is why this isn't just a
command pattern implementation using URIs.

Mark Baker

2006-12-01 15:39:10 UTC

Post by Mark Baker
As an architectural style, REST is limited in the kinds of constraints
it can define; if it's not a constraint on a relationship between
software architectural elements (data, connectors, components), it's
not in play. That leaves lots of room for best practices which have
nothing to do with REST.

That could be done, and would be RESTful.

Post by Steve Jones
or would a
parameterised approach that enables an HTML style submission be
allowed (i.e. ?startDate=10/10/01&endDate=10/10/06). If the later
then could a full parameterisation of
customer?type=invoice&request=summary be classed as being REST.

Sure.

There are advantages to the latter approach though, in particular that
you can hand that URI to any person or HTTP automata on the planet and
they'll also be able to get the data. That's not the case with the
former approach because the client needs to know the data format to
POST.

Post by Steve Jones
The reason I'm asking is that requesting a summary of invoices is a
pretty common thing that requires calculation and aggregation on the
server. My, naive, view on REST would be that the parameterised
approach is acceptable, and even the fully parameterised element seems
to be okay. The problem I'm wrestling with is why this isn't just a
command pattern implementation using URIs.

You mean the "request=summary" bit? I wrestled with that issue for
years too. The answer is because it's opaque to clients - not part of
the shared contract between client and server - unlike if it were a
command.

Mark.

Jan Algermissen

2006-11-29 14:25:44 UTC

Post by Steve Jones
o you are saying that it is _bad_ practice in REST to have sensibly
named URIs?

URIs are opaque identifiers (just like object references in any OO
language). You should
not infer anything from a URI.

Jan

Steve Jones

2006-12-03 15:23:13 UTC

Hang on, I'm getting different advice here, my understanding was that URI
naming (picking good names) was an essential part of REST. If its an
internal identifier then that isn't the case.

So should REST URIs have carefully chosen names, or is banging at the
keyboard randomly the prefered approach?

Post by Steve Jones
o you are saying that it is _bad_ practice in REST to have sensibly
named URIs?

URIs are opaque identifiers (just like object references in any OO
language). You should
not infer anything from a URI.
Jan

Stefan Tilkov

2006-12-03 20:55:07 UTC

The preferred way is to have the server create the links. This way,
it's under the server's authority to redirect you to other hosts
without you caring about it. The moment you add meaning to URIs, you
risk that a client will construct them by adding component parts to
root parts ... relying on assumptions you don't want them to rely on.

Still, having meaningful URIs makes life easier for everyone. You
just have to be aware of the risk :-)

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Post by Steve Jones
Hang on, I'm getting different advice here, my understanding was
that URI naming (picking good names) was an essential part of
REST. If its an internal identifier then that isn't the case.
So should REST URIs have carefully chosen names, or is banging at
the keyboard randomly the prefered approach?

Post by Steve Jones
o you are saying that it is _bad_ practice in REST to have sensibly
named URIs?

URIs are opaque identifiers (just like object references in any OO
language). You should
not infer anything from a URI.
Jan

Steve Jones

2006-12-04 23:34:10 UTC

But this is a big problem, there is no such thing as "maybe" for computers
and people will always read meaning into names. If naming is important then
it is always important, if naming isn't important then you should obfuscated
names to stop people getting confused.

If REST is about meaninful names then they should _always_ be meaningful,
not optionally meaningful. And if names are obfuscated and not meaningful
then how do you communicate to clients what the URI actualy means and what
request they should make?

I'm getting more confused here rather than less!

Post by Stefan Tilkov
The preferred way is to have the server create the links. This way,
it's under the server's authority to redirect you to other hosts
without you caring about it. The moment you add meaning to URIs, you
risk that a client will construct them by adding component parts to
root parts ... relying on assumptions you don't want them to rely on.
Still, having meaningful URIs makes life easier for everyone. You
just have to be aware of the risk :-)
Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Post by Steve Jones
o you are saying that it is _bad_ practice in REST to have sensibly
named URIs?

URIs are opaque identifiers (just like object references in any OO
language). You should
not infer anything from a URI.
Jan

Jan Algermissen

2006-12-05 21:44:49 UTC

And if names are obfuscated and not meaningful then how do you
communicate to clients what the URI actualy means and what request
they should make?

From a REST POV, it is important that the client knows the meaning
of traversing a certain link (the meaning of the state transition
perfromed by traversing that link). The client knows this from the
media type. The URI is *not* providing any meaning in terms of
traversing through the application's state machine, it is just an
object identifier.

If you have a URI and no clue what to do...do a GET and follow your
nose[1].

Jan

Steve Jones

2006-12-06 04:30:03 UTC

And if names are obfuscated and not meaningful then how do you
communicate to clients what the URI actualy means and what request
they should make?

What is the media type for an invoice? How do I know how to get from
invoice to customer?

I'm getting really confused as to how a link traversals meaning is
documented via a media type, unless of course you create a whole new
ontology of media types for every project.

Post by Jan Algermissen
If you have a URI and no clue what to do...do a GET and follow your
nose[1].

Sounds like debugging via printf on an application someone else wrote....

Alexander Johannesen

2006-12-06 08:41:35 UTC

Hi,

Post by Steve Jones
What is the media type for an invoice?

Does it matter? If it comes back as a PDF, your only choice is to
print it, if it's a text file I guess you just read it, if it's an XML
application I guess you look at the DOCTYPE or the namespace of the
root element, and so forth. If you view with a browser, you probably
view the document, but if you're an application, then you can do a
number of things with it. An invoice is probably an application of
XML, in which you inspect the XML to see if you understand the schema
it was written in. If it was, then you're good to go.

Post by Steve Jones
How do I know how to get from invoice to customer?

How do you do that on any other stack, or any other technology?

Post by Steve Jones
I'm getting really confused as to how a link traversals meaning is
documented via a media type, unless of course you create a whole new
ontology of media types for every project.

When you browse a URL, what does it mean? When you use a SOAP service,
what does it mean? When communicating on this mailing-list, what does
it mean? I think you're stretching the term "meaning" here ... :)

The *meaning* of a URL is whatever we make it. There's guidelines
which says we should make URL's as meaningful as possible, but there's
no requirement to do so. But if we can, we should, just with any other
URL out there; REST builds on some nice human principles of
exploration that I find very attractive.

Post by Jan Algermissen
If you have a URI and no clue what to do...do a GET and follow your
nose[1].

Sounds like debugging via printf on an application someone else wrote....

Sounds like you're trolling...

Alex

--
"Ultimately, all things are known because you want to believe you know."
- Frank Herbert
__ http://shelter.nu/ __________________________________________________

Steve Jones

2006-12-06 16:19:01 UTC

Post by Alexander Johannesen

Post by Alexander Johannesen
Hi,

Post by Steve Jones
What is the media type for an invoice?

So I have to guess what the structure of the invoice is and to guess
which link goes to the customer and which link goes to the supplier
and which link goes to each of the various products?

Post by Alexander Johannesen
If you view with a browser, you probably
view the document, but if you're an application, then you can do a
number of things with it. An invoice is probably an application of
XML, in which you inspect the XML to see if you understand the schema
it was written in. If it was, then you're good to go.

So you have to communicate the XML Schema associated with the URI
before someone uses it. Fine, how is this normally done for REST?

Post by Steve Jones
How do I know how to get from invoice to customer?

How do you do that on any other stack, or any other technology?

Well with a WSDL I get given the Schemas upfront and these are
consumed into the tools so I can see these within my IDE.

Post by Alexander Johannesen

No I'm not. When I use a SOAP service I have the name of the SOAP
endpoint and the port as well as the schemas that define the
documents. There is the concept of this being published upfront in a
standard way, with Service names and ports having sensible and
descriptive names.

Post by Alexander Johannesen
The *meaning* of a URL is whatever we make it. There's guidelines
which says we should make URL's as meaningful as possible, but there's
no requirement to do so. But if we can, we should, just with any other
URL out there; REST builds on some nice human principles of
exploration that I find very attractive.

Hang on you said it was Opaque and now saying it should be
meaningful.... which is it?

Post by Alexander Johannesen

Post by Jan Algermissen
If you have a URI and no clue what to do...do a GET and follow your
nose[1].

Sounds like debugging via printf on an application someone else wrote....

Sounds like you're trolling...

Not at all, having an approach which is "call it and see" isn't really
viable commercially.

Post by Alexander Johannesen
Alex
--
"Ultimately, all things are known because you want to believe you know."
- Frank Herbert
__ http://shelter.nu/ __________________________________________________

Jan Algermissen

2006-12-06 18:30:25 UTC

Post by Steve Jones
having an approach which is "call it and see" isn't really
viable commercially.

..and still, people made good money with the Web so far, didn't they?

Jan

Mark Baker

2006-12-06 13:12:25 UTC

The basic idiom is little nuggets of information like so;

<StockQuote href="http://example.org/stockquote?symbol=GOOG" />

That is, using the syntax and semantics of the media type, the
publisher provides information about the URI(s) in the document
instances it publishes. Consumers of the documents can then use that
information to decide whether or not they want or need to interact
with the resource(s).

Mark.

Post by Jan Algermissen
If you have a URI and no clue what to do...do a GET and follow your
nose[1].

Sounds like debugging via printf on an application someone else wrote....

Yahoo! Groups Links

Steve Jones

2006-12-06 16:23:10 UTC

The basic idiom is little nuggets of information like so;
<StockQuote href="http://example.org/stockquote?symbol=GOOG" />

So its not the media type, its schema defined element (similar to port
type and the like in WSDL) that determines the meaning?

Post by Mark Baker
That is, using the syntax and semantics of the media type, the
publisher provides information about the URI(s) in the document
instances it publishes. Consumers of the documents can then use that
information to decide whether or not they want or need to interact
with the resource(s).

How is this information published, for instance the Schema and meaning
of each of the GET/POST/etc operations that are valid for the
resource? Media type itself has no real semantics (i.e. it doesn't
say meaning) its just syntax (type).

I'm getting more confused here rather than less over what is good
REST, it appears to be that pretty much anything can claim to be and
there is no formalism that can be used as the starting point for B2B
REST interactions. I like the way you are implying that readability
is a good thing, but Jan's view of opaque appears (to me) to be the
opposite to what you are proposing.

Post by Mark Baker
Mark.

Post by Jan Algermissen
If you have a URI and no clue what to do...do a GET and follow your
nose[1].

Sounds like debugging via printf on an application someone else wrote....

Yahoo! Groups Links

Jan Algermissen

2006-12-04 08:11:56 UTC

How often do you need to look at a URL to have your browser fetch the
page??

But since sometimes humans are looking at the stuff you come up with,
http://iuwdwwwez.com/uuzuwe7266tzzzre/uhjfhh77r
is propably not ideal - as are variable names like that in source
code....

Jan

Post by Steve Jones
o you are saying that it is _bad_ practice in REST to have sensibly
named URIs?

URIs are opaque identifiers (just like object references in any OO
language). You should
not infer anything from a URI.
Jan

Steve Jones

2006-12-04 23:36:34 UTC

How often do you need to look at a URL to have your browser fetch the
page??

Well I type mail.google.com and other URLs to get directly to sites,
but I wouldn't want to try for the auth key on gmail. But the
question isn't here in a person clicking on the link (the one with the
auth code) its in the initial link and the naming of that URI.

Post by Jan Algermissen
But since sometimes humans are looking at the stuff you come up with,
http://iuwdwwwez.com/uuzuwe7266tzzzre/uhjfhh77r
is propably not ideal - as are variable names like that in source
code....

This to me is a cop-out, either URIs should be meaningful in REST or
not, having a half-way house of "kinda" doesn't help anyone or add any
sort of clarity and formalism.

Post by Steve Jones
o you are saying that it is _bad_ practice in REST to have sensibly
named URIs?

URIs are opaque identifiers (just like object references in any OO
language). You should
not infer anything from a URI.
Jan

Mark Baker

2006-12-05 15:09:34 UTC

Post by Steve Jones
This to me is a cop-out, either URIs should be meaningful in REST or
not, having a half-way house of "kinda" doesn't help anyone or add any
sort of clarity and formalism.

Here's what Roy has to say;

http://tech.groups.yahoo.com/group/rest-discuss/message/3232

Note that this doesn't mean Jan is wrong, only that he was using
"opaque" in a different way than Roy uses there. Roy meant
"completely opaque", whereas I expect Jan meant "except where the
interpretation is licensed by an associated specification". Also, the
rules are different for humans than automata; automata benefit more
from sticking to the specs than humans do because humans are more
adaptable.

Mark.

Jan Algermissen

2006-12-05 20:42:00 UTC

Post by Steve Jones
This to me is a cop-out, either URIs should be meaningful in REST or
not, having a half-way house of "kinda" doesn't help anyone or add any
sort of clarity and formalism.

Dunno, but I think it has been said before in this thread that from a
REST POV, URIs are simply opaque identifiers.

Jan

Steve Jones

2006-12-06 04:26:53 UTC

Post by Steve Jones
This to me is a cop-out, either URIs should be meaningful in REST or
not, having a half-way house of "kinda" doesn't help anyone or add any
sort of clarity and formalism.

Dunno, but I think it has been said before in this thread that from a
REST POV, URIs are simply opaque identifiers.

So in other words it is _important_ for REST that the URI be
meaningless? (http://www.askoxford.com/concise_oed/opaque?view=uk)

opaque: difficult or impossible to understand

So surely this means that the examples I used with sensible names that
mean something are therefore _not_ REST as they are easy to
understand.

Given therefore that REST URIs are meant to be unintelligable (which I
really don't understand as to why that is a good thing) how do you
communicate to consumers what URIs to use? What is the way of
documenting URIs to consumers?

Stefan Tilkov

2006-12-06 12:06:56 UTC

I have a feeling you're seeing a problem where there actually is
none. A URI is an identifier, much like a variable identifier in a
programming language.

Having a variable named "ajkshdkajshd" is probably a bad idea, having
"SecondaryShippingAddress" is probably much better. Using reflection
mechanisms and string parsing methods to extract the word "Secondary"
from the identifier to drive application logic is probably a bad
idea, though.

From the point of view of the programming language, identifiers are
"opaque" in the sense that the characters just have to follow the
syntactical rules, nothing more - from that POV they are meaningless.

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Post by Steve Jones
This to me is a cop-out, either URIs should be meaningful in

REST or

Post by Steve Jones
not, having a half-way house of "kinda" doesn't help anyone or

add any

Post by Steve Jones
sort of clarity and formalism.

Dunno, but I think it has been said before in this thread that

from a

Post by Jan Algermissen
REST POV, URIs are simply opaque identifiers.

So in other words it is _important_ for REST that the URI be
meaningless? (http://www.askoxford.com/concise_oed/opaque?view=uk)
opaque: difficult or impossible to understand
So surely this means that the examples I used with sensible names that
mean something are therefore _not_ REST as they are easy to
understand.
Given therefore that REST URIs are meant to be unintelligable (which I
really don't understand as to why that is a good thing) how do you
communicate to consumers what URIs to use? What is the way of
documenting URIs to consumers?

Steve Jones

2006-12-06 16:27:33 UTC

Post by Stefan Tilkov
I have a feeling you're seeing a problem where there actually is
none. A URI is an identifier, much like a variable identifier in a
programming language.

Which means that it is critical that the name is sensible (i.e. not opaque).

Post by Stefan Tilkov
Having a variable named "ajkshdkajshd" is probably a bad idea, having
"SecondaryShippingAddress" is probably much better. Using reflection
mechanisms and string parsing methods to extract the word "Secondary"
from the identifier to drive application logic is probably a bad
idea, though.

But if you have PrimaryShippingAddress and SecondaryShippingAddress it
is sensible for a developer to have an "if" statement that checks if
Primary is valid and ships to Secondary if not.

Post by Stefan Tilkov
From the point of view of the programming language, identifiers are
"opaque" in the sense that the characters just have to follow the
syntactical rules, nothing more - from that POV they are meaningless.

Not at all, the aim of them is communication to the developer and not
to the compiler. For this reason they are a long way away from being
opaque.

Either REST says that URIs need to be sensible and meaningful names or
its okay to have rubbish and there is another bit that gives meaning.
The fact that someone can do something badly (e.g. have a bad variable
or method name) doesn't mean that this should be the standard.

So should REST URIs have meaning or are they opaque?

Post by Stefan Tilkov
Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Post by Steve Jones
This to me is a cop-out, either URIs should be meaningful in

REST or

Post by Steve Jones
not, having a half-way house of "kinda" doesn't help anyone or

add any

Post by Steve Jones
sort of clarity and formalism.

Dunno, but I think it has been said before in this thread that

from a

Post by Jan Algermissen
REST POV, URIs are simply opaque identifiers.

So in other words it is _important_ for REST that the URI be
meaningless? (http://www.askoxford.com/concise_oed/opaque?view=uk)
opaque: difficult or impossible to understand
So surely this means that the examples I used with sensible names that
mean something are therefore _not_ REST as they are easy to
understand.
Given therefore that REST URIs are meant to be unintelligable (which I
really don't understand as to why that is a good thing) how do you
communicate to consumers what URIs to use? What is the way of
documenting URIs to consumers?

Jan Algermissen

2006-12-06 18:19:50 UTC

Post by Steve Jones
Either REST says that URIs need to be sensible and meaningful names or
its okay to have rubbish and there is another bit that gives meaning.

Steve,

why don't you take a look what REST says about resource identifiers and then we discuss *that*?

Jan

Post by Steve Jones
The fact that someone can do something badly (e.g. have a bad variable
or method name) doesn't mean that this should be the standard.
So should REST URIs have meaning or are they opaque?

Post by Paul Fremantle
Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Post by Steve Jones
This to me is a cop-out, either URIs should be meaningful in

REST or

Post by Steve Jones
not, having a half-way house of "kinda" doesn't help anyone or

add any

Post by Steve Jones
sort of clarity and formalism.

Dunno, but I think it has been said before in this thread that

from a

Post by Jan Algermissen
REST POV, URIs are simply opaque identifiers.

So in other words it is _important_ for REST that the URI be
meaningless? (http://www.askoxford.com/concise_oed/opaque?view=uk)
opaque: difficult or impossible to understand
So surely this means that the examples I used with sensible names that
mean something are therefore _not_ REST as they are easy to
understand.
Given therefore that REST URIs are meant to be unintelligable (which I
really don't understand as to why that is a good thing) how do you
communicate to consumers what URIs to use? What is the way of
documenting URIs to consumers?

Paul Fremantle

2006-11-29 09:29:04 UTC

Post by Mark Baker
No Steve, REST doesn't encode the method within the URI. With all due
respect, that statement shows me that you don't yet understand it.

Check out SOAFacts.com. Especially the third fact. Maybe we need
RESTfacts.com too.

Paul

--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
paul-***@public.gmane.org

"Oxygenating the Web Service Platform", www.wso2.com

algermissen1971

2006-11-29 10:41:59 UTC

Post by Paul Fremantle
Check out SOAFacts.com. Especially the third fact. Maybe we need
RESTfacts.com too.

REST can kill SOA *and* Chuck Norris!

(So why would anyone prefer SOA over REST....??? :-)

Jan

Post by Paul Fremantle
Paul
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
"Oxygenating the Web Service Platform", www.wso2.com

Mark Baker

2006-11-24 19:49:44 UTC

Paul,

Post by Paul Fremantle
It is perhaps a little bit wrong to talk about REST as an option for
a Service Oriented Architecture. Most existing services don't cleanly
map into REST, except those directly backed by a resource model such
as a database. Even a layer of stored procedures over the data is
likely to mean that you cannot map it into REST.

Not at all!! Resource oriented means little more than data oriented.
Give me an example of something that you don't think maps well onto
REST and I'll see what I can do. Don't get me wrong, there *are*
scenarios which don't map well. Just not the ones you're suggesting,
AFAICT.

Post by Paul Fremantle
I think its time to call the Rest-ians on their distinctions. There
are plenty of RESTians taking a hard line on what is "REST" and what
isn't,

Because REST is *very* tightly defined. *cough* 8-)

Post by Paul Fremantle
and at the same time willing to say that REST is the only good
solution for an SOA.

Whoa, nobody's saying that AFAIK. What we're trying to say at least,
is that REST is a great place to start if your system is data oriented
(large messages).

More than anything though, we're trying to promote principled design;
adopting architectural constraints which provide you the architectural
properties you need for the context in which you'll be deploying your
systems. By that measure, Web services are *not* principally
designed; they're far too tightly coupled to be useful for integration
at scale, or to evolve cleanly over time (which is, technically, a
form of integration at scale).

Post by Paul Fremantle
Well, if you analyze most "services" and SOA they
aren't based on state transitions of resources. Trying to have your
cake and eat it?

Sorry, I can't grok "based on state transitions of resources".

Mark.

Paul Fremantle

2006-11-25 10:43:34 UTC

Post by Mark Baker
Not at all!! Resource oriented means little more than data oriented.
Give me an example of something that you don't think maps well onto
REST and I'll see what I can do. Don't get me wrong, there *are*
scenarios which don't map well. Just not the ones you're suggesting,
AFAICT.

Mark

There are hundreds of legacy systems that were designed using the
simple message-in, message-out model. These have formed the basis of
proto-SOAs for many years. When I was at IBM I talked to hundreds of
customers who had existing CICS, RPC, C, C++, Fortran, and MQSeries
based systems that had this model. By layering XML interfaces,
standard protocols like HTTP, and metadata such as XML Schema and WSDL
in front of these, they can be converted into universally accessible
services.

Converting them to REST - using the real REST definitions - is no simple task.

For a simple example, why don't you take something like RosettaNet
(http://www.rosettanet.org/), which is a widely adoped B2B protocol
(used heavily in the electronics component industry), and map that
into a REST model for us. RosettaNet is just one of many protocols and
approaches that were "service" oriented before it became a buzzword.

Paul

Post by Paul Fremantle
I think its time to call the Rest-ians on their distinctions. There
are plenty of RESTians taking a hard line on what is "REST" and what
isn't,

Because REST is *very* tightly defined. *cough* 8-)

Post by Paul Fremantle
and at the same time willing to say that REST is the only good
solution for an SOA.

Whoa, nobody's saying that AFAIK. What we're trying to say at least,
is that REST is a great place to start if your system is data oriented
(large messages).
More than anything though, we're trying to promote principled design;
adopting architectural constraints which provide you the architectural
properties you need for the context in which you'll be deploying your
systems. By that measure, Web services are *not* principally
designed; they're far too tightly coupled to be useful for integration
at scale, or to evolve cleanly over time (which is, technically, a
form of integration at scale).

Post by Paul Fremantle
Well, if you analyze most "services" and SOA they
aren't based on state transitions of resources. Trying to have your
cake and eat it?

Sorry, I can't grok "based on state transitions of resources".
Mark.
Yahoo! Groups Links

--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
paul-***@public.gmane.org

"Oxygenating the Web Service Platform", www.wso2.com

Michael Poulin

2006-11-24 21:35:05 UTC

I agree with Paul.

If we can find how much money business makes on its processes and services vs. how much it makes on its resource utilization, we will get the picture of the role of ROA in SOA. My uneducated guess is that portion in profit coming from just resource utilization (business data) is far from 100%. That is, the rest of SOA does not need to use REST. Let's be realistic/pragmatic in IT instead of religious.

- Michael

Paul Fremantle <pzfreo-***@public.gmane.org> wrote: Stefan

My favourite internet Irish tin whistle music website uses SOAP to
link to Google, and Yahoo uses SOAP to power its email client, so I
don't think you can say SOAP on the internet is dead. I give the music
website as an example of a small organisation that isn't "enterprise".

Anyway, that wasn't my main point!

It is perhaps a little bit wrong to talk about REST as an option for
a Service Oriented Architecture. Most existing services don't cleanly
map into REST, except those directly backed by a resource model such
as a database. Even a layer of stored procedures over the data is
likely to mean that you cannot map it into REST.

Really you should be talking about Resource Oriented Architecture (ROA).

I actually think ROA has a number of attractive aspects, but I don't
think its the solution to everything. I think that a POX (Plain Ole
XML) or SOAP approach is going to be required because not everyone
thinks in a resource oriented way.

I think its time to call the Rest-ians on their distinctions. There
are plenty of RESTians taking a hard line on what is "REST" and what
isn't, and at the same time willing to say that REST is the only good
solution for an SOA. Well, if you analyze most "services" and SOA they
aren't based on state transitions of resources. Trying to have your
cake and eat it?

Paul

I agree with the notion that business is more important than IT, and
many, many IT folks should work to learn a lot more about the actual
business value and their part (or lack of) in it.
Whether or not REST vs. WS-* or Java vs. Ruby or C++ vs. Smalltalk or
Windows vs. Linux vs. OS X is relevant or not depends very much on
the topic of the discussion we're having. When we're talking about
business strategies for a telecommunications company, Java vs. Ruby
doesn't play a big role. That doesn't mean that they're the same
even if they're both "just programming languages".
Similarly, I refuse to agree with the assertion that when I look at
the technical, architectural properties of a system landscape, it
doesn't matter whether its architecture is built around DCOM/MTS,
J2EE, WS-* or REST.
But that's all beside Steve's original point, which IIRC was "even if
it's cool, it doesn't matter because the vendors don't do it". I
disagree: Witness the inclusion of (admittedly bad) REST support in
Indigo/WCF and Axis2, or the Systinet 2 repository's REST interface,
or the fact that Google's Nelson Minar now asserts he'd never choose
SOAP and WSDL over REST again on the Internet, it seems to me that
SOAP/WSDL has clearly lost, and this does not bode well for its
future in the enterprise.
I will continue to help build good WS-based architectures I'm not
as principled as Mark Baker :-) Whenever I can get someone to listen,
I will try to convince them of the REST alternative, though, and I
expect this to get easier over the course of the next few years.
Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

The problem isn't the technical standards IMO, its the modelling of
the business and what a service should _be_ that is the biggest
challenge to successful SOA adoption and implementation.
+1
I would add, if Steve does not already have it as part of his
interpretation of modeling the business, that semantic
understanding and agreement on the information that the business is
working with, as well the cultural/organizational aspects are also
a critical challenges to SOA adoption and implemenation.
Regards,
- Anil
:-
:- Anil John
:- http://www.aniltj.com/blog
:-

Stefan Tilkov

2006-11-24 22:50:16 UTC

Post by Michael Poulin
I agree with Paul.
If we can find how much money business makes on its processes and
services vs. how much it makes on its resource utilization, we will
get the picture of the role of ROA in SOA. My uneducated guess is
that portion in profit coming from just resource utilization
(business data) is far from 100%. That is, the rest of SOA does
not need to use REST. Let's be realistic/pragmatic in IT instead
of religious.

Michael, that seems to be based on a misunderstanding - REST does not
suggest you expose your persistent entities instead of the business
logic. This is like saying object orientation does not support
business logic because it exposes database records.

REST is not CRUD on entities.

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Post by Michael Poulin
- Michael

Michael Poulin

2006-11-25 10:11:48 UTC

GT2HQ-PY23H-TF8GH-V44YJ-DBKDJ

Stefan,

Post by Sanjiva Weerawarana
Wait, how do you advocate REST as an implementation technology for
*service* oriented architecture when REST doesn't have the concept of
services but rather has the concept of resources?
Sanjiva.

If object orientation would "exposes database records" only, I thought it did not support business logic. If REST is resource-oriented solution and business logic is not only in utilization of the resources ( and not only in exchange of plain XML documents), then I would not insist on that REST is THE "implementation technology for *service* oriented architecture" but rather one among others, in adequate cases (e.g., for technical services concentrated on resources).

- Michael

Post by Sanjiva Weerawarana
I agree with Paul.
If we can find how much money business makes on its processes and
services vs. how much it makes on its resource utilization, we will
get the picture of the role of ROA in SOA. My uneducated guess is
that portion in profit coming from just resource utilization
(business data) is far from 100%. That is, the rest of SOA does
not need to use REST. Let's be realistic/pragmatic in IT instead
of religious.

Post by Sanjiva Weerawarana
- Michael

---------------------------------
Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates.

Stefan Tilkov

2006-11-24 22:45:52 UTC

Well, maybe dead is relative -- but I don't think SOAP/WSDL would be
the obvious first choice for anyone doing a "Web API" nowadays.

Post by Paul Fremantle
Anyway, that wasn't my main point!
It is perhaps a little bit wrong to talk about REST as an option for
a Service Oriented Architecture. Most existing services don't cleanly
map into REST, except those directly backed by a resource model such
as a database. Even a layer of stored procedures over the data is
likely to mean that you cannot map it into REST.
Really you should be talking about Resource Oriented Architecture (ROA).

I agree, provided we're talking about SOA, the technology/
architecture, not SOA, the business concept (as used e.g. by Steve
Jones).

Post by Paul Fremantle
I actually think ROA has a number of attractive aspects, but I don't
think its the solution to everything. I think that a POX (Plain Ole
XML) or SOAP approach is going to be required because not everyone
thinks in a resource oriented way.

POX doesn't have a real definition, at least none that I know of. For
the sake of the argument, let's assume that POX can be just as non-
RESTful as SOAP 1.1 and as RESTful as the Atom Publishing Protocol
(which, after all, uses only plain old XML). IMO, the more RESTful,
the better, but I'm not zealous here. Obviously anything that works
is fine. Which is beside the point, I think.

Post by Paul Fremantle
I think its time to call the Rest-ians on their distinctions. There
are plenty of RESTians taking a hard line on what is "REST" and what
isn't,

That's actually one of its benefits, IMO - it's pretty easy to assess
the "RESTfulness" of something. It's pretty hard to do that for
"service-orientation" :-)

Post by Paul Fremantle
and at the same time willing to say that REST is the only good
solution for an SOA. Well, if you analyze most "services" and SOA they
aren't based on state transitions of resources. Trying to have your
cake and eat it?

I don't get that point. Many existing SOAs use Web services and are
modeled in a way that could have been achieved with CORBA (and, as
Eric is sure to point out, some have even been built on CORBA). So
what? REST proponents suggest that there's a better way, and that
it's different.

I agree that using your terminology, I'm advocating ROA instead of
SOA. Using Steve's terminology, I prefer REST as an implementation
architecture for (business) SOA as opposed to WS-*.

Stefan

Post by Paul Fremantle
Paul

I agree with the notion that business is more important than IT, and
many, many IT folks should work to learn a lot more about the actual
business value and their part (or lack of) in it.
Whether or not REST vs. WS-* or Java vs. Ruby or C++ vs. Smalltalk or
Windows vs. Linux vs. OS X is relevant or not depends very much on
the topic of the discussion we're having. When we're talking about
business strategies for a telecommunications company, Java vs. Ruby
doesn't play a big role. That doesn't mean that they're the same
even if they're both "just programming languages".
Similarly, I refuse to agree with the assertion that when I look at
the technical, architectural properties of a system landscape, it
doesn't matter whether its architecture is built around DCOM/MTS,
J2EE, WS-* or REST.
But that's all beside Steve's original point, which IIRC was "even if
it's cool, it doesn't matter because the vendors don't do it". I
disagree: Witness the inclusion of (admittedly bad) REST support in
Indigo/WCF and Axis2, or the Systinet 2 repository's REST interface,
or the fact that Google's Nelson Minar now asserts he'd never choose
SOAP and WSDL over REST again on the Internet, it seems to me that
SOAP/WSDL has clearly lost, and this does not bode well for its
future in the enterprise.
I will continue to help build good WS-based architectures I'm not
as principled as Mark Baker :-) Whenever I can get someone to listen,
I will try to convince them of the REST alternative, though, and I
expect this to get easier over the course of the next few years.
Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
"Oxygenating the Web Service Platform", www.wso2.com
Yahoo! Groups Links

Sanjiva Weerawarana

2006-11-25 07:08:18 UTC

Well, maybe dead is relative -- but I don't think SOAP/WSDL would be
the obvious first choice for anyone doing a "Web API" nowadays.

Well it shouldn't be .. if you don't need SOAP you don't need it. If all
you need is to send some XML over HTTP or HTTPS then SOAP is not at all
needed. SOAP should come into the picture IFF you need message level
security, reliability or transactions or any of the other things that
have been built on SOAP. If not why pay the price?

WSDL? You either need WSDL (2.0, not 1.1 as the new version has much
better POX/HTTP support) or something like it. How else do you tell
other (computers) what your RESTful service does? Why do you think
people are creating things like WADL (which is basically a cut down
version of WSDL targeting only POX/HTTP cases; I feel bad for anyone who
also wants to expose an XMPP way to talk talk to the service).

Post by Paul Fremantle
Really you should be talking about Resource Oriented Architecture (ROA).

I agree, provided we're talking about SOA, the technology/
architecture, not SOA, the business concept (as used e.g. by Steve
Jones).

+1.

Post by Paul Fremantle
I think its time to call the Rest-ians on their distinctions. There
are plenty of RESTians taking a hard line on what is "REST" and what
isn't,

That's actually one of its benefits, IMO - it's pretty easy to assess
the "RESTfulness" of something. It's pretty hard to do that for
"service-orientation" :-)

OK if its easy then let's see the criteria. RESTafarians say cookies are
not RESTful etc.. How do you see a GET http://foo.com/xyz?a=b&y=10 and
say whether its RESTful or not?

Post by Stefan Tilkov
I agree that using your terminology, I'm advocating ROA instead of
SOA. Using Steve's terminology, I prefer REST as an implementation
architecture for (business) SOA as opposed to WS-*.

Wait, how do you advocate REST as an implementation technology for
*service* oriented architecture when REST doesn't have the concept of
services but rather has the concept of resources?

Sanjiva.

Stefan Tilkov

2006-11-25 12:16:38 UTC

Too bad we have no agreed upon definition of SOA, but I thought we

Post by Sanjiva Weerawarana
Really you should be talking about Resource Oriented Architecture (ROA).
I agree, provided we're talking about SOA, the technology/
architecture, not SOA, the business concept (as used e.g. by Steve
Jones).
+1.

So, we agree that SOA (as supported by WS-*) and ROA (as supported by
RESTful HTTP) are different *technical* concepts. We could call this
SOA view "technical SOA".

Alternatively, we can also define SOA as a high-level business
architecture, let's call this view "business SOA". "Business SOA" is
a strategy that aligns IT capabilities and *business* offerings,
enables agility in the enterprise, allows for new business models,
improves transparency of costs etc. (To me, that's "the Steve Jones
view"). This is valid, as well, and from this perspective, "technical
SOA" and ROA are both valid implementation concepts.

I don't like this terminology; it would be far easier if we had
clearly different terms. The fact that some view SOA as a technical
architecture while others are convinced it has nothing to with
technology or IT at all makes these discussions pretty hard. Don't
blame me for this confusion :-) No-one from this list has managed to
come up with a definition of SOA yet that we can all agree with.

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Sanjiva Weerawarana

2006-11-25 14:45:16 UTC

Post by Stefan Tilkov
Alternatively, we can also define SOA as a high-level business
architecture, let's call this view "business SOA". "Business SOA" is
a strategy that aligns IT capabilities and *business* offerings,
enables agility in the enterprise, allows for new business models,
improves transparency of costs etc. (To me, that's "the Steve Jones
view"). This is valid, as well, and from this perspective, "technical
SOA" and ROA are both valid implementation concepts.

OK fair enough! I agree.

Sanjiva.

Anil John

2006-11-25 16:22:20 UTC

<StefanTilkov>
Too bad we have no agreed upon definition of SOA
</StefanTilkov>

<Gervas>
No one anywhere in the known universe has yet come up with a definition
of SOA which commands widespread acceptance.
</Gervas>

Would I be correct in my understanding that the OASIS SOA-RM Definition
of SOA [1] is pretty much of a non-starter with this group (With the
exception of Steve of course)? As such do you all see any value in
building on top of it? For example, would you see folks from this group
participating in the OASIS SOA RA (Reference Architecture) work, given
that it is built on top of the RM?

Regards,

- Anil

[1] http://en.wikipedia.org/wiki/OASIS_SOA_Reference_Model

:-
:- Anil John
:- http://www.aniltj.com/blog
:-

Steve Jones

2006-11-25 18:55:48 UTC

It would be really great to understand why the SOA RM is a non-starter,
there are bits I'd like to see in future in the standard, so it would be
great to see what people think could be improved on, or the basic
challenges.

But please remember that a definition needs to be non-technology specific.

Post by Anil John
<StefanTilkov>
Too bad we have no agreed upon definition of SOA
</StefanTilkov>
<Gervas>
No one anywhere in the known universe has yet come up with a definition
of SOA which commands widespread acceptance.
</Gervas>
Would I be correct in my understanding that the OASIS SOA-RM Definition
of SOA [1] is pretty much of a non-starter with this group (With the
exception of Steve of course)? As such do you all see any value in
building on top of it? For example, would you see folks from this group
participating in the OASIS SOA RA (Reference Architecture) work, given
that it is built on top of the RM?
Regards,
- Anil
[1] http://en.wikipedia.org/wiki/OASIS_SOA_Reference_Model
:-
:- Anil John
:- http://www.aniltj.com/blog
:-

Anil John

2006-11-25 19:49:51 UTC

<SteveJones>
It would be really great to understand why the SOA RM is a non-starter,
there are bits I'd like to see in future in the standard, so it would be
great to see what people think could be improved on, or the basic
challenges.
But please remember that a definition needs to be non-technology
specific.
</SteveJones>

Indeed! As someone who is currently participating in the OASIS SOA-RA
process, I too am really interested in this answer. If for nothing else
but to make sure that time, effort and energy are being put into the
right buckets that will resonate with folks who are implementing SOA
based solutions.

Regards,

- Anil

On 25/11/06, Anil John <aniltj-***@public.gmane.org > wrote:

<StefanTilkov>
Too bad we have no agreed upon definition of SOA
</StefanTilkov>

<Gervas>
No one anywhere in the known universe has yet come up with a
definition
of SOA which commands widespread acceptance.
</Gervas>

Would I be correct in my understanding that the OASIS SOA-RM
Definition
of SOA [1] is pretty much of a non-starter with this group (With
the
exception of Steve of course)? As such do you all see any value
in
building on top of it? For example, would you see folks from
this group
participating in the OASIS SOA RA (Reference Architecture) work,
given
that it is built on top of the RM?

Regards,

- Anil

[1] http://en.wikipedia.org/wiki/OASIS_SOA_Reference_Model

:-
:- Anil John
:- http://www.aniltj.com/blog
:-

Mark Baker

2006-11-25 13:44:04 UTC

Post by Stefan Tilkov
Well, maybe dead is relative -- but I don't think SOAP/WSDL would be
the obvious first choice for anyone doing a "Web API" nowadays.

What's interesting about this argument is an implicit assumption being
made; that if you had an existing HTTP/URI based Web API, but then
later found it needed "security, reliability, or transactions", that
you need to abandon the existing Web API and replace it with SOAP.
What about, oh, say, *adding* those ilities incrementally, within the
constraints of the existing API?

Post by Sanjiva Weerawarana
OK if its easy then let's see the criteria. RESTafarians say cookies are
not RESTful etc.. How do you see a GET http://foo.com/xyz?a=b&y=10 and
say whether its RESTful or not?

As you would answer any question of that sort; by looking at the messages.

Wait, how do you advocate REST as an implementation technology for
*service* oriented architecture when REST doesn't have the concept of
services but rather has the concept of resources?

Because virtually all services can be used as resources (usually more
than one resource per service though).

Mark.

Sanjiva Weerawarana

2006-11-25 14:50:53 UTC

Post by Sanjiva Weerawarana
Well it shouldn't be .. if you don't need SOAP you don't need it. If all
you need is to send some XML over HTTP or HTTPS then SOAP is not at all
needed. SOAP should come into the picture IFF you need message level
security, reliability or transactions or any of the other things that
have been built on SOAP. If not why pay the price?

Hey great idea! OK now tell me, what exactly does one need to do to add
message level security to HTTP? After I sign the message where do I put
it so the recipient will always check that before touching the message?

How about reliability? (Remember HTTP-R?)

How about transactions?

NOTE: We need interoperable standards with corresponding metadata (i.e.,
policies) for all of the above so that tools can work with them.

Please tell me what standards in non-WS-* REST-land do these things.

As you would answer any question of that sort; by looking at the messages.

?? No way. Only the owner of the resource can say whether this GET is
safe or not. How can you possibly say that by looking at the messages?!

Because virtually all services can be used as resources (usually more
than one resource per service though).

So your proposal is to first make service, and then introduce resources
in front of services to make it RESTful and then, voila!, you have a
beautiful RESTful system? Um, why bother with that extra layer of
complexity when the underlying guts are service oriented already?

Sanjiva.

Stefan Tilkov

2006-11-25 17:49:26 UTC

Post by Sanjiva Weerawarana
Well it shouldn't be .. if you don't need SOAP you don't need

it. If all

Post by Sanjiva Weerawarana
you need is to send some XML over HTTP or HTTPS then SOAP is

not at all

Post by Sanjiva Weerawarana
needed. SOAP should come into the picture IFF you need message

level

Post by Sanjiva Weerawarana
security, reliability or transactions or any of the other

things that

Post by Sanjiva Weerawarana
have been built on SOAP. If not why pay the price?

What's interesting about this argument is an implicit assumption

being

Post by Mark Baker
made; that if you had an existing HTTP/URI based Web API, but then
later found it needed "security, reliability, or transactions", that
you need to abandon the existing Web API and replace it with SOAP.
What about, oh, say, *adding* those ilities incrementally, within

the

Post by Mark Baker
constraints of the existing API?

Hey great idea! OK now tell me, what exactly does one need to do to add
message level security to HTTP? After I sign the message where do I put
it so the recipient will always check that before touching the
message?
How about reliability? (Remember HTTP-R?)
How about transactions?
NOTE: We need interoperable standards with corresponding metadata (i.e.,
policies) for all of the above so that tools can work with them.

Semi-seriously, I say "no, we don't". Let's take transactions as the
first example. Here are my three reasons why we don't need WS-
Coordination, WS-BusinessActivity or WS-AtomicTransaction:
1) There are many successful WS-* implementations already (or so
everybody tells me), and none of them currently relies on these
(because they're neither finalized nor widely supported)
2) Atomic (2PC) transactions are a bad idea for loosely-coupled
systems (I consider them to be the most tightly approach you can take)
3) Even using compensations à la WS-BusinessActivity, IMO, belong in
the application -- they're business logic anyway, and I don't see
what standards support buys you here

Post by Sanjiva Weerawarana
Please tell me what standards in non-WS-* REST-land do these things.

As to transactions, I don't think anyone has bothered yet. As for
reliability, examples include

SOA-Rity (http://www.goland.org/soareliability/) (by Yaron Goland) and
HTTPLR (http://www.dehora.net/doc/httplr/draft-httplr-00.html) by
Bill de hÓra

I agree that none of them is standardized yet, which doesn't prevent
anyone from using them in their own applications, but hinders tool
development (which can be considered a disadvantage).

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Steve Jones

2006-11-25 20:51:06 UTC

Post by Sanjiva Weerawarana
Well it shouldn't be .. if you don't need SOAP you don't need

it. If all

Post by Sanjiva Weerawarana
you need is to send some XML over HTTP or HTTPS then SOAP is

not at all

Post by Sanjiva Weerawarana
needed. SOAP should come into the picture IFF you need message

level

Post by Sanjiva Weerawarana
security, reliability or transactions or any of the other

things that

Post by Sanjiva Weerawarana
have been built on SOAP. If not why pay the price?

What's interesting about this argument is an implicit assumption

being

the

Post by Mark Baker
constraints of the existing API?

Hey great idea! OK now tell me, what exactly does one need to do to add
message level security to HTTP? After I sign the message where do I put
it so the recipient will always check that before touching the message?
How about reliability? (Remember HTTP-R?)
How about transactions?
NOTE: We need interoperable standards with corresponding metadata (i.e.,
policies) for all of the above so that tools can work with them.

Semi-seriously, I say "no, we don't". Let's take transactions as the
first example. Here are my three reasons why we don't need WS-

I'm with you on these ones, Atomic Transaction on Web Services... I shudder.

Post by Stefan Tilkov
1) There are many successful WS-* implementations already (or so
everybody tells me), and none of them currently relies on these
(because they're neither finalized nor widely supported)

I remember in 2001 having to do authenticated security using WS, so it
was HTTP/S with client side certificates enforced by Apache. It
worked and it was very secure, but its much better having standards
like now exist. I completely agree than some of WS-* is 100%
pointless and almost seems to be done because the product developers
find it easy to do a certain type of standards that focus on a
re-implementation of things that were better done without WS.

Post by Stefan Tilkov
2) Atomic (2PC) transactions are a bad idea for loosely-coupled
systems (I consider them to be the most tightly approach you can take)
3) Even using compensations à la WS-BusinessActivity, IMO, belong in
the application -- they're business logic anyway, and I don't see
what standards support buys you here

Post by Sanjiva Weerawarana
Please tell me what standards in non-WS-* REST-land do these things.

As to transactions, I don't think anyone has bothered yet. As for
reliability, examples include
SOA-Rity (http://www.goland.org/soareliability/) (by Yaron Goland) and
HTTPLR (http://www.dehora.net/doc/httplr/draft-httplr-00.html) by
Bill de hÓra
I agree that none of them is standardized yet, which doesn't prevent
anyone from using them in their own applications, but hinders tool
development (which can be considered a disadvantage).

Cheers for those pair, I hadn't come across them before, I'll go an
have a look. Tool development and broad vendor acceptance is critical
however.

Post by Stefan Tilkov
Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Sanjiva Weerawarana

2006-11-26 01:49:12 UTC

Post by Stefan Tilkov
Semi-seriously, I say "no, we don't". Let's take transactions as the
first example. Here are my three reasons why we don't need WS-

The reason you need something to support transactions is to be able to
build transactional applications that span a collection of services. Are
you saying that's not a useful or valid scenario?

You've changed the topic around to WS-* bashing again .. the question on
the table was how you do this stuff in REST :). FWIW I agree the WS-*
version of the TX space is definitely lagging yet.

Post by Stefan Tilkov
2) Atomic (2PC) transactions are a bad idea for loosely-coupled
systems (I consider them to be the most tightly approach you can take)

Of course, for widely distributed scenarios. However the most common
usecase for WS-AT is to hold a transaction across a Windows system and a
Java system "nearby". Is there another way to do that?

Post by Stefan Tilkov
3) Even using compensations Ã la WS-BusinessActivity, IMO, belong in
the application -- they're business logic anyway, and I don't see
what standards support buys you here

That's exactly what WS-BA does- allow the application to become part of
the transaction protocol .. the value of a standard is to be able to
bring different services together into a single coordinated activity.
Again are you seriously saying that's not a valid scenario? I agree its
not a usecase for simple Web stuff but it most certainly is IMO is
enterprise environments.

I actually believe WS-BA will be very useful in Web scenarios as well.
We just need very simple implementations and execution environments and
we just don't have them yet.

Post by Sanjiva Weerawarana
Please tell me what standards in non-WS-* REST-land do these things.

As to transactions, I don't think anyone has bothered yet. As for
reliability, examples include
SOA-Rity (http://www.goland.org/soareliability/) (by Yaron Goland) and
HTTPLR (http://www.dehora.net/doc/httplr/draft-httplr-00.html) by
Bill de hÃra
I agree that none of them is standardized yet, which doesn't prevent
anyone from using them in their own applications, but hinders tool
development (which can be considered a disadvantage).

Its more than tool support: what matters on the Web is
*interoperability*. If I publish a service and it requires reliability
to work well, I should be able to publish an interoperable protocol that
a client from VB to C to Java to Cobol can do. The only way to do that
is to have standards that all vendors support.

That's the real challenge for REST. Remember that there's nothing new in
REST- its been around for 15+ years and has worked great for the Web.
Saying its the silver bullet for integration is a bit of a stretch when
many of the core needs of integration are not met by the technology.
Whether you like the details or not, they *are* met by WS-* stuff.

Sanjiva.

Mike Glendinning

2006-11-26 12:13:52 UTC

On atomic transactions between multiple systems, I tend to agree with
Stefan and Steve. In more than 20 years of building distributed
systems, I've always found a better way than using 2PC protocols.

Besides, if your systems are so tightly coupled that they need to do
2PC then you might as well use a tightly coupled technology (LU6.2,
Tuxedo, CORBA or whatever) to connect them.

But Sanjiva makes a good point. Given that Microsoft is only
supporting WS-Everything and not others for interconnection with its
systems, you may well have a "tightly coupled" scenario of a Windows
platform sitting next to a Java platform requiring 2PC style
interactions. Perhaps here, WS-Everything is your only choice and
this also ties in with Steve's argument about the importance of
vendor technology support.

When it comes to business transactions, I have a different opinion
though.

Back in 1995/6 I designed and built a large integrated CRM system for
a telco. To implement a "single view of customer" database we had to
integrate (in real time) with dozens of other systems from many
different vendors.

Our solution was a message-oriented middleware integration framework
using request/response messaging. Of course there was no XML in
those days, so we had to invent our own flexible message format
consisting of name/value pairs and ASCII encoding. By implementing
our own APIs we could get read access to most of the customer data
required.

Unfortunately, several of the "back end" application vendors wouldn't
allow us to update their systems directly [for obvious reasons] and
we had to resort to "screen scraping" as well. Oh and one of those
vendors was so concerned about their system performance that they
insisted we could only apply updates during quiet times (i.e.
overnight).

For those interested, our screen scraping tool was also custom
designed and was driven by what today you would call a Domain-
Specific Language (DSL).

With this heady mix of synchronous read and [massively] asynchronous
update activity, the preservation of overall data integrity was a big
issue and we had to design our own extended transaction model to
cope. This was a fairly classic "chained" transaction model where
each step in the transaction chain had its own "forward"
and "compensating" actions. The system could then [re-]apply or
reverse entire business transactions in sequence and on demand.

Building this business transaction framework was hard. Of course we
wrote our own tools to help generate code for each kind of
transaction step from a "service description" held as a
database "view", but it was still a lot of work.

Today I can see a lot of value in a standardised framework for such
business transactions. Yes, the actual transaction steps
are "business logic" and unique to each application, but a consistent
framework will save a lot of development time/effort and also ease
further integration and interoperability amongst similarly designed
systems.

-Mike.

Post by Stefan Tilkov
Semi-seriously, I say "no, we don't". Let's take transactions as the
first example. Here are my three reasons why we don't need WS-

The reason you need something to support transactions is to be able to
build transactional applications that span a collection of

services. Are

Post by Sanjiva Weerawarana
you saying that's not a useful or valid scenario?

You've changed the topic around to WS-* bashing again .. the

question on

Post by Sanjiva Weerawarana
the table was how you do this stuff in REST :). FWIW I agree the WS-

Post by Sanjiva Weerawarana
version of the TX space is definitely lagging yet.

Post by Stefan Tilkov
2) Atomic (2PC) transactions are a bad idea for loosely-coupled
systems (I consider them to be the most tightly approach you can take)

Of course, for widely distributed scenarios. However the most common
usecase for WS-AT is to hold a transaction across a Windows system and a
Java system "nearby". Is there another way to do that?

Post by Stefan Tilkov
3) Even using compensations Ã la WS-BusinessActivity, IMO, belong in
the application -- they're business logic anyway, and I don't see
what standards support buys you here

activity.

Post by Sanjiva Weerawarana
Again are you seriously saying that's not a valid scenario? I agree its
not a usecase for simple Web stuff but it most certainly is IMO is
enterprise environments.
I actually believe WS-BA will be very useful in Web scenarios as well.
We just need very simple implementations and execution environments and
we just don't have them yet.

Post by Sanjiva Weerawarana
Please tell me what standards in non-WS-* REST-land do these things.

As to transactions, I don't think anyone has bothered yet. As for
reliability, examples include
SOA-Rity (http://www.goland.org/soareliability/) (by Yaron

Goland) and

Post by Stefan Tilkov
HTTPLR (http://www.dehora.net/doc/httplr/draft-httplr-00.html) by
Bill de hÃ"ra
I agree that none of them is standardized yet, which doesn't

prevent

Post by Stefan Tilkov
anyone from using them in their own applications, but hinders tool
development (which can be considered a disadvantage).

Its more than tool support: what matters on the Web is
*interoperability*. If I publish a service and it requires

reliability

Post by Sanjiva Weerawarana
to work well, I should be able to publish an interoperable protocol that
a client from VB to C to Java to Cobol can do. The only way to do that
is to have standards that all vendors support.
That's the real challenge for REST. Remember that there's nothing new in
REST- its been around for 15+ years and has worked great for the Web.
Saying its the silver bullet for integration is a bit of a stretch when
many of the core needs of integration are not met by the technology.
Whether you like the details or not, they *are* met by WS-* stuff.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation;

http://www.opensource.lk/

Post by Sanjiva Weerawarana
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/

Stefan Tilkov

2006-11-26 18:49:31 UTC

It's more than tool support: what matters on the Web is
*interoperability*. If I publish a service and it requires reliability
to work well, I should be able to publish an interoperable protocol that
a client from VB to C to Java to Cobol can do. The only way to do that
is to have standards that all vendors support.

Ideally, *every* aspect of a service (in the most general sense)
should be standardized for maximum interoperability - we agree. In
fact, I believe both the designer of REST and WS-* believed in this
-- they just put the emphasis on different aspects.

For example, in the WS-* architecture it is commonly believed that
transactions is something that should be supported by the
infrastructure, and not need to be redone by every application.
In REST, a similar example is a fixed interface with standardized
methods (e.g. GET for "safe" operations), or a standard scheme for
resource identification.

You claim it's wrong to invent a possibly new and different way to do
transactions in every application. I claim it's wrong to invent a new
and different application interface in each and every application :-)

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Sanjiva Weerawarana

2006-11-27 02:46:30 UTC

Post by Stefan Tilkov
For example, in the WS-* architecture it is commonly believed that
transactions is something that should be supported by the
infrastructure, and not need to be redone by every application.
In REST, a similar example is a fixed interface with standardized
methods (e.g. GET for "safe" operations), or a standard scheme for
resource identification.
You claim it's wrong to invent a possibly new and different way to do
transactions in every application. I claim it's wrong to invent a new
and different application interface in each and every application :-)

So if I may extrapolate a bit .. are you seriously saying that the Web
as it existed in 1996 (HTTP, URIs, XML, REST) is *all* that is needed to
replace EDI, MQ and all the bazillion integration technologies and the
only reason it hasn't been used for that for the last 10 years is simply
lack of understanding? Do you seriously mean to say that we've had the
silver bullet in our hands all these years and simply didn't know it??

No, you can't be serious :).

To me, Web services is building on the Web to create a set of standards
that are needed to make integration ubiquitous, just as much as the Web
has made information dissemination ubiquitous. I clearly don't believe
the 1996 Web is enough.

Sanjiva.

Stefan Tilkov

2006-11-27 15:33:00 UTC

Post by Sanjiva Weerawarana
So if I may extrapolate a bit .. are you seriously saying that the Web
as it existed in 1996 (HTTP, URIs, XML, REST) is *all* that is
needed to
replace EDI, MQ and all the bazillion integration technologies and the
only reason it hasn't been used for that for the last 10 years is simply
lack of understanding? Do you seriously mean to say that we've had the
silver bullet in our hands all these years and simply didn't know it??

Well ... except that I don't claim it's a silver bullet - yes :-)

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Mark Baker

2006-11-27 16:32:07 UTC

Post by Sanjiva Weerawarana
So if I may extrapolate a bit .. are you seriously saying that the Web
as it existed in 1996 (HTTP, URIs, XML, REST) is *all* that is needed to
replace EDI, MQ and all the bazillion integration technologies and the
only reason it hasn't been used for that for the last 10 years is simply
lack of understanding? Do you seriously mean to say that we've had the
silver bullet in our hands all these years and simply didn't know it??

Well ... except that I don't claim it's a silver bullet - yes :-)

+1. And that's not to say that new technologies can't be used, but
only that the successful ones will be designed to work *with* the Web
(as additional architectural constraints), not against it as "Web
services" do.

http://www.markbaker.ca/blog/2005/12/03/the-end-of-the-plumbing-wars/

Mark.

Jan Algermissen

2006-11-27 07:49:34 UTC

Hi Stefan,

Post by Stefan Tilkov
In REST, a similar example is a fixed interface with standardized
methods (e.g. GET for "safe" operations)

Just checking: you do agree that GET is GET (which happens to be
defined to be safe) and not a tunnel for arbitrary safe operations.

IOW, GET's application semantic is 'get me a representation of the
current state of the resource' and not 'perfom some safe operation foo
()'.

Jan

Stefan Tilkov

2006-11-27 15:44:06 UTC

Post by Jan Algermissen
Hi Stefan,

Post by Stefan Tilkov
In REST, a similar example is a fixed interface with standardized
methods (e.g. GET for "safe" operations)

Just checking: you do agree that GET is GET (which happens to be
defined to be safe) and not a tunnel for arbitrary safe operations.
IOW, GET's application semantic is 'get me a representation of the
current state of the resource' and not 'perfom some safe operation foo
()'.

Yes, I do agree; I should have phrased that more clearly.

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Paul Fremantle

2006-11-27 09:32:26 UTC

Post by Stefan Tilkov
I claim it's wrong to invent a new
and different application interface in each and every application :-)

Stefan

I think it is a mischaracterization to say that you don't need to
invent an application interface with REST. Thats like saying that
there is no need for database designers because SQL defines a clear
CRUD interface.

The level of uniformity in REST is useful, and I like it, but without
defining the representation of the state (i.e. if its XML the schema)
in a clear way, the REST uniformity is a tiny fraction of the
definition.

The fact is that given a reasonably written and documented WSDL, any
programmer with a WSDL tool can probably use that service. Given the
REST model and a URL there's not much I can do except call GET and
guess what the results are going to be :-)

As far as I'm concerned, the *whole* point of SOA over and above
previous integration systems, is that there is clear metadata about
the message formats as well as interaction patterns. After all,
MQSeries and JMS also define clearly uniform methods (PUT, GET,
PUBLISH, SUBSCRIBE) as well.

I hope I'm not coming across as anti-REST, I think REST is an
excellent model. I just think that REST is coming up its hype curve
and WS-* is down at the bottom and that neither position is right.

Paul

--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
paul-***@public.gmane.org

"Oxygenating the Web Service Platform", www.wso2.com

Stefan Tilkov

2006-11-27 15:57:47 UTC

Post by Stefan Tilkov
I claim it's wrong to invent a new
and different application interface in each and every

application :-)
Stefan
I think it is a mischaracterization to say that you don't need to
invent an application interface with REST. Thats like saying that
there is no need for database designers because SQL defines a clear
CRUD interface.

I never claimed that you don't have to any design work when you use
REST. You don't have to design a new interface with custom
operations. You have to decide on your URIs, data formats,
schemas ... having one part fixed doesn't mean you don't have to care
about the REST.

Post by Stefan Tilkov
The level of uniformity in REST is useful, and I like it, but without
defining the representation of the state (i.e. if its XML the schema)
in a clear way, the REST uniformity is a tiny fraction of the
definition.

You can use XML Schema with REST ...

Post by Stefan Tilkov
The fact is that given a reasonably written and documented WSDL, any
programmer with a WSDL tool can probably use that service. Given the
REST model and a URL there's not much I can do except call GET and
guess what the results are going to be :-)

... given an XML Schema you can use all the data binding tools you
want. A GET on a customer URI that returns a representation that
conforms to that schema is just as easy to process (at least!) as a
GetCustomerData operation. It's much easier to test (think "curl" and
"wget", using file: URIs ...). Similar arguments apply to the other
methods.

If you give me a WSDL, I still to have to either guess at the
semantics, or understand them from some textual description. The same
is true for a RESTful interface.
I claim that REST's default interface + descriptions of the content
types + the resource design nets less than the comparable WSDL.

Post by Stefan Tilkov
As far as I'm concerned, the *whole* point of SOA over and above
previous integration systems, is that there is clear metadata about
the message formats as well as interaction patterns. After all,
MQSeries and JMS also define clearly uniform methods (PUT, GET,
PUBLISH, SUBSCRIBE) as well.

MQ and JMS also define concepts such as queues and topics, so I agree
- they are conceptually similar. But similar to REST, not similar to
CORBA or RMI :-)

Post by Stefan Tilkov
I hope I'm not coming across as anti-REST, I think REST is an
excellent model. I just think that REST is coming up its hype curve
and WS-* is down at the bottom and that neither position is right.

No, at least from my perspective we're having a very balanced and
unemotional discussion here :-)

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Post by Stefan Tilkov
Paul
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
"Oxygenating the Web Service Platform", www.wso2.com

Paul Fremantle

2006-11-27 18:48:14 UTC

Post by Stefan Tilkov
I claim it's wrong to invent a new
and different application interface in each and every

application :-)

What you say is true. I just think that what you wrote earlier made it
sound like more was done for you than is the truth.

Post by Stefan Tilkov
You can use XML Schema with REST ...

Sure you *can* use Schema, but unfortunately there is no uniform place
to put it, no uniform REST API to retrieve it (oh - except in WS
implementations like Axis2 :-) ), and no standard for whether the
schema applies to posted messages or response messages.

Post by Stefan Tilkov
... given an XML Schema you can use all the data binding tools you
want. A GET on a customer URI that returns a representation that
conforms to that schema is just as easy to process (at least!) as a
GetCustomerData operation.

Of course.

Post by Stefan Tilkov
If you give me a WSDL, I still to have to either guess at the
semantics, or understand them from some textual description. The same
is true for a RESTful interface.

Yes, sure that's true. But of course, because there is no machine
readable standard for associating schemas with REST APIs (other than
the POX binding in WSDL 2.0) there is much more work to be done by the
human author and more possibility of mistake.

I notice you didn't respond to this.

Post by Stefan Tilkov
After all,
MQSeries and JMS also define clearly uniform methods (PUT, GET,
PUBLISH, SUBSCRIBE) as well.

MQ and JMS also define concepts such as queues and topics, so I agree
- they are conceptually similar. But similar to REST, not similar to
CORBA or RMI :-)

Of course WSDL defines uniform interfaces too. It has the concept of
in, out, fault messages, endpoints, message exchange patterns, and
schemas for types. In fact there is just as much uniformity with WSDL
as there is with MQ. I think that if you are comparing SOAP with CORBA
and RMI then you have a very outdated and mistaken view of SOAP. There
are significant differences that make SOAP much more like MQ and JMS,
as well as REST.

In particular:

* SOAP and WSDL inherently support asynchrony.
* Ever since WS-I banned SOAP encoding, SOAP is very much document and
not object based.
* SOAP is based on duck-typing
(http://en.wikipedia.org/wiki/Duck_typing), whereas CORBA and RMI are
very tightly tied to specific instances of classes which means that
they are much more fragile than duck-typed, document-based systems.

Most SOAP tools give an object-broker like model to developers,
because, wait for it, that is what developers want. The original Axis2
design was fundamentally about giving a very XML-message based view of
the world - which is incredibly similar to JMS, MQ, and the XML
binding + HTTP GET/POST that you are advocating. The effort to add
stubs, skeletons and automatic databinding has been completely driven
by user demand. The key benefit of the Axis2 design is that it has a
clear demarcation between the stubs and skeletons and the underlying
messaging infrastructure - which is completely based on a simple
message exchange pattern. So maybe the problem we're having here is
that you are stuck in the old (and wrong) view of SOAP, which was
driven by a lot of ex-CORBA developers!

Post by Stefan Tilkov
No, at least from my perspective we're having a very balanced and
unemotional discussion here :-)

:-) Glad to hear it!

--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
paul-***@public.gmane.org

"Oxygenating the Web Service Platform", www.wso2.com

Stefan Tilkov

2006-11-28 13:10:40 UTC

Post by Paul Fremantle

Post by Paul Fremantle
As far as I'm concerned, the *whole* point of SOA over and above
previous integration systems, is that there is clear metadata

about

Post by Paul Fremantle
the message formats as well as interaction patterns.

I notice you didn't respond to this.

You are right, I didn't respond. I see much value in associating
schemas with namespaces, and the easiest way to do this (that I'm
aware of) is to make the namespace name a HTTP URI that can be
dereferenced (via HTTP GET, of course) and points to a RDDL document
(http://www.rddl.org/).

Which leaves the additional value of WSDL for our discussion. As HTTP
is not limited to XML (which is fortunate, since it avoids the
attachment horror of WS-*), it needs something more generic -- which
it has in the form of its support for content types and content
negotiation. But even if you don't like this approach, the added
value of WSDL is that it explains how operations and their messages
relate to schema types. IMO, this is mostly useful for code
generation, and - as the need for WS-Policy and friends shows - not
sufficient for description on its own, anyway.

Still, I agree it would be useful to have a standardized RESTful
model for describing resources, URIs, and representations, similar to
UDDI (but of course not as bad). In fact I'm currently working with a
client to create a simple, RESTful UDDI registry/repository
replacement for managing WS-* metadata :-)

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Stefan Tilkov

2006-11-27 17:46:07 UTC

doesn't mean you don't have to care about the REST.

er, I meant "rest". I guess I need to take a break from this
discussion for a while :-)

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Gregg Wonderly

2006-11-27 04:03:11 UTC

Post by Stefan Tilkov
I agree that none of them is standardized yet, which doesn't prevent
anyone from using them in their own applications, but hinders tool
development (which can be considered a disadvantage).

The support for multiple languages and programming environments has fewer and
fewer advantages in the long run. Practically, XML content in WS-* and
elsewhere is growing semantic meaning which is making it into a mobile code,
platform in and of itself. In the long run, the industry will slowly push more
symantics into XML as the true value of mobile code becomes more visible.

As this happens, we will slowly move to a mostly tool based programming
environment where all the arguments about the "readability of java" will be a
distant memory as we argue about the inability to read what the tools have
generated, at all.

Post by Sanjiva Weerawarana
That's the real challenge for REST. Remember that there's nothing new in
REST- its been around for 15+ years and has worked great for the Web.
Saying its the silver bullet for integration is a bit of a stretch when
many of the core needs of integration are not met by the technology.
Whether you like the details or not, they *are* met by WS-* stuff.

There's nothing new in XML either. It represents nothing more than was possible
with Lisp. The issue from my perspective is how the ignorance of computer
science evolution and development is continously ignored by Microsoft. Instead
of using things that the computer science world has already developed, they
continously create churn and waste of time, resources and money requiring people
to reinvent existing technologies to align with their platform.

I'm not really an MS basher. But, it's really difficult to see how we've
progressed over the years. Microsoft's sole interest is dominance and
profitability. This is clear in every message put forth by their actions and
participation in the industry.

SOA is now all about who can make their platforms which have worked together for
decades finally work with the standard that microsoft has chosen to create.
What this creates is churn on the part of everyone else. Microsoft is holding
the reigns on everyone elses activities. They're directing your actions,
controlling your cost of business and making sure that they continue to be in a
controlling position.

This is one of the more predominate reasons why I still think that the Java
platform has far more value in managing this control than anyone really seems to
appreciate.

Many feel that the use of XML/SOAP/WS-* means that you truely have more choices
than before. You can pick the programming language/platform etc. But that's by
far the smallest impact on the industry. We've made those choices for years and
allowed various companies and standards organizations to direct the development
of a wide variety of RPC/messaging standards. None of those standards have ever
been able to solve all the problems that developers/architects have encountered.
Thus the continued development of more and more protocols/transports/transfer
mechanisms.

In the end, it's the power of mobile code that provides the tools which go
beyond the protocol and application level. We've had an available standard in
the industry for 10+ years that provided a multi-OS, mobile code platform. Yet
Microsoft chose not to play well in that interaction with the industry either.

I guess we'll all just get to set back and watch as all the vendors make the
decision of whether they'll keep following microsofts lead, or choose to really
drive SOA towards good, flexible solutions for more environments.

Gregg Wonderly

Andrew S. Townley

2006-12-01 13:56:46 UTC

Post by Sanjiva Weerawarana
Please tell me what standards in non-WS-* REST-land do these things.

Don't forget RRMTP (http://sdec.reach.ie/rigs/rig0007/) :) :) -- Similar
but slightly different to Bill's approach, but also provides reliable
message delivery using a series of HTTP request/responses.

In answer to Sanjiva, and probably against some of the more savvy REST
proponents here, my personal plan for adding support for security has
been to leverage existing specifications in the message, e.g.
XML-ENC/DSIG. As I understand applications of REST, you still have an
application protocol over HTTP as a transport protocol which defines
what you need to do with your requests and responses. In some cases,
that application protocol will be closer to HTTP than others, but it
shouldn't go against the way HTTP was intended to be used.

One reason I made the payload deliberately opaque in RRMTP was so that
you could define an application protocol on top of that which passed
completely encrypted messages over it, much the same way that we
specialized it to support the Reach Envelope as the only valid payload
in rig8204. If you attempt to send anything other than a well-formed,
RCF-able Reach Envelope to a service using rig8204 as the transport,
you're going to get an HTTP 5xx level response. HTTP principles are
still valid, RRMTP principles are still valid (you would be in the PUT
step of the protocol, in this case), but you may have the wrong
application level protocol.

The way I see this approach, you can then build your software in terms
of any one of the layers that interests you, e.g.:

HTTP Layer -- I only care about the transport
RRMTP/Reliability Layer -- I only care about the reliable delivery
protocol
Application Layer -- I only care about the message. Transport and
reliability are deferred to something else.

While the composibility of SOAP/WS-* allows you to do this conceptually,
it's harder to separate your concerns because everything is mixed in to
the same SOAP envelope. Obviously, we have proven that SOAP/WS-* will
work, but I see it as a much more "all or nothing" approach unless you
start layering your concerns in other envelopes with attachments. But
then if you're going to do that, why not just truly separate your
concerns in the first place?

Yes, clear specifications are important, and interoperability of
implementations are also important, but with the way the WS-* stack is
developing, it seems like we're rolling the "big ball of mud" from
POSA1. Just because we can, doesn't mean we should.

For my money, and the money of my clients, I want to ensure that the
right level of flexibility exists in their solutions. I think you can
achieve that flexibility in many different ways, but there's never going
to be one unifying approach. This is why Gregg keeps trying to educate
us all how you can apply JINI to implement SOA. However, I do believe
that the more easily you can separate concerns orthogonally from each
other, the more flexible your system will be.

ast

--
Andrew S. Townley <ast-***@public.gmane.org>
http://atownley.org

Mark Baker

2006-11-27 06:06:43 UTC

It's a common misconception that unsafe GETs are not RESTful.

That's a poor choice of words, because as I say, GET is defined to be
safe. What I should have said was;

"It's a common misconception that servers that change state on GET
requests are not RESTful."

Mark.

Mark Baker

2006-11-27 06:01:10 UTC

Post by Mark Baker
What's interesting about this argument is an implicit assumption being
made; that if you had an existing HTTP/URI based Web API, but then
later found it needed "security, reliability, or transactions", that
you need to abandon the existing Web API and replace it with SOAP.
What about, oh, say, *adding* those ilities incrementally, within the
constraints of the existing API?

I'm not quite sure what you mean there, but you have a number of
options in this space. Not all are RESTful, but they still follow the
most significant constraints.

Post by Sanjiva Weerawarana
How about reliability? (Remember HTTP-R?)

GET, PUT, and DELETE are as reliable as one would need, since they're
known safe and idempotent (respectively). POST is neither of course,
so any reliability solution would resemble a subset of a message-level
reliability solution (minus the latency tradeoff).

Stefan linked to some solutions, but my favourite is POE by Mark Nottingham;

http://www.mnot.net/drafts/draft-nottingham-http-poe-00.txt

Post by Sanjiva Weerawarana
How about transactions?

For reasons similar to those discussed here, transactions are
generally undesirable between untrusted parties because the cost of
resource reservation is prohibitive.

That's not to say there aren't other aspects of transactions which
don't have value in a REST context, but that's obviously too big a
problem space to explore without an example in front of us.

As you would answer any question of that sort; by looking at the messages.

?? No way. Only the owner of the resource can say whether this GET is
safe or not. How can you possibly say that by looking at the messages?!

You're confusing two concepts here; the safety of GET, and what a
particular server may or may not do in response to receiving a GET
request.

For the first part, RFC 2616 defines GET to be safe and nothing you
can implement can change that.

For the second part, what the server does is immaterial to the
architecture, as long as it meets the expectations of a GET request;
returning data corresponding to the provided URI.

It's a common misconception that unsafe GETs are not RESTful.

Because virtually all services can be used as resources (usually more
than one resource per service though).

By "service" I didn't mean "Web services", I just meant any provider
of data or functionality that one might find on an intranet;
databases, application-specific stores, file systems, content
repositories, message queues, etc..They can all be wrapped as
resources.

Mark.

Jan Algermissen

2006-11-26 10:50:39 UTC

Post by Sanjiva Weerawarana
WSDL? You either need WSDL (2.0, not 1.1 as the new version has much
better POX/HTTP support) or something like it. How else do you tell
other (computers) what your RESTful service does?

Examples:

http://ietf.org/internet-drafts/draft-ietf-atompub-protocol-11.txt

http://tools.ietf.org/wg/atompub/draft-snell-atompub-feature-01.txt

(the later one being essentially a means to discover services by
capability).

Aside: can WSDL tell me *everything* I need to know to decide that
some service
Foo is the one I want?

Jan

Sanjiva Weerawarana

2006-11-26 16:20:01 UTC

http://ietf.org/internet-drafts/draft-ietf-atompub-protocol-11.txt
http://tools.ietf.org/wg/atompub/draft-snell-atompub-feature-01.txt
(the later one being essentially a means to discover services by
capability).

I assume you're referring to ATOM service documents. I don't see how
that can be used to define say a URL template, which most people now
recognize as a necessary thing to describe even fully RESTful services.
Am I missing something?

Post by Jan Algermissen
Aside: can WSDL tell me *everything* I need to know to decide that
some service
Foo is the one I want?

Of course not.

WSDL tells you *no* semantic information. It only tells you the bare
bones of what you need to know: the format of the data to be sent and
what the service will return. That's it. It doesn't even tell you
whether the data should be signed- that's the domain of WS-Policy and
WS-SecurityPolicy.

What would make you or anyone think that WSDL provided everything you
needed to know to make a service identity decision?

Sanjiva.

Jan Algermissen

2006-11-26 20:54:03 UTC

Post by Sanjiva Weerawarana
WSDL? You either need WSDL (2.0, not 1.1 as the new version has

much

Post by Sanjiva Weerawarana
better POX/HTTP support) or something like it. How else do you

tell

Post by Sanjiva Weerawarana
other (computers) what your RESTful service does?

[...]

Post by Sanjiva Weerawarana
What would make you or anyone think that WSDL provided everything you
needed to know to make a service identity decision?

You said above "You need WSDL [...] How else do you tell other
(computers) what
your RESTful service does?" and I took that to mean WSDL would tell
me what the
service does...

Jan

Post by Sanjiva Weerawarana
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://
www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/

Sanjiva Weerawarana

2006-11-27 00:28:51 UTC

Post by Sanjiva Weerawarana
What would make you or anyone think that WSDL provided everything you
needed to know to make a service identity decision?

You said above "You need WSDL [...] How else do you tell other
(computers) what
your RESTful service does?" and I took that to mean WSDL would tell
me what the
service does...

You left off a key part of my sentence .. I was *very* careful to say:
"You either need WSDL [...] or something like it."

I didn't say WSDL was the silver bullet (as one of its original creators
and being part of WSDL 2.0 I *know* its far from that). What I said is
that the information in WSDL is a necessary condition, not a necessary
and sufficient condition.

Sanjiva.

Paul Fremantle

2006-11-25 10:57:39 UTC

Stefan

That's what I meant about having your cake and eating it. One of the
main aims of business SOA is to keep existing legacy services and make
them available to the rest of the enterprise as services. POX and SOAP
are great ways of doing that because many existing legacy applications
have simple transactional interfaces that can be mapped to XML in /
XML out.

Mapping those APIs into Resources so that you can apply REST is NOT
the same thing, and is not what is meant by business SOA. And if those
companies did a POX approach you would be the first to say that it
isn't REST :-)

So what I'm asking is that you be as clear with yourself about what
REST is applicable to as you are with everyone else about what REST
isn't applicable to!

Paul

Stefan Tilkov

2006-11-25 17:37:37 UTC

Hi Paul,

Post by Paul Fremantle

True. But even if I wear my WS-* only hat, the services you get when
you simply map existing interfaces to SOAP and WSDL "as is" will
usually not conform to your architectural principles. Whether you
accept that depends on whether the benefits you gain if you change
them are worth the effort. The same is true if you follow REST
principles - you'll have to decide each and every time whether it's
worth changing a system to conform to them (and often, the decision
will likely be "no way").

Post by Paul Fremantle
Mapping those APIs into Resources so that you can apply REST is NOT
the same thing, and is not what is meant by business SOA.

I agree under the assumption that "using legacy interfaces with
minimal changes" belongs in the "business SOA" definition. I gather
in your book it does - fine with me. But even when I talk about WS-*
to clients (and this is deemed the only reasonable option, most often
for political reasons), I strongly advise against exposing most
legacy systems "as is".

I don't know e.g. RosettaNet in any depth, so this may well be an
exception -- in this case, you have a very valid point and REST may
not be worth it.

Post by Paul Fremantle
And if those
companies did a POX approach you would be the first to say that it
isn't REST :-)

Only if I'm a) asked or b) they claim it's REST :-)

Post by Paul Fremantle
So what I'm asking is that you be as clear with yourself about what
REST is applicable to as you are with everyone else about what REST
isn't applicable to!

Valid demand :-) In cases where one wants a loosely coupled, open,
standardized, simple, easy to implement architecture and we're
debating technical merits only, I consider RESTful HTTP (or ROA, if
you prefer) superior to technical SOA based on WS-*. Any number of
requirements and restrictions, technical and political, may lead to
other options, including WS-* (but also JMS, EJB/RMI or CORBA).

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

Post by Paul Fremantle
Paul

Steve Jones

2006-11-25 18:52:16 UTC

Well, maybe dead is relative -- but I don't think SOAP/WSDL would be
the obvious first choice for anyone doing a "Web API" nowadays.

Unless of course they were
a) Exposing an ERP
b) Creating a cross industry standard
c) Wanted it to be simply consumed via tools
d) Wanted to have clear and standardised ways of adding reliability and security
e) Wanted to include async processing (WSDL 2.0) and callbacks.
f) Wanted to communicate with a partner/supplier

Which is the first six reasons that came to mind, if I'm dealing with
a commercial 3rd party then SOAP/WSDL would 100% be my first choice,
they are going to have something commercial at their end, so am I, so
SOAP/WSDL makes real sense.

Now if I was knocking up a quick demo thing then I might go for REST
(I'm looking to extend the georipper service with some extensions in
REST only for instance).

Aiming at a company = SOAP/WSDL
Aiming at certain classes of developers = REST
Aiming at other classes of developers = SOAP/WSDL

I agree, provided we're talking about SOA, the technology/
architecture, not SOA, the business concept (as used e.g. by Steve
Jones).

:) And I'll go along with that too, SOD and ROD (Service Oriented
Development and Resource Oriented Development) are two viable
approaches.

Post by Paul Fremantle
I think its time to call the Rest-ians on their distinctions. There
are plenty of RESTians taking a hard line on what is "REST" and what
isn't,

That's actually one of its benefits, IMO - it's pretty easy to assess
the "RESTfulness" of something. It's pretty hard to do that for
"service-orientation" :-)

SOA-RM does it for me. I still don't know however how a business
interface would be described using REST from the perspective of the
consumer (producer side is simple), so far the REST interfaces I've
used have been simple to use technically, but have assumed quite a bit
of XML and system knowledge on the consumer side, its not as simple
for a consumer as "import WSDL, generate client proxy, write in
language of my choice" or just plug into my BPEL and use it straight
away.

This is my issue with REST, its going to have to link in with the
process, security, reliability and other elements that are really
demanded by businesses as they do more and more work across the
internet. At the moment the claim is that its simpler and WS-* is
complex, but only because REST-* doesn't exist.

I don't get that point. Many existing SOAs use Web services and are
modeled in a way that could have been achieved with CORBA (and, as
Eric is sure to point out, some have even been built on CORBA). So
what? REST proponents suggest that there's a better way, and that
it's different.
I agree that using your terminology, I'm advocating ROA instead of
SOA. Using Steve's terminology, I prefer REST as an implementation
architecture for (business) SOA as opposed to WS-*.

Now if we are all agreed there are different options, can we just move
on and start doing the buisness bit please :)

Post by Stefan Tilkov
Stefan

Post by Paul Fremantle
Paul

--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
"Oxygenating the Web Service Platform", www.wso2.com
Yahoo! Groups Links

JP Morgenthal

2006-11-25 22:04:03 UTC

I also agree that the OASIS SOA-RM is an excellent definition. I was quite
surprised. Based on some of the other existing OASIS work, I did not have
high-hopes for this document, but I was really impressed with the results.

As Editorial Director of the SOA Institute we have discussed putting out our
recommendation on this document.

JP

_____

From: service-orientated-architecture-***@public.gmane.org
[mailto:service-orientated-architecture-***@public.gmane.org] On Behalf Of Anil
John
Sent: Saturday, November 25, 2006 2:50 PM
To: service-orientated-architecture-***@public.gmane.org
Subject: RE: [service-orientated-architecture] Another Crack at Defining SOA

<SteveJones>

It would be really great to understand why the SOA RM is a non-starter,
there are bits I'd like to see in future in the standard, so it would be
great to see what people think could be improved on, or the basic
challenges.

But please remember that a definition needs to be non-technology specific.
</SteveJones>

Indeed! As someone who is currently participating in the OASIS SOA-RA
process, I too am really interested in this answer. If for nothing else but
to make sure that time, effort and energy are being put into the right
buckets that will resonate with folks who are implementing SOA based
solutions.

Regards,

- Anil

On 25/11/06, Anil John <***@gmail. <mailto:aniltj-***@public.gmane.org> com > wrote:

<StefanTilkov>
Too bad we have no agreed upon definition of SOA
</StefanTilkov>

<Gervas>
No one anywhere in the known universe has yet come up with a definition
of SOA which commands widespread acceptance.
</Gervas>

Would I be correct in my understanding that the OASIS SOA-RM Definition
of SOA [1] is pretty much of a non-starter with this group (With the
exception of Steve of course)? As such do you all see any value in
building on top of it? For example, would you see folks from this group
participating in the OASIS SOA RA (Reference Architecture) work, given
that it is built on top of the RM?

Regards,

- Anil

[1] http://en.wikipedia
<http://en.wikipedia.org/wiki/OASIS_SOA_Reference_Model>
.org/wiki/OASIS_SOA_Reference_Model

:-
:- Anil John
:- http://www.aniltj. <http://www.aniltj.com/blog> com/blog
:-

Eric Newcomer

2006-11-25 23:07:36 UTC

I'll just point out that it's fine to say you don't need transactions - at least, until you find that you do need them.

Eric

----- Original Message ----
From: Steve Jones <jones.steveg-***@public.gmane.org>
To: service-orientated-architecture-***@public.gmane.org
Sent: Saturday, November 25, 2006 3:51:06 PM
Subject: Re: [service-orientated-architecture] ROA is not SOA - (was Alternatives to WS Standards)

Post by Sanjiva Weerawarana
Well it shouldn't be .. if you don't need SOAP you don't need

it. If all

Post by Sanjiva Weerawarana
you need is to send some XML over HTTP or HTTPS then SOAP is

not at all

Post by Sanjiva Weerawarana
needed. SOAP should come into the picture IFF you need message

level

Post by Sanjiva Weerawarana
security, reliability or transactions or any of the other

things that

Post by Sanjiva Weerawarana
have been built on SOAP. If not why pay the price?

What's interesting about this argument is an implicit assumption

being

Post by Mark Baker
made; that if you had an existing HTTP/URI based Web API, but then
later found it needed "security, reliability, or transactions" , that
you need to abandon the existing Web API and replace it with SOAP.
What about, oh, say, *adding* those ilities incrementally, within

the

Post by Mark Baker
constraints of the existing API?

Hey great idea! OK now tell me, what exactly does one need to do to
add
message level security to HTTP? After I sign the message where do I
put
it so the recipient will always check that before touching the
message?
How about reliability? (Remember HTTP-R?)
How about transactions?
NOTE: We need interoperable standards with corresponding metadata
(i.e.,
policies) for all of the above so that tools can work with them.

Semi-seriously, I say "no, we don't". Let's take transactions as the
first example. Here are my three reasons why we don't need WS-

I'm with you on these ones, Atomic Transaction on Web Services... I shudder.

Post by Stefan Tilkov
2) Atomic (2PC) transactions are a bad idea for loosely-coupled
systems (I consider them to be the most tightly approach you can take)
3) Even using compensations à la WS-BusinessActivity , IMO, belong in
the application -- they're business logic anyway, and I don't see
what standards support buys you here

Post by Sanjiva Weerawarana
Please tell me what standards in non-WS-* REST-land do these things.

As to transactions, I don't think anyone has bothered yet. As for
reliability, examples include
SOA-Rity (http://www.goland. org/soareliabili ty/) (by Yaron Goland) and
HTTPLR (http://www.dehora. net/doc/httplr/ draft-httplr- 00.html) by
Bill de hÓra
I agree that none of them is standardized yet, which doesn't prevent
anyone from using them in their own applications, but hinders tool
development (which can be considered a disadvantage) .

Cheers for those pair, I hadn't come across them before, I'll go an
have a look. Tool development and broad vendor acceptance is critical
however.

Post by Stefan Tilkov
Stefan
--
Stefan Tilkov, http://www.innoq. com/blog/ st/

Steve Jones

2006-11-26 11:08:07 UTC

I need transactions, what I don't need are transactions managed across
coarse grained facilities like Web Services. What I _really_ don't need are
transaction boundaries that span across multiple enterprises.

SAP and some other ERPs are good examples of not needing this type of
transaction, if you make a mistake you put a compensating request in (order
1000 widgets by mistake? place an order for -1000 widgets to solve the
problem), this is a standard solution to the problem and it scales
brilliantly.

In terms of priority of importance and where vendors could have invested
time (e.g. having something that enables me to say "don't call this service
between 2am and 3am because its down for backup) then transaction management
was massively at the end of the list.

Having been doing Web Service systems commercially for 5+ years now I can
safely say that I've missed not having WS-RM, I've missed not having
WS-Security et al put I've never ever missed not having Transaction
management. To me this is a great example of doing something "because we
could" and putting heavy artillery into the hands of children.

Steve

Post by Eric Newcomer
I'll just point out that it's fine to say you don't need transactions -
at least, until you find that you do need them.
Eric
----- Original Message ----
Sent: Saturday, November 25, 2006 3:51:06 PM
Subject: Re: [service-orientated-architecture] ROA is not SOA - (was
Alternatives to WS Standards)

Post by Sanjiva Weerawarana
Well it shouldn't be .. if you don't need SOAP you don't need

it. If all

Post by Sanjiva Weerawarana
you need is to send some XML over HTTP or HTTPS then SOAP is

not at all

Post by Sanjiva Weerawarana
needed. SOAP should come into the picture IFF you need message

level

Post by Sanjiva Weerawarana
security, reliability or transactions or any of the other

things that

Post by Sanjiva Weerawarana
have been built on SOAP. If not why pay the price?

What's interesting about this argument is an implicit assumption

being

Post by Mark Baker
made; that if you had an existing HTTP/URI based Web API, but then
later found it needed "security, reliability, or transactions" ,

that

Post by Mark Baker
you need to abandon the existing Web API and replace it with SOAP.
What about, oh, say, *adding* those ilities incrementally, within

the

Post by Mark Baker
constraints of the existing API?

Hey great idea! OK now tell me, what exactly does one need to do to
add
message level security to HTTP? After I sign the message where do I
put
it so the recipient will always check that before touching the
message?
How about reliability? (Remember HTTP-R?)
How about transactions?
NOTE: We need interoperable standards with corresponding metadata
(i.e.,
policies) for all of the above so that tools can work with them.

Semi-seriously, I say "no, we don't". Let's take transactions as the
first example. Here are my three reasons why we don't need WS-

I'm with you on these ones, Atomic Transaction on Web Services... I shudder.

Post by Stefan Tilkov
2) Atomic (2PC) transactions are a bad idea for loosely-coupled
systems (I consider them to be the most tightly approach you can take)
3) Even using compensations à la WS-BusinessActivity , IMO, belong in
the application -- they're business logic anyway, and I don't see
what standards support buys you here

Post by Sanjiva Weerawarana
Please tell me what standards in non-WS-* REST-land do these things.

As to transactions, I don't think anyone has bothered yet. As for
reliability, examples include
SOA-Rity (http://www.goland. org/soareliabili ty/<http://www.goland.org/soareliability/>)

(by Yaron Goland) and

Post by Stefan Tilkov
HTTPLR (http://www.dehora. net/doc/httplr/ draft-httplr- 00.html<http://www.dehora.net/doc/httplr/draft-httplr-00.html>)

Post by Stefan Tilkov
Bill de hÓra
I agree that none of them is standardized yet, which doesn't prevent
anyone from using them in their own applications, but hinders tool
development (which can be considered a disadvantage) .

Cheers for those pair, I hadn't come across them before, I'll go an
have a look. Tool development and broad vendor acceptance is critical
however.

Post by Stefan Tilkov
Stefan
--
Stefan Tilkov, http://www.innoq. com/blog/ st/<http://www.innoq.com/blog/st/>

Eric Newcomer

2006-11-26 13:18:27 UTC

I do not think anyone is trying to force you to use something you do not need. Not sure why you are arguing that.

With respect to the order of the standards, it was security first, then reliability, and then transactions.

If there was no requirement for the transactions specs I can assure you we would never have worked on them or implemented them. I do not think any of us suggest using them where they are not needed or useful.

One point that often gets missed here is that the approach is very open to extension and new models. Mark
Little and I defined a very workable protocol for long running asynch transaction coordination across multiple software domains and protocols. However much people talk about loosely coupled systems, they are still not being built abstractly across heterogeneous system types.

Once the industry gets to that stage however the only real way to ensure reliability of multiple operations on data will be to use transactions.

As with everything there is a cost benefit and today most transactions are still performed at the back end. Almost every system of record uses them. The mega sites use them for replication. But today these are all monolithic systems without interoperable protocols.

A good question is how far to extend coordination across services not just databases. The current work lays a foundation for achieving these things.

We are very nearly done in fact. And if it helps anything, you should know that for the most part different people are involved in the transaction standardization efforts, and I do not believe anyone can say what we are doing is holding up any other effort.

I think your main point is that you do not need transactions in your projects. That is of course no problem and I do not believe anyone would argue. But if you did find someday that you need them, coding the same yourself would be very difficult and expensive.

Oh yes, you did mention compensation. Every well formed transaction should have a compensation. That is not a surprise.

Another point is about forcing someone to use them simply because they exist. It seems strange to recommend the existence of something that is useful to some because it is abused by others.

Eric

[jones.steveg-***@public.gmane.org] wrote:
I need transactions, what I don't need are transactions managed across
coarse grained facilities like Web Services. What I _really_ don't need are
transaction boundaries that span across multiple enterprises.

SAP and some other ERPs are good examples of not needing this type of
transaction, if you make a mistake you put a compensating request in (order
1000 widgets by mistake? place an order for -1000 widgets to solve the
problem), this is a standard solution to the problem and it scales
brilliantly.

In terms of priority of importance and where vendors could have invested
time (e.g. having something that enables me to say "don't call this service
between 2am and 3am because its down for backup) then transaction management
was massively at the end of the list.

Having been doing Web Service systems commercially for 5+ years now I can
safely say that I've missed not having WS-RM, I've missed not having
WS-Security et al put I've never ever missed not having Transaction
management. To me this is a great example of doing something "because we
could" and putting heavy artillery into the hands of children.

Steve

Post by Sanjiva Weerawarana
Well it shouldn't be .. if you don't need SOAP you don't need

it. If all

Post by Sanjiva Weerawarana
you need is to send some XML over HTTP or HTTPS then SOAP is

not at all

Post by Sanjiva Weerawarana
needed. SOAP should come into the picture IFF you need message

level

Post by Sanjiva Weerawarana
security, reliability or transactions or any of the other

things that

Post by Sanjiva Weerawarana
have been built on SOAP. If not why pay the price?

What's interesting about this argument is an implicit assumption

being

Post by Mark Baker
made; that if you had an existing HTTP/URI based Web API, but then
later found it needed "security, reliability, or transactions" ,

that

Post by Mark Baker
you need to abandon the existing Web API and replace it with SOAP.
What about, oh, say, *adding* those ilities incrementally, within

the

Post by Mark Baker
constraints of the existing API?

Hey great idea! OK now tell me, what exactly does one need to do to
add
message level security to HTTP? After I sign the message where do I
put
it so the recipient will always check that....

Steve Jones

2006-11-26 14:46:04 UTC

Post by Eric Newcomer
I do not think anyone is trying to force you to use something you do not need. Not sure why you are arguing that.
With respect to the order of the standards, it was security first, then reliability, and then transactions.
If there was no requirement for the transactions specs I can assure you we would never have worked on them or implemented them. I do not think any of us suggest using them where they are not needed or useful.

It would be really useful to me to have some of the sample use cases
for WS-TX that explained the scenarios that it would be used in. The
charter just explains the technical infrastructure elements, rather
than the requirements that led to it being needed.

Post by Eric Newcomer
One point that often gets missed here is that the approach is very open to extension and new models. Mark
Little and I defined a very workable protocol for long running asynch transaction coordination across multiple software domains and protocols. However much people talk about loosely coupled systems, they are still not being built abstractly across heterogeneous system types.
Once the industry gets to that stage however the only real way to ensure reliability of multiple operations on data will be to use transactions.

I'm really not sure that is true, lots of ERP vendors get away without
having this sort of transaction management available to consumers, and
they seem to get on fine.

Post by Eric Newcomer
As with everything there is a cost benefit and today most transactions are still performed at the back end. Almost every system of record uses them. The mega sites use them for replication. But today these are all monolithic systems without interoperable protocols.
A good question is how far to extend coordination across services not just databases. The current work lays a foundation for achieving these things.
We are very nearly done in fact. And if it helps anything, you should know that for the most part different people are involved in the transaction standardization efforts, and I do not believe anyone can say what we are doing is holding up any other effort.

My point is that vendors concentrate on technical, rather than
business focused, standards. This is why we see lots of different
attempts at process and choreography, but very little around KPI, SLA
or contract management.

Post by Eric Newcomer
I think your main point is that you do not need transactions in your projects. That is of course no problem and I do not believe anyone would argue. But if you did find someday that you need them, coding the same yourself would be very difficult and expensive.
Oh yes, you did mention compensation. Every well formed transaction should have a compensation. That is not a surprise.
Another point is about forcing someone to use them simply because they exist. It seems strange to recommend the existence of something that is useful to some because it is abused by others.

People use things because they are there, its a simple fact, its the
reason I'm against JAX-WS in JavaSE 6, its got callbacks in it, that
is a bad idea in a basic platform IMO. WS-TX is an edge case standard
that many systems have historically successfully avoided the problem
of by architecting it out.

It would be really useful to understand the business scenarios and
requirements that led to WS-TX, I've done a of a search and all I can
find is the interop one (which is after the fact) which is purely
technical.

Post by Eric Newcomer
Eric
I need transactions, what I don't need are transactions managed across
coarse grained facilities like Web Services. What I _really_ don't need are
transaction boundaries that span across multiple enterprises.
SAP and some other ERPs are good examples of not needing this type of
transaction, if you make a mistake you put a compensating request in (order
1000 widgets by mistake? place an order for -1000 widgets to solve the
problem), this is a standard solution to the problem and it scales
brilliantly.
In terms of priority of importance and where vendors could have invested
time (e.g. having something that enables me to say "don't call this service
between 2am and 3am because its down for backup) then transaction management
was massively at the end of the list.
Having been doing Web Service systems commercially for 5+ years now I can
safely say that I've missed not having WS-RM, I've missed not having
WS-Security et al put I've never ever missed not having Transaction
management. To me this is a great example of doing something "because we
could" and putting heavy artillery into the hands of children.
Steve

Post by Sanjiva Weerawarana
Well it shouldn't be .. if you don't need SOAP you don't need

it. If all

Post by Sanjiva Weerawarana
you need is to send some XML over HTTP or HTTPS then SOAP is

not at all

Post by Sanjiva Weerawarana
needed. SOAP should come into the picture IFF you need message

level

Post by Sanjiva Weerawarana
security, reliability or transactions or any of the other

things that

Post by Sanjiva Weerawarana
have been built on SOAP. If not why pay the price?

What's interesting about this argument is an implicit assumption

being

Post by Mark Baker
made; that if you had an existing HTTP/URI based Web API, but then
later found it needed "security, reliability, or transactions" ,

that