[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] Late Binding
Anders, Ok - I'm not seeing anything here in your laundry list that conflicts with the context approach. See my notes below! Cheers, DW. ----- Original Message ----- From: "Anders W. Tell" <anderst@toolsmiths.se> To: <ebxml-bp@lists.oasis-open.org> Sent: Tuesday, January 27, 2004 2:41 PM Subject: Re: [ebxml-bp] Late Binding > David, > > Im not sure I fully agree with you. Im pointing to the fact that the > problem is more problematic than just defining a value=function() > mechanism. I agree that more parameters that timeToPerform are subject > to dynamics changes, but we are discussing a business protocol so IMO > more aspects comes into play. > > * Establisment of Trade Practices by an organization -> what values are > defined where, when and by whom. > DW: Obviously these will reflect the BPSS and industry domain exactly. In fact some factors may go across a domain very nicely - example grocery industry - refridgerated goods - Y/N ? The industry CoI must be free to set their important metrics in this way - we cannot legislate against that. > > * Predictability -> If too much flexibility is available then building > business systems are not simplified. More expensive COTS. Less is more. > DW: What the BCM and CAM work teaches us is that these factors that "bubble up" here to the CPA are the "big ticket" ones. By exposing them at the CPA level - you get that consistency - that is LOST if you bury them down lower. These factors are globally important across the BPSS, and that is why we see them declared in this way. Other factors can be handled easily locally at the interchange layer - forinstance CAM templates. So we do not get trivial factors flooding the CPA layer. I can show you example templates that clearly show this working in practice - in fact Figure 3.2 is a good illustration of this. (The CCTS work also agrees with this in terms of context of core components and the factors that one takes into account to derive context varables). > > * How can "overriding" be used to create a "natural" way of defining > timing or other constraints? > DW: By tying it to the existing BPSS structure. We are not allowing people to morph or extend the BPSS itself - so this is a naturally constrained facility here. The namespace bpss: is also intuitive way to reference the BPSS elements. > * In the business domain there is need for "propose-accept-reject" > semantics and not only "declare". Agreed business procedures often need > consent before changes can be applied. > DW: we're not supplanting that - the context instance becomes part of the CPA process - infact its empowering - because now people can exactly see what business rules directly impact their process - whereas before they could be hidden in the transaction layer - as late binding issues. We can "pretty print" the rules in say HTML from the XML to help the management sign-off. And you can propose changes and accept / reject the context document just as with the CPP/CPA itself. > > * Are you trying to use BPSS to solve another problem? (real world vs > virtual, communication world) > As Bob Haugen pointed out, many timing constraints could be viewed/are > really notification committments/duties. > (see slide > 11<http://www.toolsmiths.se/documents/serviam_legal_20040202.pdf> for an > example) > DW: Not at all. What we're providing is the context mechanism that is currently missing. You can map between say UML business rules, and the XML format for those as part of the CPA very easily indeed. > > * If you delegate the task of determining timeToPerform to a remote > method, then what happens in case of invocation failure or timeout? > DW: We are NOT doing this. The context is EXPLICTLY managed by the BPSS engine - by looking at the intersection of three factors: as:function() statements, bpss:reference(s) and doc:transaction details. All these are within the BPSS environment and there are no external calls. > * If you delegate the task of determining timeToPerform to a remote > method, then isnt really defining another BusinessTransaction the right > way to go if the remote methods is located in one of the parties > business IS/IT system? > DW: See note above - NA. > Just to complicate the issue a little ;) > > /anders > DW: Anders - actually that is the whole point of the context mechanism; it is not complicated. It is a simple, discreet approach that provides a restricted and focused mechanism that fits into the existing CPA and BPSS metaphors and enables business rules.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]