[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: questions on UMM parameters (Fwd)
Jim, I have re-read the UMM section on this, and still do not know the answers to my questions in my e-mail below. I propose that the SpecSchema leave the possibilities open, and people who use UMM to arrive at a SpecSchema can apply the constraints in the UMM process. What I mean by this is that I propose that all the parameters isAuthorizationRequired isNonRepudiationRequired timeToAcknowledgeReceipt timeToAcknowledgeAcceptance isNonRepudiationOfReceiptRequired isIntelligibleCheckRequired will be available for use in either the requesting or the responding activity. That will support more than the currently suggested allowable UMM patterns, but will not prevent any of them. The interpretation of the parameters are: isAuthorizationRequired - when you send my activity a DocumentFlow, I will authorize you against a list isNonRepudiationRequired - when my activity sends a DocumentFlow I will save it as an audit trail before sending timeToAcknowledgeReceipt - when my activity receives a DocumentFlow I must ack within this time timeToAcknowledgeAcceptance - when my activity receives a DocumentFlow I must ack within this time isNonRepudiationOfReceiptRequired - when my activity receives a DocumentFlow I must send a signed ack within the time required for timeToAcknowledgeReceipt above isIntelligibleCheckRequired - when my activity receives a DocumentFlow I must validate its syntax before I send a receiptAck back. Please speak up if either my interpretation is wrong, or if you disagree that all of these options should be open at both ends. Currently UMM does not suggest acceptance from requester, but I don't see why that could not be a future pattern, it is close to what the negotiation pattern was looking for. As far as timeToPerform is concerned, I still think it applies only to the transaction as a whole and should not be in the requesting or responding activities. -karsten >----------------Begin Forwarded Message----------------< Date: Wed, 14 Mar 2001 12:40:26 -0500 (Eastern Standard Time) From: Karsten Riemer <Karsten.Riemer@east.sun.com> Subject: questions on UMM parameters To: Karsten Riemer <Karsten.Riemer@east.sun.com> cc: "Hayes, Brian" <Brian.Hayes@Commerceone.com>, "'Sharma, Nita'" <nsharma@netfish.com>, "'Bill McCarthy (E-mail) '" <mccarth4@msu.edu>, "'Bob Haugen (E-mail) '" <linkage@interaccess.com>, "'James Jamie Bryce Clark (E-mail) '" <jbc@lawyer.com>, "'Jim Clark (E-mail) '" <jdc-icot@lcc.net>, cory-c@dataaccess.com, plevine@telcordia.com This relates to today's upcoming discussion. I am having difficulty understanding the exact placement of some of the parameters in the UMM model for the 'activities': From UMM: BusinessActivity (supertype) (to be renamed businessAction): isAuthorizationRequired isNonRepudiationRequired timeToPerform timeToAcknowledgeReceipt timeToAcknowledgeAcceptance RequestingBusinessActivity (attributes in addition to the above): retryCount isNonRepudiationOfReceiptRequired RequestingBusinessActivity (attributes in addition to the above): isIntelligibleCheckRequired Questions: If a requesting activity has isAuthorizationRequired does it mean that you must be authorized to perform this activity, or that the request that you send will be validated against a list of authorized identities? My confusion is that I don't know if this attribute relates to the outgoing or the incoming message. Can a requesting activity send an Acceptance? If not, then timeToAcknowledgeAcceptance should be in only one of the activities. Which one? When a requesting activity sends a receipt ack is it intelligible checked or not? Should intelligible check be in both? Is time to perform different for requesting and responding, if not, shouldn't it be at the transaction level? >----------------End Forwarded Message----------------<
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC