Re: first POC draft

[jacques durand <jacques@savvion.com>]

Hi all:

I have a few comments/questions on the draft (Karsten) POC demo proposal:

1. Looking into the demo scenario section, step 1 (UML Process definifion tool):
It is likely that the most common way for the user community
to generate metamodel-compliant BProcess  data inthe repository, is
by extraction/conversion of existing company models, rather than
brand new business model. (Indeed, for many companies, the problem is
how to publish already-deployed business processes.)
I suggest we keep these options open in the demo scenario...
From a practical point-of view, that can also make it easier for potential demoers
who already have business process products (modeling and engine)
that are not necessarily UML compliant (or rather, that do not
explicitly use ebXML meta-model terminology),
to participate: they just need to write a conversion/extraction tool.

2. The draft so far focuses on the new features around repository.
Step 12 is abstracting most of the "run-time" part .
I guess step 12 ( transport demo) is where reliable messaging will be demonstrated
too.
Also it seems that in a real scenario, "discovery" and registry querying
will  actually be quite interleaved with actual business transactions.
(steps 9+10+11+12 may reiterate for each trading pair, prior to their exchanges,
as the discovery is "through registry" is supposed to be quite dynamic...)

3.Regarding the repository interface, are there any more detailed specs available
on them? Or if not, some draft or existing implementation we could start from?
(Dale?) So that we can have an idea of what it takes to register BP data, and
how to extract.
I have been looking into the "Registry and Repository Part 1" specs,
but not found much more than some external reference (section 1.2)
alluding to generated XML interfaces. (I assume Part 2 or 3 will be more verbose
on this).

Regards,

Jacques Durand
Savvion







Nicholas Kassem wrote:

> Dear POCers,
>
> Please find attached a proposal which is still work-in-progress and I
> haven't  reviewed it but in the interest of time I'm forwarding to you (as
> is) for your review/consideration.
> Feel free to comment/question prior to our next conf. call.
>
> Regards,
> Nick
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Meeting notes for conf. call 8/24/2000
> ===========================
>
> - There was agreement that the Fujitsu proposal was sufficiently high-level
> that it was safe to use it as the seed document. This does not mean that we
> will not consider any other proposals - it just means we now have a
> starting point and we will build on this and refine the document.
>
> - There was agreement that we could manage and therefore have have at most
> one or possibly two controlling documents i.e. scenarios sanctioned by the
> ebXML executive.
>
> - There was agreement to create four sub-proposal teams. The goal is to
> have these teams pull together their respective parts of the proposal and
> then help pull together the overall document - each team will need to have
> a draft proposal out for review by the next conf call i.e. 9/7/00 at the
> latest. The leads are; Phillipe (TR&P), Dale (Reg/Rep), Mark (BP/CC). Steve
> will own pulling the whole document together. Thanks for volunteering folks.
>
> - Melanie gave a brief intro on the GCI work - It sounds like we should
> spend some cycles and understand the business message that could be crafted
> around GCI for possible inclusion in Tokyo - the IP status of GCI BP
> modelling work seems clear - the DTDs/Schema is copyrighted but is in the
> public domain - the only caveat is that this is still work in progress.
> Melanie will work with Steve and table the business scenario for review. I
> would like the high level message reviewed by the STC asap.
>
> - Agreed to send the word out and solicit input to any and all who would
> like to contribute to the POC - remember if it isn't backed by ebXML specs
> it's DOA.
>
> - Agreed to postpone the decision on the need for a f2f meeting - will
> revisit this later. Agreed to Shift the *possible* f2f meeting to 17->19 of
> October. Hatem (ipnet solutions) has volunteered to host the f2f if needed
> - he is in Southern Cal. - details on this later.
>
> Conf. Call participants (in no particular order)
> =================================
>
> Melanie <MKudela@uc-council.org>
> jacques durand <jacques@savvion.com> for ... Savvion & Fujitsu
> Farrukh Najmi <Farrukh.Najmi@east.sun.com>
> Joseph Baran <joebaran@extol.com>
> Philippe DeSmedt <PDeSmedt@viquity.com>
> Marc Breissinger <marcb@webmethods.com>
> Hatem ElSebaaly <hatem@ipnetsolutions.com>
> Chris Doyle <chris.doyle@tiecommerceusa.com>  for ...
> <joe.dalman@tiecommerceusa.com
> "Moberg, Dale" <Dale_Moberg@stercomm.com>
> Steven Yung <steven.yung@sun.com>
> <mark.hale@ajubasolutions.com>
>
> If I missed anyone or otherwise got the info wrong please post the correction.
>
> *Proposed* POC Milestones
> =====================
>
> Sub proposal drafts tabled (Philippe, Mark, Dale) -> 9/7/00
> POC Business message tabled (Steve/Melanie) -> 9/7/00
>
> Sub proposal final tabled (prop. leads) -> 9/21/00
> List of "interested" participants tabled (Nick) -> 9/21/00
>
> POC Proposal tabled (Steve/Melanie) -> 9/28/00
> List of *Committed* participants tabled (Nick) -> 9/28/00
>
> POC Proposal final (WG) -> 10/12/00
> Technical/logistical review (All) -> f2f , 10/17/00
>
> Target for pre-Tokyo Integration testing (All) -> 10/26/00
>
> Note that I would like to do most of the work up-front this time so that
> those who wish to participate in the Tokyo WGs can do so. We should
> review/refine this dates as we move forward.
>
> Apologies
> =======
> I inadvertently left out Krishna Sankar (Cisco) from my earlier list of
> interested parties for the Tokyo POC. Moral of the story is that you are
> only as good as your last meeting attendance ;-)
>
>   ------------------------------------------------------------------------
>                                Name: ebXMLBPCCpocProposal.doc
>    ebXMLBPCCpocProposal.doc    Type: Microsoft Word Document (application/msword)
>                            Encoding: base64