In-Depth

Managing Web services

• By Tony Baer
• March 21, 2003

For Providence Health System, a Seattle-based company serving four West Coast states, the goal was to cultivate customer loyalty with new online services ranging from personal health-care management to appointments and billings. Doing so would require integrating applications and data sources from numerous internal systems, and enhancing the user experience with personal health applications from WellMed Inc., a third-party service provider recently acquired by WebMD.

But the solution required a complex interplay of messages. When a customer uses one of the WellMed personal health applications, an exchange of Simple Object Access Protocol (SOAP) messages covering service, authorization and user profile requests would bounce back and forth behind the scenes.

Although the transactions are straightforward, and do not involve any of the remote discovery functions often associated with Web services, managing them proved to be a serious challenge. For obvious reasons, security tops the list. As the site evolves, factors such as version control and performance will loom larger. For example, once a particular service is upgraded, how will that impact the preferences and options available to existing customers? And as more customers request more services, generating more SOAP messages, will system response times be maintained?

Traditionally, these challenges have been handled within an application, source-code version control or an enterprise systems management framework. But when the functionality -- or service -- in question spans multiple systems or applications, a new approach is necessary.

"While we could use [BMC] Patrol to monitor log files and threads, we needed something else to provide a higher-level view of the actual service," said Regin. Providence currently uses the Web Services Management System (WSMS) from Infravio Inc., Redwood City, Calif., to perform functions such as brokering SOAP requests and managing the life cycle of Web services components.

The dilemma, according to Ron Schmelzer, senior analyst at ZapThink LLC, a Waltham, Mass.-based analyst firm specializing in XML and Web services, is that all the problems occur outside of the applications from which they were spawned.

"My system may be working and so is yours, but the service still might not work," he said. Such headaches may sound familiar to veterans of electronic data interchange (EDI) systems, which required intricate handshakes arranged in advance. But with Web services, the trick is that all handshakes are supposed to occur on the fly.

Managing such a dynamic environment is likely to prove far more complex compared to handling conventional transaction applications. But there is a bright side. "There is a lot more detailed information sitting in those XML headers that should be easy to grab," explained Corey Ferengul, vice president, service management strategies at Meta Group Inc., headquartered in Stamford, Conn.

From a management standpoint, a SOAP message header could provide an extremely fat target for management tools, specifying who is requesting the service, what service is being requested, how quickly the service must be provided and, for commercial situations, how much the requestor is willing to pay for such a service. In turn, the Web Services Definition Language (WSDL) headers designed for interrogation by SOAP messages could be probed by management tools as well. Furthermore, on the horizon, new standards covering security assertion, workflows, message, delivery and routing could offer additional opportunities for systems management probes.

If Web services live up to the advanced hype, managing these parameters will become necessities, not luxuries. Of course, like any young technology, the issues of what to manage and how to manage it have yet to crystallize. "The initial part of the problem is that there is no standard data model or format for universal inspection," said Ferengul.

What's different this time?

Narrowly defined, the goal of systems management has been to protect the health and performance of servers, networks, databases and applications. Existing systems management tools and frameworks offer monitoring consoles, problem notification and, in some cases, automated resolution.

Although the Holy Grail of systems management has been to equate systems health with business health, in reality, commercial products have stuck to tracking low-level performance and utilization parameters such as I/O, application threading, database response times, capacity utilization, load profiling, software distribution and failover. In most cases, security was often managed separately.

Can such an abstract feeds-and-speeds approach apply to Web services? It depends. "The goals for managing Web services-based applications are similar to traditional applications," noted Scott Garvey, director of XML Web services marketing at Microsoft. "What's changed is that the definition of the application has expanded to include more loosely coupled connections."

For example, you could deploy a Web service as a simple RPC between known parties and systems. "That's very similar to logging on to a Web site and performing a conventional database transaction," noted Amit Jesuja, vice president for product management at Netegrity Inc., Waltham, Mass. Under such a hard-wired transaction scenario, traditional systems management approaches should prove ample -- although the verbose nature of XML-based messaging might demand closer attention to performance and capacity utilization.

But Web services can also be other things. For example, if the service involves any form of dynamic discovery or third-party intermediary, traditional management approaches will fall short. "There will be control issues that weren't present with traditional distributed application models," noted Andy Astor, vice president, enterprise Web services at webMethods Inc., Fairfax, Va.

For many observers, security tops the list. Compared to traditional Web applications, where transaction requests are typically separate from the login process, SOAP messages automate the process with a declarative approach that exposes the identity of the requestor, the service request itself, as well as the methods by which the message is encrypted and the sender and request are authenticated.

Security issues grow more complex if intermediaries become involved in the Web service. For example, if the Web service is encrypted using public and private keys, could the public keys become misplaced as the service request and response passes through intermediaries? What about the integrity of the message itself?

"Web services may require inspecting the messages at application level to ensure that they are well formed and authorized," noted John Hanger, senior vice president of sales and marketing at Flamenco Networks, Alpharetta, Ga.

Furthermore, while it may prove impossible to control third-party services or networks, service providers may nonetheless be contractually bound to meet service-level agreements. At a minimum, they might have to benchmark the performance of external providers as part of quality-of-service (QoS) guarantees.

Other factors adding to the fun are the challenges of version control and dynamic discovery.

"There is no analog for this in conventional applications," noted Indu Kodukula, director of business development at BEA Systems Inc. Furthermore, added Rich Petersen, vice president, product marketing at Infravio, multiple versions of a Web service could exist side-by-side, with different iterations available to various portions of the customer base. "That introduces life-cycle management issues," he said.

Standards anyone?

In an ideal world, all the elements of a system, from hardware devices to software components or agents, would have standard interfaces that could be read by management tools to track performance.

But for now, most of the discussions on management standards have focused on more modest goals, according to Ed Horst, vice president of marketing at AmberPoint Inc., Oakland, Calif.

"The early forms of management discussion have tended to center more on, 'How do I use Web services to share management information?' as opposed to 'How do I manage Web services?,'" he said. For instance, webMethods and Hewlett-Packard have jointly proposed Open Management Interface (OMI), as a means of using SOAP messages to communicate data on the interdependency of application components to management frameworks such as HP OpenView.

A key hurdle is the spotty track record of systems management standards. "In systems management, the only standard that has worked has been SNMP," said the Meta Group's Ferengul. According to Ferengul, SNMP's success was attributable to its lowest common denominator nature, which left ample room for proprietary extensions.

Not that the standards community has not tried to reach higher up the stack. For instance, initiatives such as the Application Response Model (ARM) and the Desktop Management Taskforce's Web-Based Event Management (WBEM) and Common Information Model (CIM) have been formally approved. However, a key hurdle for these approaches was that they were too closely bound to the application layer, an area where vendors have traditionally been highly protective.

"The need to compile APIs to executables has made it hard to develop common information models," maintained Ferengul.

To date, the most successful high-level initiative has been Java Management Extensions (JMX), an optional add-on to J2SE, which provides a standard set of APIs, management "bean" components and notification mechanisms that enable Java platforms to be instrumented by systems management frameworks. This is the example that Web standards groups would like to emulate.

Observers, such as Rajiv Gupta, are more bullish about management standards possibilities on this go-round. "The difference is that the far interoperability is stronger in the Web services environment than it was with client/server," said Gupta, who is CEO and founder of Confluent Software, Sunnyvale, Calif.

Added Eric Newcomer, CTO at Iona Technologies, Waltham. Mass., "We already have the basic architecture in place," he said, noting that, because Web services messages are not executable files themselves, it might be more practical to attach management descriptors without the usual controversy.

But consensus does not yet exist on where to place all those management hooks. For instance, while Meta Group's Ferengul believes that UDDI, the Web services registry, would be the logical place to specify management descriptors, competing ideas such as Sun's WS-Reliability would graft ebXML-like management hooks to SOAP headers.

Of course, the lack of consensus has not stopped the wish lists. For example, IBM has implemented a Common Event Format based on the CIM model in its Web services toolkit, and is considering submitting the technology to standards bodies such as OASIS.

Other suggestions center on standardizing error codes and quality of service. "Today, vendors have to work with customers individually to define their own interim codes," noted Jill Huntington-Lee, vice president of marketing at Quantiva, Princeton, N.J.

"Quality of service has been a hot topic, taking up almost an entire 90-minute conference call," recalled Iona Technologies' Newcomer with regard to a recent W3C Architecture Group discussion. A related idea, suggested Toufic Boubez, CTO at Layer 7 Technologies, Vancouver, B.C., would cover specifying policy models that define parameters such as the recent XACML standard just ratified by OASIS.

"This is still very early in the discussion," said Bob Sutor, director of Web services technology at IBM, noting that management is the final piece of the core Web services technology stack. "It will probably be six months before we have a roadmap."

What is interesting is that the very nature of Web services may, in the long run, blur the distinction between application development and systems management. Theoretically, Web services is supposed to deconstruct what we currently consider to be software applications into modular, self-declaring service requests that invoke systems-oriented concerns such as security or QoS, plus application life cycle-focused disciplines such as versioning.

Conceivably, emerging Web services standards might force developers to embed systems management tags into Web services. Or scenarios, such as version control, could drive system administrators to deal with application life-cycle issues. ZapThink's Schmelzer offered the following scenario. "A revision in a Web service may trigger an analysis of component or service dependencies, ranging from who's entitled to the new version of the service to the impacts on documents, databases and the parties it touches." The result, he said, could have a pronounced impact on how fast the service provider responds to incoming requests.

"Change management will have a direct impact on performance management," he concluded.

And, added BEA Software's Kodukula, it may prod developers to pay new attention to the operational part of the application life cycle.

"Traditionally, when applications were ready for production, the developer turned it over to the production team, and operations took ownership of everything," Kodukula recounted. "With Web services, developers will have to get more involved in the production phase.

Please read the associated story "A management framework" by Tony Baer.

For more XML news, go to ADT XML Page.