Re: [ebxml-bp] Considerations for v20

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

nagahashi@fla.fujitsu.com wrote:

>Monica and all,
>
>I'm so sorry, I naively believed that uses cases being gathered are 
>business process samples, not for what people do with business processes 
>described in BPSS.
>
>Roberts posted almost the same experience I've observed. I'll post my 
>own ideas.
>
>Kenji
>
mm1: I think it is both. First gives us insight into what BPSS can do 
for business collaboration, and what people do with what is described in 
BPSS can also be another venue to investigate new functionality as 
revisiting what already exists.

Two sides of the same coin.

>
>"Monica J. Martin" <Monica.Martin@sun.com> wroteF
>  
>
>>>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
>>
>
>  
>