Service-Oriented Architecture

In any SOA integration project, inability to differentiate between these two entirely different categories of requirements leads to confusion and a sub optimal design. Key points to understand here is that logging is a key capability in detecting and resolving problems in any IT infrastructure and each SOA product supports extensive and configurable logging features in their own way. In SOA, the challenge lies in creating a centralized logging solution that can save the effort of mining plethora of logs created in variety of formats by different systems. There are various approaches to deal with this problem. These are few here:

• In the first approach all these different types of logs can be consolidated to produce a single view. A log mining software creates a more structured and centralized view of application logs for further processing e.g. alerting or reporting. This approach is more appropriate for after-the-fact monitoring and alerting purposes.

   

• In SOA platforms where separation of concerns is a key principle, it makes a lot of sense to have a centralized service responsible for logging information or events important to business. Other applications and services can use this service for business related logging or auditing. This service can be defined based on the business needs for auditing.

   

• Similarly, logging technically important diagnostics events to a similar central Logging Service would be only possible if all the systems agree on a uniform event format and interface.  This variation of monitoring approach is to generate application monitoring and logging events from different systems and applications in a uniformly defined format that can be processed by other applications and systems. In the SOA world there is more promise than this. WSDM ( Web Services Distributed Management) standard actually extends this idea  to create a management framework for distributed management of web services.