Re: [ebxml-bp] Proposal for dynamic context for BPSS

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

Martin,

I disagree for EXACTLY the reasons you state!

It's just too trite and easy to say - oh lets not do this in V2.0,
we'll think about this later.   That's PRECISELY the
response I was seeing I'd get to this.

This ignores the fact that real implementations today are
being directly impacted because this is a gaping hole in
the current implementation that users desperately
need fixed now and is therefore crippling adoption
in areas such as Automotive and Electrical industry
use cases.

And beyond that - having this feature in V2.0 makes
a huge statement about the robustness and longterm
capabilities of BPSS as a technology.

Now - if this was a brand new issue that we'd never
anticipated before, and we done absolutely no work
on ever in the past - I might be inclined to take
the "do nothing" way out.

But that is simple NOT the case.  We've been working
on this for two whole years.   We've got a whole
spec' written and we've implemented code.  The BCM
team has their whole spec' too.  And the CCTS team
and UBL have worked this.

I'm therefore seeing that the proposed draft can be
quickly and effectively brought together.

As you pointed out - this is a parallel processing task
since it is a separate piece of XML from the BPSS
schema itself - so it is self-contained from that
respect, and will not impinge on the main V2.0
specification re-write.  That work will I'm sure
take 6 weeks in of itself - and 6 weeks is more
than enough time to complete the Technical Note
document covering the context mechanism.

We should also aim to produce use case examples from
the field to show exactly how this works in practice
for BPSS today as well.

I'm not prepared to agree that the "do nothing"
approach is the right one here at all - that will
IMHO be a disasterous choice.

Thanks, DW

----- Original Message ----- 
From: <martin.me.roberts@bt.com>
To: <david@drrw.info>; <ebxml-bp@lists.oasis-open.org>
Cc: <monica.martin@sun.com>
Sent: Friday, February 06, 2004 7:32 AM
Subject: RE: [ebxml-bp] Proposal for dynamic context for BPSS


> Dear all,
>   I would like to add my weight to this as I feel that if we want to keep
2.0 of the BPSS to a reasonable scope, we are going to have to accept that
late binding really is outside of the BPSS.
>
>   One concern I have is that we have two problems which David RR suggests
can be fixed by the one mechanism.  They are input of context details to
manage the document content that will be exchanged and the manipulation of
the BPSS/CPA based information that is controlling the exchange.
>
> I feel that both of the above are very much needed to plug the gaps we
have today.
> However, there seems to be a push back that says the BPSS/CPA flexibility
should be expressedin the BPSS if that is know at the time of the BPSS
design - i.e. transaction timeToPerform is based on field x plus 24 hours.
John Yunker said this was not an agreement time arrangement but part of the
business level process definition.
> With that in mind we have to build a bridge between these views.  My
feeling is that anything we do quickly that introduces flexibility in the
BPSS also will greatly complicate the resulting structures and therefore
could lead to an unclear solution rather than making life easier.
>
> For this reason I propose that the BPSS does not attempt to address this
issue as part of the BPSS 2.0 spec, but instead we need to discuss this with
a joint team of CPA and BPSS.  This would make a great topic for New
Orleans?
>
> There is another reason why I think this should be done outside the BPSS
2.0.  I am very concerned that any expression language we say we want to use
will either prove very coomplex or too simple.  We would have to choose a
default language if we are to encourage the feature to be interoperable, but
we do not have the time to work through this to a point where we could be
comfortable that we have enough to do the job but not too much that no one
really understands the implications.
>
> Take care.
>
> Martin
>
> -----Original Message----- 
> From: David RR Webber [mailto:david@drrw.info]
> Sent: Thu 05/02/2004 21:23
> To: BPSS ebXML
> Cc: Monica Martin
> Subject: [ebxml-bp] Proposal for dynamic context for BPSS
>
>
> Monica,
>
> As requested today, here is the text of the
> context proposal.
>
> Use Cases:
> =========
>
> Given that BPSS should:
>
> a) support late binding of specific parameters within
>     the BPSS based on business factors that
>     occur during a BPSS use
> b) support business modellers being able to
>     identify critical factors during creation of a BPSS
>     that effect linking and switching within a process
>     and be able to specify those and quantify their
>     details -
>     (e.g. deliveryCountry = Mexico, USA, Canada).
> c) support ability to configure BPSS flows to match
>     locale or other factors globally based on context
>     provided when a CPA is determined between
>     participants based on their own transaction
>     needs (e.g. produceType="mustRefridgerate")
> d) provide context to external components that
>     may be directed by BPSS - such as transaction
>     handling software (Java, EDI Mapper, XSLT, CAM,
>     EAI adaptor, et al), or web service step.
> e) have a mechanism to determine pre-conditions
>     for BPSS and outcomes - start, wait, or skip
>     that allows implementers to configure when
>     a BPSS should commence.
>
> Approach:
> =======
>
> Provide an XML instance, separate from but
> relating to the BPSS, specifically for managing
> context, and link to that from BPSS either
> directly (URL) or indirectly via reference in CPA
> (CPA can provide link to constrained BPSS
> context set verified by collaboration
> participants as they define their CPA).
>
> In constructing context rules within this XML
> instance simple XML will be used along with
> XPath expressions and a basic datatyping
> system founded on the W3C foundation
> data types.  This will be supplemented
> with a limited set of string referencing
> functions necessary to complete the
> data model of context rule parameters.
>
> The aim is to make this rapidly implementable
> with off the shelf simple XML development
> tools, and concise and complete to be specified
> with a supplemental Context Technical Note
> specification of 15 pages or less.  This
> supplemental document will follow the model
> used by the Registry team for their supplemental
> notes to their main specifications.
>
> Rationale:
> =======
>
> 1) A well featured context mechanism will set
>     BPSS V2.0 apart as the premier approach to
>     business orchestration using the latest
>     techniques for integration into the SOA
>     solution stack.
>
> 2) The cost of documenting the technical
>     note in 15 pages is comparable to
>     defining a lesser capability within the
>     existing BPSS with mostly the
>     same effort (XPath expression
>     definition and control mechanisms).
>
> 3) Setting this feature now for V2.0 will
>     set the foundation for V3.0 and beyond,
>     without requiring implementers to "two-step",
>     (supporting a lesser V2.0 capability that
>     then is extended later with attendent need
>     to support two related mechanisms).
>
> 4) Having a consistent context mechanism
>     that BPSS can use to manage not only
>     its own needs but can be referenced by
>     any other component that relates to the
>     BPSS provides a single consistent
>     system across the ebXML stack.
>
> 5) The context mechanism proposed is
>     already known and therefore the level
>     of effort and risk in designing it is
>     significantly less than involved in
>     starting with nothing.
>
> 6) Having a well featured context
>     system that is extensible ensures
>     that all the use cases a) thru e)
>     can be accommodated sufficiently
>     in V2.0 - therefore significantly
>     enhancing the value and utility of
>     the BPSS specification.
>
> Technical Detail:
> ============
>
> The draft proposed initial Context Technical Note
> document will be posted separately for
> reference, but it is anticipated that this
> will be completed as a work item for V2.0
> and agreed to as part of that process, by
> BPSS team members.  Input from all
> 6 use cases and worked examples can then
> be generated as part of the deliverable too.
>
> Thanks, DW.
>
>