[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: My AI to raise an assembly issue regarding wsdl interface compatibility
Last week I took an AI to raise an assembly issue regarding interface compatibility between rpc/lit and doc/lit portTypes. I don't think there is a need to raise an issue (details below), but this was a lively discussion last week, so want to make sure that members agree and that I haven't missed something. The argument for raising the issue lies in the fact that in WSDL 1.1, (with appropriate bindings) for every rpc/lit portType there exists a doc/lit portType that results in the same messages on the wire. Are such portType that generate the same messages on the wire, compatible? Assembly currently says that compatibility is based on operation names, input/output types. The key here is what is meant by "type". WSDL 1.1. allows the "types" to be XML GED or XML type declarations. Further complicating this is that WSDL 1.1 (is mostly) about describing messages on the wire, grouping them etc. It does say much about semantics. WSDL 1.1 doesn't separate the "abstract" and "concrete" parts cleanly. SCA has, for better or worse, decided to rely on WSDL 1.1 portType as the interface contract, which can be translated to other interface types such as Java and can be used with various bindings. The definition of compatibility in assembly needs to be fixed for lot of other reasons (eg: make it apply not just to wires but also to promotions etc, define compatible superset and compatible subset). But if I were to interpret "type" as meant by the current definition to mean the same XML element or XML type then that essentially says that portTypes defined for rpc/lit and doc/lit are *not* compatible. I think that is a reasonable thing to say. Yes it restricts rpc/lit and doc/lit being mixed during promotion/wiring etc, but it is a reasonable restriction. Without that the rules will get complicated (for no apparent benefit) and I'm not sure how it will work across interface types and with non-web services bindings. Comments? -Anish --
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]