SearchSOA.com has been able recently to speak with a few people in the SOA test world, and among those is Mamoon...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Yunus. Yunus, a long-time Web services expert, now heads Crosscheck Networks. [For more on Yunus, Crosscheck Networks, and its recent purchase of Forum Systems, go to ''Crosscheck Networks acquires XML gateway maker Forum Systems'.'
We asked Yunus to provide three tips for individuals looking to improve transaction monitoring in SOA or non-SOA settings.
Of course 'transaction monitoring' means different things to different people. That's true for SOA too! So, first, we will offer Yunus's comments on definitions. He naturally distinguishes modern end-to-end transaction monitoring from CICS!
''Strictly speaking, any application that has a re-usable operation that can be used by a variety of client applications is "service enabled" and therefore SOA-based, but for this discussion we can assume SOA to mean modern, Web services-based SOA. For non-Web services based deployments (non-SOA), I would break applications into two categories: Three-tiered client-server and mainframe applications that do not use the Web services stack, and monolithic, green-screen mainframe applications. Transaction monitoring for both categories are well contained and not distributed as in the case of a SOA deployment. Therefore transaction monitoring comprises features within the application components such as Database and Application Servers or CICS apps.''
''For deeper, code- or byte-level monitoring, usually in performed pre-production, a number of monitoring technologies, such as JMX, SNMP, and log-aggregators provide deep views into the business functions for byte-level instrumentation and monitoring. Code-level monitoring is rarely used during production, since it has a performance impact on applications.''
Some notes: Efficient watching of transactions is very much about locating the places to set the monitors, as Yunus indicates here. It is Yunus's contention that agent-based monitoring has drawbacks, especially in instrumenting existing systems. Without question, agent-advocates would challenge any view that agents are necessarily intrusive in such settings. For some people, no doubt, encryption is not a first-order issue while for Yunus, it clearly is. As is often the case, ''your mileage may vary.''
But without further fanfare, here are Yunus's three tips for understanding transaction monitoring:
Tip #1 - Identification of key monitoring points along the transaction path. Choose which ones are necessary for your transaction monitoring requirements based on the business questions that you require answered. For example, if you only need to know which external partner came in and whether their SLAs are being met, then your data capture point can simply be at the network edge, perhaps at an XML gateway. However, if you need end-to-end transaction monitoring, you'll need "data capture" points across the entire transaction flow.
Tip #2 - Make your monitoring as non-intrusive as possible. Choose technology based on your deployment scenario and life-cycle. If you are already in production, then deploying agent-based technology at every Java container or .NET server is highly intrusive. Touching production systems is the last thing a CTO wants to do, especially if business transactions are being processed. A company may lose revenue if it does not monitor, but it certainly will lose revenue if its production applications are off-line because agents need to be installed, enabled and regression tested. For such deployments, you may consider proxies such as XML gateways to capture and monitor transactions. Once the data is captured non-intrusively, it has to be consolidated and correlated to ascertain the state of the transaction across the SOA deployment.
Tip #3 - Strong decryption capabilities are important for monitoring SOA or non-SOA traffic. Business transactions are usually protected, if they are not they should be through encryption, signatures, identity management and service obfuscation. To monitor such protected transactions, the complimentary functions have to be performed: encrypted data has to be decrypted to monitor business transactions. Any transactional monitoring solution needs to have strong capabilities in unraveling the data to provided consolidated monitoring statistics. Protect you data, but also be prepared to deeply inspect the messages for comprehensive transaction monitoring.