RE: ebXML - OAGIS.ppt

[Jean-Jacques Dubray <jjdubray@exceloncorp.com>]

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.