W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2004

Re: Proposed replacement text for Section 1.6

From: Francis McCabe <fgm@fla.fujitsu.com>
Date: Tue, 13 Jan 2004 09:40:10 -0800
Message-Id: <88E46E2B-45EF-11D8-B909-000A95DC494A@fla.fujitsu.com>
Cc: www-ws-arch@w3.org
To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>

It's hard to pin down the precise causes of fragility in OO approaches. 
To me, the fragility comes mostly from early binding, especially using 
nailed down types for describing messages. IMO, expressing a message 
type in XML Schema doesn't seem a whole lot different to CORBA IDL. 
However, two features of the W3C/XML space *do* seem to mitigate this:
a. The XML convention that processors ignore elements that they do not 
b. The Semantic Web/Ontology way of expressing connections between 
terms within messages.

A second root cause of fragility is, IMO, the limited models of 
conversation that we always seem to come up when getting computers to 
talk to each other. OO approaches are fundamentally 
command-and-control: I tell, you do. But, humans do not talk to each 
like that, and its limiting to make computers do that also. It is 
always possible to fit a protocol into a command-response mold, but its 
a source of fragility when you do. (E.g., instead of "tell me about X; 
X is good and cheap", you have to "tell me what properties you have, 
get property X, etc.")

On reflection, I would say that there is a equality in the relationship 
between services and messages. That is at the heart of the SOA 
approach: neither is subservient to the other. By identifying messages 
as way points in a choreography seems to be a productive way of 
capturing the essentials in the SOA. (And it re-legitimizes the WS-CHOR 


On Jan 12, 2004, at 7:22 PM, Champion, Mike wrote:

>> -----Original Message-----
>> From: Cutler, Roger (RogerCutler)
>> [mailto:RogerCutler@chevrontexaco.com]
>> Sent: Monday, January 12, 2004 9:45 PM
>> To: Champion, Mike; www-ws-arch@w3.org
>> Subject: RE: Proposed replacement text for Section 1.6
>> Sure, the grid connection is a little worrying, but surely
>> there is a way to put this that one can see the difference
>> between big honkin objects that are throwing events all over
>> the place -- and a little innocent grid?
> My main objection here is that the well-known limitations of 
> distributed
> object systems apply whether they are implemented with proprietary RPC,
> CORBA, or SOAP/WSDL -- it's not the web service technologies that make
> distributed OO less appropriate for SOA for many scenarios, it's the
> fundamental criteria for successful distobj systems not being met.
> So, I'd be happy to say something like:
> Distributed object systems have a number of architectural challenges 
> [the
> Waldo et al paper is the canonical reference -
> http://research.sun.com/techrep/1994/smli_tr-94-29.pdf].  These 
> include:
> - Problems introduced by latency and unreliability of the underlying
> transport
> - The lack of shared memory between the caller and object
> - The numerous problems introduced by partial failure scenarios
> - The challenges of concurrent access to remote resources
> - The fragility of distributed systems if incompatible updates are
> introduced to one side or the other (this article doesn't discuss that)
> These challenges apply irrespective of whether the system is 
> implemented
> using COM/CORBA or Web services technologies.  Web services are no less
> appropriate than the alternatives if the fundamental criteria for 
> successful
> distributed object architectures are met.  If these criteria are met, 
> Web
> services technologies may be appropriate if the benefits they offer in 
> terms
> of platform/vendor neutrality offset the performance and implementation
> immaturity issues they may introduce.
> Conversely, using Web services technologies to implement a distributed
> system doesn't magically turn a distributed object architecture into 
> an SOA.
> Nor are Web services technologies *necessarily* the best choice for
> implementing SOAs -- if the necessary infrastructure and expertise are 
> in
> place to use COM or CORBA as the implementation technology and there 
> is no
> requirement for platform neutrality, using SOAP/WSDL may not add enough
> benefits to justify their costs in peformance, instability due to the
> immaturity of implementations, etc.
> The bottom line is that the choices of SOA vs distributed object
> architectures and COM/CORBA vs web services implementation strategies 
> are
> somewhat orthogonal, and the right choice for a specific application 
> depends
> on a variety of factors that must be judged on a case by case basis.  
> We can
> say that in general SOA and Web services are most appropriate for
> applications a) that must operate over the Internet where reliability 
> and
> speed cannot be guaranteed; b) where there is no ability to manage
> deployment so that all requesters and providers are upgraded at once; 
> c)
> components of the distributed system run on different platforms and 
> vendor
> products; and d) there is an ability to build from the ground up using 
> an
> SOA-aware architectural style or an ability to incrementally rebuild
> components using SOA principles and WS technologies.
> [There's a guy on java.net who pretty vigorously disagrees with this 
> last
> paragraph, I believe.  See the lengthy 
> comments/response/counter-response
> threads on the article at http://weblogs.java.net/pub/wlg/891 ]
> -
Received on Tuesday, 13 January 2004 12:40:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:10 UTC