RE: Proposed text on 'SOA' (resend)

It seemed to me originally that a bunch of the governances in the stuff
that Hao wrote were a bit debateable -- or perhaps that he intended
something different by saying "must" and "required" than some might
assume.  I'm not sure what component of this is missed communication and
which is real disagreement, but I suspect that there are aspects of both
going on.

-----Original Message-----
From: David Orchard [mailto:dorchard@bea.com] 
Sent: Wednesday, September 10, 2003 10:55 AM
To: 'He, Hao'; www-ws-arch@w3.org
Subject: 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 12:40:22 UTC