John,
Thank you
for the thoughtful review and response to my proposal on the simplification of
the business transaction design patterns.
I would
like to clarify that the main purpose of my proposal is to consolidate the 4 business
transaction design patterns that include the responding document from 4 to 2
because there is no clear, testable, and easily “implement able” performance
control parameter in the section 4.4 of the N090 that differentiate 3 of the 4
design patterns.
I had a
different experience on the acceptance of the “Acknowledgment of Acceptance” by the RosettaNet community. The feedback that I’d heard from
the Supply Chain Partners (which were represented by the business users, and
not the Solution providers) on all the workshops was that they do not see a
value in the additional “separate Acknowledgment of Acceptance” signal. They saw it as an overhead action, which could not be
accomodated easily and is not used (or planned to be used) by their backend ERP
systems. They prefer to include
the “Acknowledgment of Acceptance” in the responding substantive document (just like you’d
mentioned at the end of your response and like I suggest in my document) and to
deal with the content non-compliance on the exception basis. This exception will be included in the responding
document and returned to the requester as soon as it is discovered. This feedback was expressed by Motorola,
Cisco, Bourns, Lucent and other Supply Chain partners on the RosettaNet
workshops.
I know
that at least one Solution Provider has a solution that can accommodate the “Acknowledgment
of Acceptance” parameter in their
first version of the software, and I suspect that there are others that could
support it as well. So, I
believe that the main reason of the elimination of this signal was the feedback
from the Supply Chain Partners expressed via the Solution Providers at the RNIF
2.0 development team. But this is
a moot point now.
In my proposal
I did include the “Acknowledgment of Acceptance” in the property values table for the design patterns with the
ability to override it. At the
same time I do question the necessity to have this as a separate performance control
parameter based on my experience. Here
is what I said in the section 4 of the document:
“Open issues for this
table:
a.
I left the Acknowledgement of Acceptance
parameter in, but would like to recommend to consider the removal of this
parameter, unless there are known existing scenarios that require the use of
this parameter.”
Similar concerns were
expressed by Kurt Kanaskie from Lucent.
See below.
From: Kanaskie, Kurt A (Kurt) [mailto:kkanaskie@lucent.com]
Sent: Friday, February 16, 2001 12:52 PM
Cc: ‘nlsm@chevron.com’
Subject: RE: Public Review of Specification Schema
v,0.90
For
the record,
Attached is my issues list with resolution
notes from the meeting this morning.
P.S. It was a real pleasure working with
everyone face to face.
<<Comments on ebXML Business Process
Specification Schema with
resolutions.doc>>
Kurt Kanaskie
Lucent Technologies
(610) 712-3096
Thanks for your input,
Larissa
Leybovich
Vitria
Technology
Supply
Chain Solutions
Irvine
949-857-4233
Cell
949-836-2545
Sunnyvale 408-212-2716
-----Original
Message-----
From: John Yunker
[mailto:JohnY@EDIFECS.COM]
Sent: Sunday, February 18, 2001
3:47 PM
To: ebxml-bp@lists.ebxml.org
Subject: RE: Public Review of
Specification Schema v0.90 and proposal for simp lified design patterns.
Larissa, BP Team,
I have reviewed the document submitted by
Larissa which uses RNIF 2.0 as a basis for removing elements from the UMM,
and I would like to clarify some of the representations, especially with
respect to RNIF 2.0.
I was a member of the RNIF 2.0 authoring team, as well as the Edifecs
consulting architect to RosettaNet from 12/99 to present. During the RNIF
2.0 sessions I functioned as the metamodel authority.
When the RNIF 2.0 implementation framework dropped the
acceptance signal, it was done from a technical implementation viewpoint, not
from a business modeling viewpoint. The objection to the acceptance
acknowledgement was that none of the EAI implemetors (which make up the bulk of
RNIF) supported it, nor had plans to support it immediately. Also, the
focus of the RNIF 2.0 team was to simplify implementation for application
integration in the near term, for the goal of widespread adoption.
The UMM is not an implementation
framework, it is a business collaboration modeling framework, and as such must be able to model business
operational collaborations, not just collaborations between business
services.
The acceptance signal is all about
facilitating optimized business decisions and partner alignment.
When companies integrate their operations
with their partners' operations, timing and accuracy become paramount.
Availability of materials within a supply chain is critical, and
the process to obtain those materials must be predictable and
efficient. Often business acceptance of an offer or instruction requires
coordination with manual or downstream processes, which may take some
time. While waiting for substantive
response the requestor is losing valuable time. The
responder can make the collaboration significantly more efficient by validating
the request for logical, technical,
and legal compliance before sending the request to a
downstream partner or employee for action. The expected response time for
this validation is significantly shorter than the expected time for a business
response. The requester can time out on the acceptance signal within a
few hours, allowing either resubmission or redirection of the request.
This allows the requester more certainty and higher levels of
optimization in his scheduling.
So, why can't the backend system just
respond quickly when a message is non-compliant? Two reasons: The
first reason is that the "B2B collaboration monitor" function is
waiting for the backend system as well, and will raise an exception only when substantive
response is overdue; the second reason is that many backend systems would not
respond for critical errors in content or format, thus constraining
notification to the monitor timeout; third (and most important)
reason is that one cannot know 100% of their business partners' validation
constraints, and so cannot perform a robust validation step before
submission. I would hope that my partner would validate the request
before sending it through for action and let me know in a timely manner if it
is not actionable. I would like to make business decisions based upon the
knowledge that they will do so.
It takes significant time to code changing
business rules and legal terms into backend systems, and those rules may be
dependent on previous transaction contents, which may be unavailable to a
backend system but are available to a gateway rules system. Our
collaboration modeling should allow for a rules system to verify acceptability
of the business transactions independent of the backend systems. As such we
must be able to model these interactions and their timing. We must allow
independent signals from these independent systems.
As business dependencies become more
complex, legal considerations and compiance with corporate terms and conditions
should be verified and negotiated before submission to
business systems both because of complexity of legal considerations and
specialization of business systems. (a point made very clear in James Bryce
Clark's presentation on legal implications)
The presence of the receipt and acceptance
signals allow the business activities
being modeled in the BOV to be exactly that: business activities. The
interactions between services for non-repudiation, authentication, and
compliance are removed from the business modeling, and left to implementation.
If we do not allow for an independent signal for compliance, then we in effect
place this into the business activity, which damages our ability to model and
constrain timing of the collaboration.
A robust
modeling methodology should be both simplified and extended when it
is mapped onto implementation specifications. Like UML on which it
is based, N90 should be subclassed, specialized, and extendeded for
particular uses. ebXML is all about wide adoptability of collaborative
business technical specifications. UMM is all about modeling
collaborative business processes. You should not constrain one because of
the other, but allow each to grow dependently within their domains.
Without the
acceptance signal we are modeling the collaboration of business services, with
the acceptance signal we can model and optimize the collaboration between
business operations.
It will be
easy for the ebXML process specification to state either:
1) The acceptance is by convention returned in the response
2) The acceptance is not used at this time
to allow
"simple implementation" of the specification by a wide group of
adoptors.
It will be
much more difficult to put it back into N90 when we find our ability to align
and optimize business operational processes constrained by the lack
of a signal accepting compliance with legal and business rules.
My 2
cents, (thank you for listening to those that made it this far!)
Thanks!
John
John
Yunker
Architect,
Enterprise Models
Edifecs
The DNA
of B2B
(425)-895-3026
-----Original Message-----
From: Larissa Leybovich [mailto:lleybovich@vitria.com]
Sent: Friday, February 16, 2001 2:09 PM
To: ebxml-bp@lists.ebxml.org
Subject: Public Review of Specification Schema v0.90 and proposal for
simp lified design patterns.
Please find attached my review of the current business transaction design
patterns and a proposal to simplify current classifications. This is my
action item from the f2f meeting on 1/17-1/19/01. This document was
submitted to the participants of the ebXML BP f2f meeting on
1/17/01-1/19/01, and now is distributed to the whole BP group per Karsten's
suggestion. It will be considered at the TMWG meeting next week in Dallas
while the revision of the N090 document takes place. Please note that
most
issues covered in this document were discovered by Clare Shemeta and I when
we worked as business process modelers on the RosettaNet project last year.
<<BusinessTransaction_patterns.doc>>
Larissa Leybovich
Vitria Technology
Supply Chain Solutions
Irvine 949-857-4233
Cell
949-836-2545
Sunnyvale 408-212-2716
-----Original Message-----
From: Karsten Riemer [mailto:Karsten.Riemer@east.sun.com]
Sent: Monday, February 05, 2001 9:13 PM
To: ebxml-bp@lists.ebxml.org;
ebxml-core@lists.ebxml.org
Subject: Public Review of
Specification Schema v,0.90
<< File: MozillaXML >> << File: XA.Document >>
Hi,
public review cycle #1 of Specification Schema v,0.90 started last Thursday
morning 2/1. It will conclude Wednesday night 2/14.
Please take some time to review this document which is part of the ebXML
infrastructure release, due to be adopted in April.
The document is at
http://ebxml.org/specdrafts/BPSpecificationSchemaV0.90.pdf
Starting at tomorrow's metamodel meeting we are building the list of issues
as
part of the public review. Please mail all issues to the BP list (or to
someone who can). Mark all e-mails with "Issue, SpecSchema v,0.90" so
we
don't
miss any of them.
Also, please classify your issues as "show-stopper" or "editorial".
Show-stopper means you will not vote to adopt the Specification Schema
without
resolution to that issue. Editorial means you would like the issue addressed
but can vote to adopt even if the issue is only partially addressed, or not
at
all.
At the Vancouver meeting we will have two sessions as part of the public
review. One will be a quick review of the content of the spec and an
in-person
chance to raise or expand on issues. The other will be Thursday 2/15, a
session to resolve as many of the issues as we can, so we can re-submit the
document to QR for the second review cycle.
To help interpret the document, we have made up a simpler XML example which
I
attach here. The example has a lot of comment lines that explain the use of
the DTD. The DTD itself is also attached, so you don't have to cut and paste
out of the document to view it in an XML viewer.
Looking forward receiving your issues,
thanks,
The BP/CC Metamodel Team