[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] Considerations for v20
>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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]