RE: Summing up on visibility(?) (really, I mean it this time 8-)

"Christopher B Ferris" <[email protected]>
Newsgroups gmane.comp.web.services.ws-arch
Message-ID <OFA97AA120.169B9B67-ON85256CAA.0062AC16-85256CAA.0062F382@rchland.ibm.com>
+1!

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: [email protected]
phone: +1 508 234 3624

Mike Champion wrote on 01/10/2003 12:34:00 PM:

> 
> 
> 
> > -----Original Message-----
> > From: Mark Baker [mailto:[email protected]]
> > Sent: Friday, January 10, 2003 11:19 AM
> > To: Miles Sabin
> > Cc: [email protected]
> > Subject: Re: Summing up on visibility(?) (really, I mean it this time
> > 8-)
> > 
> > 
> >
> > 
> > "The trade-off, though, is that a uniform interface degrades 
> > efficiency, since information is transferred in a standardized form 
> > rather than one which is specific to an application's needs."
> 
> I'm thinking more and more that this is the starting point for *all* web
> services and not a differentiator between REST and SOAP/WSDL.  I'm 
further
> inclined to say that this discussion has helped clarify how one can move
> toward this by either making the information needed by applications 
other
> than the intended one (e.g. intermediaries) available in at least two 
ways:
> make the message content opaque and put the needed information in the
> protocol headers (HTTP is particularly powerful in this respect), and/or 
to
> make the message content "visible" using XML and related standards,
> especially SOAP and its header extensibility model, WSDL to describe the
> contents of the message body in a machine-friendly way, and numerous
> emerging standard SOAP headers to support encryption, authentication,
> signing, routing and reliable messaging across protocols and 
intermediaries,
> choreography of multi-part messages, etc. etc. etc. 
> 
> For whatever it's worth, this discussion has deepened my understanding 
of
> the traditional Web intermediary model based on ports and HTTP header
> information, but it has INCREASED my appreciation for the value that XML 
and
> SOAP add to that.  Just as the synergy of URIs, HTTP, and HTML created a 
Web
> that is much more than the sum of its parts, the Web + XML have 
synergies
> that are just becoming apparent ... and go far beyond the "XML is just
> another opaque data format" perspective that it seems that REST 
advocates
> prefer. 
> 
> The distributed object model without XML would not work well over the
> internet, I do fully agree. But XML breaks out of the boundaries to 
achieve
> RESTful *objectives* in a way that the REST "dogma" doesn't seem to
> appreciate.  "Visibility" is an important principle, and XML makes data
> visible beyond HTTP's dreams.  Likewise, I'm coming to appreciate the
> uniform interface constraint for *data transfer*: a world of hard-coded 
RPC
> methods in opaque messages would be as problematic as Mark claims, but
> XML-serialized object interchanges can leverage both the uniformity of 
the
> data interchange methods and the specificity of traditional distributed
> object systems.  Whatever the theoretical rough spots here, they seem to 
be
> increasingly overwhelmed by the network effect (e.g. all those people 
who
> understand SOAP, WSDL, XPath, etc. are figuring out pragmatic 
workarounds).
> 
> 
> > It seems that only Walden Matthews and James Snell[1] agreed with my
> > characterization of visibility, of those who spoke up.  Is that enough
> > to get it in to the WSA doc?
> 
> Is there some draft text that doesn't talk about cows or circles that 
you
> suggest we put in?  Where would you suggest putting it? Can you live 
with
> something like my summary above of the value of "visibility" and how
> XML-based technologies complement the HTTP-based technologies? [I didn't
> think so :-) ] 
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.