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 Monday, 12 January 2004 22:22:57 UTC