OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Exposing resources/services vs hiding implementation detai

[ Lists Home | Date Index | Thread Index ]

On Apr 5, 2005 11:56 AM, Bill de hÓra <bill.dehora@propylon.com> 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.
" 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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS