Re: [ebxml-bp] BPSS executability and where it ends

["Boonserm \(Serm\) Kulvatunyou" <serm@nist.gov>]

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/
>
>