Re: Is it a facade

Responding to Sanjay...

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 .

OK. Mapping one's own experience onto an incomplete requirements statement is a common problem in responding on these forums because it is difficult to summarize complex requirements in twenty-five words or less so there tends to be lots of blanks. B-)

This (and comments below) sounds like you are monitoring how a web POS order entry system is performing -- as opposed to figuring out if someone is ripping it off.

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 am making an assumption: the audit record being built is a pure data entity because it eventually gets stored in some kind of DB. If so, then to build the record all one needs is data. (One way to view performance monitoring systems is that they are data collection systems.)

Then I would expect that the Audit Record Creation subsystem establishes requirements for the information it needs to build a given record and then the interface defines a message that the client "pushes" containing the relevant information. (The client selects the right interface message given /its/ context.)

That, of course, gets tricky if the information it needs lives in multiple other subsystems. But that is the only situation where I would see your Audit Record Creation subsystem proactively going out and collaborating with other subsystems on a "pull" basis. However, I suspect one can get around it in a pure "push" fashion (see my discussion of an event-based approach at the end of the message).

In either case, the "help" the other subsystems are providing seems to be limited to data (rather than behavior).

[Note that subsystems can be viewed as having responsibilities just like objects. (Some even view subsystems as "objects on steroids".) So a subsystem might have a responsibility for knowing, say, a customer-based discount. The fact that in response to a request it computes that value on the fly from other data it has doesn't make it a behavior responsibility. IOW, conceptually the interface method is still just a knowledge getter.]


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.

I tend to be biased. B-) As a translationist, /all/ my behaviors are described in object state machines so all behavior communication is done with events -- even when the implementation context is not inherently asynchronous.

In your case, though, an event-based architecture seems particularly attractive. Monitoring performance is intrinsically about making a note whenever something happens. So generating an event to describe what happened _when it happens_ seems rather natural. That's especially true in a context that is inherently asynchronous like a multi-user web site.

This also gets back to the point I made above that performance monitoring is really just data collection. Providing data is ideally suited to pure message interfaces, of which events are the purest form. From there one can combine application partitioning into subsystems, data collection, and event-based processing into a general design paradigm.

For example, each subsystem does unique things that need to be monitored. But the view may be quite myopic in a particular subsystem (e.g., "I logged user Frumpkin into the site at 10:14 AM on ..."). That can easily be encoded into an event data packet with a unique event identifier. That would be a "push"-based approach. But that bundle of facts may only be useful when combined with other bundles of facts from other contexts. Thus some other subsystem needs to understand how various bundles of facts need to be combined.

So in an event-based architecture, each subsystem generates events containing its myopic view of what it contributed to the Grand Scheme Of Things while some central facility (e.g., Audit Record Creation) decodes those events and pairs them up in meaningful ways to create more useful data aggregates (e.g., audit records). However, for that to work one needs a consistent view of identity and, perhaps, some infrastructure for synchronization (e.g., time stamps embedded in the event data packets). Therein lie the real design issues.

I would probably think about a two-tier analysis. The Audit Record Creation subsystem would understand a suite of larger data structures that handled meaningful aggregations. It would then decode individual events and plug them into those data structures (i.e., write them to the DB with appropriate cross-referencing). Later some other subsystem would "walk" those data structures and do the analysis and reporting.

The point I ma pushing on here is that I see three distinct problems: collecting raw performance data locally, saving it in useful aggregates, and analyzing the aggregates. Collecting the performance data then becomes a highly localized activity that is always the same: generating and sending an event. The event ID and the data packets will be different for each context but the basic triggering and generation will look exactly the same everywhere. More important, creating the events only requires knowledge about the local context where something happens.

Saving the event data in useful data structures becomes a different design issue where one needs to abstract the invariants of performance monitoring and map that into identity and data relationships. That will depend on the specific sorts of performance that you need to monitor. IOW, one essentially needs a Data Model for the DB.

Naturally one needs to keep one eye on how the analysis needs to use the data when doing that. But if one is careful, then the analysis and reporting will be relatively trivial to do when one "walks" the stored data structures.

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.

I think the conceptual event-based approach above is ideally suited to this. In effect the events are generic "hooks" into the processing. Because they are quite generic (i.e., {event ID, address, <data packet>}) they should be relatively easy to incorporate into either context. By that I mean providing the "hooks" to generate the events is minimally invasive from the other software's perspective. A minimal amount of information that the local context is bound to have is collected and bundled in a very generic fashion.

Better yet, events completely decouple the data storage and analysis functions from the applications triggering the events. So you can use exactly the same audit record creation and analysis regardless of what sort of application is generating he events. That is, the events are the interface and the same events need to be generated in either situation.

[There is another benefit: parametric polymorphism. Since all we are manipulating is data and we already need identity to organize the data aggregates, we can define the identity mapping to data externally in configuration files. So if one gets really clever, one can define customized data aggregates and events that are tailored to specific applications _without touching the code_. You can build data structures and map event data packets based on the configuration data. (The category on Invariants and Parametric Polymorphism in my blog talks about this in detail.)]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • Re: Is it a facade
    ... > classes from the audit record? ... These API's are interfaces for the client system to build the Audit ... >> Now would this pattern be a facade pattern? ... > abstraction in another subsystem. ...
    (comp.object)
  • Re: Is it a facade
    ... then the interface defines a message that the client "pushes" containing ... dependant on a subsystem + the audit system is not really meant to ... with events -- even when the implementation context is not inherently ... Things while some central facility (e.g., Audit Record Creation) decodes ...
    (comp.object)
  • Re: Enumerating logicals
    ... Hoff, you and your employer may not approve of Lnmlookup, but it does exist! ... I've been using it in our main VMS app since 1996. ... My monitoring subsystem scans the logical name table for names ... Only the monitoring subsystem needs Lnmlookup, ...
    (comp.os.vms)
  • multithreading monitoring snmp
    ... snmp protocol. ... Now it functions correctly if I select one subsystem at once. ... to select another subsystem to monitor, while there is the monitoring ...
    (comp.lang.java.programmer)