[
Lists Home |
Date Index |
Thread Index
]
I suspect there has just been a strong disconnect, here.
Paul Prescod wrote:
<snip/>
> We were talking about *networking problems* right? This is a discussion
> about how to represent messages on a wire? Data-oriented versus action
> oriented messaging???
Actually, no *I* wasn't talking about networking problems. Although if you
thought that's what we were both talking about, that would explain your
comments. Others in this thread seemed to get the point of view I was trying
to present, so I thought you did too. I apologize if I've misunderstood you,
and I apologize if I contributed to that misunderstanding. It certainly did
seem to me difficult to believe you were contending what I thought I was
hearing.
I was trying to explicitly present the view of a business developer who is
implementing business logic (in a CRM or ERP system, for example), and needs
to expose functionality via a web service. To me, that business logic is the
"application". And to me, I will need design patterns and models to guide my
design that I can relate back to the business functionality I am writing.
The web service is just one portion of my design effort, and is not even my
primary focus. It is just an interface. It sounded to me like you were
trivializing that side of things and saying the web service is all that
matters and all that needs to be considered, and that the entire design
effort of such an application can be cast in terms of an extension to HTTP.
Basically, it sounded to me like you were trivializing 99% of the sort of
work I've done in my career. That's why I took such strong offense.
I as a business developer use HTTP because it is easy and it allows me to
not have to think very much of networking issues. I can focus on the
business logic. I was contending that any model for how to implement web
services -- if it to be useful to business developers -- will need to be
cast in those terms, rather than simply those of the network protocol stack.
And I was trying to present a different way of casting the notions of
"action-oriented" vs. "data-oriented" that I felt was more useful to such
developers than the way these things are typically cast (in terms of RPC vs.
messages at a higher level of abstraction).
I read your xml.com article [1], and I think I have a clearer picture of
where you are coming from on this. I hope you can understand where I was
coming from on this (irrespective of whether you agree). I'd hate to leave
things on such a sour note.
[1] http://www.xml.com/pub/a/2002/02/06/rest.html
|
