cular log that is issued when a trunk in a trunk group goes down, occurs over a time of one week, and generating a log or triggering a mail to network administrator at the end of one week showing those trunks in the trunk group going down more often than the others. Next we have service oriented architecture. In SOA, data and functionality are exposed as reusable services described using a standards based format. A ser- vice refers to a modular, self-sufficient piece that performs a specific functionality expressed in abstract terms independent of the underlying implementation. Using SOA in NMS would involve developing the function blocks in management func- tion components as independent services. Event rule engine and reporting engine are two example functional blocks in an SOA-based NMS framework that can act as independent services. Consider the event engine in SOA. The event engine in this scenario will col- lect data from other functional blocks on fault, performance, security, or from data collection components, but it will always collect data in a specific format. This way the event engine works as an independent service that performs a set of actions based on rules, but can interwork with any module/service as it collects data and defines rules only in a specific format. Now consider the case of a reporting engine that exports data to certain standard formats like a pdf, doc, or html page. When a reporting engine is implemented to operate as a service in SOA, it can be used to create reports for multiple functional blocks. The same reporting engine will then generate a pdf document listing active logs from fault module or a doc on the graphical representation of the network. 11.10 Conclusion Most books on network management discuss the NMS functions, standards, and protocols without giving a clear picture of the implementation perspective on how NMS architecture looks. This level of information is usually available in research publications created by developers who actually work on designing and coding t