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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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


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


Jussi,

This is a VERY good point.  Even with a BPSS you may have three
sub-components or more, to ensure that a particular participant only sees
the view that makes sense to them.

Notice - using either of the OAG Autotech examples at :
http://drrw.net/visualscripts/#ebxml

Then the car dealership should only see their part of the BPSS - to the
manufacturer;
while the parts suppliers should only see their interface to the
manufacturer; and then
the manufacturer/integrater can see the complete BPSS.  We can achieve this
with a careful
use of #includes and by having CPPA definitions for each of the participants
that
then plug-in to appropriate subset.

Did I mention this usage case is one we need to address?!?

Thanks, DW.

p.s. Monica - it would be nice if we can have OAGIS officially submit the
usage case
to us - I've cc:d Dave Connelly and Tony Blazej, since the original
documentation to
the AutoTech scenario sits over on the OAGIS QuickPlace in various PDFs that
were part of the documentation used.

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





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