RE: [ebxml-bp] Considerations for v20

[nagahashi@fla.fujitsu.com]

Hi All,

My +1 to Dale.

* First of all, and obviously, BPSS should be useful. BPSS should help
people do something useful with it.

So, one of my proposal is to collect use cases for BPSS itself (not
business process samples). The question is what we want to do with BPSS
and how. Monitoring? Implementation automation? Generate BPEL?
-- Is this already done before?

I see implementation automation as an important usage.
This is the direction RosettaNet Automated Enablement program is going
for SMEs and even for big companies and I envision BPSS can help
automate implementations of business processes. Business people can
design the business process with BPSS, and then implementation is (semi-)
automatically generated. It would be great for SMEs.

I'm pretty sure many of you have such use cases in mind and I suspect we
all have different ones. Point is that we agree on particular use case(s)
 and focus on the features necessary for the use cases.

One of my colleague applied BPSS to automate protocol monitoring. He has
done pretty well and BPSS is a good choice to do it, but some people
questioned practical value of such application, because back-end systems
themselves usually maintain states and perform checks for message
sequence. Hearing his experience, I felt BPSS should help implementing
something new - something required but not-yet-implemented. Vendors can
have ideas.

* I wish BPSS to be business level, not at message or RPC level. Let it
be a tool for business people. I believe BPSS is already doing well in
this sense as it encapsulates message exchange as BusinessTransaction.

Being "business level" doesn't mean being "abstract". We have to clearly
define (possibly with help from other specifications) binding down to
the message exchange. This is necessary to be useful. Dropping technical
details like use of XPath will leave BPSS abstract and non-interoperable.
Graphical tools can hide such technical details from users.

* BPSS can and should be aligned with business process design
methodology, but we don't need to borrow concepts from the particular
methodology. Ex. Choice Points could have most useful meaning under the
context of a methodology (sorry for using as example before full
understanding). IMO, BPSS does not describe how people make decisios. It
describes possible consequence of human decision and also how partner
can figure out the decision made by the other partner. Of course
Methodology concepts can have close relationship to this, but it is in
the different layer and there can be different concepts from different
methodologies.

Cheers,
Kenji

"Dale Moberg" <dmoberg@cyclonecommerce.com>����F
>
> the sidebar I would like bring about the following suggestions for
ebBP
> 2 considerations.
>
> * Focus on the "Business" side of the protocol and not so much on
> technical features such a XPath.
>
> Xpath is a technical choice to be used in a condition language (shell).
> Presumably the real semantics is found in the expressions referenced.
Or
> am I missing your point here? Perhaps you are calling for more
> illustrations of usage of condition languages?
>
> * Focus on finding support for "instrument of offer" rather than
better
> XML support.
>
> Anders, I am not familiar with the implications of the quoted phrase.
Is
> this intended to replace the idea of "Request" somehow? I hope that
> lower level concepts like MEP can be properly separated from higher
> business level categorizations of processes with varying intent,
> presuppositions, and effects. Illocutionary and perlocutionary aspects
> of utterances still can ride on acoustic waves, after all. I am all
for
> keeping layers clear, but in some ways, BPSS is relating how the
higher
> semantics cling to a (slightly abstracted) collaboration protocol
layer
> in carrying out their tasks. The focus must straddle both IMO.
>
> * Recognise that the target users are SME companies so adding
technical
> complexities that makes the protocol difficult to "understand" for
> business users and expensive to implement should be avoided.
>
> Will BPSS be something a SME ever sees? I doubt it. I hope we expect
to
> rely on GUI abstractions to protect the SME user from either the UMM/
UML
> or XML goo underneath. But simple is good as long as it is not overly
> simple :-) (apologies to Einstein)
>
> * Avoid adding or hardcode dependencies to new specifications unless
> there are
> real business values identified.
>
> Always a good idea.