Sync Actions vs. Async Actions - do you see a difference?

[Michael Joya <mike.joya@xmlglobal.com>]

    Not long ago the TRP group adopted a syncReplyMode flag in the
message header. The flag allows the requesting party to indicate to the
responding party whether or not the response should come as synchronous
or asynchronous. The RegRep Services spec editors never had the option
of using this flag back during the inception of the action names
associated with the ObjectManager and ObjectQueryManager Service
Interfaces. However, they do now.

    In the interests of alignment with TRP I'd like to propose that
RegRep dismiss the Async versions of the Actions in these interfaces.

   The wording and diagramming of the current specification suggests
that these Actions are "functions to be called", and that the response
documents are "like return types" of those functions. By nature of the
syntax used, the payload documents are "like parameters" of those
functions. The thin distinction is made between Async and Sync versions
of those functions - Async ones do not "return".

    In practice however, the response documents are the same whether the
operation is synchronous or asynchronous, and the payload documents (or
parameters) are the same as well.

    Implementors who had previously written code to support the Async /
Sync versions of the actions have a very easy migration path: Rewrite
the synchronous Action handler to include logic that will check the
syncReplyMode flag of the message. If the flag is false, invoke your
existing Async version of your Action handler. If it is true, process as
before.

    This inhibits a faulty client application from setting syncReplyMode
to 'true' while at the same time issuing a
"GetRootClassificationNodesAsync" message. It also frees a server
implementation from having to resolve such inconsistencies.

    Feedback on this is welcome.



--
// Michael Joya
// XML Global Research and Development
// 1818 Cornwall Ave. Suite 9
// Vancouver, Canada
// 604-717-1100x230