RE: [ebxml-dev] Toolkits for BP Modelling

[Leanne Luger <leanne@zenaptix.com>]

Dear Scott

Our approach at zenAptix has been to let people use the UML tool they are
comfortable with, and then convert the XMI 1.0 (or higher) output to BPSS.
One of the analyst's tools that comes with our business process server is a
UML to BPSS converter.

I've attached a brief overview of Xeco, our business process server.

Regards
Leanne.

-----------------------------------------------------------------------
Leanne Luger
leanne@zenaptix.com
Tel: +27 (21) 882 8240
Fax: +27 (21) 882 8241
-----Original Message-----
From: Beach, Scott [mailto:Scott.Beach@goodrich.com]
Sent: Thursday, April 11, 2002 3:33 PM
To: 'ebxml-dev@lists.ebxml.org'
Subject: [ebxml-dev] Toolkits for BP Modelling


Hello all-

I'm curious as to what tools people have found useful for capturing Business
Processes in UML and exporting them to XML so they may be added to the
Registry/Repository.  The BP documentation makes mention of web-based forms
for entering business processes and tools for developing UML.  While I'm
familiar with the major UML toolkit providers, I'd love to know what
products you've found excel in ebXML-specific implementations so that our
organization can recommend and utilize the best solution.

-Scott Beach

-----Original Message-----
From: bhaugen [mailto:linkage@interaccess.com]
Sent: Monday, April 08, 2002 2:04 PM
To: Jean-Jacques Dubray; 'Nandini Ektare'
Cc: 'ebxml org'; 'Hayes, Brian'; 'Malu, Pallavi G'; 'LONJON Antoine'
Subject: Re: [ebxml-dev] <BinaryCollaboration> in eBPSS


From: Jean-Jacques Dubray
> You are raising an important issue, which I think can only be resolved
> if we either make the notification failure part of the business
> transaction protocol rather than a separate business transaction as it
> is today, or by making an explicit notification of success (either
with
> a separate business transaction, or as a timeout). I personally favor
> the former solution.

I think success can be discerned reliably from
the transaction protocol without a separate notification.
Failure could be more problematic, especially
where the last acknowledgment does not arrive
due to technical difficulties.

In RosettaNet, the precursor to the BPSS
transaction protocol, Notification of Failure
is a separate transaction that is required
in many PIPs (Partner Interface Processes).

My understanding is that RNet went over all
the design alternatives we may consider here,
and selected a separate-but-required transaction
because it may need to go via completely
different delivery mechanisms.

In other words, if the end state of the transaction
is not aligned properly because of a technical
failure on the last acknowledgment, another
notification using the same mechanism
will most likely fail, too.

-Bob Haugen

Attachment: XECOdatasheet.pdf
Description: Adobe PDF document