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.

Cheers,
Dave

Received on Tuesday, 9 September 2003 23:03:28 UTC