New teams required for Web services management -- ADTmag

New teams required for Web services management

By Tony Baer
June 30, 2003

Could the meek really be inheriting the earth? If you are a systems administrator dealing with Web services for the first time, that could well be your impression. According to a recent report by research firm Meta Group, Web services could impact how systems administrators manage their transaction environments, forcing them to look not from the top down, but from the bottom up.

When it comes to managing Web services, none of the established vendors has yet stepped up to the plate to explain its vision. For now, companies wishing to go beyond the prototyping of Web services must either depend on service providers or a series of start-up vendors with their own broker or agent technologies.

Enterprise systems management tools have traditionally been aimed at the big picture, checking the health of a system or application by monitoring the big “choke points”: servers, databases, storage arrays and network devices. Better-known management frameworks, such as HP OpenView, IBM Tivoli and CA Unicenter, typically monitored and, in some cases, predicted and automatically resolved problems that occurred when there was too much contention over these resources.

In transaction processing environments, databases merited special attention because they were considered to be the most fragile link in the chain. This is where providers such as BMC gained fame, providing tools to manage every aspect of database performance -- optimizing I/O, SQL statements, physical placement in storage arrays and media, and other parameters.

Security was important, but since applications were largely static -- assuming a well-defined user base and set of transactions -- static gateways were typically created that were enforced by the application, database or standalone tools employed by the data center administrator. Although critical, security was traditionally not considered a direct function of keeping systems humming.

Getting the little picture

According to Corey Ferengul, a senior program director at Meta Group, Web services could change the equation, requiring a view of performance from the standpoint of individual transactions or processes as they discover their way through a nested maze of network devices, middleware, databases and servers. In a way, this would mimic the odyssey of IP messages wending their way across the Internet, because the paths for IP messages and Web services transactions are not necessarily charted in advance but “discovered” at runtime. In the case of IP messages, it is traffic conditions that dictate the path; for Web services, it may be a combination of congestion levels and business rules that govern if, when and how a service request is to be fulfilled.

Consequently, transaction-based views would not replace the need for Web services to monitor the health of the usual big-ticket items, but would supplement them. Specifically, while infrastructure utilization provides the overall context, factors such as message routing and prioritization, method compliance, security policy compliance, service availability, utilization and delivery acknowledgement would provide more precise gauges of the health and proper deployment of particular services.

Unlike conventional apps, Web services management may bring in other players beyond systems administrators. For instance, because different groups of customers or business partners might be entitled to different versions of a service, development staff may have to become involved. Additionally, with Web services automating processes formerly performed by humans, anything that impacts service levels might end up concerning not only DBAs or systems administrators, but line-of-business professionals responsible for managing specific business or trading partner contractual relationships.

It could be argued, therefore, that traditional management products geared toward system administrators, network managers or DBAs might not necessarily provide meaningful pictures to developers or business process owners.

The answer to this question may well determine whether conventional frameworks and methods of systems management could be adequate for Web services. The answer probably depends on how Web services are actually deployed.

If a Web service were dropped into an existing application or set of apps simply to replace a messaging component, the only change would be the internal messaging interface. In that event, service “requestors” and “endpoints” might replace an app message, but the identities of users and systems would remain pre-defined. From a management standpoint, managing Web services would be no different than conventional apps relying on familiar technologies such as IBM MQSeries messaging or EAI brokers.

However, if an organization deploys Web services as part of a full-blown “Services-Oriented Architecture,” all bets are off. Under this scenario, SOAP messages would communicate service requests, dynamically searching and discovering services that are subsequently deployed, all without human intervention. The identity of requestors and the services would not be reset but determined at runtime via rules-based processes.

Consequently, from a systems management perspective, the consumption of resources could grow far less predictable. Using traditional approaches that monitor parameters such as CPU utilization or database I/O would tell only part of the story when it comes to the health of the service environment.

To compound the situation, if the identity of requestors becomes similarly dynamic -- varying based on a set of rules that could depend on deployment rules for a particular service or on other factors such as traffic levels, customer qualifications or time of day -- the effectiveness of the security framework can also become a management concern. And if companies sell their Web services to other companies, or base the conduct of business processes on them, the health of the Web service may become a contract compliance issue. Although some framework providers have promoted the idea of connecting service levels to business metrics, such as charge back, until now existing frameworks have not succeeded in providing the types of dashboards with which a business process owner would feel comfortable.

First things first

The question of what technologies are available today for managing Web services may be akin to putting the cart before the horse, as few organizations have advanced beyond the pilot stage in their Web service projects. Consequently, most early adopters have relatively few Web services to manage. That message grew loud and clear at an XML One conference roundtable session last spring, where most attendees asked questions about what Web services are and how to use them, rather than how to manage them.

Compounding the uncertainty is the lack of a firm standards roadmap beyond the SOAP, WSDL and UDDI building blocks, or the existence of best practices to deploy Web services. But Web services are hardly unique here. Just about every major generational technology shift has undergone similar teething processes that have resolved themselves over time.

Today, managing Web services is still the domain of service providers or start-up vendors. For instance, providers such as Grand Central Communications, San Francisco, are offering managed trading environments for Web services, recalling the glory days of Electronic Data Interchange (EDI) hubs. Within the Grand Central environment, management parameters such as acknowledgement and fulfillment would be tracked completely.

Aside from service provider approaches, most of the current ideas rely on agents, probes, brokers or proxies to monitor and, in some cases, adjust parameters ranging from authorizations to component dependencies and code validation.

In general, the argument for brokers is that the technology is well established in the J2EE and Microsoft .NET worlds. Consequently, if a firm knows IBM WebSphere or Microsoft Windows Servers, they should be capable of getting up to speed with Web services brokering tools pretty readily. A drawback to brokers is that they introduce potential bottlenecks and single points of failure to environments likely to have numerous tiers.

The Web services broker camp includes established middleware players such as Actional Corp. and Iona Technologies -- which have extended their integration hubs to accommodate Web services -- and new names such as Infravio Inc., Confluent Software Inc. and Talking Blocks Inc. Products from these firms act as development and runtime environments that integrate authentication, authorization/access control, message logging and orchestration of Web services with life-cycle management functions such as versioning, change management and dependency control.

For instance, Actional Corp., Mountain View, Calif., uses proxies that play traffic cop to incoming SOAP messages. On the horizon, it also plans to add agents that would reside on app servers and provide higher-level views of an entire service network. Iona Technologies, Waltham, Mass., is focusing more on the development and deployment, rather than the management, of Web services.

San Francisco-based Talking Blocks Inc. provides security features aimed at managing authentication and access monitoring capabilities that log messages and provide the raw data for tracking utilization and generating alerts, as well as performance management features such as load balancing and routing. Infravio Inc., Redwood City, Calif., promotes its life-cycle management capabilities by providing several different views, including business objects, that provide a schema-based logical view; a business service that provides a mechanical view of how the message is transformed, transported and orchestrated; and an application model that focuses on brokering services. Confluent Software Inc., Sunnyvale, Calif., adds a “business activity” monitor that correlates performance data and exceptions with compliance to promised service levels.

Providers such as AmberPoint Inc., Flamenco Networks, Mindreef Inc. and Blue Titan Software Inc. provide distributed, probe-like approaches that “sniff” SOAP messages over the wire, but for different purposes. Mindreef Inc., Hollis, N.H., focuses more on developers by providing debugging abilities through viewers that display the content of SOAP messages or WSDL files as either raw XML or pseudocode -- stripping out the ubiquitous angle brackets and showing the remaining XML as plain English. To help with the debugging process, Mindreef’s tools trace SOAP messages to verify whether they execute properly.

AmberPoint, Flamenco and Blue Titan take more operations-oriented views. For instance, Oakland, Calif.-based AmberPoint Inc. tracks performance and transactions by type or business process, such as the number of orders or shipment requests processed, and response times for those requests. Proxies intercept incoming requests and accept and redirect them, while plug-ins run inside the application server.

Flamenco Networks, Alpharetta, Ga., emphasizes that its server is extremely compact, and that its distributed, federated approach is extremely scalable. Distributed proxies perform most of the heavy lifting, performing the usual traffic cop functions and logging the appropriate parameters regarding service levels and reliability. The Flamenco server can stand alone or reside as a plug-in with a J2EE or .NET server. Services can be monitored and coordinated by federating the distributed proxies on the fly.

San Francisco-based Blue Titan Software Inc., whose product was engineered to extend BEA WebLogic, takes a more specialized approach, focusing strictly at the network transport level to enforce service levels and thresholds for latency. Blue Titan stays out of higher-level concerns, such as versioning, life-cycle management or security.

According to Sam Boonin, Blue Titan’s vice president of marketing, that would add another layer of complexity and redundancy. “Everyone is dragging their portfolio products into Web services,” he said, noting, for example, that players like BEA are working on making the logical aspects of Web services manageable, while players such as IBM focus at the systems level. “We see this as a distributed networking problem that should be solved by distributed networking companies.”

Blue Titan’s products intercept SOAP messages on the wire, just before they hit devices such as routers, load balancers or storage area network (SAN) switches, inspecting SOAP headers to direct the message in the most appropriate fashion. It focuses on providing an audit trail, logging the ebb and flow of SOAP messages, and enforcing service level agreements at the transport level.

Missing in action?

Conspicuously absent so far are the players that one would normally associate with systems management. Over the next year, household names are likely to jump into the act; but for now, most are still holding their cards close to their chests. “We are not a company that likes to hop on a bandwagon,” admitted Richard Niku, product architect at BMC Software Inc., Houston. “We have products that do Web site analysis,” he said, adding, “many [other] companies have taken Web site analysis tools and called them ‘Web services.’”

Today, products such as Tivoli, Patrol, Unicenter and OpenView have agent technologies that can actively manage infrastructure elements and activate alerts and consoles that provide the big picture on services levels at the node level. Measuring traffic levels, response times, and the stops and starts of specific operations is already second nature for most of the brand-name framework tools. Currently, these tools do not probe inside a SOAP message or inspect its headers, but they can record end-to-end performance data about when messages are sent or received, and how long it takes to process them.

It would be logical for household names to extend their frameworks to more granular analysis of SOAP message consumption, the level of utilization of WSDL service definitions or other aspects of Web services deployment. The difference on this go-round, however, would be the need to correlate service levels with business processes, a Holy Grail that many enterprise framework vendors have preached in the past, but never met.

Conceivably, another obvious point for managing Web services might be at the app server in the Java world, or the OS for .NET. For instance, many middleware platform providers have consoles for configuring and monitoring code execution, clustering, transaction pooling, load balancing and failover. Yet players such as Microsoft have been conspicuously silent, while others have largely deferred to third parties.