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

[Farrukh Najmi <najmi@east.sun.com>]

This is a good point Micheal. However, I would say that we should consider
removing the synchronous version of call and rename the async version to no
longer have the word Async as suffix. Rationale is that the default is async
communication. What do people think?

PS: Micheal I am having some trouble posting from home. In case this does
not make it to list please post on my behalf.

Michael Joya wrote:

>     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
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-regrep-request@lists.ebxml.org

--

--

Regards,
Farrukh

begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard