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

["Jussi Lemmetty" <jussi.lemmetty@republica.fi>]

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