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

Re: Exposing resources/services vs hiding implementationdetail

• To: algermissen@a...
• Subject: Re: Exposing resources/services vs hiding implementationdetails
• From: Uche Ogbuji <Uche.Ogbuji@f...>
• Date: Tue, 05 Apr 2005 12:18:19 -0600
• Cc: Michael Champion <michaelc.champion@g...>,xml-dev <xml-dev@l...>
• In-reply-to: <4252B1D7.8090707@t...>
• Organization: Fourthought, Inc.
• References: <200504051139.j35BdXDR050954@s...> <42528FB5.7040300@p...> <e3a5cb2c0504050804887b795@m...> <4252B1D7.8090707@t...>

Bill de hÓra:

> I understand this to mean: create objects (=resources, when speaking 
> about REST) for the things of interest and expose them to the client 
> (to  make caching of read-data-requests (GET in REST-land) possible.

Michael Champion:

> >That seems to violate the principle of information
> >hiding 

Jan Algermissen:

> Hmm...making the objects of interest known to the client is not what I 
> understand by "information hiding". "Information hiding" to me means to 
> hide the implementation from the client.

Precisely.  That's where Mike got confused.  One interesting property of
SOA (assuming I have the right idea from the hundred pundit-flavor-of-
the-day definitions) is that at first glance it seems to turn every
classic architectural convention on its ear.  But if you pay proper
attention to what those classic conventions really mean, you find
there's no real conflict.


> Of course there are issues with the granularity of what you choose to 
> expose (Facade pattern comes to mind[1]), but the extreme of providing a 
> single poiunt of access (e.g. http://foo.org/myService ) to POST 
> everything to just doesn't seem to cut it when it comes to scalability 
> and integratability.

Navigating this compromise is the main reason why SOA/REST/WS/etc. do
not eliminate the roles of expert data architects, as wizard toolkit
vendors like to suggest.  See also David Megginson's REST questions.
The answer is that there is no one answer.  You need a deft hand to tune
things for your specific application.  The result, of course, is well
worth the care, or we wouldn't be advocating what we do.


-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
Use CSS to display XML, part 2 - http://www-128.ibm.com/developerworks/edu/x-dw-x-xmlcss2-i.html
Writing and Reading XML with XIST - http://www.xml.com/pub/a/2005/03/16/py-xml.html
Use XSLT to prepare XML for import into OpenOffice Calc - http://www.ibm.com/developerworks/xml/library/x-oocalc/
Be humble, not imperial (in design) - http://www.adtmag.com/article.asp?id=10286
State of the art in XML modeling - http://www.ibm.com/developerworks/xml/library/x-think30.html

• Follow-Ups:
  • Re: Exposing resources/services vs hiding implementationdetails
    • From: Rich Salz <rsalz@d...>

• 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: Jan Algermissen <jalgermissen@t...>

• Prev by Date: Re: Exposing resources/services vs hiding implementationdetails
• Next by Date: XML-based format for educational test / quizes
• Previous by thread: Re: Exposing resources/services vs hiding implementationdetails
• Next by thread: Re: Exposing resources/services vs hiding implementationdetails
• Index(es):
  • Date
  • Thread