RE: [ebxml-dev] Toolkits for BP Modelling

[Jason Boledovich <jboledovich@silverstream.com>]

Scott,

Check out eXtend Composer from SilverStream if you are looking for EAI
integration server that runs on J2EE and it has a BPM, WSFL designer.

http://www.silverstream.com/Website/app/en_US/Composer#

Regards,

Jason Boledovich
SilverStream Software
Technical Account Manager
Office-310-318-6050
Cell-310-722-1684
jboledovich@silverstream.com
Join SilverStream CTO Steve Benfield for the "Web Services & J2EE: Dominate
it!" Online Seminar
and gain the skills you need to create, assemble, consume and deploy Web
Services.
Register Today! <http://www.silverstream.com/onlineseminars>








-----Original Message-----
From: Beach, Scott [mailto:Scott.Beach@goodrich.com]
Sent: Thursday, April 11, 2002 6:33 AM
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