Logging Messages
Currently we are in the process of adopting EDRA in our software development process. In this process we are trying to map our own architectural requirements to EDRA functionality. For some of our requirements this means creating new EDRA handlers, or even creating new services (like the directory service described earlier). Today another requirement came up…
‘Within our systems it must be possible to monitor the complete flow of a message and all messages that are send as a result of this message’
… In our architecture we recognize 3 different kind of services: user interface services, business process services and business information services. These kind of services will be build as separate services according to the ‘EDRA specs’. So a user interface service (for example an ASP.NET page) is using the EDRA infrastructure to communicate with a business process service. This business process service is using the EDRA infrastructure to communicate with an business information service. All services in this example are completely separated from each other. This is a bit different from the Global Bank example (in my opinion) in which for example the process is implemented in a page controller in the front- end. In the Global Bank situation there is only 1 EDRA call to a service action (from user interface all the way to the business action). In our preferred way, there will be a least two EDRA calls, one from to the user interface to the business process service AND one from the business process service to the business information service.
Our logging requirement means that we would like to ‘see’ that the request message send from the user interface to the business process service “belongs” to the request message that is send from the business process service to the business information service.
At this moment I haven’t found the best solution for this requirement. These are my thoughts at the moment:
- Implement a new logging handler that simply logs the message in a database. I think we can use the logging handler of Global Bank as a starting point for this
- Define a set of default fields that are available on EVERY message that is send in the architecture. I am thinking of ‘timestamp’ and some sort of an ‘request id’
- If a message is send from the user interface service to the business process service, supply an ‘request id’ in the message. (this message is logged in the database by the log handler). In the business process service use the ‘request id’ in the message from the user interface to store in the ‘request id’ field of the message that is send to the business information service (also this message is logged in the database by the log handler)
- Now there is a way to ‘link’ (using the ‘request id’) the two log entries in the database to each other.
- Make some sort of overview that shows the relation between the different messages. Now it is possible to see that a call to service ‘A’ means that also messages are sent to service ‘B’ and ‘C’
Any better ideas? .... let me know!

3 Comments:
It might be useful to have a look at the design of the Enterprise Instrumentation Building block. It contains the functionality you are trying to design, but its current implementation only supports .NET Remoting.
Every message will have to carry a globally unique conversation ID. When receiving a message you could assign the conversation ID to the .NET CallContext. When creating a new message, you could initialise the Conversation ID of the new message to the value present in the CallContext, or - if the CallContext does not contain a value - create a new Conversation ID.
Gerke,
I think you are right. using the EIF appliction block is the logical choice for this kind of functionality.
Because, by default the EIF block only supports writing to eventlog, tracelog and WMI I decided to use the logging block in addition to EIF. The logging application block adds a 'SQLServer sink' to the sink collection that is supported by EIF.
For our situation, I think it is best to store the messages in a SQL Server database. This makes it possible to build some sort of monitor tool
that can be used by our system administrators to monitor the 'conversation' between the services in our arcitecture.
One thing to keep in mind is, the performance loss when writing to SQL server instead of writing to the eventlog for example.
Because EDRA also uses EIF and the logging application block this solution fits perfectly within the EDRA architecure.
Adding a 'conversation ID' as a default element in all the messages flowing through our architcture will be one of the necessary steps to support this logging feature.
EIF may or may not what you want to use, but it definitely worthwhile to have a look at how they designed the logging of conversation flow (nested invocations across distributed components).
Post a Comment
<< Home