Re: [service-orientated-architecture] Re: WebServices to repeat CORBA's mistakes : "The Rise and Fall of CORBA"

Mon, 26 Jun 2006 14:59:11 -0700

>>HTTP GET, PUT and POST have no meaning without a URI.
Exactly. They are the operations that are uniformly applicable on all resources.
 
>>It is that URI that is the denormalizing force for me.
>>It is exactly that information that is the name of the service
>>and operation that you wish to invoke some operation on. The
>>data that you pass in that request is also varied.
>>
>>It doesn't matter to me how you say
>>
>>service1, please add customer Joe Bob Bundy to the database.
Not sure what you mean by "denormalizing force" but I don't think a REST advocate would conceive of this operation in this way. Rather, for them, it would simply be a matter of sending an HTTP message where the method is PUT, the URI identifies the new Customer resource, and the Entity (or payload) for the message is the new Customer representation to be "transferred". The "service" is just the active agent processing these messages; the operations are on the resources.
 
>>How in the world does HTTP make it possible where anything else doesn't?
I've never understood anyone to be claiming that.
 
Peter
 
On 6/26/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote:

Jan Algermissen wrote:
> On Jun 22, 2006, at 8:47 PM, patrickdlogan wrote:
>
>
>>Arguments can be made about how WS-* is better than IIOP/CORBA and I
>>cannot argue one way or the other. They appear to be for all intents
>>and purposes, on the same order of complexity and value. There are
>>probably pieces of each that would lend themselves to a better whole.
>
> What I really do not understand (vendors trying to make money set
> aside) is that anyone even considers non-uniform APIs to be the right
> path to follow in large scale, integration intensive environments
> (aka enterprises). Even if you do not look at the until now *very*
> successful systems that use a uniform API, an approach where you have
> an entirely different set of methods and parameters per service just
> feels so contrary to what one tries to achieve.
>
> The whole debate really is about uniform vs. non-uniform APIs and I
> seriously wonder why the vast majority of people isn't instantly
> jumping on the former one.
>
> But then, I have this hunch that the point of uniform APIs just
> hasn't come accross *at all*.

Jan, I suspect you are saying that REST has a uniform API because there are an
exact set of application layered operations defined by HTTP?

HTTP GET, PUT and POST have no meaning without a URI. It is that URI that is
the denormalizing force for me. It is exactly that information that is the name
of the service and operation that you wish to invoke some operation on. The
data that you pass in that request is also varied.

It doesn't matter to me how you say

service1, please add customer Joe Bob Bundy to the database.

In the end all bits and pieces have to travel from a client application to the
environment where the work is done.

How in the world does HTTP make it possible where anything else doesn't?

Gregg Wonderly


__._,_.___


SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture

YAHOO! GROUPS LINKS



__,_._,___

Reply via email to