My first impression was:
"The mechanism is related to the transport
layer, it may not be the proper solution to put it into the
and also thought:
"Should the core be 'transport'
For instance, the WS-Polling may
support this already (https://www.w3.org/Submission/ws-polling/)
but maybe it is a dead proposal (I did not check it completely)
WS-Polling defines a special URI that is
similar to the anonymous URI defined by WS-Addressing, meaning the
client is unable to offer an endpoint for responses:
Use of this URI in the wsa:ReplyTo EPR of
a request message will indicate to the service that the client
will use WS-Polling to retrieve the response if the response does
not come back through some other means (such as the HTTP response
flow). When the service receives a request containing this URI in
the wsa:RepyTo EPR it can immediately return an HTTP response code
of 202 back to the client - with the assumption that the client
will poll for the response at some later point in time.
for 'ease of use' and the situation that most services are
probably synchronous, the async profile can help in the
am in favor.
Andreas Kuehne wrote:
here is a question that nags me for some time:
Should we keep the Async Profile or should we merge it into the core?
There are good reasons for both:
Into the core:
- async is used by many applications
- async is quit small compared to the profile
- It is nasty to deal with a separate profile for this little functionality
- Focus the core on the 'minimal viable product'
- Don't irritate readers with details they may never use
- Async describes a quite simple way to solve the requirement. Other
solutions may show up
What's your opinion?
Greetings and have nice early-summer weekend,