Re: Is it a facade


H. S. Lahman wrote:
> Responding to Sanjay...
>
> > The classes inside the Audit Module under consideration is building
> > this Audit record.
>
> OK, so the Audit Module itself may be a subsystem requiring several
> objects from different classes to build the audit records.

Yes

>
> Normally an original audit record is pretty simple and is easily
> formatted into a DB update query of file record write. So I am getting
> the impression that this auditing system of yours is not a typical
> financial auditing system. (Or the processing here is some sort of
> second tier consistency analysis of the audit records vs. actual
> transaction records.)
>

Its not a financial system, its a very simple request, response
analyser, performance / access monitor. Reports are more like which
page was a popular request, how much time of the total server response
time did that page take, repeat / unique visitors coming into the site,
user agent details to list few .

> > I guess I didnot complete my problem, the audit record is not for the
> > clients. They are used by the Audit Module under consideration to
> > generate reports.
>
> Hmmm. In you situation requires multiple objects to /build/ the audit
> records. The records are then stored persistently. At some point --
> presumably later -- the audit records are used to create reports.
> Generating reports usually requires a suite of objects that abstract the
> invariants of reports (e.g., Heading, Page, Paragraph, Table, etc.).
>
> All this complexity suggests to me that building the audit records and
> creating reports from them are two quite different subject matters.
> Their separation in time also suggests this (i.e., the context for each
> activity is different, probably with different clients). So that
> suggests to me that the report generation also wants to be encapsulated
> in its own subsystem. Then we would have a system view that looked
> something like:
>
> [Auditing Client] [Reporting Client]
> | |
> | |
> V V
> [Audit Record Creation] [Report Generation]
> | |
> | |
> +-----------> [DB Access] <------+
>
> where the arrows indicate flows of requirements in client/service
> relationships.

Didnt take you long to picture. :)

>
> > The clients systems help the Audit module under consideration to build
> > an Audit record.
>
> You will have to put more words around this also. In particular, what
> do you mean by 'help'?

Implcitly the module may build an Audit record for every request,
besides it would also need some contextual information from the client
systems, if let us say an e-commerce or a marketing product then either
the item the user is interested in or the campaign information can be
published by the clients respectively.


>
> I would expect that other subsystems just generate events when they do
> certain processing and those events are directed to the Audit Record
> Creation subsystem. But all the processing of the event would be in the
> Audit Record Creation subsystem.

Oh, there could be events also, like login, logout, registration,
client entity creation like ( Order, Carts, ...)

>
> [Isolating audit processing from the processing that's being monitored
> is a pretty fundamental security issue. An auditing system may access
> other data persisted by the other subsystems to check consistency with
> the event data packet and whatnot but they are unlikely to directly
> access the other subsystems because that would provide too much
> information about how the audit records are created and the audit
> process itself. IOW, the auditors want to make it difficult for the
> developers maintaining the other subsystems to "cook" the audit records.]

Yeah that is correct, I feel that more than the security (since the
client system has already compromised for auditing), its the
handshaking (never know where to look up to make sense). Can think of
exposing interface which finally the client subsystems can implement,
but can be debated.

>
> > These API's are interfaces for the client system to build the Audit
> > records.
>
> Hmmm. I'm still missing something. More and more I am getting the
> impression you aren't doing financial auditing here. B-)

No I am not.

>
> Usually auditing is event-based. The event data packet contains the
> necessary information to describe what happened in the source system
> (e.g., a Deposit transaction in banking software). So the only
> interface the clients need is a single event message of {event ID, <data
> packet>}. They would need to understand how to form the data packet for
> each event, but once the event is formed the API is pretty simple to
> "push" it.

Yes, event based. But can think of some more API's like
API to let the audit module know if clients want to track this user
request.
API may be to set and get the current session user's choice on being
tracked in audit.
I can never complete the list unless I get the whole functionality
listed.
Can we assume few more API's just for the heck of it.

>
> > Do you still see any concerns here, I am unable to understand your
> > concerns.
>
> Any time one sees an XxxxManager class name the odds are very good that
> it is a god object designed to coordinate (sequence) collaborations
> among other objects. Such classes are essentially higher level nodes in
> a functional decomposition tree. Since OO collaborations are supposed
> to be peer-to-peer, that is a Major No-No in OOA/D. IOW, there should
> be no middleman objects sequencing collaborations. So such a name is
> like waving a red flag to a reviewer.
>
> [There are situations where an entity in the problem space actually has
> exactly such coordination responsibilities. However, those situations
> tend to be rare so one would still have to justify that it exists with
> the reviewer.]

I got your concern now.

When I think more about this problem, I feel there are different types
of applications that we are trying to audit. When I say types, I mean
The building of Audit record is different for an application that could
be an
1. in house application , which could have out-of-the-box
implementation.
Here the audit is created in a step by step process.
Hence different set of API's for clients to build the audit.
Probably I made a mistake by saying Manager just because it
provides set of interfaces. It should probably be a ConcreteBuilder

2. an external application, which could uptake auditing through a
different implementation.
Here the audit is created in one shot.

Sanjay

.

Relevant Pages

  • [PATCH] Light-weight Auditing Framework
    ... as the ability to audit system calls, ... void do_syscall_trace ... int fastcall path_lookup ... +/* The audit_buffer is used when formatting an audit record. ...
    (Linux-Kernel)
  • Re: question about column types and lengths
    ... each table and create and audit record for each insert update delete. ... know all the different collength values. ... when generating an insert the sid doesn't need quotes ...
    (comp.databases.informix)
  • RE: CBO Selection utilizing the same table
    ... Use the IDAudit and the New "AuditVersion" as a composite primary key. ... the IDAudit and Audit Version. ... To use the combo to look up an audit record, ... a date range and a client among other fields. ...
    (microsoft.public.access.forms)
  • Re: Audit Explanations
    ... Subject: Audit Explanations ... > explains, tells, deciphers what the text in a typical audit record means. ...
    (Focus-SUN)
  • UPDATE: Missing South Carolina/Hilton Head Couple
    ... police questioned him in the disappearance of two wealthy clients had ... An audit ordered by The Club Group found that chief financial officer Dennis ... Police have said Gerwing, 54, was the last person to see the Calverts. ...
    (alt.true-crime)