OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue - 53 - Should include Business Transaction Management (BTM) programming constructs compatible with WS-T, BTP and WS-TXM]


> Mark,
>
> I think that is too narrow a view.
>
> As a short term band-aid - just tracking the BPEL context will
> work - same as WS-CAF is doing too.   And that is fine if that
> is all you care about.

Sorry, but WS-CAF doesn't do this (more precisely, the WS-Context
specification doesn't do what you are suggesting, or rather what I was
suggesting as an initial approach for BPEL): it allows the tracking of
contexts of arbitrary complexity. However, I'm not sure this is the
appropriate forum to discuss that (though if people want to open this up, we
could).

>
> However - for eBusiness orchestration you have to know the
> complete ebusiness context - because that can effect your
> execution path downstream or upstream from where you are
> at that instant.

What's your definition of the complete context? I wasn't actually imposing
any restrictions on what could be in this BPEL context element - essentially
anything that is needed for the BPEL process to run. However, what I was
suggesting was that defining a general context structure (that could, for
example, be used to carry a security context, a transaction context, ...)
and then showing how it could also carry a BPEL context, is out of scope.
Other specifications/standards efforts (like BCM, for example) may do this,
so why re-invent the wheel or step on their toes?

>
> That's why the BCM Choice Point approach is providing that
> ability to do more than just a "thread ID" and status style
> approach.

For some b2b interactions just being able to correlate is sufficient. For
others it isn't, as you mention.

>
> Anyway - you can either resolve this with a short-term BPEL
> only technique - or you can look beyond that to the bigger
> picture.

I don't think anyone can say what the bigger picture is going to look like
at the moment, unfortunately. IMO if we are going to tackle this issue at
all in this TC then we should look at what's needed for BPEL in terms of a
context "element" (or whatever you want to call it). Then implementers can
worry about how it's conveyed.

Mark.

>
> Thanks, DW.
> =====================================================
> Message text written by "Mark Little"
> >
> I agree, but I think it's too early (aka wrong) to try to define how the
> context will be propagated (or at least to mandate it). I think defining a
> BPEL context element is fine - we should be able to provide an element
that
> can be carried in a manner defined by whatever BPEL is layered on (e.g.,
> WS-C or WS-Context, or WS-...) because at the level of BPEL we aren't
> interested in anything other than the BPEL specific context component.
>
> Mark.
> <
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.
php.
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]