RE: Proposed text on 'SOA' (resend)

fair enough.  I should have more clearly distinguished that the "required"
part was what I was objecting to.  You had asserted that it was
extensibility and uniform interface were required constraints and SOAs, and
that continues to be the main source of my pushback.  I believe they are
optional.

I would say that extensibility an optional constraint, but it might be
viewed as a good practice as there is some debate about the definitions [1].
From our perspective the difference between a good practice and an optional
constraint is probably not that big.  But the difference between a required
constraint (as in if it doesn't meet the constraint, it's not xyz) vs
optional is huge.  What ever the terms - practice or constraint - that are
used, the important points to debate are whether they are optional or
required, and what properties they yield.

Cheers,
Dave

[1]http://www.w3.org/2001/tag/webarch/#app-principles

> -----Original Message-----
> From: He, Hao [mailto:Hao.He@thomson.com.au]
> Sent: Tuesday, September 09, 2003 8:28 PM
> To: 'David Orchard'; He, Hao; www-ws-arch@w3.org
> Subject: RE: Proposed text on 'SOA' (resend)
>
>
> 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.
>
> Hao
>
> -----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.
>
> Cheers,
> Dave
>

Received on Wednesday, 10 September 2003 11:58:57 UTC