Proposal for dealing with solicit/response and notification

 Hi all, 
 I've agreed to send a concrete proposal for dealing with these
"outbound" operation patterns.
 First the proposal, then the rationale and other related 
thoughts.

 Proposal:
 1) remove solicit/response and notification operation patterns
-> a portType operation will have the following structure (if
there is no <output> element, no <fault> element is allowed,
either):
 <operation>
   <input>
   <output>?
   <fault>*
 </operation>
 2) extend <service> to the following structure (and extend 
<serviceType> appropriately):
 <service>
   <port>+
   <requirement>*
 </service>
 3) the structure of the <requirement> element is the following:
 <requirement portType="QName"/>
 i.e. empty element with a mandatory attribute referencing a 
portType.

 The semantics of this:
 If a client wants to access a service, it must provide (by any 
means) an implementation of the required portTypes.
 This may be used to have a callback (the implementation of the
requirements is the client) or a Gudge->Football service->Mobile
phone (GFM, see footnote) scenario (the implementation of the
requirements is the mobile phone).

 The rationale: 
 The only things why we want the outbound operations are 
callbacks and some more complex scenarios like the mentioned GFM 
scenario above. Having <serviceType>, there is no inherent need 
to combine the inbound operation patterns with outbound operation 
patterns in one portType (especially since the outbound patterns 
are not even supported in the current bindings). Therefore I 
mandate splitting inbound and outbound parts of an interface into 
two portTypes. 
 This furthermore eases considerably the reuse of these portTypes 
(for example when somebody wants to describe their mobile phone, 
reusing its definition from the GFM scenario).

 Related thoughts:
 Some may argue that these more complex scenarios (and in fact
callbacks, too) are orchestration and therefore out of scope of
WSDL; some argue that request/response coupling is the same case.
We want some 80/20 division, so we allow description of these
patterns but not more. 8-)
 We may decide that the requirement should reference a binding, 
not a portType.

 I apologize for not sending it earlier.

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/



Footnote about GFM scenario:
 There is a service that can send football scores to people's 
mobile phones after the people subscribe with their phone 
numbers. There are two operations: 1) subscribe, 2) send score; 
and there is one service (Football service) which should be 
described with one WSDL concept.
 The name comes from the fact that Gudge was involved heavily in 
creating this scenario (drawn in the picture of it, in fact).

Received on Thursday, 20 June 2002 06:19:47 UTC