Save outbound ops, not just output and output-input

I fear that if we keep output-only and output/input operations as is, we 
will somehow try to patch the spec to support them, but only them. It 
will then be difficult to support other outbound operations.

If on the contrary, we clearly separate inbound and outbound operations, 
we can build a mechanimsm to support all outbound operations (like a web 
service reference passing mechanism).

Let's use don's event's notification mep:
        a server will use it to say: you can subscribe to some of my 
events (new operation type as of today).
Surely someone else will need to use this piece of functionnality but in 
the other way:
        a server will use it to say: I want to be able to subscribe to 
some of my client's events (new operation type as of today).
We will face the same problem as with output and output/input operations.
If we had a general mechanism to support outbound operations, it would 
be done.

Why not having a new definition for operations:
    - an operation is either inbound or outbound
    - an operation has one associated mep: one-way, request-response, 
event's notification...

This way, we keep today's functionnalities behind output and 
output-input operations and allow any new outbound operation type to be 
integrated nicely within wsdl.

I 'd also like to know what is today's exact use of outbound operations. 
I know one and half of them: callback and  client's requirements 
description. Any other use ?

    Youenn

Received on Friday, 6 December 2002 09:34:25 UTC