Re: Port type extension proposal

At 01:27 PM 10/2/2002, Sanjiva Weerawarana wrote:

>"Martin Gudgin" <mgudgin@microsoft.com> writes:
> > > - We need to have multiple portTypes per service, not just one. We
> > >   believe that different aspects of a service's function are best
> > >   modeled by different portTypes and it does not make sense to
> > >   force one to combine all of them into one portType.
> >
> > OK, I've just written up what I think the TF agreed. We need to think
> > carefully about what we want going forward.
>
>I believe the IBM position (as a member of the TF too) has changed.
>So it is no longer the view of the TF .. sorry.
>
>Also, multiple portTypes per service is status quo right? So I'd
>say the onus is on the proponents of a single portType scenario
>to justify why its better to go down to one?

I have no significant objection to this.  Conceptually, this is basically 
equivalent to the current notion, but where the final aggregating portType 
is implicitly defined -- that is, the WSDL service element is doing the 
implicit aggregation, rather than having an explicitly defined and named 
portType to do that final aggregation.


> > > - The service must indicate its "type": with portType inheritance
> > >   in place we (IBM) would prefer to have the service just indicate
> > >   the interfaces it supports:
> > >     <service implements="pt1 .. ptn"> ... </service>
> >
> > Are you saying that you don't want port type B to inherit from port type
> > A but rather that a service would just say that it implements port type
> > A and port type B?
>
>I'm saying that A or B may have their own inheritance hierarchies,
>but that we do not want to force every service to have precisely
>one portType. This is functionality that already exists in WSDL ..
>
>If one wants to say B inherits from A and then say the service
>implements B that's fine. However, we believe there are many
>scenarios where a service will support more than one portType
>which are not related by an inheritance relationship.
>
> > > - The semantics of inheritance needs to be defined more. What are
> > >   the rules for two operations of the same (local) name from two
> > >   inherited portTypes?
> >
> > Currently the rule is as defined by:
> >
> > 'For each port type operation component in the {operations} property of
> > a port type component the {name} property must be unique.'
> >
> > Which means it would be an error if port type B derived from port type A
> > and both port types had an operation called 'Foo'

That is not what this member of the TC thought he agreed to. :-)

We have a perfectly good disambiguater between the two operations that have 
an name of 'Foo', namely the qname of the portType in which the operation 
is declared.  So the fully qualified names of the operations are basically 
A:Foo and B:Foo.

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.

-Steve

> >
> > > I guess the Java (and I assume C# too?) rule
> > >   of ignoring the namespace (package for Java) and just merging
> > >   the local names will work. If there's a conflict then since we now
> > >   don't allow operation overloading, we must require all inherited
> > >   operations of the same name to have the same "signature." Similarly
> > >   if the new portType defines an operation of a same ncname as one
> > >   from an inherited portType, then it must have the same signature
> > >   or its illegal.
> >
> > I think I prefer the current formulation.
>
>Can't blame you for it, however, it is quite restrictive it seems.
>However, I'm all for simplicity.
>
>Sanjiva.

Received on Thursday, 3 October 2002 02:16:25 UTC