Content area
Full Text
SOA management suites give you iron control over operational policies
Managing a SOA isn't for the faint of heart. Services crop up like mushrooms and comprise multiple touch points (operations) that may require different policies based on the person or application using the service. Forget conventional methods of managing and monitoring Web resources-they can't offer visibility into the operation being executed within a service. Most are capable only of recording and monitoring URIs, and log-culling products simply cannot provide a transactional view of service use for your service-oriented architecture.
You need an application that can monitor services at the operation level, perform authentication and authorization, apply security policies that safeguard the privacy of data, conform to regulations such as HIPAA and Sarbanes-Oxley, and ensure availability of services using SLA management and enforcement. Oh, and it must also integrate into your existing architecture.
Traditional APM (application performance monitoring) models in the form of agents residing on enterprise service platforms, such as BEA Systems' WebLogic or IBM's WebSphere, don't fit the bill because they haven't evolved along with SOA. APM agents are focused on URIs and don't speak XML or SOAP, both must-haves to collect metrics and apply policies accurately based on XML-specific standards and best practices, such as encryption, data transfermation and monitoring at the operation level. They're also not proficient at enforcing policies that may modify requests and/or responses, nor can they perform authentication and authorization. Give 'em the boot.
Play Reveille for Me
If you're squirming because we just described your SOA management strategy, wake up and smell the mess hall coffee. Web services are not only not conventional Webbased resources, they aren't even always Web-based. Many Web services, especially those exposed by middleware, such as ESB (enterprise service bus) suites, are accessed using messaging protocols like JMS (Java Messaging Service) and not through HTTP, making life difficult for some SOA management products-and leaving many IT pros shaking their heads at the erroneous use of "Web services" to describe services within a SOA. JMS (Java Messaging Service) advocates are particularly irritated at the misnomer and plan to launch a counterstrike to rename all SOAP transports "messaging services." You heard it here first.
If you're serious about SOA, you need the right weaponry to...