RE: Model review time!

["Nieman, Scott" <Scott.Nieman@NorstanConsulting.com>]

Yuta, I am now just getting to the detail of you email and you raise very
good points.  My comments are below in <Scott></Scott> tags.  thank you very
much for your review.

Scott



-----Original Message-----
From: Yutaka Yoshida [mailto:Yutaka.Yoshida@eng.sun.com]
Sent: Thursday, March 16, 2000 2:16 PM
To: ebxml-regrep@lists.oasis-open.org
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.

<Scott>The point of this was that the ebXML Business Process project team
was going to give us a checklist of required items in a submission, and the
software could verify if the items in the checklist were present.  This is
their definition of the "metamodel".  So if the submission was in a format
that we could analysis (e.g., XMI - if that works for us), we could parse
it, and verify its integrity.</Scott>

 + We might want to separate the authentication process, or
   the authentication process for SO registering could be an inheritance
   of the regular authentication. 
 
<Scott>This was addressed in a separate thread.  Packages have been added to
the model referencing ebXML Architecture Security Services and ebXML
Architecture Messaging Services.</Scott>

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

<Scott>Corrected.  Thanks.</Scott>

 > 
 > 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.

<Scott>A couple points here:  
1) I created a <<Logical>> Registration package in the Domain Package
Diagram that now has a Registration Use Case diagram.  The <<Logical>>
stereotype will reflect the human interface and the <<Physical>> stereotype
will represent the workflow engine or basically the component API.
Therefore, the use cases in the <<Logical>> will <<use>> the <<Physical>>
use cases.   The <<Physical>> implementation of the start point for the RA
could be to move the registratoin request to the RA inbox and that would
happen in the background.  The <<Logical>> implementation would have the RA
look at his inbox to view etc.

I do not have a problem changing the <<Logical>> stereotype to <<GUI>> or
something more clear, and likewise with <<Physical>> to <<API>>.  

2)The N090 methodology is similar to the RosettaNet UML profile in that the
"actions" on an Activity in an activity diagram will be an operation in the
component interface, possibly in a one-to-one relationship.  A operation on
a component interface is realized by a collaboration of objects.  We first
represent this as a number of sequence diagrams; one main path and a number
of exception paths.  We can then combine the sequence diagrams into one
collaboration diagram which represents the realization of that operation
with traceability back to the activity in the activity diagram.  To model
the activity diagram as a sequence diagram itself would be very cluttered
and is not encouraged.

</Scott>

 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?
<Scott>
Correct. The workflows that we have today are software specific, and less on
the GUI.  As discussed above, the needs to be separation between the two to
show the business-specific process, and the physical realization.  We need
both perspectives.  
</Scott>


yuta