Subject: RE: no synch vs asynch indicator in CPP/CPA
There is something that plays (in my mind) against the idea that sync/async would be a BP matter. Perhaps I am wrong, but if by "BP" we mean the modelling of a given exchange (business process), I would be surprised that business analysts (which, in my mind, are the ones who actually define business processes) would really care about sync or async. Furthermore, seems to me that the discussion that went on in this thread assumes that the BP modeller would actually know the implementation technology. Wouldn't this be "against" the rules of reusability? I am not sure completely, but I am tempted to think that the issue of sync/async is just an "accident" of implementation, i.e. it is something that gets into the picture at the time the CPP is actually created. Something like: - do you have a browser? Well, you should use this and that... - do you have something different? Well, in this case you can use something else. But always to carry out the same business exchanges. If the BP "assumes" (could it prescribe something like this??) that the exchange is "almosty real time, then it will be up to the parties to try to use the best technology to fit this requirement, it cannot be imposed by the BP. So, if I only have SMTP, I could try to arrive as close as I can to the "real time" but I know that I will never arrive; nonetheless, if I find a partner who is happy with that, I am ok. This mirrors in some way a similar thread on multi-hop from the TRP. If the only mean I have is HTTP and a Browser, I would never be able to receive multiple acks for the same request, unless I find an escape somewhere. But if the two partners agree on "cutting" some part, why not? Does this make sense? As said, it is more a brainstorm rather than a final opinion. /stefano » -----Original Message----- » From: Martin W Sachs [mailto:mwsachs@us.ibm.com] » Sent: 23 January 2001 21:30 » To: Duane Nickull » Cc: christopher ferris; ebxml-tp@lists.ebxml.org » Subject: Re: no synch vs asynch indicator in CPP/CPA » » » » I may be repeating what I just said in my response to Chris but let me try » it again. » » The question is, why would Sync ever be used? Possibilities: » » 1. For whatever reason, the business process decides that it must » receive a sync reply to a request, so it specifies sync in one way or » another and the result is that the other party is forced provide a sync » receive capability, meaning that it must receive requests with HTTP and » send the replies synchronously (in the response to the POST). An example » of this case is where the BP that sends requests is a browser and has no » async receive capability. » » 2. The BP that receives requests has no capability for sending » asynchronous replies. But this is backwards. If it is receiving » requests, it has server-type function and surely is capable of sending » asynchronous responses. » » Notice also that the delivery channel defines receive capabilities. » However for such a delivery channel a sync/async attribute is really » describing response-sending capabilities, not receive capabilities. I'm » not sure this matters but there may be a comprehensibility issue for the » standard here. » » My conclusion is that it is the BP which cares whether the response is » synchronous or asynchronous although the only obvious example I can think » of is where the BP is actually a browser. I'm not sure whether that makes » it an implementation matter but it's still the BP characteristics that » count. » » One CPP-structural problem with putting the sync/async choice inside the BP » is that it is not clear to me how to convey that information to the rest of » the CPP or CPA, which is a separate document. Can the value of an » attribute in the BP document be conveyed back to the CPP or CPA and used to » choose the correct delivery channel or is this a case where the CPP writer » has to know that certain messages must be synchronous and set the service » bindings accordingly? » » Regards, » Marty » ****************************************************************** » ******************* » » Martin W. Sachs » IBM T. J. Watson Research Center » P. O. B. 704 » Yorktown Hts, NY 10598 » 914-784-7287; IBM tie line 863-7287 » Notes address: Martin W Sachs/Watson/IBM » Internet address: mwsachs @ us.ibm.com » ****************************************************************** » ******************* » » » » Duane Nickull <duane@xmlglobal.com> on 01/23/2001 02:46:41 PM » » To: christopher ferris <chris.ferris@east.sun.com> » cc: "ebxml-tp@lists.ebxml.org" <ebxml-tp@lists.ebxml.org> » Subject: Re: no synch vs asynch indicator in CPP/CPA » » » » » » christopher ferris wrote: » » > The distinction as I see it is that the BP should be » > independent of an implementation, but an implementation » > that supports a BP would be engineered so as to provide for » > either response pattern according to its needs. » > » > Comments? » >>>>>> » Chris: » » YOu make some very good points and I fully concur that the synch/asynch » details belong in the CP* » » The BP should remain agnostic to certain delivery details. » » Duane Nickull » » » »
Powered by
eList eXpress LLC