[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] Considerations for v20
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 "Monica J. Martin" <Monica.Martin@sun.com> wroteF > > >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]