Hi,
My first impression was:
"The mechanism is related to the transport
layer, it may not be the proper solution to put it into the
core."
and also thought:
"Should the core be 'transport'
agnostic?"
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:
http://www.w3.org/2005/08/ws-polling/HoldResponse
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.
===
But
for 'ease of use' and the situation that most services are
probably synchronous, the async profile can help in the
adoption.
So I
am in favor.
Regards
Ernst
Jan
Andreas Kuehne wrote:
Hi all,
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
Separate profile:
- 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,
Andreas