Re: Port type extension proposal

Personnally, I see a number of advantages to making operations 
first class objects (option 1). Comments?

Jean-Jacques.

Martin Gudgin wrote:
> The problem is that the disambiguator[sic] is not ( currently ) visible
> at the binding level. The current formulation at least works with the
> current binding mechanism. Off the top of my head I can see a couple of
> ways forward:
> 
> 1. Make operation names QNames, by promoting operation to be top level
> components of a description. Bindings would then reference operation
> names by QName rather than a name which is local to a port type.
> Syntactically we can do this one of two ways:
> 
> 	a. Make operations top-level syntactic constructs and have port
> types reference them
> 	b. Say that operation names are qualified by the targetNamespace
> even through they are nested inside port types.
> 
> 2. Modify bindings so that they also support inheritance, bind each port
> type in turn, and end up with an aggregate binding for all the port
> types up the inheritance hierarchy. This would probably look something
> like Kevin's proposal for reusable binding components. Operation names
> would stay as local names.
> 
> 3. Modify bindings so that operations are referred to by combination of
> port type name and operation name. Operation names would stay as local
> names.
> 
> I'm sure there are other approaches we could take. I present these as
> possible ways forward, I'm sure people will come up with other
> suggestions.
> 
> 
>>To push on this a bit more...  What if you have a portType A
>>with operation 
>>'Foo', a portType B with operation 'Foo', and portType C that 
>>extends both 
>>A and B?  Would this also be an error?  If so, I think you 
>>are completely 
>>breaking encapsulation.  The designers of portTypes A and B 
>>cannot choose 
>>their operations in isolation.  In effect, this decision would force 
>>designers to ensure that all operation ncnames be globally 
>>unique (without 
>>the benefit of namespaces) if you hope to allow them to be 
>>aggregated by 
>>independent parties. This effectively negates most of the 
>>purpose of having 
>>portType extension, which is to allow reasonable modelling of 
>>interfaces 
>>and interface extension.
> 
> 
> Another interesting question ( to me, at least ), which is along the
> same lines, is what happens if two operations in a port type reference
> the same global element declaration ( via a message ). How does a
> service disambiguate them? It seems like this is a similar problem.
> portType designers apparently need to make sure they don't use the same
> GEDs for messages, otherwise there is no way to tell them apart on the
> wire. 
> 
> Gudge
>

Received on Thursday, 3 October 2002 11:17:57 UTC