perfectxml.com
 Basic Search  Advanced Search   
Topics Resources Free Library Software XML News About Us
  You are here: home »» Info Bank »» Articles » Web Services Application Support Saturday, 14 July 2007
 

Back to Articles Page      

        

Web Services Application Support: Managing the moving parts that are out of our control.

Author: Joe Labbe
Joe Labbe is CEO of Primordial, an IT consultancy that helps clients create and deploy Web services to improve processes, open new markets, and extend existing IT infrastructure.


No doubt, Web services is a giant leap forward towards achieving cross-enterprise application interoperability. Organizations across the board are taking stock of their core competencies and building service-based interfaces in the hopes of reducing operating costs or of unlocking latent value. But all is not joyous in Mudville as Web services consumers start to confront the realities of application support in a world where service components originate outside their enterprise.

There is something new here

Theoretically, embedding Web services in enterprise application software should present few new challenges for operations and support staff. Unfortunately, in practice, this is not true. While many organizations have learned how to support traditional component-based applications, the vast majority of these components came under the control of someone within the organization. Obviously in the Web services world, this is often not the case -- in fact, it's a big part of the value proposition. So while the appeal of embedding "black box services" into applications without regard to their underlying development or runtime platform is seductive to system architects and developers, potential support problems are causing a bit of angst among application support staff.

Three times the headache

Recently, a client described the following support problem. The company had decided to embed a Web service provided by a valuable business partner in three unrelated applications. Since the service provider adhered to the SOAP specification, integrating and invoking the service from within these three applications went relatively smoothly. After the applications were tested and deployed, they then became the responsibility of the client’s ASIS (Application Support and Infrastructure Services) team.

Since Web services was new to the company, it was not clear to the ASIS team that supporting applications containing embedded Web services should be handled differently from any other application they supported. They assumed changes to these applications would pass through the normal channels to which they’ve grown accustomed, and that deployments of new functionality would be controlled and orderly. Of course, this assumed all proposed system changes were subject to their company’s change management protocols. Unfortunately, this was not the case.

One Monday morning, all three applications were experiencing seemingly intermittent and unrelated performance problems. Since each of the three applications implemented the partner Web service with different user interfaces and served different macro functions, it was not clear to the support staff that the problems plaguing all three applications were, in reality, the fault of the same Web service. Based on the established escalation procedures, the application support staff created three high-priority trouble tickets and dispatched three separate resolution specialists. By the end of the day, all three specialists had isolated the problem, identified partner service as the problem source and spent a significant amount of time transacting with the partner representatives resolving the problem. The problem was further exacerbated by the fact that each resolution specialist dealt with a different support contact at the partner organization.

In the end, if the ASIS team had been aware that these three applications were relying on the same Web service and that the service was malfunctioning, one specialist could have resolved the issue instead of three. Further, both parties may have been able to correct the problem more quickly had all the resources been focusing on the same problem instead of three seemingly separate problems.

Corrective Action

Since this incident, the client has implemented a Web Services Demand Management (WSDM) solution that tracks not only the health of the Web services they consume, but also a list of the applications that depend on these services. Further, when the WSDM system detects a service failure, it routes a message to the company’s help desk software, letting it know which applications may be effected by the service fault. Such support alignment allows the support staff to allocate and target resolution resources properly and, equally importantly, to convey a sense of control.

Lessons learned

The purpose of this story is not to scare organizations away from embracing Web services. On the contrary, we firmly believe Web services will allow organizations to build better and smarter applications faster than ever before. The story should serve as a wake-up call that the rules governing application support need to change to accommodate applications that rely on embedded Web services.

As organizations increase their consumption of Web services, more and more of the code they support will be out of their control. Overall application health and welfare will depend both upon the performance of others and the consumer’s ability to put into place new change management tools and procedures (see the Primordial paper on Web Services Demand Management (WSDM), at http://www.primordial.com/primordial_wsdm.pdfExternal link (PDF) or in HTML format at http://www.perfectxml.com/articles/WebSvc/WSDM.asp).

Since the service components upon which our applications rely can spontaneously change, we need to implement management solutions that not only tell us how these services are performing but also which applications rely on a given service. The first step towards implementing orderly change management and support procedures in a services-based world is to thoroughly understand application exposures, service dependencies and usage patterns.




Note: This article is published with kind permission of Primordial.

About Primordial
Primordial is an ebusiness consultancy that helps Global 2000 companies conceive and execute Web services to evolve existing IT infrastructure and realize greater return on assets. Through process orchestration and application syndication, Primordial helps businesses achieve operating efficiencies and generate revenue opportunities throughout the value chain. Primordial is a member of the World Wide Web Consortium® (www.w3c.org), the non-aligned body that evaluates and adopts Web standards.

  

Back to Articles Page      

  Contact Us | E-mail Us | Site Guide | About PerfectXML | Advertise ©2004 perfectxml.com. All rights reserved. | Privacy