[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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----- 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----- 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----- 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]
Powered by eList eXpress LLC