Re: [ebxml-bp] Considerations for v20

[nagahashi@fla.fujitsu.com]

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> 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