Common Protocols and Errors

[srh@us.ibm.com]

Architecture Team,
This is a post from the Registry group during model review.

My suggestion is that the ebXML Architecture incorporate StandardErrors and
(along with
the transport team) StandardBusinessProtocols.

Scott R. Hinkelman
IBM Austin
SWG Java Solutions
XML/Java Standards Architecture
Office: 512-823-8097 TL793-8097
Home: 512-930-5675
Cell: 512-940-0519
srh@us.ibm.com
Fax: 512-838-1074



---------------------- Forwarded by Scott Hinkelman/Austin/IBM on
03/17/2000 05:17 PM ---------------------------
Scott Hinkelman
03/17/2000 05:06 PM

To:   Yutaka Yoshida <Yutaka.Yoshida@eng.sun.com>
cc:   ebxml-regrep@lists.oasis-open.org
From: Scott Hinkelman/Austin/IBM@IBMUS
Subject:  Re: Model review time!  (Document link: Scott Hinkelman)

Yutaka,
 >+ We might want to separate the authentication process, or
 >  the authentication process for SO registering could be an inheritance
 >  of the regular authentication.

I agree that authentication sequence should/will be a [potentially
specialized] StandardProtocol in ebXML.
Further, the LoginError [I would suggest AuthenticationError] should be
common across ebXML.

I have brought up (and suggesting here) that we should include Versioned
and nonVersioned
StandardBusinessProtocols and StandardErrors defined in the ebXML overall
architecture.

Thanks,
Scott R. Hinkelman
IBM Austin
SWG Java Solutions
XML/Java Standards Architecture
Office: 512-823-8097 TL793-8097
Home: 512-930-5675
Cell: 512-940-0519
srh@us.ibm.com
Fax: 512-838-1074



Yutaka Yoshida <Yutaka.Yoshida@eng.sun.com> on 03/16/2000 02:16:18 PM

Please respond to Yutaka Yoshida <Yutaka.Yoshida@eng.sun.com>

To:   ebxml-regrep@lists.oasis-open.org
cc:
Subject:  Re: Model review time!




Scott, thanks a lot for this.

 > From: "Nieman, Scott" <Scott.Nieman@NorstanConsulting.com>
 >
 > 1) determining if people can actually view via the web the model

 I had to download the zipped one because the online version had
 an applet which my browser didn't allow to run due to a security reason.
 I don't know what's wrong with it, though.

 > 2) helping review and complete the model.
 >
 > Authentication Use Case
 > Authentication Workflow Activity Diagram

 + I like the following Terry's idea, but I'm not sure
   what kind of 'software screening' Scott and Terry are thinking of.
    || "Submit anything in any form" could be made to apply to related
    || data for something in one of the formats the registry is set up to
    || handle.  Then if the submission's "principal registered item" (see
    || attached) is in one of those formats the software check would pass
it.

 + We might want to separate the authentication process, or
   the authentication process for SO registering could be an inheritance
   of the regular authentication.

 + The actor "ebXML-Compliant Business Application" says "may interface
   with a repository...". Is it not suppose to interface with registry?

 >
 > Register Submitting Organization Workflow

 + Probably, SO needs to view the status of registration.
 + Needs a start point for RA. The current start could be used for
   both SO and RA, but it needs another diverging point in that case.
   Maybe all RAs' actions in this diagram can be put into "Authorize
   Submitting Organization" Workflow because when I think about the
   sequence diagram and the collaboration diagram, SO registering
   workflow and RA authentication workflow could be ubiquitous.

 General question:
   Most of the workflows do not look like business-specific procedures,
   but do like regular flows. Do we really need to describe non-
   business specific flows in detail?
   Or, are we trying to figure out what and where the critical
   point is to satisfy business requirements?

yuta