W3C home > Mailing lists > Public > www-ws-arch@w3.org > September 2003

RE: Proposed text on 'SOA' (resend)

From: He, Hao <Hao.He@thomson.com.au>
Date: Wed, 10 Sep 2003 13:28:25 +1000
Message-ID: <686B9E7C8AA57A45AE8DDCC5A81596AB0922DB71@sydthqems01.int.tisa.com.au>
To: "'David Orchard'" <dorchard@bea.com>, "He, Hao" <Hao.He@thomson.com.au>, www-ws-arch@w3.org
In your original words:"Extensibility is an optional constraint that yields
the desirable property of evolvability, imo. "  So you seem to imply that
"Extensibility" is indeed a constraint. Now, you claim that "Extensibility"
is just a good practise. I guess that you are right, I don't understand the
difference between your good practise and constraint. So you would be the
best person to explain the difference and I would highly appreciate that.


-----Original Message-----
From: David Orchard [mailto:dorchard@bea.com]
Sent: Wednesday, September 10, 2003 1:04 PM
To: 'He, Hao'; www-ws-arch@w3.org
Subject: RE: Proposed text on 'SOA' (resend)

This isn't getting very far.  Maybe somebody else has the time or energy to
explain the difference between practices and constraints.  I'll do a final
round of comments inline and then stop.

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of He, Hao
> Sent: Tuesday, September 09, 2003 6:51 PM
> To: 'David Orchard'; www-ws-arch@w3.org
> Subject: RE: Proposed text on 'SOA' (resend)
> Extensibility is an optional constraint that yields the
> desirable property
> of evolvability, imo.  It is not a constraint that is unique to web
> services.  So why spend time on it in web services?  The only
> thing I'd like
> to say something like "Web services should use a Must Ignore unknown
> elements and their descendents", whereas other apps might
> only ignore the
> unknown element.  Again, what is specific to web services ability
> extensibility and evolvability.
> <hh>We are talking about SOA here and I believe extensibility is
> fundamentally important to SOA.  One must have extensibility
> in order to
> claim SOA. This is because we don't want to tightly couple
> service to one
> particular version or we just keep creating new legacy
> systems all the time.
> I agree that we can and need to define Web service specific
> extensibility
> and evolvability but we only talk about SOA at this moment. </hh>

Extensibility is certainly good practice and required to achieve compatible
versioning.  But by no means is it a fundamental constraint.  Heck, there
are even proposed xml to asn.1 bindings that don't allow extensibility as
they require fixed schema.  You don't seem to understand the difference
between a fundamental constraint and a good practice.

> I disagree also that SOAP-RPC=!interoperable and
> !SOAP-RPC=interoperable.
> The principle property of SOAP-RPC is a particular schema
> that constrains
> the wire format.  This may or may not help with
> interoperability because it
> is unclear whether mapping arbitrary programming constructs
> to arbitrary
> schema language constructs is easier or harder to create
> interoperability
> than mapping arbitrary programming constructs to constrained
> schema.  There
> are lots of interoperability problems in both soap-rpc constrained and
> document formatted.
> <hh>I would still insist that SOAP-RPC=!interoperable because the RPC
> introduce unnecessary artificial dependencies from
> programming languages and
> potentially object models. Those differences in programming
> languages and
> object models are too difficult to reconcile, if not
> impossible at all. I
> agree that !SOAP-RPC may not give you interoperable but have
> !SOAP-RPC is a
> good start. Mapping arbitrary programming constructs to
> constrained schema
> is more like an implementation issue. Personally, I believe
> it is a bad
> approach because objects are not XML. However, that is separate issues
> altogether.  </hh>

Again, in a real architecture, there must be limits.  soap-rpc is probably
"bad" practice, but excluding it can by no means be considered a constraint
on web services.  Therefore, it should go in a "bad" practice section but
not a constraint.
> I still don't understand your first constraint.
> <hh>The purpose of the first constraint is to ensure a simple
> and universal
> interface so the cost of consuming a service is reduced to
> the absolute
> minimum. This may sound very much like REST and it does.  The
> difference
> here is that you don't necessary use HTTP.  You may use RMI
> for example, if
> all you software agents are Java based. Of course, the RMI
> interface has to
> be really simple, for example:
> public interface SOA {
> public String get(String msg);
> public String post(String msg);
> }
>  would be more than enough. </hh>

This isn't even worth debating.  Let's just vote on who thinks SOAs, and by
derivation Web services, must be constrained.


Received on Tuesday, 9 September 2003 23:26:29 UTC

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