----- Original Message -----
Sent: Friday, November 07, 2003 7:35
PM
Subject: RE: [ebxml-bp] BPSS
executability and where it ends
It is not completely impossible to do that today. BPSS 1.01
has the concept of a "logical" business document and transitions can be
guarded by these documents.
A logical business document is nothing more than a physical
document with a condition.
So one could define an "Invoice_is_paid" business document
which is really a Process payment message with a payment amount equal to the
order amount. The BSI should execute this without problem.
I am not trying to say that it is already in there and that we
should do nothing about it, I am just saying that we are not too far, and that
could easily fit into BPSS.
Jean-Jacques
tel: 425-649-6584
Cell: 508-333-7634
-----Original Message-----
From:
Yunker, John [mailto:yunker@amazon.com]
Sent: Friday, November 07, 2003 4:26 PM
To: Boonserm (Serm) Kulvatunyou;
ebxml-bp@lists.oasis-open.org
Cc:
anderst@toolsmiths.se
Subject: RE: [ebxml-bp] BPSS
executability and where it ends
This is an area that Business Entity Types was supposed to
partially address, by allowing the BPSS to reference named states of business
objects (e.g. Shipment is Delivered), and then layering the definition of
"Delivered" (rule expression) in the business agreement (being addressed by
UBAC).
Note that you could still put the BET state expression on the
BPSS transitions (e.g. Invoice.is_Paid AND Product.in_Shipment AND
Shipment_is_Delivered), and provide an element in the BPSS where the states
could have their complete definition (e.g. < 5% scrap).
By allowing conceptual "business" state to guard the
transitions, and then allowing both standard and partner specific definition
of those states, we could truly extend the BPSS to be "business process" and
not just "message exchange choreography".
John
-----Original Message-----
From:
Boonserm (Serm) Kulvatunyou [mailto:serm@nist.gov]
Sent: Thursday, November 06, 2003 6:44 PM
To:
ebxml-bp@lists.oasis-open.org
Subject: Re: [ebxml-bp]
BPSS executability and where it ends
I have a comment here that I would like to hear
comments.
I think I totally understand the role of BPSS in the B2B
Collaboration and its functionality and scope as Monica quoted from the
charter makes a total sense to me. However, when I came to think again about
this scope against the ebXML vision of dynamically composing, configuring, and
execution of the collaboration, the expressiveness of BPSS alone may not
sufficiently facilitate that. If the two parties have no way of seeing and
dynamically aligning/agreeing with some underlying business logic (which will
likely be not apparent in the BPSS), I think such vision will not be
realizable. Parties agreeing on the same BPSS only agree on the format and
data (not taking into account infra level) to be exchanged and not the
behaviors associated with the data. I am not sure if I took the ebXML vision
too further away. I understand that some dynamic configuration alignment can
happen up to some level like MSH.
Taking a PO example. Even if a PO biz process says that it is
the exchange of ProcessPO and AckPO, there can be a lot of other underlining
agreement to be done off-line. Like if your shipment has more than 5% scrap, I
will return. Will anything like BPEL, etc support this or is there some way to
engineer this into the BPSS as of now?
Comments?
-serm
----- Original Message -----
From:
"Jussi Lemmetty" <jussi.lemmetty@republica.fi>
To: "Monica J. Martin" <Monica.Martin@Sun.COM>
Cc: <ebxml-bp@lists.oasis-open.org>
Sent:
Tuesday, November 04, 2003 3:09 PM
Subject: RE:
[ebxml-bp] BPSS executability and where it ends
Monica,
I wasn't completely clear expressing what I meant with BPSS
describing 'one side'. How I was trying to visualize the BPSS-configured layer
was that it acts as a curtain between organizations stage and backstage. BPSS
describes what happens on the (visible to partners) stage. Whatever is bound
to the curtains backstage, is not necessarily visible to others. Since BPSS is
shared among partners and they might have different runtime-systems, any
binding-information (which might be partner-specific) should be in separate
definition instance.
I hope this clarified what I had in mind. I was probably
thinking the deployment-time too much when writing :)
Jussi
-----Original Message-----
From:
Monica J. Martin [mailto:Monica.Martin@Sun.COM]
Sent: 4. marraskuuta 2003 16:58
To:
Jussi Lemmetty
Cc:
ebxml-bp@lists.oasis-open.org
Subject: Re: [ebxml-bp]
BPSS executability and where it ends
Jussi Lemmetty wrote:
>Hi,
>
>I'm yet another one to agree on the executability of BPSS, meaning
that
BPSS-instance should contain enough information
to be deployable without excessive configuration-phase.
>
>What comes to the definitions of
process/transaction binding to
>back-end
systems, it's getting quite case/implementation/technology
dependant.
>
>During the
first teleconference, I mentioned having done something with
BPSS and agents (one kind of approach to execution).
>Here's a link:
>http://www.kanetti.fi/~juslem/docs/Bridging%20the%20gap.pdf
>
>My point is, that there are
several ways in practice to produce the
>runtime
for the BPSS (as expressed already
here on the list), so clarification to the boundaries of executability is
something I'm eager to see agreed upon. How I see it, BPSS is deployable
configuration describing one side of the organizations public process and
specifications that are defining the binding to back-end systems should be
considered/recommended but not anchored.
>
>
mm1:
Jussi, typically BPSS describes the shared view of both parties, not just one
party. This is in contrast to lower level views from one party's perspective
such as described in WS-BPEL. If you look at your charter and previous
specification versions:
"The ebXML Business Process Specification Schema provides for
the nominal set of specification elements necessary to specify a collaboration
between business partners, and to provide configuration parameters for the
partners' runtime systems in order to execute that collaboration between a set
of e-business software components." (ebBPSS, v1.05).
Bindings may be within our scope as defined in the charter,
although the first primary focus is the specification itself (The bindings may
be expressed in white papers or other position documents).
"The ebBP TC may identify bindings to support the business
process instance and ultimately the run-time execution. A binding (map) could
enable other executable process mechanisms to drive enterprise applications
where ebBP controls (rather than create) service behavior."
I believe if we can first place boundaries that differentiate
computability and execution, we can lay the groundwork for future development.
Thanks.
>Cheers,
>Jussi
>
>--------------------------------------------
>Jussi Lemmetty
>Product Manager
>Republica Corp., R&D Labs
>Ohjelmakaari 1
>40500 Jyväskylä
>Finland
>E-mail:
jussi.lemmetty@republica.fi
>Tel. +358 (0)443 011
146
>http://www.republica.fi/
>http://www.x-fetch.com/
>
>