Re: [ebxml-bp] Linkage BusinessTransaction to Success/Fail

[David RR Webber <david@drrw.info>]

Monica,

The model and tutorial both contain the example.

You will see each transaction back is tied to some
failure or succeed condition.  So RejectPurchaseOrder is
tied to Business Failure; ConfirmPurchaseOrder is tied
to succeed, and so on.

Otherwise the model is profoundly confusing IMO WRT a
user looking at the model and figuring out what happens
when.

There may already be another way of doing this (Dales Rule?!)
but it seemed to me that using name to denote documentName
is clean and obvious.

Thanks, DW


Quoting "Monica J. Martin" <Monica.Martin@Sun.COM>:

> David RR Webber wrote:
> 
> > Team,
> >  
> > One last piece here.  While in a simple business transaction ( 
> > initiation / response)
> > the success / fail are tied by default to the single response, in a 
> > business transaction
> > that involves more than one possible response - then we need a way to 
> > tie the
> > succeed and fail guard conditions to the response.  The obvious way to 
> > do this is
> > documentName = "string" as an optional parameter. 
> 
> mm1:  David, don't we already have this with the existing functionality 
> (XOR, business state) where more than activity can occur (and in 
> parallel) but only one business state can be reached? Or, are you 
> indicating more than one response figures into the business state and 
> transition that occurs? Would these not be modeled separately?
> 
> I think we need an example so we can more effectively understand the 
> context of your question.
> Thanks.
> 
> > The same thing applies to Join and Decision.
> >  
> > Now - we could simply re-use "Name" and note that Name should be the
> > documentName.
> >  
> > Usually I don't like overloading - but seeing that nameID is the 
> > linkage point,
> > name is purely informational at this point - so making it the explicit 
> > documentName
> > would make total sense.
> >  
> > I've implemented it in my BPSS model this way for now - and I'll post 
> > that all
> > shortly so you can actually look at this and see how and why it all links
> > together.
> >  
> > This actually sits well with the BusinessTransaction block model - but 
> > gives
> > you the necessary specicifity needed to allow the transport layer to 
> > equate
> > transaction / msg occurences with conditions and guard expressions.
> >  
> > Thanks, DW
> 
> 
> 
> 


http://drrw.net