[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Exposing resources/services vs hiding implementation detai

• To: xml-dev <xml-dev@l...>
• Subject: Re: Exposing resources/services vs hiding implementation details
• From: Michael Champion <michaelc.champion@g...>
• Date: Tue, 5 Apr 2005 12:48:03 -0400
• Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=AfqW8V8xubIFlISWDxYoQgBoTfuNE2phD6plgjZCehRu1z5gOJRPQOVoIVHvcQjTZzYSHSR+S+fiW7y67rLx7s96h9ycn8GbaZK6Nx8WJ2PHNC0uGbmZ8En4cjJ3irDnYCgm1xn0Y/9LeLYGNZeuIMk6J5W3+jj5ppquarNNKNw=
• In-reply-to: <4252B522.70600@p...>
• References: <200504051139.j35BdXDR050954@s...> <42528FB5.7040300@p...> <e3a5cb2c0504050804887b795@m...> <4252B522.70600@p...>
• Reply-to: Michael Champion <michaelc.champion@g...>

On Apr 5, 2005 11:56 AM, Bill de hÓra <bill.dehora@p...> wrote:
> Michael Champion wrote:
> 

> Oh gosh, I wasn't talking about actually mapping table rows or objects.
> But many systems have a domain model. I see no reason not to have
> multiple URLs to name the things of interest to the domain.

OK, I don't have a problem with that.

>  I think
> you're arguing for an obscurity by design that isn't always valuable.

Well, I'm just arguing the classic information hiding position, e.g.
http://en.wikipedia.org/wiki/Information_hiding
" hiding of design decisions in a computer program that are most
likely to change, thus protecting other parts of the program from
change if the design decision is changed."  I would have to agree that
security by obscurity is not something to rely on, but I'm not sure I
would agree that advertising your internal architecture to potential
hackers is a great idea either.

> If I turned your argument around and said there should be one
> self-joining uber-table (property values) or one uber-object (HashMap?)
> in a system it would surely be something to question. What's special
> about mapping a domain onto URL space that we have to have one uber-URL?

The strawman version of my position is essentially SOA dogma - expose
the service and the service contract to the client, hide everything
else.  Whether the service is implemented as an ubertable, an
uberobject, or a nicely normalized/decomposed system of both, or by an
army of people in a call center somewhere, is none of the client's
business, so long as they get the contracted service and the quality
of service they expect.  More importantly, the implementation
techniques can evolve without affecting the client.

Yes, Amazon is a nice example of how exposing domain objects (books)
with URIs can be done.  You implied in the original message that other
approaches are antipatterns, and I wondered  why.  I think your answer
about exposing domain "objects" rather than real programming objects
and database tables  takes me at least half way toward
understanding/agreement.

• Follow-Ups:
  • Re: Exposing resources/services vs hiding implementationdetails
    • From: Leigh Dodds <leigh@l...>

• References:
  • RE: What Does SOAP/WS Do that A REST System Can't?
    • From: "Marc de Graauw" <marc@m...>
  • Re: What Does SOAP/WS Do that A REST System Can't?
    • From: Bill de hÓra <bill.dehora@p...>
  • Exposing resources/services vs hiding implementation details
    • From: Michael Champion <michaelc.champion@g...>
  • Re: Exposing resources/services vs hiding implementationdetails
    • From: Bill de hÓra <bill.dehora@p...>

• Prev by Date: Re: XQuery/XSLT drafts
• Next by Date: XML Query, XSLT, XPath and related specifications - last call
• Previous by thread: Re: Exposing resources/services vs hiding implementationdetails
• Next by thread: Re: Exposing resources/services vs hiding implementationdetails
• Index(es):
  • Date
  • Thread