Re: [ebxml-bp] BPSS evolution

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

Title: Message

I strongly agree with Dick here.  We need to stay GENERIC. 

 

I do not want to see us specifically bound to CAF, ws-chor,

WSDL, REM, MEM, or whatever flavour is here next week!

 

I believe implementers are looking for a clean simple approach that is

business user friendly and does not require major amounts of

programming knowledge.

 

That is the legacy we have been passed.  BPSS can be expressed

in terms that business users readily grasp.

 

We need to continue to extend that model - so they can build

sophisticated exchange models easily.

 

Beyond that - the programmers will figure out how to tie that into

the specific lowlevel syntax - as my work with BPEL is showing.

And we can provide some reference renderings to help steer them.

 

All we need to ensure is that the key aspects of the flow control

are represented and available.  Things like the OAG Autotech scenarios

are extremely valuable in allowing us to understand how to model

realworld usage cases and make sure that BPSS can handle

the interchange control.

 

DW.

----- Original Message -----

From: Dick Brooks

To: ebxml-bp@lists.oasis-open.org

Sent: Monday, November 03, 2003 12:41 PM

Subject: RE: [ebxml-bp] BPSS evolution

IMHO, BPSS will be beneficial if it provides:

 

1. An intuitive *external* interface definition for each service/action pair (e.g. what a trading partner needs to invoke a service/action)

    This should include input/output parameter definitions, transport binding options (e.g. HTTP, SMTP) and possible responses.

    Ideally the external interface definition would align with WSDL, however this may not be practical for several reasons.

 

2. An intuitive *internal* definition of a workflow associated with each service/action pair (e.g. what the "system" needs to execute a business process).

   The internal  definition adheres to the interface contract defined in the external interface definition in 1.

   The internal definition is *not* accessible to external parties because it may contain sensitive information.

 

3. A graphical modeling approach that enables implementers to describe the internal and external definitions in 1 and 2 for each service/action pair

 

This is all that's needed as a starting point, IMO.

 

4. Going forward BPSS could describe more complex processes that involve multiple service/action interactions.

 

Dick Brooks
B2B Integration and Cyber Security Consultant
http://www.tech-comm.com/dbc
Mobile:602-684-1484
eFax:240-352-0714
I'm in Ireland from November 3-26 on business and am not reachable by mobile phone. Email is best.