Re: [ebxml-bp] Considerations for v20

["Monica J. Martin" <Monica.Martin@Sun.COM>]

>Nagahashi: 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.
>  
>
mm1: We will definitely be gathering use cases, which I have started to 
ask for with a proposed simple format (ERCOT-utility, non-profit, IV&I, 
STAR, etc).
I've also started other discussions with other standards organizations 
informally to ask for use cases. I'll add this to our issue related to 
generation.
Kenji, I would ask you craft more of a proposed work item related to 
monitoring. I've distributed the key items that would be a part of Work 
Item (see WorkItem draft process uploaded under Documents on ebBP OASIS 
site.

We look forward to more detail from you.

>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.
>
+1

>* 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.
>
+1