RE: Proposed replacement text for Section 1.6

Although it is probably not possible to say anything meaningful that
someone won't vigorously disagree with, it seems to me that this
discussion is looking pretty good.  I'd say, "Book 'em, Dano" -- or
perhaps you're not old enough to get the reference?

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of Champion, Mike
Sent: Monday, January 12, 2004 9:23 PM
To: www-ws-arch@w3.org
Subject: RE: Proposed replacement text for Section 1.6



 

> -----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 10:41:58 UTC