OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: ebXML - OAGIS.ppt


Jim,

 

Thanks, it helps, but unfortunately it doesn’t put all the pieces together yet, at least not for me. The question I don’t have an answer for (I thought I did) is how do I know to transition to the next business state, such as Success or Failure, and how do I express it in BPSS?

 

I’m consumed with other things right now, but I will get back to this.

 

Best Regards,

________________________________________________________________

Kurt Kanaskie

IT Architecture Strategy Group

Lucent Technologies

kkanaskie@lucent.com

(610) 778-1069

 

-----Original Message-----
From: Jim Clark [mailto:jim.clark@e2open.com]
Sent: Thursday, July 12, 2001 11:13 AM
To: 'Kanaskie, Kurt A (Kurt)'; 'jj@exceloncorp.com'; 'LONJON Antoine'; 'ebxml-bp@lists.ebxml.org'; 'Karsten.Riemer@sun.com'; 'plevine@telcordia.com'
Subject: RE: ebXML - OAGIS.ppt

 

Kurt,

 

The Success or Failure of a Business Transaction is not determined by any indicator or status with a reponse document itself. Success or Failure is determined by 'guard' or business rules applied within the initiating activity. These rules are notated on the transitions that from the initiating activity to the Success or Fail state even in an asycronous Business Transaction like a notification. The signals back are simply that, signals. An event which effects a transitional change, is defined to be the result of combinational/compuational logic applied to a set signals. This logic is the guards. Remember that we are defining/modeling the state of a BT.

 

There has been lost of dialogue around the meaning of 'isPositiveResponse'. I have heard it described as 1) an indicated from the responding process of success/failure of the responding activity. 2) an indicated that defines the success/failure of the BT, or 3) a residual indicator that reflects the sucess/failure of BT.  Number 2 it is definely not. Number 1 or 3 would be determined based on when the attribute was populated. I prefer Number 1 and see this as the most useful purpose.

 

Hope this helps,

Jim Clark
Director of Industry Solutions
E2Open
936.263.3366(direct)
936.520.7428(cell)

 

 

-----Original Message-----
From: Kanaskie, Kurt A (Kurt) [mailto:kkanaskie@lucent.com]
Sent: Thursday, July 12, 2001 7:37 AM
To: 'jj@exceloncorp.com'; LONJON Antoine; ebxml-bp@lists.ebxml.org; Karsten.Riemer@sun.com; plevine@telcordia.com
Subject: RE: ebXML - OAGIS.ppt

JJ, Antoine,

 

I finally got around to giving this some quality time. I agree with JJ, isPositiveResponse clearly indicates success or failure of a BusinessTransaction. However, I think there may be some confusion or non-obvious behavior when a BusinessTransaction does not have a RespondingBusinessActivity as would be the case in a notification type of BusinessTransaction. In this case Success or Failure is determined by the signalResponse messages or lack there of, and this is not directly specified in XML or modeled in the diagrams.

 

Regarding the diagram conventions, I prefer JJ’s approach, because it explicitly states Success or Failure conditions. In your diagram Antoine, how would I represent Success or Failure constraints if the same BusinessDocument was used for both? How is the “virtual business document” indicated and what is the mapping? In JJ’s diagram, I can see how this would be done and mapped, because there is a constraint on both the Success and Failure arrows.

 

Best Regards,

________________________________________________________________

Kurt Kanaskie

IT Architecture Strategy Group

Lucent Technologies

kkanaskie@lucent.com

(610) 778-1069

 

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jjdubray@exceloncorp.com]
Sent: Friday, July 06, 2001 1:15 PM
To: LONJON Antoine; jj@exceloncorp.com; ebxml-bp@lists.ebxml.org; Karsten.Riemer@sun.com; plevine@telcordia.com
Subject: RE: ebXML - OAGIS.ppt

 

Antoine:

 

I disagree with your document. As you know, a requesting and responding activity contains a reference to a document envelop, as pointed out in your document with this extract from the DTD:

 

<!ELEMENT RequestingBusinessActivity (Documentation*, DocumentEnvelope)>

<!ELEMENT RespondingBusinessActivity (Documentation*, DocumentEnvelope*)>

 

The DocumentEnvelop has an attribute isPositiveResponse. This attribute clearly identifies an end state and whether it is a success or a failure.

 

As I understand the conditionExpression on a document, it allows us to specify a “logical document” based on a physical document. If the conditionExpression is true we should consider that the intend of the responder with to send this “logical document” but it is materialized with a physical document which could be common to several logical documents.

 

I am certainly really far from being a UML expert and I may use arguments that are not logical in the context of UML activity graph but I personally don’t see the big deal about directly specifying the conditionExpression on the transition to the failure. I also don’t see the conditionExpressions as necessarily constrains on the document but rather a way to mapping a logical intend into a physical document.

 

I also don’t see the big deal about the possibility to transitioning into a request for a second time. If it is not clear enough for people what’s going on (knowing that it happens the same way for EVERY business transaction specification) we should add a guard to that transition.

 

I see another issue that you may not have addressed in you document: this is when multiple responses are allowed to a given request, do you simply represent as many object flow?

 

Thanks,

 

JJ-

 

 

-----Original Message-----
From: LONJON Antoine [mailto:alonjon@mega.com]
Sent: Friday, July 06, 2001 2:11 AM
To: 'jj@exceloncorp.com'; ebxml-bp@lists.ebxml.org; Karsten.Riemer@sun.com; plevine@telcordia.com
Subject: RE: ebXML - OAGIS.ppt

 

All:

 

Here is a first document that responds to JJ proposal and that hilights some inconsistencies in the way of representing BusinessTransactions within ActivityGraphs.

 

Antoine

 

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jjdubray@exceloncorp.com]
Sent: Thursday, June 21, 2001 2:15 PM
To: ebxml-bp@lists.ebxml.org; Karsten.Riemer@sun.com; plevine@telcordia.com
Subject: ebXML - OAGIS.ppt

All:

 

following our conference call today. Here is the notation I came up with the represent BPSS collaboration definitions. My objective was to provide a navigation mechanism not necessarily provide an isomorphic view of the specification. I also did not try to respect the "rules" of UML activity diagrams (such as all activities that are forked are required to join, ...)

 

The slide number 6 represents some recurrent business transaction activities, as well as a business failure within a fork/join.

 

The OAGI scenarion is #55, it is freely available on the OAGI web site: www.openapplications.org

 

Any comments are welcome.

 

Jean-Jacques Dubray, eXcelon Corp.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC