OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC