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

[Jean-Jacques Dubray <jeanjadu@Attachmate.com>]

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

Dick:

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.

<JJ>I think that being able to transparently go from D2D to B2B is the ultimate test for a SOA and Web Services framework.</JJ>

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.

<JJ>
I have published a paper explaining how BPSS could be transformed to be able to deal with web service definitions (http://www.ebpml.org/ebpml.doc). I actually view it as two very different case, to have a web service that sit there to wait on a request to send a response, and have two web services that need to "collaborate" via a complex message interchange.

Actually, WSDL and BPSS have some things in comon but a different approach to deal with it.
WSDL describes an interface, so two parties needing to "collaborate" need each to have their own WSDL. Interestingly enough, these two WSDL are often mirrors of each other.

On the other hand, BPSS allow you define a neutral point of view of the exchange, yielding to a single view of the message exchange rather than two mirrored views. So in a collaboration: 2 WSDL + a choreography = 1 BPSS + 2 CPP + 1 CPA.

What plays in favor of ebXML is that the CPPs are often identical for a lot of BPSS and a CPA in itself is not more than a reference to 2 CPPs and a BPSS.

BPSS also avoids the need to separate document definitions and operations. They are lumpsummed together in the concept of BT which I think simplifies the overall definitions.

In your case, it is interesting to see that BPSS (in a multiparty capacity) should also allow you to specify the inner workings of the TA. The ability to include web service in the mix should help you also link the "units of work" that the TA implements to the whole process. Please remember that BPSS is not "executable" in the sense of orchestration (please see my presentation: http://www.ebpml.org/technoforum_2003_b_eng.ppt). BPSS runtime engine, i.e. the BSI is only allowed to "monitor" and the only thing that are "executed" are the generation of exception. In BPSS there is nothing that says, if you send me a PO and I respond with an AckPO then your BSI will send me an invoice. BPSS relies on internal services to generate that invoice and pass it back to the BSI for sending it.

BPSS works like a business process firewall in many ways. As such it is a critical element of security for B2B (specially DOS attacks) since it can very quickly (much more than any other architecture) figure out if an incoming message makes sense or not (sender, conversation id, structure of message, sequence of messages,...)

BPSS and BSI should be an essential part of your TA because it will garanty that everything happens according to plan. The TA services themselves should implement an orchestration engine.

</JJ>

Cheers,

JJ-

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