[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----- 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 -----Original Message----- 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