[
Lists Home |
Date Index |
Thread Index
]
Michael Champion wrote:
> On Apr 5, 2005 6:31 PM, Leigh Dodds <leigh@ldodds.com> wrote:
>
>
>>I don't see how defining a public URL space exposes any details about
>>my application structure. I've done it, for both human and machine
>>oriented interfaces, and you can't tell from the url structure or
>>response formats what my backend is doing. Or even if the entities in
>>the URI map 1:1 with entities in my database schema.
>
>
> I interpreted Bill's original post as arguing that one should expose
> actual implementation objects, tables, etc. as URIs. We cleared that
> up -- he was talking about abstractions or "domain objects" a la
> Amazon.com's book-specific URIs that one can exchange, bookmark, etc.
> and not the physical tables where all this stuff resides. If the
> backend is hidden, behind URIs, services, or whatever, my concerns
> about information hiding are irrelevant.
>
> If the entities in the URI map 1:1 with your database schema, well, it
> seems like an unnecessary risk to me, but I don't claim to know much
> about security. Judging by the state of the industry, I'm not sure
> that very many of us do either :-) . My main reason for starting this
> thread was not to argue against this, but to wonder why several people
> are so certain that having a single message dispatcher URI is a bad
> idea, irrespective of whether exposing all the individual resource
> URIs is a good idea.
>
> I'm not sure my strawman has been demolished yet: The SOA dogma is to expose
> the service and the service contract to the client,and hide everything
> else. That seems to reflect decades of best practice, back to
> "information hiding" in the days when Structured Programming was the
> One True Path to software quality. I'm not sure what's wrong with that
> dogma, other than the fact that REST advocates making "domain
> objects" visible via URIs and having clients manipulate them by
> transferring representations. Why is that supposedly better?
> What's the evidence?
>
> My motivation in all this uber-permathread is that I opposed the
> notion that was popular 3-4 years ago of extending the COM/CORBA/RMI
> distributed object paradigm to the Web; I agreed with the
> RESTifarians that it wouldn't scale, wouldn't leverage the Web
> infrastructure, all the classic arguments that appear to have been
> validated by Amazon, Bloglines, Flickr, etc. But now I'm questioning
> the currently popular notion that the Web architectural style is
> generally suitable for enterprise scenarios where COM/RMI/J2EE/etc.
> are entrenched. In these, information is often confidential, lots of
> real money is on the table and armies of slimeballs want to steal it,
> there is a more even balance between readers and writers (making all
> the cacheing goodness somewhat irrelevant), and the data is consumed
> by mission-critical programs that can't just sigh and click on the
> next link if there is a 404, or try again later if there is a timeout.
> MAYBE the Web architecture principles apply here as well, obviously
> many people think they should. I'm skeptical, and asking for solid
> arguments and concrete success stories.
Well you know, my beef with all that stuff is that I didn't think it
transplanted onto to the Web. Which is to say it felt like a ton of work
to get something done between a pair of firewalls until I stuck to HTTP
and untyped XML. How far Web/REST-as-deployed can push into the
enterprise and influence approaches is an unknown to me. I don't expect
the J2EE or .NET folks to pay much attention since most of them see
the web as a problem to be solved, whereas a database is a solution. I
think approaches like NetKernel and Indigo are cool tho'. And I think
every enterprise architect looking at ESB backbones should be reading
the XMPP specs and asking hard questions of the vendors; that's not
necessarily REST.
There are two specs in the wild now for reliable transmission, POE and
HTTPLR; which one you'd go for would depend on your circumstances. Rich
has mentioned end to end reliability as a problem, so he should check
them out. I know I'll end up using both of them at some point, but I
could also end using WS-ReliableMessaging - I already use BizTalk for
such things. I wrote down HTTPLR because it was fun, but also because
no-one had solved that problem in that way and written it down well
enough for the next guy (I'm always reminded about what Marshall Rose
said about syslog) - and for three other reasons. One is the amount of
baggage something like WS-ReliableMessaging brings with it; it depends
on a bunch of other WS specs which ups the surface altogether too much
for me if only because so few of those specs seem to be stable. Two is
the WS RM specs don't necessarily play well where on endpoint is a pure
HTTP client - I have deployment scenarios where dropping in a
server/ws-stack into an infrastructure is a non-runner (getting onto 80
is a non-runner period), but which are dealt with well-enough by HTTPLR.
Three is that the right Webby thing to do is to deploy a new HTTP
method, but I think your chances of adoption go to zero - you can't even
rely on PUT being available. HTTPLR is by one reading, realtechnik, a
litany of compromises. I wrote what I thought would get used. But I
think the fact that I wrote it indicated I agree with Rich to some
extent about the need not being addressed.
How webarch resulted in value to that protocol is in two ways a)
everything gets a name, b) the protocol is kept as an application of the
HTTP layer rather than a declarative message the majority of which. I
did those not because I drank Roy Fielding's or TBL's kool-aid but
because I have to a) be able to administrate systems and reconcile
messages spanning a heck of a lot of systems (too many) and b) not
having full control of the deployment environment. There are maybe more
reasons than that.
Concrete success story: there are deployments of early versions of that
protocol running for over a year now; I can't talk about them in detail,
that's just how it is, but I can say they've never lost a message. Can
they handle 10,000 messages a minute? No. Do they need to? No. Could
they? I guess they might if I had enough computers and resources to ramp
up (I hear you can download the web and index it given enough computers,
and I hear you can build LiveJournal and Slashdot out of free stuff
given the will and the smarts). Is there a theoretical limit? Yes -
aping full-duplex with twinned HTTP servers should be theoretically
faster than an asymmetric client/server pair. Was it hard to build? No,
it took two people a few weeks. Is it secure? I punt to whatever HTTP
can provide on that - I think it would be dumb to build security into an
rm protocol.
Security - I'm no expert on that. My observation is to think we have
enough security tech, but can't package it adequately. Everyone says
they want it, but who's actually doing it? That's a business problem,
not a technology one.
cheers
Bill
|
