Re: [ebxml-bp] Considerations for v20

["David RR Webber" <david@drrw.info>]

Nagahashi,

With reference to usage cases, the overarching
purpose that I see is these items:

1) Industry communities can publish catalogues of
    standard business process definitions for use
    by their members.

 2) Members can take these standard definitions
     and easily apply their localization context parameters
     to these so they can quickly and easily use them to
     manage ebXML processes in tandem with CPA and
     ebMS.  This applies at both the large enterprise level
     with multi-partner collaborations as well as simple
     partner collaborations.

 3) Members can customize these business process templates
     by extending them to include linkage to webservice and other
     internal application systems via WSDL linkages that
     conform to the BPSS WSDL method (eg. can include
     performing some steps as BPEL executions).

 4) Member can further customize transaction handling details
     using either OASIS CAM templates, or their own inhouse
     transaction handling tools to propagate better information
     alignment across their industry.

 5) Members can easily build their own business process
     definitions in business terms without needing highly
     specialized IT skills.

I think we can collect our usage cases that are already showing
these items.

Thanks, DW

----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: <nagahashi@fla.fujitsu.com>
Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
Sent: Thursday, November 20, 2003 12:07 PM
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
>
>