Single interface per service?... Why?

I have been reading the summary of F2F and decisions made there and this particular one I had an immediate doubt about. May be someone who is standing behind the "single interface per service" could clarify this for me. May be there is something I'm missing from the dicussions that I'd better understand instead of simply recoding an objection to that decision.

Here is an example. There is a service A that has an endpoint that binds the interface A1. There is a service B and interface B1 similarily. Those are internal services. I'd like to offer service C that is an aggregate of two functionalities to a partner. I may have an intermediary that may merely represent an aggregate. So, in the WSDL I'd have service C that has two endpoints, one binds interface A1 and another binds B1. Both may or may not share the same address.

Now, this works in WSDL 1.1 and 1.2 restricts this to a very weird workarround to represent the aggregation with some sort of foreign targetResource or via inheritance and partial interface bindings. WHY?

What was the objective of inroducing the one interface per service restruction? Did it make anybody's life any significantly easier? WSDL processors have to take care of partial intefrace bindings now, that may be even more complicated…
It seems this has satisfied some kind of abstract concern that may be dabated to the end of the life, but the reality of implementations did not become any better, in fact it became uglier in one of the most interesting cases of WS deployments.

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788