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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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


Subject: RE: BPSS strategic issue: transaction integrity


If I may jump into this thread,  The Open Applications
Group currently has over 60 Business Process Collaborations
defined in their UML model and has definite plans to adopt
the BPSS.

We plan to populate the BPSS with our process content and
we are working with some vendors now to support this.

I encourage that the BPSS support flexibility as we have found
many customers who are not willing to accept a "standard"
process defined by someone else.  By what we can tell, the
ebXML BPSS is flexible and therefore we and our constituency are
happy with it.

David Connelly

-----Original Message-----
From: Bob Haugen [mailto:linkage@interaccess.com]
Sent: Friday, April 13, 2001 9:02 AM
To: 'Welsh, David'; 'Larissa Leybovich'; 'ebXML-BP@llists.ebxml.org'
Subject: RE: BPSS strategic issue: transaction integrity


Larissa and Dave,

I'm happy to hear that Vitria does not hard code PIPs.
I'm really sorry if I implied differently.

I asked this question on the lists on Monday, and got no response
about Vitria at that time.  (Also called a bunch of people.) I do not
pretend that constitutes a scientific research program, and am
always ready to be proved wrong about anything.  At this point,
I am happy to say I was wrong, at least in respect to Vitria.

However, if I was totally wrong about the state of PIP implementations -
if most people don't hard-code them - then that is good news for ebXML.

What I was trying to find out was if ebXML is doing something so
different with interpreted XML for business processes that there
was not enough prior practice to make it realistic.  If there is
significant practice interpreting XML PIP processes then that makes
the ebXML transaction level very realistic, since it is so close to the PIP
transaction model.

Followup questions:

Larissa Leybovitch:
>I would like to comment that not all the RN PIP software is "hard-coded".
>Vitria's RN solution does NOT have any "PIP hard-coded" components.  Our
>software is based on the generic code (which does not have to be changed to
>each new PIP) that is parameter/table driven and is capable of interpreting
>the XML representations of business processes.

Excellent!

>Please adjust your research notes to reflect more accurately the state of
>the solution provider's progress.

I will.

Dave Welsh:
>I'm using Netfish and you're right, we have a super PIP editor.
>Maybe Bob's refering to something else.

My understand of Netfish's PIP editor from a phone conversation
is that you still need to define each PIP in their editor. Is code
generated, or is the process definition saved in XML and interpreted
at runtime?  Could you take PIP process definitions in XML from
some other source and run it in Netfish's PIP software?

Thank you all,
Bob Haugen

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org



[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