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

["David RR Webber" <david@drrw.info>]

Dick,

Great summary.

Your scenario is very close to the AutoTech scenario in many
aspects. ( http://drrw.net/visualscripts/#ebxml )

Looking at that JPG picture of the BPSS - you can see that
there are various roles being done - dealership, manufacturer,
par suppliers, shippers.

As I mentioned before - each participant needs to only see
their own discreet role and set of actions.

I'd proposed that we could solve this using include (aka links out)
references to associated processes that occur on the partners
system - but which the individual partners do not necessarily
get access - unless the originator wants to publish that detail.
We also as part of this multi-party BPSS need a "main" driver
thread - and then "supporting" threads - again the AutoTech
scenario shows this.

So each participant gets their own descreet "set" of actions,
steps and process flow that is self-contained - but when
included into the overall master choreography - also works.
Similarly you can build the master picture - and then export
out the sub-BPSS definitions.

We just need to set down examples of how this
associative system works.  We have
faced the same issues in the OASIS CAM work with
sub-assemblies and "include" v "import".  What we're talking
about here is essentially creating an "import" facilitity for BPSS,
and the notion that there is a "main" controlling process,
completion of which drives the subordinate processes.  A
simple 80:20 approach for this is what is needed first off
(obviously this can get very flashy with all kinds of signalling
and intra-process interaction - but IMHO - simple wins -
i.e. actions such as Synchronize (waits for something), Join
(closes branch and merges) and Terminate (return done)
are more than enough for the basics).

On the WSDL front - I'm seeing three go-forwards there.

1) We allow BPSS to directly call a WSDL defined service,
     and provide a model for that and how a BPSS requires
    inputs/outputs.  So long as the service conforms to the model,
    it will then work correctly.
2) We leverage the fact that ebMS team are working on supporting
     WSDL and therefore you can access a service via a ebMS
     intermediary.
3) We figure out what WSDL needs to extend and support its
     capabilities natively to be more B2B friendly and get those
     added to the W3C issues list (this seems like it would be
     a joint effort with ebMS and other teams).

DW

----- Original Message ----- 
From: "Dick Brooks" <dick@tech-comm.com>
To: <ebxml-bp@lists.oasis-open.org>; <serm@nist.gov>
Sent: Saturday, November 08, 2003 2:40 PM
Subject: RE: [ebxml-bp] BPSS executability and where it ends


> Serm's conclusions and observations are in line with my own, with regard
to
> what is/is not achievable using BPSS.
>
> I present the actual business cases I'm working on to describe what I
> believe BPSS needs to provide, in order to be beneficial (to me).
>
> First, I'll provide some background about my project areas, this will be
> followed by a description of the Service Oriented Architecture being
> developed in these project areas and lastly I describe the "missing
pieces"
> which BPSS may be able to fill, some day.
>
> Background:
>
> Electric markets around the world are deregulating. Utility companies are
> being split into separate legal entities and information exchange which
was
> department-to-department within a utility are transformed into
> business-to-business information exchanges. In addition, new competitors
are
> entering these markets. A "standard" B2B infrastructure is needed to
> facilitate the "new market". Certain "functions" (e.g. scheduling capacity
> of transmission system resources, balancing power generation with demand,
> etc.) remain regulated and these functions are performed by a central
> "Transmission Authority" (TA). The TA must provide "services" to all
market
> participants on a fair and equal basis.
>
> Architecture:
>
> The role of a centralized TA is ideally suited for a Service Oriented
> Architecture B2B infrastructure.
>
> In one sense the TA is managing an auction site where power generators
> submit "offers" to sell power
> and power purchases are made each half hour. All parties are notified of
> auction results on the half hour and specific generators are given
operating
> instructions for the period.
>
> A service oriented architecture lets the central Transmission Authority
> "publish" services that are available to all market participants. Each
> service is described in terms of:
> -  its "Service" and "Action" values (used within the ebXML header message
> within ebMS when invoking the service)
> -  the input required to perform the service (e.g. required Manifest
> contents - described as XML Schema documents)
> -  the output produced by the service (e.g. described as an ebXML message
> with Service and Action values that will be returned, along with output
data
> described using XML Schema).
>
> For example, the "Offer to Sell Power" service provided to Market
> Participants by the Central TA might be described generically as follows:
>
> <serviceDescription>Offer to Sell Power
> <Entry-point-url>http://.../URI-to-ebMSH
> <Message-Exchange-Pattern synchronous=true
> delivery-ack-requested=true>Request-Response
>
> <request-service>PowerSales
> <request-action>OffertoSell
> <request-payload-required>http://.../OffertoSell.xsd
>
> <response-service>PowerSales
> <response-action>ResultsofOffertoSell
> <response-payload-provided>http://.../ResultsofOffertoSell.xsd
>
> At a cursory level, this is all the information needed to describe the
> EXTERNAL interface of services available to market participants by a TA.
> The details of how a service is implemented by the TA is not necessary for
a
> market participant to invoke a service and indeed the TA may consider the
> "processing steps" to be sensitive information that it does not wish to
> disclose.
>
> On the other hand the TA will want to maintain a detailed "choreography"
of
> the steps performed within each service. This is the "executable" business
> process the TA performs whenever a service is invoked. Likewise a market
> participant may have their own "choreography" associated with a service,
> which they do not wish to disclose to a TA when invoking a service.
>
> Missing Pieces:
>
> The ebXML Message Service clearly provides the facilities to implement a
> service oriented architecture and is the prescribed solution for secure,
> reliable implementation.
>
> WSDL appears to provide the means to describe the "external interface" of
a
> service, but it appears deficient in its support for ebXML MS.
>
> BPSS appears to provide a description of a business process but contains
> "too much" information, that may be considered sensitive, or perhaps
> irrelevant given the individual nature of "internal" business processes of
> each trading party.
>
> What "I need" is:
> 1.  a standard "external service description" which contains the minimal
> information needed to invoke a service from an external source
> AND
> 2. a flexible means to describe and implement the steps associated with
each
> service, ideally this description would be "executable" by a "workflow
> engine".
>
> At this time, I don't believe BPSS or WSDL meet my needs, but I am
> participating in both efforts in the hope that this will be rectified.
>
> Sincerely,
>
> Dick Brooks
> B2B Integration and Cyber Security Consultant
> http://www.tech-comm.com/dbc
> Mobile:602-684-1484
> eFax:240-352-0714
>
> -----Original Message-----
> From: Boonserm (Serm) Kulvatunyou [mailto:serm@nist.gov]
> Sent: Thursday, November 06, 2003 9: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/
> >
> >
>
>
>
>
>
>