Re: my due items

[Carol Burt <cburt@2ab.com>]

Konstantin,

Thanks.  I like having this kind of discussion in the introduction.  It
makes it clear what a HRAC client really needs to think about.  I've taken
your input and redrawn the picture to clearly indicate that the invocations
go thru the orb and to mark the scope of the application and hrac.  I also
renumbered your description to make those numbers match the numbers in the
diagram, but the spirit of the discussion is the same and you'll recognise
the re-arranged words I think.  I also agree that Outstanding issues should
go at the end of section 2 and have made that change.

Thanks for your input... 

Carol

At 03:20 PM 10/15/98 -0400, Konstantin Beznosov wrote:
>Carol,
>
>The following are my due items for the submission text:
>
>1. A sentence that introduces the issues in the section:
>
>"The problems described in this section are not yet addressed by the current
>submission. The submission team is intended to address some of them in the
>future revisions of the proposed specification"
>
>
>2. Additional wording in the section 2.1
>
>"In the proposed design, authorization logic is encapsulated into an external
>to the application authorization service. In order to perform an
>application-level access control, an application requires an authorization
>decision from such a service and enforces that decision. A simplified
schema is
>depicted in Figure 1 (file high-level-schema.jpg attached). The sequence
of the
>interaction, illustrated by Figure 1, is as follows:
>
>1. An application client invokes an operation on the interface provided by
> the target object. The invocation is translated by the ORB into a request
>message. This corresponds to step 1 in the figure.
>
>2. The target object's ORB receives the request and translates it into
>invocation of the appropriate operation on the target object.
>
>3. While processing the invocation, the target object requires an
authorization
> decision from the ADO by invoking a corresponding operation on the
object. The
>invocation, as in previous case, is translated to a request by the target
>object ORB. Step 2 in the figure.
>
>4. The request is translated back into invocation of the appropriate
operation
>on the ADO.
>
>5. The ADO completes the invocation and the reply is translated by the ORB
into
>return from the invocation performed in 3. This corresponds to step 3 in the
>figure.
>
>6. The target object, after receiving an authorization decision, enforces it.
>If access was granted by the ADO, the target object returns expected
results of
>the invocation. Otherwise, it either returns partial results or raises an
>exception. Step 4 in the figure.
>
>7. The client receives either results of the invocation or an exception.
>
>More detailed description of the design can be found in Section 2.5"
>
>
>
>3. Also, I'm browsing through the submission and find that section
"Outstanding
>Issues" would be better read if it was at the very end of section 2.
Comments?
>
>I think those two items are all what I'm supposed to provide by today. Carol,
>let me know if you want anything else from me or any help with the
submission.
>
>Konstantin
>
> 
_________________________________________________________
Carol Burt                                             2AB, Inc.
cburt@2ab.com                                     Integration Architects
205-621-7455                                        www.2ab.com
Member, OMG Architecture Board          OMG Domain Member

   --  integrating yesterday's systems with today's technology --
----------------
Broadcast message to hrac-rfp from Carol Burt <cburt@2ab.com>.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.