RE: Public Review of Specification Schema v0.90 and proposal for simplified design patterns.

[John Yunker <JohnY@EDIFECS.COM>]

Title:

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

johny@edifecs.com

(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