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>


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>


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>

Hao