[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: "Michael Champion" <michaelc.champion@g...>,"xml-dev" <xml-dev@l...>
• Subject: RE: Exposing resources/services vs hiding implementation details
• From: "Dare Obasanjo" <dareo@m...>
• Date: Tue, 5 Apr 2005 16:01:25 -0700
• Thread-index: AcU6A2qezD71uxOoQdCPwpqAQj8ALwALLJ+A
• Thread-topic: Exposing resources/services vs hiding implementation details

> -----Original Message-----
> From: Michael Champion [mailto:michaelc.champion@g...] 
> Sent: Tuesday, April 05, 2005 9:48 AM
> To: xml-dev
> Subject: Re:  Exposing resources/services vs hiding 
> implementation details
> 
> 
> 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.

It seems you are confusing domain models with internal architectures. 

> > 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.

And the service will still have a domain model because it will have to
describe what messages it sends back and forth. I don't see how this
differs from the REST case except the fact that with REST you get to
address such objects via URIs and gain a bunch of benefits from the Web
infrastructure. 

Can you clarify your position? 

--
PITHY WORDS OF WISDOM 
We make our friends. We make our enemies. God makes our next door
neighbor.    

This posting is provided "AS IS" with no warranties, and confers no
rights.  

• Prev by Date: Re: Exposing resources/services vs hiding implementationdetails
• Next by Date: Re: What Does SOAP/WS Do that A REST System Can't?
• Previous by thread: Re: Exposing resources/services vs hiding implementation details
• Next by thread: RE: Exposing resources/services vs hiding implementation details
• Index(es):
  • Date
  • Thread