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

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

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


Subject: BTP & BPM (in all its flavours)


All

I am posting this now such that people can comment on the Workflow doc
attached in light of the current ebXML BPSS / UMM controversy /opportunity
(dependant upon your perspective). I have chosen not to copy the ebXML guys
in at this point as I think this high level overview will be seen as
"ignorant" - as well it might be, but I figure less fuel to the fire is
prudent at this time.

This is by no means an in depth report on how BTP will be or can leverage
other standards surrounding the area of BPM, and should be read as a first
version / draft. As agreed in the conf call this week I will work with Bill
Pope and the Security guys to determine the correct level and format for the
two appendices to the spec  - this area Workflow and the Security area. The
doc attached constitutes a start such that we understand at a high level
what and where opportunities lie to collaborate, consolidate or again
leverage other standards and efforts in the arena of BPM.

I have read the BPSS spec and am still of the opinion that we are not in
conflict with this in respect to transactions. Where there maybe some
overlap / convergence / opportunity is  with multi-party collaboration,
Monitored Commitment, and the UMM defined business transaction Patterns
 UMM is not part of the ebXML standards but is used in the BPSS ).

Hopefully we can get a more in-depth understanding in an informal discussion
with these guys, when they have also read more about BTP.

Regards,
-------------------------------------------------
Mark Potts
Chief Technology Officer
Talking Blocks
www.talkingblocks.com

t. 415 255 7424
f. 415 255 7425
c. 415 606 9096
e. mailto:mark.potts@talkingblocks.com
-------------------------------------------------


-----Original Message-----
From: Peter Furniss [mailto:peter.furniss@choreology.com]
Sent: Friday, July 06, 2001 9:27 AM
To: BTP - mainlist
Subject: fw from ebxml-bp: FW: What to do in phase 2: Monitored
Commitments


I hope Bob wanted me to forward this, 'cos I have.

-----Original Message-----
From: Bob Haugen [mailto:linkage@interaccess.com]
Sent: 06 July 2001 16:53
To: 'ebXML-BP@llists.ebxml.org'
Cc: 'Peter Furniss'
Subject: What to do in phase 2: Monitored Commitments


This is the first draft of a document I promised on the
July 2 ebXML-BP conference call.

Table of contents:
1. Short overview
2. How to make ebXML business collaborations really easy,
    or Declarative vs Procedural
3. A stack of binary interactions

_1. Short overview:  _

Q: Assuming the transaction level of BPSS is consolidated by implementors,
what should the ebXML-BP team do next?
A: Monitored Commitments.

Monitored Commitments are also the answer to these related questions:
How to make ebXML business collaborations really easy to use?
How to facilitate business patterns at the collaboration level?
How to start incorporating REA into BPSS?

It is also part of the answer to the questions:
What is better about ebXML than traditional EDI?
What are the unique contributions of ebXML-BP to the current herd
of candidates for business process modeling standards?

_Brief definition of Monitored Commitment:_

An Economic Commitment is an REA concept defined in UMM N090R9
as "an obligation to perform an economic event (that is, transfer ownership
of a specified quantity of a specified economic resource type) at some
future point in time. Order line items are examples of commitments."

In this proposal, I want to generalize the idea of commitment to
mean a promise to perform any specified event in the future,
according to specified time constraints.  As in Economic Commitments,
when the specified event occurs within the specified time constraints,
the commitment is fulfilled.

A commitment includes not only the time constraints but also
(in Bill McCarthy's words) an image or detailed specification of the event
that will fulfill the commitment.  Comparison of the specification with
the record of the candidate event will determine if the commitment
is fulfilled completely, partially, or not at all.

A Monitored Commitment is a mechanism that keeps track of the state
of the commitment - whether it is coming due, past due, fulfilled partially
or completely or unfulfilled - and can raise appropriate events and
exceptions.
For an inexact analogy, think of an appointment in a computer calendar that
raises timely reminders.

A Monitored Commitment gives us a critical element we have lacked
at the ebXML-BP Collaboration level:  time constraints.  We have
time constraints within a transaction, but no time constraints between
transactions in a collaboration.

Note:  I am proposing Monitored Commitments here as a business
requirement.  I have ideas about how to implement them, but this
is not an implementation proposal.  However, I *do* propose that
Monitored Commitments be implemented in phase 2 of ebXML-BPSS,
whenever and wherever that occurs.

_2. How to make ebXML business collaborations really easy,
    or Declarative vs Procedural_

Most of the current work on business process standards focuses
on procedural choreography:  transitions, guards, forks, joins,
pre and posconditions, etc.  While this work is necessary to
implement business transactions and collaborations, I seriously
doubt if business people (even business app programmers) will
want to spend a lot of time on choreography, especially if they
can avoid it.

By contrast, the UMM transaction patterns are declarative:
declare the transaction pattern you want to use (offer-acceptance),
the requesting and responding documents, and maybe override
some default parameters, and you're done.

We made use of the declarative nature of the UMM transaction
patterns by incorporating them by reference into BPSS and the
BP analysis worksheets, instead of insisting that business
users redefine each transaction using UML models.

The business collaboration level can be made similarly declarative.
(And I mean declarative from the business requirements view here.)

For the most common example, order-fulfillment-settlement is a
pattern that can be canned as a procedural choreography and then
used in a declarative manner by businesses.

However, to support declarative collaboration processes, we
need time constraints between transactions.  Plus we need the
time constraints connected to the future events they constrain.
Thus the idea of Monitored Commitments.

>From a business requirements view, it should be possible to
declare that a commitment has been made (for example to
deliver 1000 products next Thursday at 9am) and the collaboration
management software should be able to monitor the state of
that commitment and raise exceptions if it is not properly
fulfilled.

_3. A stack of binary interactions_

Binary or two-way interactions are easy-to-understand building blocks
for more complex business conversations.

Request-response is the basic interaction of HTTP.

Offer-Acceptance is one business transaction counterpart of
Request-Response.

Commitment and Fulfillment is the collaboration-level counterpart
of Offer-Acceptance.

Stacks of binary interactions are much closer to the design sweet
spot for business conversations than procedural workflow scripts.

Respectfully,
Bob Haugen


BEGIN:VCARD
VERSION:2.1
N:Potts;Mark
FN:Mark Potts (E-mail)
ORG:Talking Blocks
TITLE:Chief Technology Officer
TEL;WORK;VOICE:(415) 255-7424
TEL;CELL;VOICE:(415) 606-9096
TEL;WORK;FAX:(415) 255-7425
ADR;WORK:;San Francisco;10 United Nations Plaza, Suite 610;San Francisco;CA;94102;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:San Francisco=0D=0A10 United Nations Plaza, Suite 610=0D=0ASan Francisco, CA=
 94102=0D=0AUnited States of America
EMAIL;PREF;INTERNET:mark.potts@talkingblocks.com
REV:20010412T180824Z
END:VCARD

OASIS Business Transactions Technical Committee - WorkflowReport.doc



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


Powered by eList eXpress LLC